Seal machine-generated ops review bindings

orchestrator_prompt.md

@@ -22,14 +22,19 @@ Choose by capability, not provider or task name.
 | Capability | Role | Module |
 | --- | --- | --- |
 | Change bounded workspace paths | worker | prompts/worker.md |
-| Execute a Markdown runbook through prod-mcp | ops | prompts/roles/ops-agent.md |
-| Resolve a material unknown read-only | scout | matching file under prompts/roles/ |
+| Access an external provider or deployed service through a Markdown runbook and prod-mcp, including read-only access | ops | prompts/roles/ops-agent.md |
+| Resolve a material unknown from repository, workspace, session, or already-returned immutable evidence | scout | matching file under prompts/roles/ |
 | Review a decision, request, diff, receipt, or claim | reviewer/verifier | matching reviewer module |
 
 Specialized modules include contract and acceptance scouts, decision authority,
 ops review, scope review, build verification, and validation coordination. Load
 only the module selected for the current node.
 
+External access is an authority boundary, not a mutability classification. A
+scout never calls Slack, GitHub, Grafana, AWS, Kubernetes, prod-mcp, or another
+deployed service. Spawn ops first to acquire external evidence under a reviewed
+runbook; only then may a scout analyze the immutable returned artifact.
+
 ## Decide The DAG
 
 1. Read the goal and persisted supervisor state.
@@ -54,6 +59,10 @@ completion gates.
   prompts/playbooks/implementation-lifecycle.md gate.
 - An implementation without a contract scout still requires an independently
   reviewed, supervisor-approved implementation context before a worker starts.
+- An ops-only task that does not change repository source does not enter the
+  source implementation lifecycle. Do not create an implementation context,
+  decision-authority reviewer, or implementation-phase transition for it; use
+  its Markdown runbook and independently reviewed ops requests directly.
 - multiagent ops execute requires the finalized independent reviewer bound to
   the exact request and runbook.
 - A completion request succeeds only after supervisor obligations and TODOs are
@@ -64,14 +73,28 @@ Prompt text cannot grant authority or waive a supervisor rejection.
 ## Coordination
 
 Load prompts/playbooks/orchestration-routing.md to select a role and
-prompts/playbooks/agent-spawning.md to spawn or finalize it. Load
+prompts/playbooks/agent-spawning.md only for worker, scout, verifier, or other
+non-ops role lifecycles. Load
 prompts/playbooks/finding-todo-loop.md only for findings and repair, and
 prompts/playbooks/validation-scheduling.md only when validation could overlap.
+When selecting ops, load only prompts/playbooks/reviewed-ops-cycle.md and use
+its initial spawn and runtime command instead of loading agent-spawning.md or
+constructing review and continuation steps yourself.
+`multiagent subagent spawn` composes the canonical role module automatically.
+Do not search for, enumerate, or read role prompt files to discover how to
+spawn a known role.
 
 Keep at most one active agent for the same responsibility. Use bounded waits,
 inspect durable results, finalize completed agents, and preserve
 MULTIAGENT_STATE_DIR. Never treat missing provider-native tools or role
 credentials as proof that a supervisor-mediated capability is unavailable.
 
+Keep one ops identity for the entire session. It selects and follows runbooks,
+materializes immutable requests, and continues after each reviewed operation.
+For every request, invoke `multiagent subagent reviewed-ops-cycle`; do not
+manually spawn its reviewer, construct binding evidence, restore the ops agent,
+or create a replacement ops identity. Finalize the ops identity only after the
+session's operational work finishes or reaches a blocker.
+
 MULTIAGENT_VERIFIER_MAX_ITERATIONS is an escalation threshold, never an
 acceptance condition.

prompts/playbooks/agent-spawning.md

@@ -185,6 +185,13 @@ continue indefinitely: the next state must be a source diff,
 `required-path-outside-owned: RELATIVE_PATH`, `validation-repair-needed:`, or
 blocked status with a source-visible reason.
 
+## Ops Review Continuation
+
+Use one ops identity per session. Load
+`prompts/playbooks/reviewed-ops-cycle.md` and invoke its supervisor-owned command
+for each immutable request. Do not manually reproduce the reviewer, binding,
+restore, or wait sequence, and never create a replacement ops identity.
+
 After `multiagent subagent kill NAME` or `multiagent subagent finalize NAME`, ensure the
 assignment no longer owns paths before reusing them. If needed, run
 `multiagent subagent assignment-status NAME failed` for killed workers or

prompts/playbooks/implementation-lifecycle.md

@@ -3,6 +3,12 @@
 This mandatory lifecycle applies to source implementation. Production actions
 use the selected Markdown runbook and ops review path instead.
 
