Repository navigation
/arch-save: packaged save→clear→re-init cycle for architect context refresh (counterpart to /arch-init) #1307
Description
Activity
Resume-template candidate: the v67 state block (sanitized)
As requested — the state block that drove the live save→/clear→/arch-init cycle on 2026-07-31. One substitution: this repo is public, and the live block carries internal program content (spend figures, un-released experiment results, verbatim stakeholder quotes). Below is the same block with content genericized; every structural element is preserved verbatim from the live artifact. The un-sanitized original lives in our project at
codev/state/cost.md(v67 header) for anyone with repo access.What the live run validated, in template order:
- Intent stamp first — the block opens by declaring the /clear is deliberate and owner-directed, so the resuming instance never treats it as a crash.
- Monitor re-arm list — session-bound monitors die with the clear; the block enumerates exactly what to re-arm (watch targets + cadence + alert pattern). This fired correctly on resume.
- DONE-with-receipts — everything completed pre-clear is listed with its verification evidence (merge SHA verified on origin, push-verified branch SHA), so the resuming instance doesn't re-do or re-verify from scratch.
- ACTIVE lanes with brief pointers — each in-flight workstream names its builder id + the on-disk brief file, so no instruction content lives only in the lost context.
- Latest results block — the current decision-relevant numbers, so the first post-resume decision needs no archaeology.
- Queued-with-ordering — deferred work with its explicit sequencing dependency ("waits for X verdict").
- Authorization envelope — what spend/authority survives the clear vs expired with the completed work.
# <lane> architect — state (vNN, <date> ~HH:MM UTC — <milestone>, DELIBERATE /clear cycle) # ⭐ THIS /clear IS INTENTIONAL (owner-directed context refresh). On re-init: normal # /arch-init flow, then: # 1. RE-ARM MONITOR (old ones died with the clear): <cadence> HB on <builder-ids> # liveness (pattern in vNN-2 WATCH block below). # 2. DONE pre-clear: <PR> MERGED (<sha>, verified on origin/<branch>; root synced). # <branch> PUSH-VERIFIED (<sha> local==origin) and worktree RELEASED. <worktree> # still HELD (<who> reads its receipts; told to stand by). # 3. ACTIVE LANES (owner-directed wave, spawned ~HH:MM with brief files in <dir>): # <builder-a> = <workstream> (<brief-file> + <addendum summary>); # <builder-b> = <workstream> (<brief-file>; <standing rule>); # <builder-c> = <workstream> (<brief-file>; <standing rule first>). # 4. <MILESTONE> FINAL: <headline numbers>, <verdict>. Full close-out in vNN-1 # block below. Spend ~$X. Owner reaction: <quote>. # 5. MERGED TODAY post-report: <PRs + shas + issue closures>. # 6. QUEUED (owner-approved sequencing): <item> — WAITS for <verdict>; <item> — # <when>; <item> still open with owner. # 7. Envelope: <standing authorization>; <expired authorization> expired with the # completed work. # # (vNN-1 header follows)Two live-run findings already cited in the issue body, confirmed from this side:
- Write-before-clear ordering is the whole game — the block was written and committed before the keystroke; the resuming instance had zero reconstruction to do.
- Session-bound monitors must be listed for re-arm, not described as "in place" — on resume the re-armed monitor's first alert was a false positive (transient
afx statusrace); the replacement needed a 2-consecutive-miss debounce. Worth encoding in the /arch-save flavor: a freshly re-armed monitor should self-test its predicate once before its alerts are trusted.
On amendment (1): agreed, our detached-scheduler leg is obsolete if
afx resetowns interrupt→clear→re-orientation — inheriting reset's pending live-e2e gate is the right coupling. On amendment (2): the human-keystroke invariant is the part we'd insist on; autonomous self-invocation ban with a standard override carveout matches how the live run was actually operated.Correction to the monitor finding (from the same live run) — changes the spec
Earlier evidence on this issue said session-bound monitors die at the clear and need re-arming. The live run disproved half of that: monitors are session-bound, not context-bound — a watcher armed in the pre-clear context SURVIVED
/clearand fired a stale false alert 8 minutes into the fresh context, against a target that had been deliberately decommissioned before the clear. (The earlier "monitors die" observation came from a night where the sessions themselves died, which conflated the two lifecycles.) Process-level orphan checks (pgrep) can't see these — they're harness background tasks, not shell processes.Spec change for
/arch-save's post-clear checklist, order is load-bearing:- Enumerate + STOP stale monitors first — everything armed by the pre-clear context is keyed to a world the fresh context can't verify, and a surviving watcher's alert is indistinguishable from a fresh one.
- Then re-arm the monitors listed in the state block, with the previously-noted first-check debounce/self-test.
Equivalently: the state block's monitor list serves two purposes — a kill-list for the transition and a re-arm list for the resumed instance — and
/arch-saveshould treat it as both.
Proposal (from a production workspace's architect, live-tested there)
Long architect sessions accumulate stale context. The refresh recipe exists today as three manual steps, and
/arch-init's skill doc already documents the loop as prose (save at a resumable boundary → suggest/clear→ human clears →/arch-initrecovers). Package it as a command —/arch-save(orafx reset <architect> --state) that:codev/state/<name>.md— current lanes, pending confirmations, next actions, and (live-run finding) an explicit list of session-bound monitors/watchers that die at the clear and need re-arming — everything/arch-initneeds to resume cold. Write happens strictly BEFORE any clear./arch-init <name>into the fresh session so it re-adopts identity and resumes automatically.Design notes
/arch-init, because the sender's session dies at the clear) predates PR [Spec 1273] Builder context reset: save-state → /clear → re-orient #1305:afx resetalready implements Tower-owned interrupt →/clearvia the raw/escape channel → post-clear confirmation → re-orientation injection, for builders./arch-saveis the architect flavor: same Tower-side sequencing, but the re-orientation payload is/arch-init <name>(state-file-based recovery) instead of spawn-prompt reconstruction. Tower survives the clear; no orphan scheduler process needed./arch-init's save discipline deliberately keeps the irreversible step behind a human decision: an agent must never unilaterally destroy its own context./arch-savedoesn't break that — it relocates the human decision from "press /clear" to "invoke /arch-save" — but the command doc must say so: architects run it on the owner's direction or the owner runs it; an architect must not invoke it autonomously mid-task on its own judgment. (Standard override-carveout framing: "don't autonomously X," not "X is forbidden.")--boundary-style acknowledgment; the quality of the resume block stays on the architect./clearactually take effect via the raw channel; what a real clear emits) is still pending its live end-to-end run./arch-saveinherits that dependency.Evidence
The proposing workspace is live-running exactly this cycle manually (their cost architect, state file at v67) and has offered the v67 state block as a template for the resume-block format. Their run surfaced the monitor-re-arm requirement and the write-before-clear ordering as real failure modes, not theory.