[OTHER][RELEASE] Complete S6 external-controller trust binding and live release evidence

[Joncallim]

Execution mode: implementation
Parent release Epic: #181 / #172
Depends on: #348, #352

Issue Type

Project Setup / Release Governance

Context

Repository-side S6 scaffolding is already substantial on main: the canonical S6 manifest has five partitions (contract, postgres, operator-desktop, operator-mobile, host-boundary) driven by four S6 suite commands plus a separate signed host preflight. Historical integrated review explicitly removed a duplicate issuance S6 partition because packet issuance belongs to #179/S4 and is already proven there.

The S6 controller surface defaults fail closed with externalControllerRequired: true, host evidence untrusted locally, ingress/issuance disabled and live activation disabled. Repository code cannot itself provide the required independent external trust.

The remaining release-critical work is operational: bind the independently installed controller GitHub App/check identity, protected repository rules, supported isolated host/root harness, signer/attestation material and final signed evidence chain to an exact reviewed commit.

Desired Outcome

An independently controlled supported-host release lane executes S6 against an exact reviewed SHA, produces externally signed preflight/suite/output/teardown/destruction evidence, publishes the exact-App-pinned forge/host-boundary-controller Check Run, and allows final Epic-172 readiness only when all required predecessor/authorization/lease/evidence predicates are satisfied.

Repository Actions/checkout code cannot counterfeit the required controller identity/evidence.

Tasks

