Promote Pi and OpenCode from preview to core harness tier — with live release evidence, then docs

[NetDevAutomate]

Problem

A docs-vs-code congruence review (2026-09-14) found that OpenCode, pi and Grok Build are not confirmed as production-supported. The code agrees and is honest about it:

• packages/studyloop/src/studyloop/harnesses.py:23-25 — CORE_HARNESSES = ("kiro", "codex", "claude"), PREVIEW_HARNESSES = ("opencode", "pi", "grok"); the Harness(...) records for opencode/pi/grok carry production=False (lines 40–44).
• docs/agent-install.md:13 — "complete integrations for OpenCode, pi, and Grok Build … shown as preview harnesses until their live release checks pass on the target environment."

The owner's target state is five core harnesses — Kiro CLI, Claude Code, Codex, Pi and OpenCode — fully wired in and documented as such. Grok Build stays preview until separately evidenced.

What "fully wired in" must mean (checkable, per harness)

For each of pi and opencode, produce the same evidence the three core harnesses already have:

1. Install path — studyloop install agents --tool <h> writes the persona/agent definition and registers both MCP servers (session-db, studyloop) in the harness's own config schema; studyloop doctor reports the harness healthy.
2. Session launch — studyloop study --agent <h> (PTY) and, where the harness supports it, the ACP path start a session, deliver the canonical persona, and the one-session authority / reconnect / cleanup behaviour matches the core three (tests/test_web_session_start_pty.py, ..._acp.py parity).
3. Session export — the harness's transcript exporter lands rows in sessions.db with the correct source (pi, opencode), and session-export --<h>-only works (agent_session_tools exporters + tests).
4. Live release check — the harness-matrix live lane (tests/acceptance/, wave 2a B2) passes for the harness on a real install, and the receipt is committed under docs/architecture/plan-integration/receipts/ or the acceptance evidence bundle (wave 2b B4).
5. Study-plan-architect mode — studyloop study --mode plan-architect --agent <h> resolves the persona (OpenCode already has a global study-plan-architect agent; confirm pi).

Then, and only then

• Move pi and opencode into CORE_HARNESSES; set production=True; RELEASE_HARNESSES unchanged.
• Update docs/agent-install.md §"Supported in the initial pre-release" (five core; Grok Build remains preview), the capability matrix, AGENTS.md's harness sentence, the installer's printed language, and openspec/specs/agent-adapters/spec.md + harness-session-memory/spec.md.
• Pin with a test that the documented core list equals CORE_HARNESSES (there is a docs-contract test pattern in packages/agent-session-tools/tests/test_docs_semantic_layer_contract.py to copy).

Definition of done

• For pi and opencode: items 1–5 above each have a passing test id or a committed receipt named in this issue.
• harnesses.py core tuple = ("kiro", "codex", "claude", "pi", "opencode"); grok remains preview.
• Docs/spec/installer language updated in the same change; a contract test pins docs ↔ code.
• Full suite green; just lint; just typecheck.
• Council review (GPT Astra, Grok 4.6, + one best-for-purpose seat) of the evidence before the tier flip is merged.

Notes

