codex-workflow-v2 2.0.0-beta.1 → 2.0.0-beta.10

package/docs/development-flow.md

@@ -40,6 +40,11 @@ failed checks, or any manual/unrecorded Worker commit block completion.
 If the current Plan Risk Audit marks the Step for strict review, the atomic commit is still
 created by core, but the Step remains non-terminal and `next` routes to `task step-review`
 until commit-bound strict review and reviewer attestation pass.
+Use the exact claimant or required actor from `next` as `--actor`; the independent reviewer
+runs inside Core and is not supplied as the CLI actor.
+When `next` includes `gitMutationPolicy`, obtain bounded permission for that exact Git-writing
+transition before the first call instead of probing and retrying after a `.git/index.lock`
+failure. For `task start`, this applies only when invoking `--workspace-owner local`.
 
 After a Step changes approved project knowledge, the Delivery Coordinator reconciles and
 reapproves the Project Knowledge Map, then runs `task knowledge-rebind` between Steps. The
@@ -58,7 +63,9 @@ additions under Milestone autonomy; every unsafe source-set, category, scope, au
 conflict change is rejected.
 
 Submission requires a clean, auditable Task history and records evidence for the exact
-Task head. `task review-launch` starts a separate read-only reviewer. A passing fresh review
+Task head. `task review-launch` starts a separate read-only reviewer and atomically records its
+result. If C1 handoff is active, keep `--actor` equal to the current claimant or required actor
+from `next`; the reviewer identity remains internal to the compound route. A passing fresh review
 permits Result creation. Human final acceptance binds Brief, Plan, Result, evidence, and
 the accepted head. Base advancement forces synchronization, checks, review, and acceptance
 to be repeated before merge.
@@ -97,7 +104,12 @@ may finish while an amendment awaits authorization.
 
 During initial planning, all linked Tasks may be materialized before one complete
 `milestone plan-set`; no execution is available until the Plan classifies every reverse
-membership. After that boundary, semantic changes use human-only
+membership. Repository `next` returns `milestone initial-assembly` both before Task 1 and between
+linked Tasks. Its `linked-task-assembly` option explicitly permits `discovery start` and
+`discovery materialize`; after the first linked Task exists, its closing option permits one
+complete `milestone plan-set`. A failed
+`status` or `next` is not permission to call the closing command directly. After that boundary,
+semantic changes use human-only
 `milestone scope-change-prepare` and `milestone scope-change-apply`. A previously issued
 Milestone Autonomy Contract may instead use `milestone autonomy-evolve` for membership-only
 changes while the outcome, success signal, acceptance, checks, discovery, and base branch
@@ -128,11 +140,29 @@ With an eligible `milestone.final_accept` grant, `next` additionally returns
 `delegatedApprovalOptions`. The delegate may then use the current `MSA-*` code in the same
 turn because the earlier grant-issuance turn is the controlling user decision. Without such
 an option, the ordinary later-message human gate remains mandatory.
+Pass `--delegation-grant` only when the same `next` response exposes an exact eligible
+`delegatedApprovalOptions` entry for that transition. Ordinary C1 handoff, claim, run,
+step-complete, step-review, merge, and sync-base do not consume a Milestone approval grant.
 
 The Milestone coordinator keeps implementation out of its long-lived context: every required
 Task runs in a dedicated user-visible Task chat. The Milestone chat owns ordering, exact
 delegated transitions, merge observation, cross-Task validation, and final acceptance.
 
+The coordinator creates that chat as a new standalone Codex task, never as a fork/handoff of its
+own thread, and sends only a fresh TaskContextPacket for the exact Task. It creates or reuses the
+chat just before dispatch, not as an empty membership placeholder. The project registry allocates
+one monotonic `#NNN` and builds `#NNN · M<NN> · Coord · <Milestone title> · <MS-ID>` or
+`#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>`; the Task ordinal still comes from approved
+membership order. Exact readback and registry-owned fallback are mandatory.
+
+Dispatch is followed by an explicit coordinator supervision loop. The Milestone chat waits on the
+one currently routed Task chat with bounded `wait_threads` calls, reads it when it completes or
+needs attention, and then verifies repository `status -> next`. A recoverable non-human boundary is
+returned to the same chat with `send_message_to_thread`; only a genuine user/semantic gate or
+unrecoverable blocker ends the coordinator turn. The next Task chat is created only after Core
+confirms that the prior required Task is terminal and merged. Task completion does not implicitly
+wake a coordinator that has already ended its turn.
+
 ## Responsibility boundaries
 
 | Participant | Responsible for | Cannot decide |