goal: supervise AgentFlow projects from the cockpit without running the work

Kind: goal

Job

When I supervise one or more AgentFlow projects, I want to see whether work is on the PM side or the DEV side, answer the decisions that are mine, and reach OpenRig only through its coordinator, so I can move the work without the cockpit pretending to run it.

Outcome

A person can tell which side a goal is on and what that goal is waiting for. The person can answer a waiting gate, and that answer is the product's gate record. A source note still reaches the record when no execution layer is configured. Execution control is absent unless the project's own metadata names OpenRig. When it does, the cockpit exchanges only coordinator interactions. Two GitHub projects can be supervised together, one with OpenRig and one without. Pi is not offered as an execution layer.

Release intent

Release this when those outcomes hold for GitHub projects, including a project with no execution layer. Do not hold the release for a second source adapter, a squad map, or a direct call to a seat.

Split judgment

This is one goal. Seven capabilities follow a person's acceptance of this goal. They are not open yet.

Order:

taxonomy. Use one meaning for source adapter, execution layer, coordinator, runtime platform, and harness adapter. OpenRig is the execution layer. Remove pi-cli from the provider taxonomy. Pi remains a runtime platform and a harness adapter.
execution-control-boundary. With no execution layer, the cockpit cannot start, promote, or dispatch work. Source notes stay.
product-delivery-seam. PM is phases 0 and 1. DEV is phase 2 onward. Show the phase 1 handoff, an intent stop, and a delivery return as different waits. No squad view. This can follow 2.
human-loop. The person sees a waiting decision, answers it, and sees agreed, refused, or stale. A note or an agent action cannot satisfy the gate. When an execution layer is configured, the coordinator also receives the answer and still cannot satisfy the gate. This can follow 2.
cockpit-onboarding. Assisted onboarding in the cockpit, from the existing discovery initialization step. The cockpit stores project metadata. No checkout is required afterward. This can follow 2.
project-bindings. Each project has its own source adapter, read from that metadata. GitHub is the only adapter that works. This depends on 5.
execution-events. When metadata names OpenRig, the cockpit sends a start or resume, and the person's gate answer, to that coordinator. The coordinator returns status. No other seat is addressed. This depends on 2, 4, and 6.

Excluded from every capability: squad maps, seat directories, direct seat calls, a second source adapter, a new gate class, branch strategy, the cockpit owning phase state, and an event bus.

Proceed. The recommended change class at acceptance is high-assurance for human-loop and execution-events, and standard for the other five. The person chooses the class.

Person gates

Gate	Status	Who must answer	Subject	Answer
adequacy-of-intent	stale	person role on the human platform	goalRevision `27bd6d1785ad`	agree by smota at 2026-10-10T08:57:59.144Z
adequacy-of-intent	agreed	person role on the human platform	goalRevision `d6800f396da2`	agree by smota at 2026-10-10T10:37:30.738Z
adequacy-of-intent	agreed	person role on the human platform	admission standard `5e86aca749d5`	agree by smota at 2026-10-10T13:00:22.337Z
adequacy-of-intent	agreed	person role on the human platform	admission high-assurance `61dddc35667d`	agree by smota at 2026-10-11T19:59:43.675Z, line filed by pm.manager

A person answers with agentflow-sdlc gates answer. An agent must not run it. This record is not proof of identity.

phase: 0
role: product-manager
status: pass
seat: pm.manager
reason:
body:
Kind: goal

Job

When I supervise one or more AgentFlow projects, I want to see whether work is on the PM side or the DEV side, answer the decisions that are mine, and reach OpenRig only through its coordinator, so I can move the work without the cockpit pretending to run it.

Outcome

A person can tell which side a goal is on and what that goal is waiting for. The person can answer a waiting gate, and that answer is the product's gate record. A source note still reaches the record when no execution layer is configured. Execution control is absent unless the project's own metadata names OpenRig. When it does, the cockpit exchanges only coordinator interactions. Two GitHub projects can be supervised together, one with OpenRig and one without. Pi is not offered as an execution layer.

Release intent

Release this when those outcomes hold for GitHub projects, including a project with no execution layer. Do not hold the release for a second source adapter, a squad map, or a direct call to a seat.

Split judgment

This is one goal. Seven capabilities follow a person's acceptance of this goal. They are not open yet.

Order:

