Plan Page

Plan page

The user reads pages, not replies; the block's Plan pages rule says when to publish and what the reply holds. A subject is one thing the work changes, and it has one page. Its file, <plans>/topics/<slug>.md, holds the current state. Each plan that continues it is an iteration carrying only its delta. node .agents/pstack/plan-page.mjs <plan> renders the page from both into <plans>/artifacts/, a local copy that regenerates from the committed plan and subject files, which are the record. node .agents/pstack/plan-page.mjs --index renders every subject's page there and an index linking them. A published claude.ai page is where the user comments on one hand-back; it is not the record. sync-pstack ships that renderer and status.mjs into every project it manages.

Read references/shape.md before writing a plan or a subject file. It holds every file shape, the page order and the renderer's refusals.

Render

1. Pick the subject before writing the plan. Continue the subject whose thing the work changes. Start a new one only for a new thing that will be revisited. A one-off plan, such as a single fix or check, has no subject and keeps its own page. A stop with no plan yet, such as a review verdict or a close of work that wrote none, writes one now, either the iteration that later stops continue or a one-off plan.
2. Name the subject with Topic: <slug> under Status:, or through the first entry of the frontmatter list the project names in pageTopic.field, so list the scope that owns the change first. A plan whose list-named subject has no file yet keeps its own page until someone creates that file; the renderer refuses a Topic: line whose subject has no file until that file exists.
3. When a project playbook in .agents/playbooks/ writes the plan, name it with Playbook: <name> under Status:, so its page sections lead and its required sections apply. Otherwise leave the line out; the renderer refuses a name with no playbook file.
4. Walk Check's reading list before the first publish and after each revision, then run node .agents/pstack/plan-page.mjs <plan>. It refuses every shape it can check and names the fix. Fix the plan or the subject file, never the HTML.
5. At a close, write the plan's ## Close before rendering: what landed, the proof and its limits, the counts the block's Todo list and close rule requires, reversals and deviations first, and open work with owners.
6. Publish the printed file with the Artifact tool to the subject's Page: URL, or to the one-off plan's own, so the user can comment on it. The first publish writes Page: <url> under the subject file's title, or under a one-off plan's Status: line. When that link no longer opens, because the page was deleted or belongs to another account, publish a new page and replace the line. The block's Plan pages rule says what the reply holds and what a Codex session does instead.
7. After a subject page renders, run node .agents/pstack/plan-page.mjs --index, which renders every subject's page and the index locally. The index is never published.

Check

Run node .agents/pstack/plan-page.mjs <plan> --check. It runs every refusal and writes nothing. Then read the plan and its subject for what the renderer cannot judge:

• Each before fence is a real call site at the commit before the plan, and its after fence the same call in the checkout, or the planned call while the plan is unbuilt. Each fence names its path in a comment, with one sentence above the pair.
• While the plan is open, the subject file shows the state before it. That holds for a subject the plan created too.
• Every subject section the plan changes carries a Delta table keyed to the subject's rows. Otherwise the page marks the section unchanged.
• Main changes lists only non-public changes that alter how the code works.
• Status: is one short line: the state word, then what the plan waits on. Open items go in their own section, each with its owner and where it is tracked.

Repair

1. Copy each file to scratch before rewriting it, and keep the copy as the must-refuse fixture for any refusal that should have caught it.
2. Run Check and fix each finding at its source. A subject that shows a plan's delta while its steps are all closed and its proof done is a finished fold whose Status: was not flipped yet; flip it instead of restoring. For an early fold, restore the subject file to its state before the open plan from the plan's before fences and git show <base>:<path>, and move the delta into the plan.
3. Log one decision-log row for the repair.
4. A ledger record that binds the plan's bytes goes stale on the edit. Rebind it by the project's record rule.
5. Render and republish to the same URL.

Change

The renderer source is skills/sync-pstack/assets/pstack/plan-page.mjs in the dotai checkout, with status.mjs beside it. Its tests are the plan-page tests in skills/sync-pstack/scripts/sync-pstack.test.mjs. A section that only one project's plans write belongs in that project's playbook frontmatter, never in the renderer.

Run sync-pstack's Lesson mode, which owns the gates, the corpus rules and the delivery. This mode adds the renderer's specifics inside its steps:

1. In Lesson step 2, when another session holds uncommitted edits in the dotai checkout, edit in a detached worktree at origin/main instead, and rebase onto their commit before each panel round, each proof and the dotai commit.
2. In Lesson step 3, give each new refusal or behavior a test that fails on the old renderer for its named defect. A refusal that compares text gets one must-pass and one must-refuse case on each axis before any panel: case, indentation, spacing inside literals, punctuation-only lines, line order, partial overlap with another iteration and a missing section.
3. In Lesson step 4, copy each managed project's plans, subject files, hubs, .agents/pstack.json and playbooks to scratch once, for the old renderer, then cp -R that copy and apply the change's migration to it for the new one, and diff the two plan lists before any body. When the live trees hold no instance of a state a refusal gates, also replay subject files at past commits where an iteration was open, and the scratch copies Repair kept. Give a renderer that predates --check an adapter that exits before it writes. Run both over every plan, list each newly refused plan with its owner, then render every plan with both and diff the bodies, ignoring the Updated line.
4. Also in Lesson step 4, render one real plan in each mode the renderer branches on: a one-off plan, a subject with an open iteration and a subject with none. Use a scratch copy with its Status: flipped when no live subject is in a mode. Publish both versions for the owner to compare.

Playbook sections

A project playbook in .agents/playbooks/<name>.md names the review sections its plans write, as comma lists in its frontmatter beside extends and when:

yamlCopy code
page-lead: What other editors do, Layer and owner
page-pairs: Document shape
page-require: What other editors do

• page-lead sections render right after Public API, the leading plan's playbook first.
• page-pairs sections hold before and after pairs, like Public API.
• page-require sections must exist in the subject file or its open plan whenever the project's pageTopic.hub file exists for that subject.

When the leading plan names no playbook, every playbook's sections and requirements apply. The playbook, or the skill it names, defines what each section holds.