codex-workflow-v2 2.0.0-alpha.7.2.1 → 2.0.0-beta.10

package/docs/delegated-approval.md

@@ -118,7 +118,32 @@ project, status active, delegate, scope, transitions и expiresAt. Не созд
 всегда agent:deputy, никогда user.
 
 Required Tasks выполняй последовательно. Для каждой Task обязательно создай
-отдельный пользовательский Codex-чат, передав ему Task delegate prompt, тот же actor и DGR-ID.
+новую standalone Codex task через create_thread, а не fork/handoff/продолжение этого чата.
+Передай только TaskContextPacket из свежего Workflow state: repository, exact Milestone/Task ID,
+membership ordinal, Task revision/title, Brief/Plan bindings, requirements/acceptance, Task-local
+scope/checks/stop conditions, маршрут status -> next --task <exact Task ID> и тот же actor/DGR-ID
+только когда они требуются. Не передавай transcript этого чата, sibling Tasks, recovery narrative,
+reasoning, confirmation codes, handoff credentials или writer tokens.
+Title обязателен и выделяется проектным registry:
+#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>. До dispatch проверь уникальность
+Task-ID-to-thread mapping, выполни exact registry readback и проверь Task-only input. Служебный
+codex_delegation envelope с source_thread_id допустим, parent turns/transcript запрещены. Если
+title отсутствует или изменён, явно переименуй и перепроверь. Ошибка create_thread не разрешает
+fallback на fork_thread.
+Если readback изменён, применяй только deterministic fallback registry; полный `#NNN`, ordinal и
+entity ID сохраняются. В
+TaskContextPacket потребуй закрытый secret-free CoordinatorReport на terminal/attention boundary:
+Task ID, observed revision/status, outcome, next action, requiresUser, blocker class,
+commits/checks/review evidence; никаких confirmation/handoff/writer bearer values.
+После dispatch не завершай coordinator turn. Жди текущий Task-чат через bounded wait_threads,
+сохраняй cursor, а при completed/attention прочитай чат и выполни свежий status -> общий next.
+Если та же Task остаётся nonterminal и точный next допускает non-human continuation, продолжи тот
+же чат через send_message_to_thread. Пользователя привлекай только для mandatory human/semantic
+gate, external permission, unrecoverable integrity conflict или исчерпанного infrastructure retry.
+Следующий Task-чат создавай только после подтверждённого Core terminal+merged результата текущей
+Task. Завершать Milestone-чат при работающей nonterminal Task можно лишь по явной команде
+checkpoint либо при таком блокере; обязательно сохрани Task/thread/host/title/cursor mapping и
+fresh next для возобновления без duplicate dispatch.
 Milestone-чат не реализует Steps и не накапливает fix-loop всех Tasks;
 не запускай два writer на одном checkout. Worker и Reviewer не используют
 grant: approval-команды выполняет только delegate-координатор после их evidence.
@@ -160,9 +185,10 @@ exact `task step-complete` из `next`, а core выполняет checks, со
 записывает evidence. Worker не использует grant. При изменении Knowledge Map
 выполни reconcile; approve разрешён только при exact project_memory.approve
 option этого project-scoped grant. Затем knowledge-rebind и новая authorization.
-Если next содержит exact `contextRefresh` для того же grant, можешь вместо четырёх
-команд выполнить `task context-refresh`; при любом изменении source set,
-category/authority, gaps или conflicts используй обычный видимый процесс.
+Если next возвращает top-level `action: task context-refresh` и exact `contextRefresh` для того же
+grant, выполни только `task context-refresh`; не запускай перед ним standalone reconcile. Exact
+Plan-declared supporting additions допустимы только когда их признал Core. При любом другом
+изменении source set, category/authority, gaps или conflicts используй обычный видимый процесс.
 
 После submit запусти отдельный Independent Reviewer; Reviewer не использует
 grant и не исправляет код. После второго failed review не запускай очередной

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
@@ -50,13 +55,17 @@ active Worker Step, a no-op binding, an invalid knowledge target, or a modified
 artifact. After the user authorizes the rebound Plan, execution resumes in the existing
 workspace; if all Steps are complete, the next action is submission.
 
-When `next.contextRefresh` exposes an eligible project-scoped grant and content-only mode,
-`task context-refresh` may compose reconcile, delegated map approval, rebind, and delegated
-execution reauthorization. Core validates both approval transitions before writing and
-rejects any source-set, category, scope, authority, gap, or conflict change.
+When `next` returns top-level `action: task context-refresh` with an eligible grant,
+`task context-refresh` composes reconcile, delegated map approval, rebind, and delegated
+execution reauthorization. Do not run standalone reconcile first. Core validates both approval
+transitions before writing. It permits content-only drift and exact Plan-declared supporting-source
+additions under Milestone autonomy; every unsafe source-set, category, scope, authority, gap, or
+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.
@@ -95,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
@@ -126,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 |