• Do not flip the tier first and "fix docs later" — the preview label is currently the honest state, and the congruence review's finding was precisely that docs must not outrun evidence.
• Blocked by nothing; independent of the plan-integration programme (Integrate Study Plans across Now, Web architect, and MCP #7–Plan integration 8: Reconcile release contract and verify #15, PR Plan integration: PlanApplication seam, Bugs A/B closed (Phases 0–1) [in progress] #20). Can run in parallel.

---

Re-scope 2026-09-20 (milestone 0.5.x) — the original text above is kept as written

State on main (a03fc9bd): CORE_HARNESSES = ("kiro", "codex", "claude", "pi"), PREVIEW_HARNESSES = ("opencode", "grok") (harnesses.py:27-28). pi's items 1–5 are evidenced in docs/architecture/plan-integration/receipts/harness-evidence-2026-09-16.md; the promotion merged with the council's two conditions recorded as a checklist and not yet discharged. OpenCode's items 3 and 4 fail live. Grok stays preview and is out of this issue's scope (open a separate ticket if the transport-parity constraint changes).

What remains — each box is a single, checkable piece of work:

pi (already core; conditions from the 2026-09-16 harness-tier council)

• Replace the PaneDriver "prompt echo counts as a reply" heuristic with a programmatic completed-reply assertion in the acceptance lane, with a test that fails on an echo-only pane (packages/studyloop/tests/acceptance/).
• Re-run just testacc pi with STUDYLOOP_ACC_REAL_AUTH=1 on pi 0.73.1 (the mise/npm build; Homebrew's 0.65.0 is what pi resolves to today) and commit the run's evidence bundle under the receipt directory.

OpenCode (preview → core)

• OpenCodeExporter reads ~/.local/share/opencode/opencode.db (SQLite session/message/part), pinned by a live-schema test, not another fixture; session-export --opencode-only lands source='opencode' rows from a real install.
• One live acceptance run with a completed model reply (a provider with quota), evidence bundle committed.
• Then, and only then: CORE_HARNESSES gains "opencode", production=True, docs/spec/installer language in the same change, tests/test_docs_harness_tier_contract.py extended to pin it; council review of the evidence before the flip merges (per the DoD above).

Definition of done for this issue: all five boxes ticked, or the OpenCode boxes moved to their own issue with this one closed on pi's two. Not part of the 0.5.0 line — 0.5.0 ships the tiers exactly as main states them today.

_Milestone renamed 0.6.0 → 0.5.x on 2026-09-21 (owner rule): follow-on work ships as 0.5.N patch releases until every issue outstanding at v0.5.0 is resolved. Where the linked receipt says "0.6.0", read "the follow-on milestone"._

[NetDevAutomate]

Status, 2026-09-19 — posted from the committed record (docs/architecture/plan-integration/receipts/harness-evidence-2026-09-16.md, council record council/harness-tier-review-2026-09-16.md), both on main at a03fc9bd. Left open on purpose: the definition of done names OpenCode in the core tuple, and that is not met.

Where each harness stands

Harness	Items 1–5	Tier on main	Why
pi	5/5 PASS — install + doctor (scratch), real-auth session launch/end/resume, export lands a source='pi' row, live check with a real Socratic reply (Bedrock claude-opus-4-6, $0.139), plan-architect mode resolves the persona	core — CORE_HARNESSES = ("kiro", "codex", "claude", "pi") (harnesses.py:27)	Council ACCEPT / ACCEPT-WITH-CONDITIONS / ACCEPT. Conditions recorded as the owner's pre-merge checklist: a programmatic completed-reply assertion in the lane instead of a pane read, and a re-run on pi 0.73.1 (the machine's pi resolved to Homebrew 0.65.0).
OpenCode	1, 2, 5 PASS; 3 FAIL (live), 4 FAIL	preview	OpenCode 1.18.30 persists sessions in ~/.local/share/opencode/opencode.db (SQLite session/message/part), which OpenCodeExporter does not read — the fixture passes, the live export does not; and the live run captured no model reply (0-token assistant rows, provider quota). To go green: teach the exporter opencode.db with a live-schema test, not another fixture; re-run with a provider that has quota; just testacc opencode with STUDYLOOP_ACC_REAL_AUTH=1.
Grok Build	5/5 on the CLI/tmux path, item 4 with a caveat	preview (unchanged)	No completed Grok reply was captured (the lane ended the session mid-reply) — the same class of gap that keeps OpenCode preview; and Bedrock bearer-token auth is env-only while the web PTY/ACP transports scrub it by design (child_env.py), so "core" would advertise transport parity Grok cannot deliver on this configuration. Council: HOLD ×3. The trust pre-write the run needed is opt-in (STUDYLOOP_GROK_TRUST_SESSION_DIR=1), default off.

Docs for the split are pinned by tests/test_docs_harness_tier_contract.py (parses each document's own statement of the tiers).

What this issue still tracks

• OpenCode: the opencode.db exporter (live-schema test) and a live run with a completed reply → then the tier flip with the docs contract test, per the DoD's "do not flip the tier first".
• pi: the two council conditions above before the promotion is called finished.
• Grok: stays preview; nothing on this issue — re-open a separate ticket if the transport-parity constraint changes.

A related, standing rule from the owner (2026-09-18): nothing in the planning/architect flow may be kiro-cli specific — every process and steering surface applies across all supported harnesses. The one owner-side receipt still due from that rule is a per-harness reachability check of the architect's tools on a real install (one row per harness: what the architect can call, what prompts); it belongs beside the harness evidence here.