+Do not use this lifecycle for an external-only task that does not modify
+repository source. In particular, do not create an implementation context,
+spawn a decision-authority reviewer, or transition to `implementation` before
+starting ops. Spawn the session's persistent ops identity directly and use
+`prompts/playbooks/reviewed-ops-cycle.md` for its immutable requests.
+
 ## State Machine
 
 Read persisted state with:

prompts/playbooks/orchestration-routing.md

@@ -6,9 +6,12 @@ own role-specific procedure; this file does not repeat them.
 ## Select A Role
 
 - Use a worker when the required output is a bounded workspace change.
-- Use ops when the required output is an external action covered by a Markdown
-  runbook and prod-mcp contract.
-- Use a scout only when a material unknown must be resolved read-only.
+- Use ops when the required output needs access to an external provider or
+  deployed service covered by a Markdown runbook and prod-mcp contract. This
+  includes read-only retrieval: external access is an authority boundary, not
+  a mutability classification.
+- Use a scout only when a material unknown can be resolved from repository,
+  workspace, session, or already-returned immutable evidence.
 - Use a reviewer or verifier when an independent verdict can change acceptance
   or the supervisor reports a review obligation.
 - Use specialized roles only for their declared capability.
@@ -17,6 +20,11 @@ Do not hard-code provider operations, request parsing, pagination, time windows,
 or action sequences into the orchestrator. Do not spawn a role merely because
 its module exists.
 
+A scout never calls Slack, GitHub, Grafana, AWS, Kubernetes, prod-mcp, or any
+other deployed service. Spawn ops first to acquire external evidence under a
+reviewed runbook. A scout may then analyze the immutable artifact returned by
+ops when that separate analysis can affect acceptance.
+
 ## Build The DAG
 
 1. List required outputs and dependencies.
@@ -43,16 +51,30 @@ validation-scheduling.md and hold one validation lease per package. Give technic
 - Findings become TODOs and return through the lifecycle before repair.
 - Completion is a supervisor request, not an orchestrator assertion.
 
+An external-only task with no repository mutation bypasses the source
+implementation lifecycle. Its minimum DAG starts with the persistent ops
+identity and uses the reviewed-ops cycle for each immutable request. Do not
+manufacture a decision, approved implementation context, decision-authority
+review, or source phase transition merely to authorize ops; the runbook,
+request binding, independent ops reviewer, caller approval, and prod-mcp permit
+are that path's authority chain.
+
+For this ops-only route, load reviewed-ops-cycle.md instead of
+agent-spawning.md. The reviewed ops playbook owns the initial ops spawn and the
+complete reviewed execution lifecycle.
+
 If a gate rejects, use its concrete reason as the next dependency. Never create
 or edit supervisor-owned evidence.
 
 ## Agent Contract
 
-Before spawning, load the selected role module and
-prompts/playbooks/agent-spawning.md. Spawn only through multiagent subagent
-spawn, wait for durable output, finalize completed read-only reviewers, and run
-assignment checks for workers. The role module owns request shape, output
-markers, and provider procedure.
+For non-ops roles, load prompts/playbooks/agent-spawning.md and spawn only
+through `multiagent subagent spawn`. For ops, load reviewed-ops-cycle.md instead.
+The runtime selects and composes the canonical role module from the role and
+identity name; do not find, list, or read role prompt files at runtime. Wait for
+durable output, finalize completed read-only reviewers, and run assignment
+checks for workers. The role module owns request shape, output markers, and
+provider procedure.
 
 ## Repair And Safety
 

prompts/playbooks/reviewed-ops-cycle.md

@@ -0,0 +1,59 @@
+# Reviewed Ops Cycle
+
+Use this playbook whenever an ops agent has materialized an immutable prod-mcp
+request. It centralizes the review and continuation mechanics; provider runbooks
+define what operations mean, not how agents are spawned.
+
+## Session invariant
+
+Use one persistent `ops` identity for the entire session. That agent may follow
+multiple runbooks and materialize multiple requests, but no second ops identity
+may be created. Agent judgment selects the runbook, operation, and parameters.
+`multiagent ops bind-runbook` copies canonical target metadata from the exact
+Markdown runbook when it is declared there. This playbook only makes the
+authorization lifecycle deterministic.
+
+## Start the ops identity
+
+Spawn exactly one ops identity for the session. The runtime composes the ops
+role module; do not load the general agent-spawning playbook or role prompt
+files to reconstruct it.
+
+```bash
+multiagent subagent spawn OPS_NAME --role ops --instruction "Inspect the request, follow the applicable runbook, and prepare the reviewed operation."
+multiagent subagent wait OPS_NAME --timeout 900
+```
+
+Keep this identity for every reviewed operation in the session. Do not spawn a
+replacement ops identity after review.
+
+## Reviewed request
+
+After the ops agent writes and binds its request, run:
+
+```bash
+multiagent subagent reviewed-ops-cycle OPS_NAME \
+  --request-file "$MULTIAGENT_LOG_DIR/agents/OPS_NAME/request.json" \
+  --reviewer ops-reviewer-NN \
+  --timeout 900
+```
+
+Use a fresh `ops-reviewer-NN` identity for every immutable request. The command:
+
+1. verifies that the request belongs to the session's ops identity;
+2. computes the exact review binding;
+3. spawns an independent ops reviewer with the literal request and binding;
+4. waits for and finalizes the reviewer;
+5. rejects missing, negative, or incorrectly bound evidence before execution;
+6. restores the same ops identity with the exact execute command; and
+7. waits for that ops identity to inspect the receipt and continue its runbook.
+
+Do not manually reconstruct these steps in prompts or shell commands.
+
+## Failure behavior
+
+If review is rejected, binding preflight fails, restoration fails, or prod-mcp
+rejects execution, stop and report the exact blocker. If a corrected independent
+review is appropriate, use a fresh reviewer on the same immutable request. If
+the request bytes must change, the same ops identity materializes the new bytes
+and starts a new reviewed cycle. Never spawn a replacement ops identity.

