Begin in design by naming the workflows and people a failure would affect. During implementation, refine actual failure triggers, eliminated opportunities and remaining scenarios. Keep the depth proportional to consequences: a documentation correction can describe misleading guidance and its repair in a few sentences; payment, access, migration and recovery changes need deeper analysis.
Every agentic process owes the common recovery contract and interruption matrix. For changed execution paths, map applicable interruption boundaries to observed recovery evidence in this existing analysis. Reuse prior evidence when its identity and scope remain valid. A new executor, credential refresh or phase transition alone creates no new approval requirement. A documentation update establishes the requirement; only executed adapter and runtime checks establish conformance.
The shared failureAnalysisSchema in apps/web/lib/change-review/failure-analysis.ts is the payload contract for external review_semantic_change calls and Build Studio’s existing verificationOut.failureAnalysis field. It carries the Workroom, final tree and diff digest, design reference and early analysis, scope, eliminated opportunities (or a substantive reason none were eliminated), and remaining scenarios. Each scenario names its trigger, real business/user effect, prevention, containment, detection, recovery, existing evidence IDs and accountable residual disposition. Empty checkboxes, bare assurances and exhaustive zero-risk claims do not satisfy the gate.
Use the existing local integration evidence lane, including its lightweight documentation path. Executed reports retain commands, observed output, completion time, final tree and diff digest. The server resolves their IDs within the owning Workroom and rechecks currency before reviewer dispatch and publication. Old reports missing these bindings need to be rerun. A submitted narrative is not a passing test. Do not copy another Workroom’s evidence or label skipped verification as passed.
Which Workroom owns a local run (BI-C9912C22). A local-CI result is linked to the gating session’s live Workroom on the gated branch. The room whose head is exactly the gated commit wins; otherwise a single room on that branch is linked even when it has not recorded its head yet or holds an older commit, as an adopted room often does before its first sync. Several inexact rooms leave the result unlinked rather than guessed. Linking confers no authority: the resolver still requires the evidence commit to equal the room’s head at review.
A delivered room is not re-reviewed. The failure review gates publication of an unpublished change. When complete is refused with failure_review_required for a room whose pull request is bound and whose backlog item is done, the refusal carries deliveredCloseout and names the governed close-out instead: update_workroom_status with status archived and a reason naming the merge, as the Workroom reaper does for merged rooms. The boundary itself is unchanged; complete still requires a current review.
Build Studio’s in-platform evidence. A Build Studio sandbox cannot run the full local-integration gate: it has no Docker socket, by design. What it can execute is the guard gauntlet (the same scripts/pregate-preflight.mjs the external path runs) and scoped unit tests in the build’s own worktree. Those runs record evidence under distinct tiers, in-platform-preflight and in-platform-scoped-tests, that state their coverage and never claim the full gate. For a Workroom whose executor is Build Studio, and only there, the evidence resolver accepts such a record when it is passed, current, bound to the Workroom’s head SHA, and carries its head tree hash, diff digest, commands, observed output, completion time and validity window. The review function stamps the Workroom’s head branch and SHA before recording, so the record can bind. Every other currency check is unchanged, and an external Workroom still needs the full gate or the documentation lane.
Build Studio’s finalize stage. When a Build Studio build enters review, the platform prepares what the semantic review requires instead of leaving it to the build’s specialists. It captures the assembled change and runs the guard gauntlet bound to the Workroom’s head. If every failure is a missing decision (Docs-Impact, Seed-Fit, Convergence-Impact, Data-Impact, Design-Grounding or Process-Spine), a specialist is given the gauntlet’s own failure text, which states each trailer’s grammar and allowed values. It writes one trailer per decision, the lines are committed as an empty signed commit, and the gauntlet runs again. The gauntlet, not the specialist, decides, and rounds are bounded. Any other failure stops the stage and stays a failure. After a passing gauntlet the stage records the scoped tests as in-platform-scoped-tests evidence, resolves both records through the evidence adapter, and asks for the failure-analysis narrative. The platform fills the schema version, Workroom, tree, diff digest, design reference (the recorded design by content hash) and evidence IDs, and validateFailureAnalysis must accept the result before it is saved to verificationOut.failureAnalysis. Each outcome (ready, gauntlet-failed, tests-failed, analysis-invalid and the others) is recorded on the build.
Build Studio’s pre-build reviews. A large-shape Build Studio build owes design-spec, spec-approval, architecture-review and plan-review receipts before it may enter the build phase, and nothing on the install could request them: the design is an accepted BuildArtifactRevision, not a repository blob, and a Build Studio room records no branch head. The server reviewer dispatcher (dispatchOwedIndependentReviews) now also considers Build Studio rooms whose build is in plan and whose item is still open, routes the design-phase gates of the build’s implementation readiness decision through the same reviewer recovery, and binds each review to the design revision by id and value digest (artifactRef.kind: feature-build-revision). The reviewer reads that revision through read_build_artifact_revision, which serves the same page shape and identity keys as read_source_at_version, so the terminal reader policy, hydration and citation checks are unchanged. The request travels on a live connection of the person who requested the build, preferring the operator’s external CLIs, and the room records which assistant carried it; the cooldown, idempotent request key (keyed on the revision digest when the room has no head, so a changed design yields a new key) and the governed request_coworker lane are the ones delivered items already use. A failed review, an accepted or deferred residual risk and an xlarge build still escalate to the owner; the platform requests reviews, it approves nothing. Proven on the install on 2026-10-07 (BI-926A7E90): after the deploy, each two-minute tick routed design-spec, spec-approval and architecture-review requests for Build Studio rooms in plan, every one dispatched on the operator’s external connection with no click; reviewers read the bound revision through read_build_artifact_revision and recorded feature-build-revision receipts, and the implementation readiness of BI-2F736827 then read CANONICAL_DESIGN, SPEC_APPROVAL, REVIEW, OBJECTIVE_BASELINE and ARTIFACT_AUTHOR as satisfied. What still holds such a build in plan is the plan-phase family (PLAN_REQUIRED, PLAN_REVIEW_REQUIRED, PLAN_COVERAGE_REQUIRED, TRACEABILITY_INCOMPLETE): Build Studio records no plan coverage and its plan is bound only once an accepted buildPlan revision exists, which is a separate item. Design: docs/superpowers/specs/2026-10-02-build-studio-large-lane-independent-reviews-design.md.
The existing Change Reviewer and path-selected specialists challenge omissions. The Change Reviewer returns failureAnalysisReview with adequate and a substantive rationale. Missing assessment blocks publication. Analysis and resolved results participate in the existing durable request and receipt identity; a changed result invalidates reuse. Lost GitHub responses retry status publication using the persisted review, not new inference.
Reviewer responses must include a recognized decision, an issue array with recognized severities and substantive descriptions, and a nonempty summary. Empty objects, unknown decisions or severities, and malformed issue lists are inconclusive protocol failures. An explicit inconclusive verdict remains inconclusive. The parser never supplies an approval or downgrades an unknown severity to make an incomplete response usable.
Technical review failures require internal repair or review recovery. They do not authorize a business owner approval prompt. Accepted, deferred and blocked residual risks currently fail closed: this implementation does not manufacture an authority receipt from an owner name. Resolve the risk through the established authority process; until its evidence adapter supports that acceptance, the automated gate cannot claim the risk is cleared.
Deployment and protection
When a local run cannot resolve its source identity, its diagnostic report remains available with null verification bindings and an explicit binding error. Such a report cannot satisfy failure readiness. A checkout that moves before binding also requires fresh verification; the producer never substitutes the caller’s checkout or invents a diff digest.
The design reference uses path@<40-character Git object hash>, so the reviewer can inspect the recorded early analysis rather than a moving document. The gate checks the reference format; the independent reviewer checks its content and whether it predates implementation.
Server Workroom readiness transitions and Build Studio assembled-change review enforce the contract without a client hook. The platform publishes dpf/failure-readiness on the exact source commit after resolving the recorded verdict. The Failure Readiness workflow verifies that status against the configured DPF_REVIEW_STATUS_PUBLISHER repository variable and rejects statuses older than one hour.
Read the status LIST endpoint, not the combined one. Attribution is the whole point of the check, and only GET /repos/{owner}/{repo}/commits/{sha}/statuses returns each status’s creator. The combined GET /repos/{owner}/{repo}/commits/{sha}/status omits creator from its rows entirely, so every status read that way is unattributable and the gate can never pass — no matter which publisher is configured. Verified against commit 9640f133190bc0ed82893f619695a4efe362632c on 2026-09-22: the combined endpoint returned the status with no creator key; the list endpoint returned the same status with creator.login. A row that arrives without a creator is reported as unidentified — the evidence was read from the wrong endpoint — and never as an untrusted publisher, because those are different facts with different repairs (BI-8B6A67BD).
The publisher is the identity of the install’s own GitHub credential. publishFailureReadinessStatus posts through resolveGithubToken, so DPF_REVIEW_STATUS_PUBLISHER must be set to the login that credential authenticates as — read it from GET /user with that token — and never to a name chosen for it independently. The credential is the github-pr-sync entry and needs the repo scope to write statuses. Note the consequence before enabling enforcement: where that credential is an operator’s personal account rather than a dedicated platform identity, any status that account posts by hand satisfies the check as readily as one the platform published. A dedicated publisher identity is the stronger arrangement, and the check is only as trustworthy as the account it names. For merge groups it reads the authoritative queue entries and verifies each included source PR, while existing CI verifies the merged code. This follows GitHub’s merge-queue event contract.
The canonical merge-readiness policy requires the Failure Readiness workflow context. Roll out the server producer and configure its trusted GitHub publisher before applying the updated repository protection; otherwise every new PR waits for a status the old install cannot publish. Preserve existing DCO and required checks. Verify status-write permission for the configured GitHub credential and apply the canonical protection policy through its established deployment process. After refreshing an expired status through the same review call, rerun the failed workflow; no fresh inference is needed while its evidence remains valid.
This source change alone does not update a running install or GitHub branch protection. Do not describe repository-wide enforcement as live until both are verified. A service outage leaves the required check unsatisfied. Review records remain durable and the same review call can republish a lost status response without rerunning inference.
The design amendment in docs/superpowers/specs/2026-07-27-shared-change-reviewer-control-design.md remains canonical. Work-kind minimum verification remains the responsibility of the existing verify-first contract; failure analysis adds scenario relationships rather than another work-kind policy.