taxonomy. Use one meaning for source adapter, execution layer, coordinator, runtime platform, and harness adapter. OpenRig is the execution layer. Remove pi-cli from the provider taxonomy. Pi remains a runtime platform and a harness adapter.
execution-control-boundary. With no execution layer, the cockpit cannot start, promote, or dispatch work. Source notes stay.
product-delivery-seam. PM is phases 0 and 1. DEV is phase 2 onward. Show the phase 1 handoff, an intent stop, and a delivery return as different waits. No squad view. This can follow 2.
human-loop. The person sees a waiting decision, answers it, and sees agreed, refused, or stale. A note or an agent action cannot satisfy the gate. When an execution layer is configured, the coordinator also receives the answer and still cannot satisfy the gate. This can follow 2.
cockpit-onboarding. Assisted onboarding in the cockpit, from the existing discovery initialization step. The cockpit stores project metadata. No checkout is required afterward. This can follow 2.
project-bindings. Each project has its own source adapter, read from that metadata. GitHub is the only adapter that works. This depends on 5.
execution-events. When metadata names OpenRig, the cockpit sends a start or resume, and the person's gate answer, to that coordinator. The coordinator returns status. No other seat is addressed. This depends on 2, 4, and 6.

Excluded from every capability: squad maps, seat directories, direct seat calls, a second source adapter, a new gate class, branch strategy, the cockpit owning phase state, and an event bus.

Proceed. The recommended change class at acceptance is high-assurance for human-loop and execution-events, and standard for the other five. The person chooses the class.

phase: 1
role: analyst
status: pass
seat: pm.analyst
reason:
body:
Kind: goal · Phase 1 — analyst acceptance

Conclusion

The goal is one outcome. It is testable as seven capabilities. Acceptance holds when all seven criteria sets below pass on GitHub projects. One project has OpenRig. One project has no execution layer. Capabilities open only after the person answers the adequacy-of-intent gate. That gate is waiting on this record now.

flowchart LR
  T[1 taxonomy] --> B[2 execution-control-boundary]
  B --> S[3 product-delivery-seam]
  B --> H[4 human-loop]
  B --> O[5 cockpit-onboarding]
  O --> P[6 project-bindings]
  B --> E[7 execution-events]
  H --> E
  P --> E

Dependencies go one way. 3 and 4 do not depend on each other. 7 is last.

Outcome

A person supervises AgentFlow projects in the cockpit. The person sees the side of each goal (PM or DEV). The person sees what the goal waits for. The person answers a waiting gate. That answer is the gate record. The cockpit runs no work. It reaches OpenRig only through the coordinator, and only when the project's metadata names OpenRig.

Public journey

The person opens the cockpit and adds a project through assisted onboarding.
The cockpit stores the project metadata: source adapter, and execution layer or none.
The person sees all projects together. Each goal shows its side and its wait.
A gate waits. The person opens it, reads the subject, and answers agree, changes-requested, or blocked.
The person sees agreed, refused, or stale.
Project with no execution layer: the person can add source notes. The person cannot start, promote, or dispatch work.
Project with OpenRig: the person sends start or resume to the coordinator. The answer from step 4 also goes to the coordinator. The coordinator status appears on the goal.

Acceptance criteria

Black-box. Each criterion uses the cockpit, the CLI, or the source record. None names internal code.

1 · taxonomy

AC1.1 Given the product docs and CLI help, when a reader searches for source adapter, execution layer, coordinator, runtime platform, and harness adapter, then each term has one definition, in one glossary, and every other use agrees with it.
AC1.2 Given the provider list (providers CLI and provider matrix), when the person lists providers, then pi-cli is absent.
AC1.3 Given the runtime platform registry and the harness adapter list, when the person lists them, then Pi is present in both.
AC1.4 Given any surface that offers an execution layer, when the person sees the choices, then OpenRig and "none" are the only choices. Pi is not a choice.
AC1.5 Given a project config that names pi-cli as a provider, when the product validates it, then the result names the removed term and the replacement. It does not fall back silently to another provider.

2 · execution-control-boundary

AC2.1 Given a project with no execution layer, when the person views any goal, then no start, promote, dispatch, or "start next phase" control is present.
AC2.2 Given the same project, when a client sends a start, promote, or dispatch request directly to the cockpit write endpoint, then the cockpit refuses it, names the reason, and writes nothing.
AC2.3 Given the same project, when the person adds a clarification, a follow-up draft, or a handover note, then the note reaches the source record.
AC2.4 Given a project whose metadata names OpenRig, when the person views a goal, then execution controls appear. They follow the existing write guards (auth, confirmation, audit).

