Long protocol runs on opencode have no context recovery path

[pseudoseed]

What happened

builder-spir-52 (SPIR, 4 phases, --harness opencode --model xai/grok-4.6) hit porch's context-refresh task at the phase_1 → phase_2 boundary and reported:

Context refresh refused at plan-phase:phase_2: harness opencode has no in-session reset. Continuing into phase 2.

That refusal is correct behaviour — afx refresh documents that it requires a harness with in-session context clearing and aborts loudly otherwise. The problem is what happens next.

Why it matters

Porch emits refresh tasks at phase boundaries because a multi-phase SPIR is expected to exhaust a context window. On Claude that is handled. On opencode it is not, and the protocol continues anyway, so the run proceeds with no mechanism to reclaim context and no plan for what happens when it runs out.

The recovery options are all blocked or unhelpful:

• afx spawn <id> --resume reattaches the same conversation, so it does not help with exhaustion — that is exactly what afx refresh exists for.
• afx cleanup + respawn is explicitly forbidden (irreversible-acts rule; it destroys the worktree).
• So the only real fallback is a human decision, on a run that may be hours deep.

This matters more now rather than less: opencode is the lane you reach for when the Claude account is constrained, which means the longest, least-supervised runs are the ones most likely to be on the harness with no recovery path.

What I did as mitigation

Told the builder to commit and push at every phase boundary and keep codev/state/spir-52_thread.md current enough for a stranger, on the reasoning that a pushed branch and an honest thread log are the only artifacts that survive the builder. That is a workaround, not a fix, and it depends on the builder complying while its context is already degrading.

Options worth considering

1. Refuse at spawn, not at the boundary. If a protocol has more than N phases and the harness has no in-session clear, say so at afx spawn time when the choice is still free, rather than mid-run when it is not.
2. A supported handoff. A way to end one builder and start a fresh one on the same worktree and branch, carrying the thread log, without destroying anything. This is the missing primitive: --resume keeps the conversation, cleanup destroys the worktree, and nothing keeps the work while dropping the conversation.
3. Warn loudly at the first refused refresh rather than logging and continuing, so the architect knows the run is now unprotected.

Option 2 looks like the real fix. Options 1 and 3 are cheap and would have surfaced this before a four-phase run was underway.

Found while running spec 52 (#52) on opencode.

[pseudoseed]

Second operational cost on this harness: stuck composers

Separate from the context-recovery gap, and it showed up 6 times today across 4 opencode builders (39, 52, 62, 63, 74).

Symptom. afx send reports held with reason busy. The mailbox monitor then fires: "its composer never classifies as a ready prompt, so nothing is being delivered (cron nudges included)." The builder is often still burning CPU, so it is not obviously wedged.

Remedy that works. afx interrupt <builder> --no-enter. ESC alone. The default sends ESC+Enter, and Enter can select a highlighted option if the harness is sitting on a permission dialog, which is exactly the state that tends to cause this.

When it does not work. Builder 63 took 3 ESC interrupts without clearing and sat at 0.0% CPU. afx send --interrupt (Ctrl+C) killed the opencode process; .builder-start.sh relaunched it as a new conversation, which resolved the block by discarding the session. Acceptable there because its work was merged; it would not have been otherwise.

Why it belongs on this issue. Both this and the context-recovery gap say the same thing: an opencode builder needs an architect present. That is the opposite of the reason to reach for opencode, which is to run work when the Claude account is constrained. The harness you pick when you have least attention to spare is the one that demands the most.

Not asking for a fix here. Recording the cost so harness choice is made with it visible.

[pseudoseed]

The stuck composer is not intermittent: it is every spawn

7 occurrences today, and the pattern is now clear enough to state precisely.

It is always the first message sent after afx spawn. The builder is still working its spawn prompt, so its composer never reaches a ready state, the message is held with reason busy, and it does not self-resolve — cron nudges included. Every opencode builder spawned today (39, 52, 62, 63, 74, 77) needed a manual afx interrupt <id> --no-enter before its briefing arrived.

Why that matters more than the annoyance. The post-spawn briefing is where a builder learns the things it cannot derive: which issue is really its assignment when the spec path collides (#65), that it cannot refresh context on this harness, which architect to address (#47). A builder that never receives that message works from the spawn prompt alone, which is precisely the input known to be wrong.

And it defeats the reason to use this harness. opencode is what you reach for when the Claude account is constrained, which is exactly when nobody is watching. An unattended opencode spawn silently discards its briefing. The harness that needs the most supervision is the one chosen when there is least available.

Two shapes of fix, neither of which is mine to pick:

1. Hold the message until the spawn prompt's first turn completes, rather than treating the busy composer as an anomaly to nudge.
2. Deliver the briefing as part of the spawn prompt rather than as a follow-up message, so there is no window in which it can be lost.