Repository navigation
Bind rendered publications to one immutable blueprint snapshot #123
Description
Activity
Roadmap clarification after reviewing the frozen #70 implementation and the current open-PR board:
#73 is historical source material for this issue, not the branch that should be revived or merged. Its useful invariants and adversarial tests should be mined, but the successor implementation should start from current
mainand close #123 directly.The focused replacement should:
- capture one descriptor-bound blueprint generation before graph or page derivation;
- derive the complete page plan and
publication.jsonidentity from that generation; - stage and validate the complete output before touching the live site;
- commit the new site transactionally while retaining the old complete site on any pre-commit failure or source drift; and
- preserve and report an exact recovery generation when final-state or durability verification is uncertain.
Current
mainhas changed substantially since #73 and now includes the #95 snapshot primitives and newer render/dashboard contracts. Copying #73 wholesale would reintroduce stale architecture and unrelated code. A new focused PR should cite #73 for provenance, identify the specific tests/invariants it reuses, and use #123's acceptance criteria as the source of truth.
Problem
Rendering reads graph/pages before computing the final publication source revision. A blueprint edit during render can therefore label stale or mixed output with the current hash, defeating the dashboard's stale-publication check.
Draft #73 contains transactional publication work but is stale/conflicting and should be mined or restacked rather than merged wholesale.
Acceptance criteria
publication.jsonis derived from that exact snapshot.