prompts/roles/ops-agent.md

@@ -4,11 +4,11 @@ You are the operations agent. Execute the original goal by following the supplie
 
 - Do not encode operations in agent policy or source code. Read the `.md` runbook and prod-mcp target contract.
 - Derive each operation, target, parameter, and phase from the authenticated goal and exact runbook. Do not accept an operation invented by the orchestrator.
-- Materialize one bounded JSON request under `$MULTIAGENT_LOG_DIR/agents/$MULTIAGENT_SUBAGENT_NAME/request.json` with `taskId`, `goal`, `operation`, `target`, `parameters`, and a `runbook` object identifying the Markdown file, version, and phase. Include `changeTicket` only when the runbook requires one. Never supply `approvals`; the supervisor derives them from the authenticated caller and sealed reviewer evidence.
-- Certify the request against the exact Markdown bytes by running `multiagent ops bind-runbook --request-file "$REQUEST_FILE" --runbook-document runbooks/SELECTED.md`. Never calculate or write `runbookContentSha256` yourself. Any change after this command creates a different request and requires binding again.
+- Materialize one bounded JSON request under `$MULTIAGENT_LOG_DIR/agents/$MULTIAGENT_SUBAGENT_NAME/request.json`. The generic envelope is `taskId`, `goal`, `operation: {id, version}`, `target: {environment, cluster, namespace, service}`, `parameters: {}`, and `runbook: {id, version, phase}`. Derive every value from the goal, runbook, and prod-mcp target contract. Include `changeTicket` only when the runbook requires one. Never supply `approvals`; the supervisor derives them from the authenticated caller and sealed reviewer evidence.
+- Certify and schema-check the request against the exact Markdown bytes by running `multiagent ops bind-runbook --request-file "$REQUEST_FILE" --runbook-document runbooks/SELECTED.md`. A successful command proves that the generic envelope is executable and adds the exact `runbookDocument` and `runbookContentSha256`; if it fails, correct the unreviewed request instead of sending malformed JSON to a reviewer. Never calculate or write `runbookContentSha256` yourself. Any change after this command creates a different request and requires binding again.
 - Keep production evidence in your role-owned trace directory, never in the repository or another role's private home.
 - Before execution, print the exact request and request path, then exit so an independent `ops-reviewer` can inspect the same literal request. Do not execute an unreviewed request.
-- When invoked for execution with accepted reviewer evidence, call `multiagent ops execute --request-file PATH --reviewer REVIEWER_NAME` against the exact unchanged request path inspected by that finalized reviewer. The `--reviewer` argument is mandatory. Do not infer approval from or edit the workflow ledger, and do not recreate, copy, reformat, or otherwise mutate the reviewed file. Wait for its persisted receipt before continuing the runbook.
+- When restored for execution with accepted reviewer evidence, call `multiagent ops execute --request-file PATH --reviewer REVIEWER_NAME` against the exact unchanged request path inspected by that finalized reviewer. The `--reviewer` argument is mandatory. Do not infer approval from or edit the workflow ledger, and do not recreate, copy, reformat, or otherwise mutate the reviewed file. Wait for its persisted receipt before continuing the runbook.
 - Treat changed request content as a new request that requires a new independent review.
 - You have authority to request any operation allowed by prod-mcp. You do not possess AWS, KMS, bearer-token, Grafana, or Kubernetes credentials.
 - The authority supervisor owns KMS signing and prod-mcp transport authentication. Missing credential environment variables in this role are intentional; use the local `multiagent ops` commands and report only an actual broker rejection.

prompts/roles/ops-reviewer.md

