[EPIC] MCP S6 release proof and external-controller finalization

[Joncallim]

Execution mode: tracking
Parent: #172
Canonical architecture: docs/architecture/issue-181-e2e-admission-regression.md
Historical review/rationale: docs/architecture/issue-181-review-amendments.md

Issue Type

Release / regression Epic. Do not dispatch this Epic as one coding task.

Context

Most repository-side S6 architecture/test scaffolding is already on main. The current integrated S6 topology is intentionally:

• separate signed host preflight;
• five manifest partitions: contract, postgres, operator-desktop, operator-mobile, host-boundary;
• four S6 suite commands: test:mcp:contract, test:mcp:postgres, e2e:mcp-operator, test:mcp:host-boundary.

A standalone test:mcp:issuance S6 suite is not missing. Integrated review moved packet-issuance proof back to #179/S4 because issuance is owned/proven there; duplicating it in S6 violated test ownership.

The repository-side S6 controller remains fail-closed (externalControllerRequired, live activation/ingress/issuance disabled by default). The major remaining gate is the independently controlled external trust lane and live signed release evidence.

Desired Outcome

S6 proves that the already-delivered S1-S5 MCP admission/context/grant/recovery behavior remains connected across real routes, PostgreSQL, operator UI and the supported hostile host boundary, and final Epic-172 readiness is enabled only with exact externally signed controller/App/host/build evidence.

S6 owns proof/integration. It does not silently redefine S1-S5 production policy.

Tasks

• Canonical/parity/controller contract suites and manifest wrappers on main.
• Real PostgreSQL and approval-route representative S6 flows.
• Desktop/mobile operator recovery partition.
• Host-boundary Playwright partition and signed-preflight verification surface.
• Output quarantine/diagnostic reason-code contract; no raw report upload in ordinary CI.
• Exact-SHA guard on trusted handoff workflow.
• Remove duplicate S6 packet-issuance partition; retain issuance ownership in [FEATURE] S4 — Specialist prompt and bounded context packet assembly with run evidence #179/S4.
• S6 release adapter uses the generic authorized transition/receipt-consumption path on current main.
• [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348 — protect repository release boundary/ruleset.
• [BUG][P1][SECURITY] Pin GitHub Actions dependencies to immutable commit SHAs #352 — pin external GitHub Actions dependencies used by required/privileged workflows.
• [OTHER][RELEASE] Complete S6 external-controller trust binding and live release evidence #357 — provision/verify the external controller GitHub App, exact check binding, supported host/root harness and final signed live release evidence.
• Run final current-build preflight + four-suite proof against the exact reviewed SHA with no skip/retry/missing manifest identity.
• Consume final enablement/enabled-build evidence only within the valid provisional owner/lease/deadline and record release closeout.

Acceptance Criteria

• Repository-side S6 suites remain green and their manifest topology matches the current canonical five-partition/four-command ownership model.
• Packet issuance remains proved by [FEATURE] S4 — Specialist prompt and bounded context packet assembly with run evidence #179/S4 and is not duplicated as an S6 policy suite.
• Required release rules cannot be satisfied by an untrusted same-name Actions check or moving branch/tag.
• External controller/root harness/App identity and signed evidence cannot be forged/replaced by repository checkout code.
• Final supported-host proof is bound to exact reviewed SHA/build/image/App/check/epoch and has first-attempt/no-skip/no-retry evidence.
• Preflight, suite, output quarantine, teardown/quiescence and destruction/reimage evidence are independently signed/verified according to the canonical contract.
• Wrong/stale/replayed evidence, controller/lease loss, unsupported host or failed suite prevents activation/final readiness without lowering/corrupting durable evidence state.
• Final readiness consumes the exact required receipts atomically while the provisional window/lease is still valid.
• [OTHER][RELEASE] Complete S6 external-controller trust binding and live release evidence #357 closes with an operator/release record containing only approved sanitized/path-free evidence metadata.

Out of Scope

• Reimplementing S1-S5.
• Adding a new issuance suite merely because older issue text mentioned five commands.
• Letting ordinary checkout/Actions code own external controller secrets/root authority.
• Treating beta CI success alone as enabled-production release evidence.

Technical Notes

Issue history contains many rounds of architecture detail; the checked-in primary architecture + amendments are now the source of truth. Future implementation should work from current main and #357 rather than reconstructing the old stacked PR branches.

[Joncallim]

Round 19 finding — High / issue-to-architecture drift / blocking architecture readiness

Issue #181 still says Implementation Scope: Medium — test-only and its completion evidence ends at in-repository lint/typecheck/test/build. The authoritative S6 architecture now requires a separately trusted supported-host boundary, external controller-owned exact-App-pinned Check Run, signed preflight/suite-result/teardown/destruction evidence, disposable zero-egress VM, output quarantine/allowlist, and Release/DevOps controller runbook/commands.

Failure mode: an implementation can declare #181 complete using only ordinary in-checkout tests, with no independent host/controller trust or release gate.

Smallest correction: update #181's scope and acceptance criteria to name the five suite commands, six manifest partitions, separate preflight, external controller/App pin, signed evidence chain, VM destruction, output boundary, operator runbook, and complete ten-node release-order receipts. Keep S6 from owning production policy while making its CI/controller wiring explicitly release-critical.

[github-actions]

FORGE issue validation

This Epic issue now matches the required FORGE template structure.
The validator applied ready-for-agent and removed needs-clarification if it was present.

[Joncallim]

Clarification and decision

I have updated the issue body to the standard FORGE Feature format and clarified that S6 is a large, release-critical controller and regression slice, not a medium test-only task.

The implementation decision is:

• S6 uses four layers: contract matrix, real PostgreSQL/route flows, thin Playwright presentation, and a separately trusted supported-host boundary;
• the exact five suite commands are test:mcp:contract, test:mcp:postgres, test:mcp:issuance, e2e:mcp-operator, and test:mcp:host-boundary, with a separate preflight:mcp:host-boundary prerequisite;
• the reviewed manifest has exactly six partitions: contract, postgres, issuance, operator-desktop, operator-mobile, and host-boundary;
• the host-boundary required check is controller-owned and pinned to the exact expected GitHub App/check identity forge/host-boundary-controller;
• the trusted controller/root harness lives outside the repository checkout and provisions a disposable supported Ubuntu/cgroup-v2 host boundary;
• checkout/test code runs zero-egress and cannot own or reach controller keys, privileged identities, root commands, protected state, or unrestricted GitHub APIs;
• the signed evidence chain must cover preflight, exact suite identities/results, output scan/manifest, teardown/quiescence, and VM destruction or trusted reimage receipt;
• only schema-validated sanitized path-free text/JSON may leave the VM; raw logs, traces, reports, screenshots, videos, DOM snapshots, attachments, diffs, dumps, archives, binaries, prompts, credentials, and seeded sentinels remain quarantined and are destroyed;
• Release/DevOps runbooks and literal supported commands are part of the release contract;
• the complete ten-node release chain must have durable predecessor, owner, build, host, App/check, and receipt evidence;
• S6 proves S1–S5 production policy but does not own or silently change it.

This clarification resolves the architecture-readiness finding and the issue-template validation request. Ordinary in-repository CI success alone is explicitly insufficient for S6 completion.