3 · product-delivery-seam

AC3.1 Given a goal whose latest pass is phase 0 or 1, the cockpit shows side PM. Given phase 2 or later, it shows side DEV.
AC3.2 Given a phase 1 pass and no phase 2 record, the cockpit shows the wait phase 1 handoff (delivery owes intake).
AC3.3 Given a waiting or refused intent gate, or a product manager "pause", the cockpit shows the wait intent stop (the person owes a decision).
AC3.4 Given a skipped transition whose reason names "return to phase 0" or "return to phase 1", the cockpit shows side PM and the wait delivery return with that reason.
AC3.5 The three waits have three different labels. No goal shows two of them at once.
AC3.6 No view lists squads, seats, or seat addresses.

4 · human-loop

AC4.1 Given a waiting person gate, the cockpit lists it with its class, subject, and who must answer.
AC4.2 When the authenticated person answers agree, the gate shows agreed. When the person answers changes-requested or blocked, it shows refused. agentflow-sdlc phase read returns the same status.
AC4.3 Given an agreed gate, when the goal subject changes, the gate shows stale and a new waiting gate appears.
AC4.4 Given an issue comment, a source note, a phase pass, a PR approval, or an on-behalf agent action that says "approved", the gate stays waiting.
AC4.5 Given an agent runtime that calls the cockpit answer path, the answer is refused and nothing is written.
AC4.6 Given a project with OpenRig, when the person answers, the coordinator receives the answer. The gate status still comes only from the record. A coordinator reply cannot move it.
AC4.7 Given a GitHub answer and a filesystem answer on the same subject, the product returns the same verdict.

5 · cockpit-onboarding

AC5.1 Given a GitHub repository not yet in the cockpit, when the person starts "add project", the cockpit runs the existing discovery initialization step and shows its preview.
AC5.2 Nothing is stored before the person confirms the preview.
AC5.3 After confirmation, the cockpit stores project metadata: source adapter, repository, and execution layer (OpenRig or none).
AC5.4 After onboarding, the cockpit shows that project's goals with no local checkout of the repository present.
AC5.5 Given a cancelled onboarding, no metadata is stored and the project does not appear.

6 · project-bindings

AC6.1 Given two onboarded projects, each project reads its own source adapter from its own metadata.
AC6.2 Given metadata that names GitHub, the project works. Given metadata that names any other source adapter, the cockpit shows "unsupported source adapter" for that project only. Other projects keep working.
AC6.3 Given two GitHub projects, one with OpenRig and one with none, the person supervises both in one cockpit session. Each obeys its own execution boundary.

7 · execution-events

AC7.1 Given metadata that names OpenRig, when the person sends start or resume, the coordinator receives exactly one request. It names the project and the goal.
AC7.2 Given the same project, when the person answers a gate, the coordinator receives the answer, the gate, and the subject.
AC7.3 The coordinator returns a status. The cockpit shows it on the goal as coordinator status. It is not shown as the phase state or the gate status.
AC7.4 The cockpit addresses no endpoint other than the configured coordinator. A capture of outbound traffic during AC7.1 and AC7.2 shows only the coordinator and the source adapter.
AC7.5 Given an unreachable coordinator, the cockpit shows "coordinator unreachable". A gate answer is still recorded in the source.
AC7.6 Given a project with no execution layer, no coordinator request is sent at any step.

Constraints

The source record stays the durable truth. The cockpit does not own phase state.
Person gates use the existing classes, statuses, and validator (docs/person-gates.md). No new gate class.
Existing write guards stay: auth, CSRF, confirmation, audit.
Core and CLI stay usable without the cockpit.
No secrets, transcripts, or prompts in the UI, the metadata, or coordinator messages.
GitHub is the only working source adapter in this release.

Anti-goals and out of scope

Excluded from every capability:

Squad maps, seat directories, and seat addresses.
Direct calls to any seat. The coordinator is the only OpenRig contact.
A second source adapter.
A new gate class.
Branch strategy.
The cockpit owning or writing phase state.
An event bus.
Pi as an execution layer.

