Keep the Plan and Progress Log out of merged work; journal the Iteration prompt; unify the window style

[JacobStephens2]

Problem Statement

Reviewing a Proposal today means reading the Plan and the Progress Log, but those same files ride the Proposal branch into the merge: the Seeding step commits them, each Iteration appends to them, and the proposal step pushes them. Once merged they sit on the base branch, where a later Seeding treats a leftover Progress Log as a Run record it must not overwrite — this already blocked dispatches once on another target's base branch. Failed Runs add a second wrinkle: a draft Proposal from a failed Run looks identical to one ready for review unless the Route says otherwise. Separately, the Iteration prompt — the actual words each fresh agent process reads — is a scratch file deleted at Iteration end, so no reviewer can ever see what the agent was told. And the window wears two visual identities (an editorial shell on accounts/decisions/auth pages, a terminal shell on the board and history), so the product reads as two sites.

Solution

Keep the Plan and Progress Log readable during review but guarantee they never reach the base branch: each Run ends with a cleanup commit removing them before the Proposal is pushed, with the evidence preserved in history and the narrative carried in comments. Failed Runs keep a draft Proposal as evidence but are always routed to the human with an explanatory issue comment, never to the review queue. The rendered Iteration prompt is journaled at Run start and shown in the window on the live card and in Run History for both roles. The whole window wears the single terminal identity, with clarity of information as the governing priority over any particular styling.

User Stories

1. As an Operator, I want the base branch to never contain a Plan or Progress Log from any Run, so that later Runs seed cleanly and the codebase carries no Run scaffolding.
2. As an Operator, I want draft Proposals to still carry review context (what the task was, what area was scoped, how it ended), so that I can judge work knowing how it was arrived at.
3. As an Operator, I want the Iteration narrative available from history and comments after the cleanup commit, so that removing the files from the branch tip costs me no evidence.
4. As an Operator, I want a failed Run to leave its draft Proposal in place as evidence, so that I can inspect what happened before retrying or giving up.
5. As an Operator, I want every failed Run to come with an issue comment naming what happened, so that I never have to open a Proposal to learn a Run failed.
6. As an Operator, I want failed Runs routed to the human and never to the review queue, so that nothing unverified waits in review.
7. As an Operator, I want retried Runs to continue the same branch with the earlier Progress Log kept aside, so that a retry never discards the first attempt's record.
8. As an Operator, I want to read the exact briefing each Run's Iterations received, so that I can tell whether a bad outcome came from bad instructions or bad execution.
9. As an Operator, I want the prompt visible while the Run is in flight and after it ends, so that live monitoring and post-hoc review use the same record.
10. As a Reader, I want to see the same prompt and contract record as an Admin, so that review is transparent without a privileged account.
11. As a Reader, I want route badges to keep their current meaning (green means reviewable, red means needs a human), so that the board stays glanceable.
12. As an Operator, I want one visual identity across the whole window — board, history, accounts, decisions, and auth pages — so that the product reads as one site.
13. As an Operator, I want clarity of information to outrank styling (hierarchy, readable prompt blocks, meaningful badges, no decoration competing with content), so that the window stays a working tool.
14. As an Operator, I want Iterations to keep working from the inlined checklist plus the named discipline skills, so that behavior is unchanged by this spec's display work.
15. As an Operator, I want a real unattended Run on a labeled task to serve as the live test of these changes, so that the behavior is proven outside the offline suite.

Implementation Decisions

• The Run gains a final cleanup step: after the last Iteration, the Plan, the Progress Log, and any kept-earlier log are removed in a Run-authored commit before the Proposal is pushed. The branch tip is always merge-clean; the files remain readable in the branch's history.
• The Proposal body is rewritten to match: it names the task reference, the Owning Area, the ending Bound, and the removal commit, and points at history plus comments instead of branch-tip files.
• The Run Notification (comment on the Proposal) and the Selector's Route comments (on the issue) become the narrative carriers after removal; existing failure/give-up/pending comments are extended only where they leave gaps.
• Failure routing itself is unchanged: a Run that reached its cap is judged on its Proposal's checks (green to review, red/pending/none to the human with a comment); a cut-short Run retries once on the same branch, then goes to the human with a comment. No third attempts.
• The scope rule is "nothing routed to review or merged contains the scaffolding files," not "nothing pushed contains them": draft Proposals from failed or in-review Runs may carry the files in history.
• The Iteration prompt is persisted once per Run at Run start (the first Iteration's rendering; later Iterations differ only in number) as a new payload in the Selector Journal, owned by the Journal's event vocabulary. The window renders the stored text and never reconstructs it from current scripts.
• The prompt record carries no credentials (task reference, file paths, checklist, completion promise), so both window roles may read it with no redaction.
• The window converges on the terminal identity on every human-viewed page including auth flows; the legacy editorial shell is removed after migration so there is a single source of truth. Clarity of information governs all presentation choices.
• No change to skill invocation: the user-invoked implementation skill stays user-invoked; Iterations keep the inlined checklist plus the three model-invoked discipline skills. Prompt wording may be strengthened only on evidence from a live Run.
• Seams: the offline Loop substitutes (scripted agent, scripted proposal surface, scripted task source), the Selector's pytest suite plus Journal event vocabulary, and the window's existing tests are the test seams. One new seam is proposed: the Journal prompt payload (a new payload on the existing vocabulary, not a new channel).

Testing Decisions

• Test external behavior, not implementation details: the Proposal's branch tip must not contain the scaffolding files; the Proposal body must reference history/comments; the Journal must hold the prompt text; the window must render stored (not reconstructed) text; every page must wear the single shell.
• Prior art: the Loop's offline suite driving the real entry points through scripted fakes (run/propose/seed coverage), the Selector's dispatch/outcome/notice tests, and the window's tests.
• New coverage follows the same shapes: a Loop test asserting the cleanup commit and merge-clean tip, a proposal-body test asserting the new pointers, a Journal test asserting the prompt payload, and a window test asserting stored-text rendering on the live card and in history.
• Live proof: one real unattended Run on the already-eligible labeled task (open, labeled, acceptance criteria present, blockers closed, no open Proposal; area defaulting to the title) after the instance-side preconditions (Target enrollment, operator allowlist, retry budget) are confirmed.

Out of Scope

• Flipping the implementation skill to model-invoked or forking skill frontmatter for the Loop.
• Changing route judgment (which outcomes go to review vs. the human) or the retry budget.
• Merge-time enforcement: the guarantee is established before the push, not at merge.
• New window roles, new notification channels, or per-Iteration prompt storage (escalation only if a debugging session demands it).
• Restyling beyond the single-shell convergence governed by clarity of information.

Further Notes

• Precedent for the leak: a merged Progress Log on another target's base branch blocked subsequent Seeding until the kept-aside mechanism landed; the cleanup commit removes the whole class.
• The vaulted-agent draft-Proposal-on-failure observation that motivated this spec is consistent with current routing (failed Runs keep evidence, routed to the human) and needs no router change.
• The ## Owning area section remains optional: without it the Run scopes to the issue's title, which covers the live-test task.
• Server-side preconditions could not be verified from here (direct host probe failed before executing anything); confirm Target enrollment, operator allowlist, and retry budget before dispatching the live test.