• Consume [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348's effective base ruleset/break-glass policy and [BUG][P1][SECURITY] Pin GitHub Actions dependencies to immutable commit SHAs #352's immutable external Action identities.
• Provision/verify dedicated external controller GitHub App identity and immutable App ID/fingerprint outside checkout control.
• Add the release-specific forge/host-boundary-controller required Check Run binding only for the applicable S6 release path/ruleset, without weakening base [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348 checks or deadlocking unrelated changes.
• Provision/verify supported ephemeral host image/kernel/cgroup-v2/identity layout, root-owned harness/services, protected sockets/keys, PostgreSQL TLS fixture and zero-egress checkout namespace.
• Ensure controller prefetches/digest-pins exact reviewed SHA, external Actions/dependencies/cache/image/fixtures/harness before checkout code executes.
• Install/verify attestation public key + controller challenge path required by npm run preflight:mcp:host-boundary.
• Run exact current S6 set: preflight + test:mcp:contract + test:mcp:postgres + e2e:mcp-operator + test:mcp:host-boundary; do not resurrect a separate S6 issuance suite.
• Verify manifest identity/count and zero skip/retry/missing scenario behavior.
• Produce signed evidence bound to exact SHA/build/image/App/check/epoch for preflight, suite results, output allowlist/scan, teardown/quiescence and VM destruction/trusted reimage.
• Exercise wrong App/check identity, wrong SHA/moving ref, stale/replayed signature/authorization, controller loss/lease expiry, runner loss, suite timeout/failure, output quarantine violation and missing destruction receipt.
• Run canonical inspect/disable/retry/key-rotation operator commands and prove fail-closed behavior under wrong identity/fingerprint/state.
• Execute final enabled-build proof only inside allowed provisional window/lease and verify final readiness consumes required enablement + enabled-build receipts atomically.
• Record release-closeout receipt/report containing only approved sanitized/path-free evidence metadata; no raw quarantined artifact upload.

Implementation Sequence

1. External authority inventory — re-read current [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348 ruleset, [BUG][P1][SECURITY] Pin GitHub Actions dependencies to immutable commit SHAs #352 pins, S6 manifest/adapter/operator docs and exact controller/check requirements on current main; produce one immutable external-dependency manifest before provisioning.
2. Controller App/check provisioning — create/verify dedicated GitHub App, least-privilege installation, exact App ID/key lifecycle and release-specific Check Run/ruleset binding; same-name Actions check negative test.
3. Supported host bootstrap — immutable/ephemeral host image, kernel/cgroup/runtime prerequisites, root-owned controller/harness users/files/sockets, TLS database fixture, local-only attestation material and zero-egress checkout identity.
4. Prefetch/attestation chain — controller resolves exact 40-char reviewed SHA and digest-pins checkout dependencies/cache/actions/image/harness/fixtures before untrusted checkout execution; generate one-time challenge/attestation envelope.
5. Preflight proof — run signed preflight from exact checkout; wrong host/image/key/challenge/SHA/dependency digest fails before suites.
6. Suite proof — execute current four commands/five manifest partitions with fixed ordering/limits, no skip/retry, isolated fixtures and exact scenario identity/count assertions.
7. Quarantine/output proof — scan/allow only schema-validated sanitized path-free evidence; prove raw Playwright reports/logs/traces/screenshots/videos/dumps/diffs/archives/prompts/credentials cannot leave disposable host.
8. Teardown/destruction proof — signed quiescence/process/resource teardown plus controller-owned VM destruction/trusted reimage receipt outside checkout authority.
9. Failure/replay/controller-loss matrix — wrong/replayed signatures, stale authorization, lease expiry, controller/runner loss, timeout/failing suite/quarantine/destruction loss; every path fails closed with no readiness promotion.
10. Provisional activation/final readiness — exercise controlled activation window with live controller lease/heartbeat and atomically consume exact enablement + enabled-build green receipts before deadline.
11. Key rotation/disable/retry/recovery — canonical operator commands and signer/controller lifecycle evidence; no stale key/receipt promotion.
12. Release closeout — exact build/App/image/manifest/receipt identities and residual uncertainty recorded; [EPIC] MCP S6 release proof and external-controller finalization #181/[EPIC] MCP admission, bounded context, and release-readiness trust boundary #172 tracking Epics can close only after independent evidence review.

Primary Code / Control Seams To Inspect First

• docs/operators/host-boundary-controller-v2.md
• docs/architecture/issue-181-e2e-admission-regression.md
• docs/architecture/issue-181-review-amendments.md
• .github/workflows/mcp-host-boundary-trusted.yml
• web/test-contracts/mcp-admission-v2.json
• web/lib/mcps/epic-172-s6-release-adapter.ts
• S6/preflight/release scripts referenced from web/package.json
• Epic-172 signer/transition/lease/release-evidence tables and operator scripts
• external GitHub App/ruleset and host/root configuration (kept outside repo; do not copy secrets into issue/CI artifacts)

Orthogonal Checkpoints

1. Repository/App authority: base [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348 checks remain mandatory; exact external App/check cannot be spoofed by Actions/checkout/bot; break-glass cannot silently satisfy S6 proof.
2. Supply chain: exact SHA, Action/dependency/cache/image/harness/fixture digests, moving-ref and poisoned-cache attempts.
3. Host containment: untrusted checkout cannot access root/controller users, sockets, keys, secrets, network egress or privileged services; process/cgroup/mount/user namespace assumptions tested.
4. Cryptographic freshness: signer/key generation, domain separation, nonce/replay/cross-build/cross-App/cross-epoch/cross-check substitution and retirement.
5. Suite identity: exact five partitions/four commands, no accidental duplicate issuance partition, manifest/scenario identity/count/skip/retry rules.
6. Output privacy: hostile sentinel secrets/paths in stdout/stderr/test artifacts; quarantine allows only contract-approved status/evidence.
7. Failure ownership: controller vs runner loss, DB/host/suite timeout, lease/heartbeat expiry, partial evidence, teardown/destruction failure.
8. Activation race: provisional deadline/lease/current owner/build changes between preflight/suites/enablement/final evidence consumption.
9. Recovery/rotation: disable, retry and key rotation cannot lower epoch/reuse stale evidence or strand unsafe enabled state.
10. Independent release review: controller evidence is inspected outside the checkout that produced test output; no self-verifying path.

Acceptance Criteria

• [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348 and [BUG][P1][SECURITY] Pin GitHub Actions dependencies to immutable commit SHAs #352 are closed before this release provisioning begins.
• Base main protections remain intact and S6 adds an exact external App/check requirement only where applicable; ordinary PRs are not deadlocked.
• Controller/root harness/key material lives outside checkout and cannot be read/replaced by checkout/test identities.
• Reviewed input is an exact immutable 40-character commit SHA, never a branch/tag/moving ref.
• Checkout/test code runs in supported zero-egress confinement and cannot access controller credentials/privileged identities/root commands.
• S6 topology is verified as five manifest partitions / four commands plus preflight; issuance remains owned by [FEATURE] S4 — Specialist prompt and bounded context packet assembly with run evidence #179/S4.
• Every required suite runs first-attempt with no skip/retry and exact manifest identities/counts.
• Signed evidence covers preflight, exact suite result, output scan/manifest, teardown/quiescence and VM destruction/reimage bound to exact build/image/App/check identity.
• Wrong/stale/replayed/cross-build/cross-App evidence or controller/lease loss fails closed before activation/final readiness.
• Output quarantine permits only schema-validated sanitized path-free status/evidence; raw reports/logs/traces/screenshots/videos/dumps/diffs/archives/prompts/credentials do not leave disposable environment.
• Final readiness occurs only while same provisional owner/lease/deadline is valid and consumes required receipts atomically.
• Unsupported hosts remain activation-ineligible without corrupting epoch/evidence/state.
• Operator inspect/disable/retry/key-rotation/rollback behavior is proven against the live configured lane.
• Closeout contains no raw controller private key/token/credential and is independently reviewable.

Out of Scope

• Reimplementing S1-S5 admission/grant/packet policy.
• Reintroducing a standalone S6 packet-issuance suite.
• Letting repository code own the privileged controller/harness.
• Weakening output quarantine for debugging.

Implementation Scope

Very Large / release-critical infrastructure - repository-side changes may be small, but host/App/ruleset provisioning and evidence exercises require multiple independently reviewable operational checkpoints.

Technical Notes

This work necessarily includes external GitHub/host mutations and secret material. Implementation agents may prepare/configure through available authorized interfaces, but every consequential change must retain operator-visible evidence and never expose raw keys/tokens in ordinary GitHub issues/Actions artifacts.

[Joncallim]

Hostile S6 release addendum — controller independence, release-ref topology, trusted approval manifest, and controller self-supply-chain

A fresh external-trust pass found several details that must be explicit before S6 can legitimately be called independent of the checkout it evaluates. The original issue is already strong; these amendments close the remaining trust/composition gaps.

1. Do not require the S6 external check on every ordinary main PR unless the controller is intentionally an always-on PR gate

GitHub branch/ruleset required-check policy is fundamentally ref/rule scoped, not a magic per-file “S6 only when relevant” semantic. A required context that is not emitted blocks the ref; a controller that runs only special release exercises cannot be attached to ordinary main merges without either deadlocking them or emitting a potentially misleading neutral success.

Define the release topology explicitly before provisioning. Preferred safe options are:

Option A — protected release-candidate ref/lane (recommended unless existing architecture already specifies another exact lane):

• base [BUG][P0][SECURITY] Enforce Forge release gates with GitHub main-branch protection/ruleset #348 main rules remain web + check for ordinary development;
• an explicit protected release-candidate branch/ref pattern is created from an exact already-reviewed/merged main SHA;
• the release ref/ruleset additionally requires exact forge/host-boundary-controller App/context;
• S6 evidence and final Epic-172 activation bind that exact SHA/release epoch;
• no code is developed directly on the release ref; it is a promotion/evidence lane, not a second source branch.

Option B — controller is genuinely always required on main: only if the operator deliberately accepts controller availability/cost for every merge and the controller emits an independently evaluated result for every PR. Do not use a checkout-controlled “not applicable” script as the external required-check authority.

Whichever is chosen, document/test it. Do not leave “release-specific required check where applicable” as an implementation guess.

2. The external Check Run is a publication of controller evidence, not the root evidence itself

GitHub integration_id proves which App published the Check Run; it does not prove the private key was uncompromised or that the publisher actually ran the expected host protocol.

Keep the independent signed controller evidence chain as the release authority. The App check publishes a summary/digest/status of that verified evidence and binds:

• exact repository + SHA;
• release epoch/challenge;
• controller software/image identity;
• host image/runtime identity;
• suite/manifest identity;
• evidence-root digest;
• final result.

Final readiness verifies the external evidence/receipt predicates already designed, not merely check_run.conclusion == success.

A stolen/same App credential without the controller signer/evidence chain must be insufficient to mint S6 readiness.

3. Separate GitHub App credential from controller evidence-signing identity

Use different key roles where practical:

• GitHub App private key/token capability: publish/check/read repository metadata only as required;
• controller evidence signer: signs the domain-separated S6 evidence envelopes/challenges consumed by Forge/release policy.

Compromise/rotation of one is independently detectable/recoverable. Never use the GitHub App private key itself as a generic evidence-signing key merely because it is already secret.

Controller evidence verification pins signer public-key generation/fingerprint through the protected release/operator configuration. Key rotation creates a new generation/epoch with explicit overlap/retirement policy; no stale signer can publish applicable new evidence after retirement.

4. The controller itself has a pinned, independently reviewed software/deployment identity

Independence from checkout is lost if “the controller” means an unversioned script pulled from a mutable location at runtime.

Controller/harness trusted manifest includes:

• controller executable/image/source revision/digest;
• harness/preflight implementation digest;
• signer binary/library versions where material;
• host bootstrap/image digest;
• configuration schema/version;
• external Action/dependency manifest from [BUG][P1][SECURITY] Pin GitHub Actions dependencies to immutable commit SHAs #352;
• fixture/cache/toolchain identities required for the proof.

Controller updates use a separate full independent security/release review and staged test. A repository PR under test cannot replace the installed controller binary/config/key simply by changing docs/scripts in the checkout.

5. “Exact reviewed SHA” needs an external trusted approval manifest, not only the SHA string

Running strong tests on an exact malicious/weakened test commit is not sufficient. The controller needs a trusted statement that this SHA is the operator/release-review-approved subject and what security-critical test topology is expected.

Before the controller executes checkout code, create/provide an immutable approval/input manifest outside the checkout authority containing at least:

• repository identity;
• exact 40-char SHA;
• release epoch/challenge;
• expected S6 contract manifest digest/version;
• expected four suite command identities/five partitions and critical harness/preflight digest(s);
• required dependency/image/controller identities;
• operator/release-review authorization identity/evidence reference.

The controller compares the checkout's security-critical manifest/scripts against these externally approved digests/expectations before trusting results. A commit cannot simply delete a hostile test, reduce scenario count, or change the manifest and still call itself S6-complete because its own new tests pass.

Do not require the external manifest to enumerate every application source file; it binds the reviewed SHA plus the trust-critical release contract identities that make “tests passed” meaningful.

6. Suite outcome is computed by controller-owned orchestration, not checkout-authored success prose

Checkout/test processes may emit untrusted output. The controller independently determines:

• process exit/timeout/signal state;
• exact command invoked;
• manifest partition/scenario accounting;
• zero skip/retry/missing requirements;
• expected result/evidence files and schemas;
• output quarantine status;
• teardown status.

A test printing PASS, writing an arbitrary JSON success: true, setting a GitHub output, or editing its own result file is not enough unless the external controller validates the exact schema/evidence relationship expected by the approved manifest.

Hostile fixture: checkout emits forged “all green” artifacts while a required scenario/process fails; controller result remains failure.

7. #352 direct dependency pins are inputs, but S6 prefetch recursively closes the executable dependency set it claims

For S6's stronger lane, do more than ordinary #352:

• prefetch exact pinned external Actions/reusable workflows and inspect/resolve the actual executable dependencies used in this S6 path;
• pin OCI images by digest;
• pin package/tool/cache content digests used offline;
• do not execute a pinned composite Action that will later resolve an unprefetched mutable nested Action/download while checkout network is denied;
• cache entries are content-addressed and bound to the approved manifest; cache key collision cannot substitute content;
• cache miss or digest mismatch fails before untrusted suite execution.

This is where the programme proves a substantially more closed supply chain than ordinary GitHub-hosted Web CI.

8. Prefetching cannot become an untrusted code-execution phase

The privileged/networked controller prefetch phase resolves/copies artifacts as data before the zero-egress checkout runs.

• do not execute lifecycle/install hooks from the untrusted application checkout while the networked privileged prefetch context is active;
• package extraction is path/symlink/special-file bounded;
• signatures/digests are verified before content enters the trusted cache where applicable;
• downloaded archive names/manifests cannot write into controller key/config paths;
• the final offline execution environment only receives the exact approved cache subset.

Separate “fetch bytes” from “run untrusted dependencies.”

9. Zero-egress means effective network isolation, including side channels reachable from the sandbox

Host containment tests include more than public internet:

• DNS;
• loopback/controller sockets not explicitly required;
• host gateway/private LAN/link-local/cloud metadata;
• Unix sockets (Docker/container runtime, SSH agent, credential helpers);
• inherited proxies;
• IPv6 paths;
• service discovery;
• privileged filesystem paths that expose network credentials.

The intended local PostgreSQL/fixture/harness endpoints are explicit allowlisted Resources. Checkout cannot repurpose their credentials/endpoints to reach other host services.

If the chosen test technology requires browser networking to the local app/fixture, bind exact local namespaces/sockets rather than granting generic outbound network.

10. Controller challenge/nonce freshness does not trust checkout/runner wall clock

Evidence freshness binds unpredictable controller-generated challenge + release epoch + exact SHA + DB/release authorization state. Timestamps are explanatory/expiry inputs from trusted controller/database clocks; a checkout-controlled clock or forged timestamp cannot make replayed evidence fresh.

• nonce is single-use within the release epoch;
• exact domain separation for preflight/suite/quarantine/teardown/destruction receipts;
• consumption recorded atomically so the same signed receipt cannot satisfy two epochs/builds;
• future-dated/clock-skewed runner evidence cannot extend the provisional window;
• final deadline/lease authority remains the canonical database release state where designed.

11. Controller/runner loss has explicit fail-safe Check Run semantics

Avoid a stale old success appearing current when the external lane dies.

For each release SHA/epoch:

• controller opens/updates the exact Check Run bound to that SHA/epoch according to GitHub semantics;
• loss/timeout leaves the new required check non-success/failing, never reuses a prior SHA's success;
• rerun creates a new attempt/evidence chain but same exact subject as policy permits;
• wrong SHA cannot receive a Check Run copied from another run;
• if controller service is unavailable, release promotion blocks rather than base main development being silently weakened (another reason to choose explicit release topology in section 1).

12. Host destruction receipt is supplied by authority outside the disposable guest

The guest/test environment cannot attest to its own destruction.

Destruction/trusted-reimage receipt comes from the controller/infrastructure layer that owns the VM/host lifecycle and binds:

• release run/host instance identity;
• prior host image/build identity;
• teardown/quiescence result;
• provider/hypervisor/controller action identity;
• completed destruction/reimage time/result;
• new instance/image identity if reused.

A script inside the checkout/guest saying “cleanup complete” is only preliminary evidence.

If physical/local hardware rather than disposable cloud VM is used, define an equivalently trusted reset/reimage/cleanup proof; do not use the word “destruction” if the actual guarantee is weaker.

13. Output quarantine is a one-way schema gateway

All untrusted output is classified potentially sensitive until the controller's trusted sanitizer/gateway validates it.

The gateway accepts only closed bounded evidence types—IDs, booleans, counts, approved reason codes, digests, coarse timings/build identities as specified—and rejects:

• unknown keys/types;
• arbitrary strings/path fields;
• ANSI/control/Unicode-confusable tricks where relevant;
• URLs/file names unless explicitly schema-allowed and sanitized;
• nested/unbounded collections;
• raw exception/test stdout.

Sanitize/validate in trusted controller code, not a checkout script whose output is then trusted. Sentinel-secret tests cover filenames, errors, process env, browser traces, database errors and archive metadata.

14. Independent release review examines evidence and controller/config identity, not just GitHub UI green

Final reviewer receives a bounded release manifest with exact identities and signed receipt chain. It checks:

• approved SHA/review manifest;
• controller/App/signer generations;
• effective release ruleset/check source;
• suite/partition/scenario counts;
• preflight/quarantine/teardown/destruction receipts;
• provisional owner/lease/deadline/current epoch;
• key/dependency/image digests;
• failures/retries/attempt history.

A green Check Run without the complete required receipt chain is insufficient. The reviewer cannot self-sign/fix missing evidence.

15. Break-glass cannot satisfy or fabricate S6 evidence

#348 operator break-glass may recover repository development when GitHub/check infrastructure fails. It must not be interpreted as S6 pass evidence.

• bypassing a repository merge gate does not mint forge/host-boundary-controller signed receipts;
• final Epic-172 activation still requires the exact external evidence predicates;
• if controller infrastructure is unavailable, S6 release/activation waits or is explicitly disabled—there is no “admin says tests are probably fine” path;
• emergency disable/revoke of unsafe provisional activation remains possible without needing a successful S6 run.

16. Hostile additions

Add/prove:

• S6 check incorrectly attached to ordinary main but controller not running -> topology review catches/deadlock avoided via explicit release lane;
• same GitHub App credential on a fake publisher but no valid controller signer/evidence -> cannot satisfy final readiness;
• controller binary/config mutable location changed after review -> identity mismatch blocks;
• exact SHA changes S6 manifest to remove hostile cases while tests pass -> external approved-manifest digest/count check fails;
• checkout prints forged green result -> controller-owned exit/scenario accounting fails it;
• pinned composite tries mutable nested Action/download offline -> prefetch/identity gate blocks;
• malicious package hook attempts execution during privileged prefetch -> never run;
• checkout reaches Docker socket/metadata/private LAN/IPv6 despite “no internet” -> confinement test fails;
• replayed signed suite receipt with forged future timestamp -> nonce/epoch consumption rejects;
• prior SHA success exists, new controller run dies -> new SHA remains blocked;
• guest claims it destroyed itself -> insufficient without external lifecycle receipt;
• raw path/secret hidden in unknown nested evidence field -> trusted schema gateway rejects;
• operator GitHub break-glass merge occurs -> still cannot activate S6 without external receipts.

The strengthened invariant is:

S6 is independent because the subject, release contract, controller software, signer, host/dependencies, result accounting and evidence publication are all bound outside the checkout's authority. The GitHub Check Run is a pinned external signal, but final readiness rests on the complete independently signed evidence chain—not on a green label the repository could indirectly influence.

[Joncallim]

Architecture reconciliation — external release authority stays separate

Reviewed 1 October 2026 against the current issue, its external-trust addendum, current S6 scripts/manifest and release adapter. No provisioning, credential access, host action or live release test was performed.

Preserve and clarify the authority graph

• [SECURITY][P0] Provision isolated base-gate GitHub App and protected credential lane #371/[BUG][P0][SECURITY] Establish unique, source-bound GitHub gate contexts before main protection #370's base gate publisher and [OTHER][RELEASE] Complete S6 external-controller trust binding and live release evidence #357's external host-boundary controller serve different trust claims. Do not reuse the base publisher as the independent S6 evidence signer or treat base CI success as host proof.
• Retain the recommended explicit protected release-candidate lane unless the operator deliberately chooses the always-on alternative. Do not attach a sometimes-emitted check to all ordinary main PRs and paper over missing runs with success.
• Pin approved repository/SHA, manifest, controller/harness, App, signer generation and host/dependency identities before executing checkout content. Current main's five-partition/four-command inventory is confirmed in [EPIC] MCP S6 release proof and external-controller finalization #181's reconciliation; no duplicate issuance suite.
• The Check Run is a published signal. Final readiness still requires the independently signed evidence chain and live canonical transition authority.

Remaining failure boundaries

1. Preflight cannot rely on guest self-report alone. Bind effective host isolation/resource configuration to the independently controlled harness/host identity, and prove actual denied access. A supported version string or rootless configuration label is not containment evidence.
2. No-skip/no-retry applies to one release attempt. Failed attempts stay visible. A deliberately authorised fresh release attempt has a new challenge/attempt identity and cannot splice green partitions from earlier attempts into its chain. A check rerun is not permission to reuse old teardown/destruction receipts.
3. Same SHA can still have different release epochs. Current GitHub success on the same SHA must not substitute for the exact current epoch/challenge/owner. Key rotation, host rebuild or policy change can invalidate applicability even with unchanged repository bytes.
4. Failure cleanup is part of the release result. Timeout/controller loss/output violation must still lead to independently observed quiescence/destruction or an unresolved blocked cleanup state. “Tests failed” must not skip the only step that removes a credential-bearing or sentinel-bearing guest.
5. Quarantine debug recovery remains external and bounded. Do not loosen output policy after a failure just to obtain raw traces. Fixed diagnostic codes and approved identity metadata can be improved under a reviewed schema; raw untrusted artifacts stay within the established boundary.
6. Provisioning remains an operator-authorised action. App/key creation, persistent credentials, security/network settings and live activation need their applicable explicit operational approval. This issue review authorises none of those actions.

Acceptance additions

• Base-check publisher credential alone cannot sign/activate S6.
• Two release epochs share one SHA: the earlier green Check Run/receipts cannot complete the newer epoch.
• Failed attempt followed by fresh authorised attempt: no mixed-attempt suite or destruction evidence.
• Controller or suite dies before cleanup: final readiness remains blocked until external lifecycle evidence resolves the host.
• Guest claims supported containment but can reach a prohibited socket/destination: lane fails before activation.
• Wrong/retired signer or changed controller image with identical app SHA: applicability fails closed.

Next step

Prepare one externally reviewable provisioning/input manifest and release-lane decision after #348/#352 are genuinely satisfied. Keep the independently controlled signer, result accounting and destruction authority outside checkout control. Source inspection confirms fail-closed defaults; it does not establish live lane readiness.