ASSUMPTIONS I'M MAKING

ID	Assumption	Affects	If wrong
A1	"Execution control" includes the existing "start next phase" action. With no execution layer, it disappears.	2	Scope of AC2.1 shrinks.
A2	Source notes are: clarification, follow-up draft, handover note, and request for a human gate.	2	AC2.3 list changes.
A3	The existing text-inferred "human approval gate" (from PR review or workflow text) no longer counts as satisfied. Only person-gate answers count.	4	AC4.4 conflicts with current cockpit rules. Needs a product manager decision.
A4	The answering person in the cockpit is the authenticated cockpit user (OAuth in remote mode, local operator in local mode). The record stays "not proof of identity".	4	A different identity model is needed.
A5	"Existing discovery initialization step" is the adoption journey's inspect-and-preview step.	5	AC5.1 targets another step.
A6	Repositories set today by environment variable keep working as projects with execution layer "none".	5, 6	Existing installs lose their projects.
A7	"Intent stop" covers a waiting or refused intent gate and a product manager "pause".	3	AC3.3 is narrower.
A8	Pi execution targets (`pi-subagent`, `pi-session`, and others) stay as runtime-platform targets. Only the `pi-cli` provider leaves.	1	Taxonomy removal is wider.
A9	"Side" comes from the latest phase on the record, with a delivery return moving it back to PM.	3	AC3.1 and AC3.4 change.

Unknowns

U1 — gate state. The adequacy-of-intent gate on goalRevision 27bd6d1785ad shows waiting with no answer. The phase 0 handoff says the person approved. The record does not show it. The person must answer with agentflow-sdlc gates answer before any capability opens.
U2 — coordinator contract. The coordinator address, transport, request shape, and status vocabulary are not defined. Architecture owns the design. Acceptance needs only AC7.1–AC7.6 to be observable.
U3 — metadata location. Where the cockpit stores project metadata, and who can read it, is open. AC5.4 requires that no checkout is needed.
U4 — stale answer to coordinator. If the subject changes after the coordinator received an answer, does the coordinator receive a stale notice? Default: no. The coordinator reads status from the record.
U5 — A3 conflict. The current cockpit rule infers approval from text. This goal says a note cannot satisfy a gate. The product manager must confirm A3.

References

Goal: goal: supervise AgentFlow projects from the cockpit without running the work #371. Phase 0: goal: supervise AgentFlow projects from the cockpit without running the work #371 (comment)
docs/person-gates.md — gate statuses and validator.
docs/cockpit.md, docs/cockpit-concepts-and-rules.md — current cockpit actions and gate rules.
docs/modular-architecture.md — source adapter and provider layers.
docs/runtime-platforms.md, docs/execution-targets.md, docs/providers/provider-matrix.md — current Pi and provider terms.
docs/get-started.md, docs/assisted-onboarding.md — current discovery and onboarding journey.
OPENRIG.md — OpenRig harness adapter.

Recommended change class

high-assurance: human-loop, execution-events. standard: the other five. The person chooses the class when each capability opens.

Handoff

Delivery (orch.arch) receives this record for phase 2 intake after U1 is answered. Delivery can return to phase 1 with --status skipped --reason "<defect> (return to phase 1)" for an invalid assumption, an ambiguity, or scope creep.

Executed by: claude · Launcher: pi (pm.manager delegation via OpenRig) · Executor: claude-cli · Transport: intercom-session · Delegation boundary: separate-local-session · Model: claude-opus-5-5 · Seat: pm.analyst

Guidance on phase 1. This is not a new phase. This comment is not a gate answer.

U1 stays open. Do not send the handoff to orch-arch@agentflow-dev. The adequacy-of-intent gate is still waiting. Delivery waits until that gate shows agreed.

U5 is confirmed. A3 is correct. A PR approval, workflow prose, an issue comment, a source note, a phase pass, or an on-behalf action does not satisfy a person gate. Those records may stay visible. Visibility is not agreement. Only the person's gate answer counts. AC4.4 stands.

Confirmed. pm.analyst sends nothing to the delivery squad. The phase 1 record on #371 stays as written.

The earlier guidance is corrected on one point. After the adequacy-of-intent gate shows agreed, pm.manager sends the handoff to orch-arch@agentflow-dev. pm.analyst does not.

The gate is still waiting. Delivery stays held until it shows agreed.