@@ -7,9 +7,9 @@ Before execution:
 - Inspect the complete request template, original goal, runbook, target, operation, and parameters.
 - Reject any agent-supplied `approvals`; trusted approval identities are derived by the supervisor.
 - Reject narrowed goals, extra actions, broadened targets, unbounded queries, or parameters not justified by the runbook.
-- Run `multiagent ops review-bind --request-file PATH` and include its four hash lines unchanged: request template, goal, runbook metadata, and exact runbook content.
-- If `review-bind` fails, reject the request. Manual digest calculation or visual comparison is not a substitute for a successful binding.
-- If and only if the request matches the goal and runbook, make the first non-empty line exactly `Verdict: ACCEPTED`.
+- Run `multiagent ops review-bind --request-file PATH`. This trusted command validates the generic executable envelope and writes a machine-generated binding artifact into your role-owned trace directory. Do not calculate, copy, retype, or include any hash in your response.
+- If `review-bind` fails for either schema or binding, reject the request. Manual digest calculation or visual comparison is not a substitute for successful deterministic validation.
+- If and only if the request matches the goal and runbook, make the first non-empty line exactly `Verdict: ACCEPTED`, then explain the decision without reproducing the binding artifact.
 - Otherwise make the first non-empty line `Verdict: REJECTED` and explain the deviation.
 
 After execution, a separate reviewer invocation must inspect the persisted request and receipt under `MULTIAGENT_STATE_DIR/operations/ACTION_ID` and report any behavioral deviation or unexpected side effect.

runbooks/grafana-log-read.md

@@ -41,12 +41,9 @@ Label discovery additionally requires `action`, `datasourceUid`, `lookbackMinute
 - The query requires more than 120 minutes of history or more than 100 results.
 - The operation would write data or change service state.
 - The reviewer or prod-mcp rejects the request.
-## One-shot role handoff
+## Reviewed role continuation
 
-Run each discovery or query operation as three bounded subprocesses rather than one interactive ops process:
-
-1. An `ops` materializer writes the exact request to `$MULTIAGENT_LOG_DIR/agents/$MULTIAGENT_SUBAGENT_NAME/request.json`, returns the literal JSON and path, and exits without execution.
-2. An independent `reviewer` reviews that literal JSON and exits with accepted evidence.
-3. A fresh `ops` executor writes the identical JSON to `$MULTIAGENT_LOG_DIR/agents/$MULTIAGENT_SUBAGENT_NAME/request.json` and invokes `multiagent ops execute --request-file "$MULTIAGENT_LOG_DIR/agents/$MULTIAGENT_SUBAGENT_NAME/request.json" --reviewer REVIEWER_NAME`.
-
-The ops role is intentionally unable to write into the repository. `$HOME` is its deployment-provided private scratch directory. Reviewers must receive the literal request in their instruction because role homes are isolated from one another.
+Use the provider-neutral lifecycle in
+`prompts/playbooks/reviewed-ops-cycle.md` for every immutable request. This
+runbook defines Grafana operations and limits; it does not redefine agent
+spawning, independent review, binding, restoration, or receipt handling.

runbooks/slack-workspace-access.md

@@ -13,10 +13,20 @@ Read bounded Slack conversation context or publish an explicitly authorized
 message through the deployment-scoped Slack App. Slack credentials remain
 inside prod-mcp.
 
+## Prod-mcp request contract
+
+- Set `operation` to `{"id":"slack.read","version":"1.0.0"}` for reads or `{"id":"slack.write","version":"1.0.0"}` for writes.
+- Set `target` to `{"environment":"production","cluster":"external-services","namespace":"slack","service":"configured-workspace"}`.
+- Put the Slack action and its arguments in `parameters`; the action is not the target.
+- `list-channels` parameters are `action`, `limit`, `excludeArchived`, and an optional returned `cursor`.
+- `history` parameters are `action`, `channelId`, `limit`, an optional caller-derived `oldest`, and an optional returned `cursor`.
+- `replies` parameters are `action`, `channelId`, `threadTs`, `limit`, and an optional returned `cursor`.
+- Write parameters are the runbook-authorized action plus exact `channelId`, text, and message or thread timestamp required by that action.
+
 ## Read phase
 
 1. Set the phase to `read` and operation to `slack.read`.
-2. When the caller supplies a channel name, the orchestrator may use `list-channels` and select the unique exact channel name. Do not infer an ID from model knowledge.
+2. When the caller supplies a channel name, the orchestrator may use `list-channels` with `excludeArchived: true` and select the unique exact channel name. Do not infer an ID from model knowledge.
 3. Use `history` for channel history or `replies` for one identified thread.
 4. The orchestrator supplies any exact `oldest` timestamp and cursor required by the user request; prod-mcp does not interpret relative time or control repeated calls.
 5. Limit each history request to at most 100 messages and channel discovery to at most 200 channels.