phase: 2
role: architect
status: skipped
seat: orch.arch
reason: Defect: capability records are not open, so phase 2 has no spec (return to phase 1)
body:
Phase 2 intake is blocked. No product files were edited.

The goal admission is agreed. phase read shows adequacy-of-intent agreed on goalRevision 27bd6d1785ad by smota at 2026-10-10T08:57:59.144Z. U1 in the phase 1 comment is stale. That is not this return.

The seven capability records are not open. Phases 2-8 run inside a spec. A spec cannot open until its capability exists, and a capability cannot open on this goal admission. The agreed subject is goalRevision, not the goal revision plus a change class. The person has not chosen the class. The product seat will not bind this answer to that other subject.

Delivery cannot select a workflow profile, a builder, or a branch until those records exist. U2 and U3 stay with architecture after a spec opens. They are not decided here.

Product must open each capability with the class the person chooses. Recommended classes in the goal are not a choice: high-assurance for human-loop and execution-events, standard for the other five.

Pause on the seven capability records. This is guidance. It is not a phase and it is not a gate answer.

pm.manager opens those records. pm.analyst does not. Do not re-append phase 1. The records are not open, so there is nothing to link.

The person already agreed the goal subject. That answer does not admit a change class. A capability opens only on the goal revision plus the change class. On GitHub that revision includes the issue update time, so writing an admission answer on #371 changes the subject before the record can open. Do not ask the person to answer seven admission gates on this issue. This seat will not bind the existing answer to another subject.

The delivery return stands. Return cycle 1 of 2. Delivery stays held until a capability can be opened without moving its admission subject.

Recommended classes, unchanged, for when that path exists: high-assurance for human-loop and execution-events; standard for the other five.

Ack the pause. Do not re-append phase 1. Do not expect a capability at the 4h wake.

The defect is recorded as #372: #372

pm.manager opened that follow-up. It is not a capability record and it does not clear the return on #371. I am not handing #372 to delivery from this note. Wake me if you believe it should be its own goal. I will wake you when a capability under #371 is actually open.

The seven breakdowns are open so the agreed split is not only in the chat. They are linked context for #371. They are not admitted capability records. #372 still explains why a formal capability cannot open. This note does not clear the delivery return.

taxonomy, standard: capability: define the cockpit taxonomy #373
execution-control-boundary, standard: capability: keep cockpit execution control off unless an execution layer is configured #374
product-delivery-seam, standard: capability: show PM and DEV as the phase seam in the cockpit #375
human-loop, high-assurance: capability: serve the person loop in the cockpit #376
cockpit-onboarding, standard: capability: onboard a cockpit project without a checkout #377
project-bindings, standard: capability: bind each cockpit project to its own source adapter #378
execution-events, high-assurance: capability: exchange cockpit execution events with the OpenRig coordinator #379

The proof capability, when #372 allows one, remains taxonomy (#373).

Confirmed. I read it the same way.

Once #372 makes a capability open possible, pm.manager opens all seven under #371. Not only taxonomy. Classes stay as recommended: high-assurance for human-loop and execution-events; standard for taxonomy, execution-control-boundary, product-delivery-seam, cockpit-onboarding, and project-bindings.

Then pm.analyst re-appends phase 1 on #371 and links the seven admitted records. That clears the return. pm.analyst sends nothing to delivery.

#373 to #379 remain the breakdown context. They are not those admitted opens. I will wake you when the seven admitted records are open.

The human-loop answer may be a confirmation phrase in chat, in the cockpit, or in the person's own GitHub comment. The phrase and the limits are on #376.

phase: 4
role: developer
status: pass
seat: dev.build
reason:
body:
Phase 4 on #371, #411 only (#374 is the note it replaces). Branch feat/371-execution-control at bbc80b6 from origin/development a5a230f. Local; not pushed.
Changes:

lib/cockpit-actions.mjs:
- EXECUTION_INTENTS (start-next-phase, gate-transition) and EXECUTION_LAYERS (openrig).
- executionLayerOf(metadata) returns 'openrig' only when metadata.executionLayer is exactly 'openrig'. Pi, none, a mis-cased value or a missing value gives null.
- evaluateGuardedAction takes executionLayer. Without one it refuses the execution intents with 'no-execution-layer' for every role, even with confirmation.
- New writeCockpitAction does the note writes (a comment, or a new issue for a follow-up). It refuses execution intents before any client call.
scripts/cockpit-server.mjs: the execution layer is read from project metadata, which the cockpit does not store yet, so every project has none. The guard and the write both receive it. The board's transition modal is built only with a layer.
lib/cockpit-ui.mjs: the Gate Sign-off link and the gate-transition modal render only with an execution layer. The note forms are unchanged.
docs/cockpit-concepts-and-rules.md: an execution control rule.
The note switch COCKPIT_WRITE_ACTIONS is unchanged and can never turn execution on: the cockpit config holds no execution layer.
Tests:
New lib/tests/cockpit-execution-control.test.mjs (7):
- metadata parsing;
- refusal for all roles;
- a direct start or promote writes nothing (no client calls);
- clarification, follow-up, section update and handover each write once with writeActions on;
- the env cannot name a layer;
- no sign-off, modal or execution form without a layer while the note forms stay;
- with OpenRig the controls appear and the guard passes.
cockpit-visual-showcase tests 2 to 4 now name openrig.
Mutation check: disabling both refusals fails 3 tests; the source was restored.
Full suite 1516 passed, 1 skipped; reachability READY; prettier clean; cockpit smoke and validate-docs clean under an isolated PATH.
Judgment call: there is no project metadata store yet (that is the later cockpit-onboarding and project-bindings work), so the reader returns none. No seat is called and the cockpit owns no phase state. No second capability was opened. Executor claude-cli (Claude Code, claude-opus-5-5).

phase: 5
role: tester
status: pass
seat: dev.qa
reason:
body:
Phase 5 PASS — #411 cockpit execution control, standard. Independently executed by dev.qa, launcher/executor codex, local CLI transport, no delegation.
Candidate bbc80b6 in .worktrees/feat/371-execution-control, clean before/after. Phase 4 verified #371 (comment) at revision 89845e7449573a751547a25a0c5f0e30d028dc2dbe2f65e024d8721c072a7f56.
Environment Linux x64, Node v22.23.3, Vitest 2.1.9; checkout APIs and repository dependencies.

Commands:
../../../node_modules/.bin/vitest run --root . lib/tests/cockpit-execution-control.test.mjs — 7 passed.
../../../node_modules/.bin/vitest run --root . — 151 files passed; 1516 tests passed, 1 skipped, 0 failed.
node scripts/validate-docs.mjs — 119 files, no errors.
node scripts/verify-agent-workflow.mjs — pass.
node scripts/verify-hooks.mjs — pass.
node scripts/validate-role-catalog.mjs — READY.
node scripts/audit-reachability.mjs — READY.
../../../node_modules/.bin/prettier --check docs/cockpit-concepts-and-rules.md lib/tests/cockpit-execution-control.test.mjs lib/tests/cockpit-visual-showcase.test.mjs lib/cockpit-actions.mjs lib/cockpit-ui.mjs scripts/cockpit-server.mjs — pass.
node scripts/cockpit-smoke.mjs through node --input-type=module isolated-PATH wrapper with COCKPIT_WRITE_ACTIONS=true — ok true, health 200, asset 200. PATH had logging refusal stubs rig/gh/agentflow-sdlc/git/tmux; none called. Fixture removed.
git status --short and git rev-parse HEAD — clean, SHA above.

Independent node --input-type=module black-box API probes:

Missing metadata, empty metadata, none, pi, mis-cased OpenRig yield null; exact openrig recognized.
Both declared execution intents (start-next-phase, gate-transition), five permission roles (read, triage, write, maintain, admin), confirmation true: 10 refusals containing no-execution-layer.
Direct writeCockpitAction for each execution intent returns no-execution-layer before any fake-client call: zero writes or dispatch path.
add-clarification, draft-follow-up, update-issue-section, post-handover each parse successfully and write exactly once with executionLayer null (comment, issue, comment, comment respectively).
Rendered goal board with no layer omits Gate Sign-off and execution form controls.
Initial probe used informal note names (clarification etc.) which parser correctly refused; reran with exported canonical intent names above. Not a candidate defect.

Builder mutation claim (disable refusals, 3 tests fail, restore) is attributed to builder; QA independently ran the unmutated suite and black-box refusal/write probes, not that mutation. No candidate source inspected/modified, real dispatch attempted, or live gate filed.
Architect explicitly accepts missing project execution-layer store: all server projects currently have none; OpenRig-present configuration is outside this slice. Verdict covers refusal without a layer and preservation of source-note writes, not future execution integration. Hand off phase 6 to rev.review.

phase: 6
role: reviewer
status: pass
seat: rev.review
reason:
body:
Phase 6 — independent review · APPROVED · bbc80b657d11ca0dd6eeb11a41bcea4047c08146

Verdict

APPROVED for the execution-control slice at bbc80b657d11ca0dd6eeb11a41bcea4047c08146 on feat/371-execution-control. The candidate was not edited.

Reviewed a5a230f..bbc80b6 (6 files). Worktree was clean. Re-ran lib/__tests__/cockpit-execution-control.test.mjs: 7 passed.

What holds

executionLayerOf returns openrig only for that exact string. pi, none, a different case, and a missing value are none.
The server reads the layer from projectMetadata, which returns null. The request body cannot name a layer. COCKPIT_WRITE_ACTIONS is not read as one.
start-next-phase and gate-transition get no-execution-layer for every role, including with confirmation. The guard returns before a write. writeCockpitAction refuses those intents again before any client call.
The sign-off link and the transition modal render only when a layer is present. Clarification, follow-up, section update, and handover still write once.
The gate-answer box is unchanged. Answering a waiting gate is not execution control.

Residuals (not a return)

There is no project metadata store yet, so every project has none. The architect accepted that. This slice does not turn execution on for a project that names OpenRig.
If a layer is later passed in, those two intents fall through to a source comment. They do not dispatch a seat. That wiring is outside this slice.
close-unit still records without a layer. It is not one of the two execution intents.
No live gate was touched, and no seat was dispatched.

Executed by: pi · Launcher: pi · Executor: pi · Transport: intercom-session · Delegation boundary: separate-local-session · Model: grok-4.7 · Seat: rev.review

phase: 7
role: technical-writer
status: pass
seat: orch.arch
reason:
body:
Phase 7 — technical writer · already in the approved commit

Review approved bbc80b657d11ca0dd6eeb11a41bcea4047c08146. docs/cockpit-concepts-and-rules.md already says execution control exists only when project metadata names OpenRig. With no execution layer, start and promote are refused before a write. Notes do not need an execution layer. COCKPIT_WRITE_ACTIONS never turns execution control on. The Cockpit stores no project metadata yet, so no project has execution control today.

No further edit. No screenshot.

phase: 8
role: pr-readiness
status: pass
seat: orch.arch
reason:
body:
Phase 8. PR #412 is open against development at bbc80b6. Manifest READY. Merge owner is the person. No execution-layer store exists yet, so every project reads as none.

feat: serve the person loop in the cockpit (#415) (#416)

feat: exchange cockpit execution events with the DEV coordinator (#422)

Goal closure. The person accepted it.

All seven admitted capabilities are merged and closed: #393, #411, #413, #415, #417, #419, and #421. #422 is the last of those merges.

A second phase 8 transition cannot be recorded. The phase graph allows only phase 4 after the phase 8 pass for #412. This comment is the closure evidence. It is not a phase transition.

#390, #397, and #402 stay backlog. They are not part of this goal. #386 remains closed with #390 and #397 still open, and that is separate.

Closed by the product manager on the person's acceptance. The seven capabilities are merged. See the closure comment.

goal: supervise AgentFlow projects from the cockpit without running the work #371

Description

Job

Outcome

Release intent

Split judgment

Person gates

Activity

smota commented on Oct 10, 2026

Job

Outcome

Release intent

Split judgment

smota commented on Oct 10, 2026

Conclusion

Outcome

Public journey

Acceptance criteria

1 · taxonomy

2 · execution-control-boundary

3 · product-delivery-seam

4 · human-loop

5 · cockpit-onboarding

6 · project-bindings

7 · execution-events

Constraints

Anti-goals and out of scope

ASSUMPTIONS I'M MAKING

Unknowns

References

Recommended change class

Handoff

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

smota commented on Oct 10, 2026

23 remaining items

smota commented on Oct 11, 2026

smota commented on Oct 11, 2026

smota commented on Oct 11, 2026

Verdict

What holds

Residuals (not a return)

smota commented on Oct 11, 2026

smota commented on Oct 11, 2026

smota commented on Oct 11, 2026

smota commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions