codex-workflow-v2 2.0.0-beta.1 → 2.0.0-beta.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +13 -2
- package/dist/src/alpha6/milestone.d.ts +10 -0
- package/dist/src/alpha6/milestone.js +98 -1
- package/dist/src/alpha6/milestone.js.map +1 -1
- package/dist/src/cli.js +220 -3
- package/dist/src/cli.js.map +1 -1
- package/dist/src/reviewer.d.ts +4 -0
- package/dist/src/reviewer.js +24 -7
- package/dist/src/reviewer.js.map +1 -1
- package/dist/src/version.d.ts +1 -1
- package/dist/src/version.js +1 -1
- package/dist/src/workflow.d.ts +18 -0
- package/dist/src/workflow.js +186 -8
- package/dist/src/workflow.js.map +1 -1
- package/docs/autonomy-guardrails.md +8 -1
- package/docs/beta2-initial-assembly-navigation-brief.md +616 -0
- package/docs/development-flow.md +17 -2
- package/docs/release.md +8 -1
- package/docs/split-required-recovery.md +5 -4
- package/docs/stable-release-defect-register.md +330 -1
- package/docs/updating-existing-project.md +2 -0
- package/package.json +1 -1
- package/plugins/codex-workflow-gateway/references/protocol.md +56 -1
- package/plugins/codex-workflow-gateway/skills/codex-workflow-gateway/SKILL.md +44 -0
- package/references/state-machine.md +4 -1
package/docs/development-flow.md
CHANGED
|
@@ -40,6 +40,11 @@ failed checks, or any manual/unrecorded Worker commit block completion.
|
|
|
40
40
|
If the current Plan Risk Audit marks the Step for strict review, the atomic commit is still
|
|
41
41
|
created by core, but the Step remains non-terminal and `next` routes to `task step-review`
|
|
42
42
|
until commit-bound strict review and reviewer attestation pass.
|
|
43
|
+
Use the exact claimant or required actor from `next` as `--actor`; the independent reviewer
|
|
44
|
+
runs inside Core and is not supplied as the CLI actor.
|
|
45
|
+
When `next` includes `gitMutationPolicy`, obtain bounded permission for that exact Git-writing
|
|
46
|
+
transition before the first call instead of probing and retrying after a `.git/index.lock`
|
|
47
|
+
failure. For `task start`, this applies only when invoking `--workspace-owner local`.
|
|
43
48
|
|
|
44
49
|
After a Step changes approved project knowledge, the Delivery Coordinator reconciles and
|
|
45
50
|
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
|
|
|
58
63
|
conflict change is rejected.
|
|
59
64
|
|
|
60
65
|
Submission requires a clean, auditable Task history and records evidence for the exact
|
|
61
|
-
Task head. `task review-launch` starts a separate read-only reviewer
|
|
66
|
+
Task head. `task review-launch` starts a separate read-only reviewer and atomically records its
|
|
67
|
+
result. If C1 handoff is active, keep `--actor` equal to the current claimant or required actor
|
|
68
|
+
from `next`; the reviewer identity remains internal to the compound route. A passing fresh review
|
|
62
69
|
permits Result creation. Human final acceptance binds Brief, Plan, Result, evidence, and
|
|
63
70
|
the accepted head. Base advancement forces synchronization, checks, review, and acceptance
|
|
64
71
|
to be repeated before merge.
|
|
@@ -97,7 +104,12 @@ may finish while an amendment awaits authorization.
|
|
|
97
104
|
|
|
98
105
|
During initial planning, all linked Tasks may be materialized before one complete
|
|
99
106
|
`milestone plan-set`; no execution is available until the Plan classifies every reverse
|
|
100
|
-
membership.
|
|
107
|
+
membership. Repository `next` returns `milestone initial-assembly` both before Task 1 and between
|
|
108
|
+
linked Tasks. Its `linked-task-assembly` option explicitly permits `discovery start` and
|
|
109
|
+
`discovery materialize`; after the first linked Task exists, its closing option permits one
|
|
110
|
+
complete `milestone plan-set`. A failed
|
|
111
|
+
`status` or `next` is not permission to call the closing command directly. After that boundary,
|
|
112
|
+
semantic changes use human-only
|
|
101
113
|
`milestone scope-change-prepare` and `milestone scope-change-apply`. A previously issued
|
|
102
114
|
Milestone Autonomy Contract may instead use `milestone autonomy-evolve` for membership-only
|
|
103
115
|
changes while the outcome, success signal, acceptance, checks, discovery, and base branch
|
|
@@ -128,6 +140,9 @@ With an eligible `milestone.final_accept` grant, `next` additionally returns
|
|
|
128
140
|
`delegatedApprovalOptions`. The delegate may then use the current `MSA-*` code in the same
|
|
129
141
|
turn because the earlier grant-issuance turn is the controlling user decision. Without such
|
|
130
142
|
an option, the ordinary later-message human gate remains mandatory.
|
|
143
|
+
Pass `--delegation-grant` only when the same `next` response exposes an exact eligible
|
|
144
|
+
`delegatedApprovalOptions` entry for that transition. Ordinary C1 handoff, claim, run,
|
|
145
|
+
step-complete, step-review, merge, and sync-base do not consume a Milestone approval grant.
|
|
131
146
|
|
|
132
147
|
The Milestone coordinator keeps implementation out of its long-lived context: every required
|
|
133
148
|
Task runs in a dedicated user-visible Task chat. The Milestone chat owns ordering, exact
|
package/docs/release.md
CHANGED
|
@@ -15,12 +15,14 @@ Before tagging a release:
|
|
|
15
15
|
5. `npm run plugin:check`
|
|
16
16
|
6. `npm run release:check`
|
|
17
17
|
7. validate `plugins/codex-workflow-gateway` with the Codex plugin validator
|
|
18
|
+
8. validate the append-only real-agent log with
|
|
19
|
+
`node scripts/validate-lifecycle-transcript.mjs --file <lifecycle-log.jsonl>`
|
|
18
20
|
|
|
19
21
|
The downstream smoke packs the actual tarball, installs it into an empty temporary project,
|
|
20
22
|
runs the packaged CLI handshake, and proves installation created none of `.codex`, `.tasks`,
|
|
21
23
|
`.increments`, or `.memory-bank` in that project.
|
|
22
24
|
|
|
23
|
-
For beta.
|
|
25
|
+
For beta.2, the release gate also relies on `npm run release:check` to fail if:
|
|
24
26
|
|
|
25
27
|
- canonical entity schema 2 shapes drift;
|
|
26
28
|
- protocol 1 compatibility is no longer additive;
|
|
@@ -30,6 +32,11 @@ For beta.1, the release gate also relies on `npm run release:check` to fail if:
|
|
|
30
32
|
proof-obligation capabilities and schemas are absent from the packaged surface;
|
|
31
33
|
- terminal Task replacement, project-level transaction recovery, secret-safe lock diagnostics,
|
|
32
34
|
version/base diagnostics, or serialized maintainer validation are missing.
|
|
35
|
+
- truthful initial-assembly navigation capability is absent from the packaged surface.
|
|
36
|
+
|
|
37
|
+
The separate lifecycle transcript validator fails if the real-agent log contains a mutation that
|
|
38
|
+
bypasses failed `status`/`next`, an unadvertised or failed mutation, an unresolved syntax-only
|
|
39
|
+
retry, or missing post-mutation checkpoints.
|
|
33
40
|
|
|
34
41
|
Full `npm test` and `npm run validate` invocations share destructive build outputs and are therefore
|
|
35
42
|
single-owner operations. A concurrent invocation fails immediately with
|
|
@@ -23,14 +23,15 @@ Continue the active Milestone through the package-local codex-workflow-v2 Core o
|
|
|
23
23
|
create/link the replacement Task, change both memberships, supersede Milestone execution
|
|
24
24
|
authorization, and leave the Milestone awaiting reauthorization. Do not perform a separate
|
|
25
25
|
scope change for these effects.
|
|
26
|
-
5. Run `status
|
|
26
|
+
5. Run `status`, wait for terminal success, then run `next`; never issue the pair in parallel.
|
|
27
|
+
Verify: old Task `cancelled`; old membership `cancelled`; new Task
|
|
27
28
|
`planning` and `replacementForTaskId` points to the old Task; new membership `required`;
|
|
28
29
|
Milestone `awaiting_execution_authorization`. If any relation is missing, stop and run `doctor`.
|
|
29
|
-
6. Follow the exact `next` transition to reauthorize the changed Milestone. Run `status`
|
|
30
|
-
again. Do not reuse the historical Task's Plan or authorization.
|
|
30
|
+
6. Follow the exact `next` transition to reauthorize the changed Milestone. Run `status` to
|
|
31
|
+
terminal success and then `next` again. Do not reuse the historical Task's Plan or authorization.
|
|
31
32
|
7. Plan the replacement Task from its own Brief, record the required Plan Risk Audit, authorize it,
|
|
32
33
|
prepare and claim its C1 handoff, and execute only the exact Step returned by `next`. Run
|
|
33
|
-
`status`
|
|
34
|
+
sequential `status` then `next` checkpoints after every state boundary.
|
|
34
35
|
8. Complete review, final acceptance, merge, remaining required Tasks, Milestone validation, and
|
|
35
36
|
Milestone final acceptance through exact Core transitions. Never create a fourth remediation
|
|
36
37
|
attempt for the historical Task.
|
|
@@ -14,6 +14,335 @@ Last reviewed: 2026-08-15.
|
|
|
14
14
|
- **Closed-regression** means a patch exists; the stable release must retain its regression coverage.
|
|
15
15
|
- **Downstream** means the finding belongs to `signal_v4`, not to the workflow package.
|
|
16
16
|
|
|
17
|
+
## Beta.2 closure candidates
|
|
18
|
+
|
|
19
|
+
### WF-STABLE-009 — initial assembly creates a state rejected by `status` and `next`
|
|
20
|
+
|
|
21
|
+
- Status: Closed-regression in beta.2
|
|
22
|
+
- Severity: Critical
|
|
23
|
+
- Area: Milestone initial assembly, reverse membership, repository navigation
|
|
24
|
+
- Evidence: both the beta.1 real-agent E2E and the live read-only `signal_v4` reincarnation
|
|
25
|
+
materialized a first linked planning Task successfully, after which `status` and `next` returned
|
|
26
|
+
`MILESTONE_SCOPE_INCOMPLETE` for the intentionally repairable pre-Plan membership gap.
|
|
27
|
+
- Risk: the documented seven-Task initial assembly cannot follow authoritative `next`; agents must
|
|
28
|
+
either stop before work begins or bypass navigation and invalidate lifecycle evidence.
|
|
29
|
+
- Closure evidence: centralized initial-assembly assessment, deterministic fresh/adopted/unsafe
|
|
30
|
+
regressions, exact copied `signal_v4` snapshot replay, and real-agent seven-Task assembly all pass;
|
|
31
|
+
strict reverse-membership blocking remains active outside the exact predicate.
|
|
32
|
+
|
|
33
|
+
### WF-STABLE-010 — beta.1 release E2E continued after failed `next`
|
|
34
|
+
|
|
35
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
36
|
+
- Severity: Critical
|
|
37
|
+
- Area: release evidence, real-agent transcript validation
|
|
38
|
+
- Evidence: the beta.1 final E2E transcript contains failed `status` and `next` calls with
|
|
39
|
+
`MILESTONE_SCOPE_INCOMPLETE`; the Delegate labelled the gap expected, invoked direct
|
|
40
|
+
`milestone plan-set`, and the final audit still accepted the run despite the Brief explicitly
|
|
41
|
+
declaring a `next` bypass invalid.
|
|
42
|
+
- Risk: a real-agent run can conceal a Core lifecycle defect and produce a false release
|
|
43
|
+
recommendation.
|
|
44
|
+
- Candidate evidence: the append-only transcript validator rejects navigation bypasses,
|
|
45
|
+
unadvertised mutations, failed non-retryable mutations, unresolved syntax retries, and
|
|
46
|
+
unterminated harness invocations. Final-21 passed the complete validator with `250/250` events.
|
|
47
|
+
|
|
48
|
+
### WF-STABLE-011 — pending Task review `next` names a non-autonomous primitive
|
|
49
|
+
|
|
50
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
51
|
+
- Severity: High
|
|
52
|
+
- Area: Task final review, truthful navigation, real-agent evidence
|
|
53
|
+
- Evidence: the first beta.2 real-agent diagnostic run reached a submitted Task with pending review;
|
|
54
|
+
`next` returned `task review-record`, while the packaged and successfully executed autonomous
|
|
55
|
+
command was `task review-launch`.
|
|
56
|
+
- Risk: an agent following the exact autonomous route appears to bypass authoritative navigation,
|
|
57
|
+
while an agent following the literal response must manufacture reviewer output instead of using
|
|
58
|
+
the isolated reviewer launcher.
|
|
59
|
+
- Candidate evidence: deterministic navigation regressions prove exact `task review-launch` while
|
|
60
|
+
preserving `task result-set` after a passed review. Final-21 completed strict Step review and the
|
|
61
|
+
final independent Task review without a rejected lifecycle mutation.
|
|
62
|
+
|
|
63
|
+
### WF-STABLE-012 — Core-owned Git transitions omit the sandbox permission contract
|
|
64
|
+
|
|
65
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
66
|
+
- Severity: High
|
|
67
|
+
- Area: Task execution, truthful navigation, Codex sandbox integration
|
|
68
|
+
- Evidence: the rebuilt beta.2 real-agent E2E followed `next.action = task step-complete`; Core ran
|
|
69
|
+
its owned checks and then failed non-mutating at `git add` because `.git/index.lock` was denied.
|
|
70
|
+
The exact same transition succeeded after a bounded Git-metadata escalation.
|
|
71
|
+
- Risk: a nominally autonomous Milestone learns required authority only by failing a lifecycle
|
|
72
|
+
mutation. This creates noisy retry history, invalidates clean release transcripts, and can strand
|
|
73
|
+
less capable agents despite a valid Plan and grant.
|
|
74
|
+
- Candidate evidence: positive and negative navigation regressions cover the four local Git-writing
|
|
75
|
+
transitions and absence on read-only/external routes. Final-21 consumed the policy before local
|
|
76
|
+
start, Step completion, and Core merge without a rejected lifecycle mutation.
|
|
77
|
+
|
|
78
|
+
### WF-STABLE-013 — strict reviewer can wait indefinitely or fail before launch
|
|
79
|
+
|
|
80
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
81
|
+
- Severity: Critical
|
|
82
|
+
- Area: strict Step review, final Task review, non-interactive Codex subprocess lifecycle
|
|
83
|
+
- Evidence: beta.2 `real-agent-release-final-6` left two `task step-review` parents and two nested
|
|
84
|
+
`codex exec` reviewers alive for more than five minutes at unchanged Task revision `6`. Neither
|
|
85
|
+
invocation returned a terminal success or failure result.
|
|
86
|
+
- Additional evidence: beta.2 `real-agent-release-final-10` exposed an integration error in the
|
|
87
|
+
first correction: the global `--ask-for-approval never` option was placed after `exec`, which the
|
|
88
|
+
real Codex CLI rejected with status `2`. Two launch failures consumed the two ordinary
|
|
89
|
+
remediation attempts before the run was stopped.
|
|
90
|
+
- Root cause: the strict reviewer used inherited/default approval behavior despite intentionally
|
|
91
|
+
probing a denied write, the synchronous subprocess had no host-side deadline, and the initial
|
|
92
|
+
correction did not test the real CLI's global-option ordering contract.
|
|
93
|
+
- Risk: an autonomous Milestone can hang forever inside Core before review evidence exists; a retry
|
|
94
|
+
can create a second concurrent reviewer for the same Step/revision.
|
|
95
|
+
- Candidate evidence: strict reviewers now place `approval=never` before the `exec` subcommand,
|
|
96
|
+
retain read-only sandboxing, and have a fixed host-side execution deadline that returns terminal
|
|
97
|
+
`unverified` evidence on timeout. Focused tests assert the exact global-option ordering as well as
|
|
98
|
+
deadline propagation and timeout fail-closed behavior. Final-21 completed both strict reviewer
|
|
99
|
+
invocations under the non-interactive, ephemeral, ignore-config/rules, read-only contract.
|
|
100
|
+
|
|
101
|
+
### WF-STABLE-014 — transcript validator accepts a started mutation with no terminal result
|
|
102
|
+
|
|
103
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
104
|
+
- Severity: Critical
|
|
105
|
+
- Area: release evidence, append-only harness transcript, indeterminate mutation recovery
|
|
106
|
+
- Evidence: the incomplete `real-agent-release-final-6` transcript originally returned PASS with
|
|
107
|
+
`181` checked events even though two `task step-review` commentaries had no matching mutation
|
|
108
|
+
result and the Task remained at revision `6`. Final-8 then exposed the same class for read-only
|
|
109
|
+
commands: successful `milestone autonomy-prepare` had no terminal observation event, so the
|
|
110
|
+
wrapper log alone could not distinguish success, failure, or interruption.
|
|
111
|
+
- Risk: a hung or externally interrupted mutation can be presented as valid release evidence; an
|
|
112
|
+
agent may re-enter the same semantic transition without knowing whether the first process is
|
|
113
|
+
still active.
|
|
114
|
+
- Candidate evidence: the validator pairs trusted-harness invocation commentary with the exact
|
|
115
|
+
terminal navigation, mutation, or read-only observation result; rejects failed observations,
|
|
116
|
+
EOF with a pending invocation, and any second command before the pending invocation resolves.
|
|
117
|
+
Immutable final-6 and final-8 transcripts are retained as diagnostic evidence and rejected for
|
|
118
|
+
their respective stranded invocations.
|
|
119
|
+
|
|
120
|
+
### WF-STABLE-015 — `task plan-set` navigation omits its exact inclusion contract
|
|
121
|
+
|
|
122
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
123
|
+
- Severity: High
|
|
124
|
+
- Area: Task planning navigation, autonomous Plan construction, fail-before-write usability
|
|
125
|
+
- Evidence: the Delegate followed `next.action = task plan-set` and produced substantive acceptance
|
|
126
|
+
statements, but Core rejected the first Plan because it did not contain the opaque Task acceptance
|
|
127
|
+
ID `AC-001` as an exact array member. The Task remained planning at revision `1`; the transcript
|
|
128
|
+
correctly rejected the run as failed release evidence.
|
|
129
|
+
- Root cause: Core validates exact Task requirement and acceptance ID inclusion, while `next`
|
|
130
|
+
previously exposed only the action and revision. The machine-readable precondition was visible
|
|
131
|
+
only indirectly in large status/Brief output and was not part of the exact transition contract.
|
|
132
|
+
- Candidate evidence: every `task plan-set` navigation now returns `taskPlanContract` with exact
|
|
133
|
+
required requirement IDs, acceptance IDs, current risks, Brief hash, and current Knowledge Map binding. The
|
|
134
|
+
packaged gateway requires planners to copy those exact IDs before adding semantic detail.
|
|
135
|
+
|
|
136
|
+
### WF-STABLE-016 — Git-completion navigation omits the required writer lease input
|
|
137
|
+
|
|
138
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
139
|
+
- Severity: High
|
|
140
|
+
- Area: Task completion/merge navigation, writer lease continuity, autonomous execution
|
|
141
|
+
- Evidence: after successful implementation, strict Step review, Task review, result, and delegated
|
|
142
|
+
acceptance, `next` advertised `task merge` plus `gitMutationPolicy`. The Delegate followed that
|
|
143
|
+
response without `--writer-token`; the CLI rejected the invocation before any mutation.
|
|
144
|
+
- Root cause: the mandatory writer lease was enforced by each transition but absent from the exact
|
|
145
|
+
machine-readable navigation contract. The gateway therefore had no local precondition telling it
|
|
146
|
+
to retain and pass the sensitive lease on the first call.
|
|
147
|
+
- Candidate evidence: `next` returns a non-secret `writerTokenContract` for `task step-complete`,
|
|
148
|
+
`task submit`, `task merge`, and `task merge-confirm`, and omits it for non-consuming adjacent
|
|
149
|
+
transitions. The packaged gateway treats it as a first-call precondition and never prints or
|
|
150
|
+
persists the token.
|
|
151
|
+
|
|
152
|
+
### WF-STABLE-017 — subcommand `--help` is treated as a lifecycle mutation
|
|
153
|
+
|
|
154
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
155
|
+
- Severity: High
|
|
156
|
+
- Area: CLI command discovery, autonomous execution, release transcript integrity
|
|
157
|
+
- Evidence: after clean seven-Task assembly and an active owner autonomy grant, the real Delegate
|
|
158
|
+
invoked `milestone authorize --help`. The CLI dispatched the underlying lifecycle operation and
|
|
159
|
+
rejected it with `INVALID_ARGUMENT: Missing required option --id` before any state write.
|
|
160
|
+
- Root cause: CLI dispatch had no early help route; parsed `--help` remained an unused option while
|
|
161
|
+
noun/action matching entered the ordinary mutation implementation.
|
|
162
|
+
- Candidate evidence: help is intercepted before repository/state construction, returns exit `0`
|
|
163
|
+
with a machine-readable `readOnly` response at top-level, noun, and action scopes, and never
|
|
164
|
+
requests mutation inputs or changes workflow state. Critical autonomous transitions expose exact
|
|
165
|
+
required and optional option lists. The transcript validator recognizes safe trusted-harness help
|
|
166
|
+
observations, rejects mutation-style help inputs, and requires a fresh successful `next` before
|
|
167
|
+
any subsequent mutation.
|
|
168
|
+
|
|
169
|
+
### WF-STABLE-018 — credential-bearing receipts are buried after large Task payloads
|
|
170
|
+
|
|
171
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
172
|
+
- Severity: High
|
|
173
|
+
- Area: C1 handoff, writer lease continuity, autonomous credential consumption
|
|
174
|
+
- Evidence: the real Delegate completed initial assembly through `task handoff-prepare` with zero
|
|
175
|
+
rejected lifecycle calls, then reported that the one-time claim token was unavailable. The raw
|
|
176
|
+
successful CLI result proves that the token was emitted exactly once but was buried after roughly
|
|
177
|
+
5 KiB of Task/event data; the wrapper did not truncate stdout.
|
|
178
|
+
- Root cause: credential-bearing values shared the same large compatibility payload as canonical
|
|
179
|
+
Task state and context. Although Core emitted the token correctly, the response supplied no
|
|
180
|
+
compact, prominent transfer receipt for an autonomous consumer.
|
|
181
|
+
- Candidate evidence: `task handoff-prepare` now emits first-field `credentialHandoff`, and `task
|
|
182
|
+
run` emits first-field `writerLeaseReceipt`. Both name the intended next action, source, target or
|
|
183
|
+
owner, option, and sensitivity; the exact credential occurs once, while legacy payload data and
|
|
184
|
+
read-only responses contain no duplicate secret.
|
|
185
|
+
|
|
186
|
+
### WF-STABLE-019 — claimed Task run requires a lease that navigation says will be issued later
|
|
187
|
+
|
|
188
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
189
|
+
- Severity: High
|
|
190
|
+
- Area: C1 claim, writer lease continuity, truthful Task navigation
|
|
191
|
+
- Evidence: the real Delegate consumed the first-field claim token and completed `task claim`, then
|
|
192
|
+
safely paused for bounded Git permission. After resume, Core-owned `task start` succeeded. The
|
|
193
|
+
following `next` advertised `task run` without a writer-token contract, and the exact call was
|
|
194
|
+
rejected because claimed posture already required the lease created by claim.
|
|
195
|
+
- Root cause: the first writer-lease receipt was emitted by `task run`, but claimed posture requires
|
|
196
|
+
that same credential as an input to run. `task claim` returned the lease only inside its large
|
|
197
|
+
payload, while action-only navigation intentionally omitted `task run` from the writer contract.
|
|
198
|
+
- Candidate evidence: `task claim` now emits first-field `writerLeaseReceipt` with `task run` as its
|
|
199
|
+
consuming action, and claimed `task run` navigation advertises the exact `--writer-token`
|
|
200
|
+
precondition. Unclaimed runs still acquire their initial lease without a token.
|
|
201
|
+
|
|
202
|
+
### WF-STABLE-020 — transcript validator rejects safe top-level help
|
|
203
|
+
|
|
204
|
+
- Status: Closed-regression in beta.2
|
|
205
|
+
- Severity: High
|
|
206
|
+
- Area: release transcript integrity, read-only CLI discovery
|
|
207
|
+
- Evidence: phase 1 completed initial assembly, one complete Plan, and autonomy preparation with
|
|
208
|
+
zero rejected lifecycle calls. A successful trusted-harness top-level `--help` was immediately
|
|
209
|
+
followed by fresh successful `next`, but packaged validation returned
|
|
210
|
+
`Unsupported read-only observation`.
|
|
211
|
+
- Root cause: CLI help semantics covered top-level, noun, and action scopes, while the transcript
|
|
212
|
+
recognizer's regular expression required at least one noun before `--help`.
|
|
213
|
+
- Candidate evidence: the validator recognizes bare top-level `--help` as safe help, retains the
|
|
214
|
+
mandatory fresh-`next` barrier, and still rejects failed help or embedded mutation inputs.
|
|
215
|
+
|
|
216
|
+
### WF-STABLE-021 — checkpoint guidance permits parallel invocations rejected by release validation
|
|
217
|
+
|
|
218
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
219
|
+
- Severity: Critical
|
|
220
|
+
- Area: gateway protocol, release transcript integrity, lifecycle checkpoints
|
|
221
|
+
- Evidence: `real-agent-release-final-21` completed phase-1 initial assembly with no individually
|
|
222
|
+
rejected command, but four times started `next` before the paired `status` had emitted its
|
|
223
|
+
terminal result (or vice versa). The strict validator rejected the first overlap with
|
|
224
|
+
`INCOMPLETE_INVOCATION` at event index `29`, before owner grant or Task execution.
|
|
225
|
+
- Root cause: the packaged gateway required both `status` and `next` after each boundary but did not
|
|
226
|
+
state that the first invocation must terminate before the second starts. Real agents may
|
|
227
|
+
parallelize independent-looking read-only calls, while the append-only validation contract
|
|
228
|
+
deliberately treats overlapping lifecycle invocations as indeterminate evidence.
|
|
229
|
+
- Candidate evidence: Skill, protocol, recovery guide, and E2E Brief now require terminal
|
|
230
|
+
`status` followed by terminal `next` and explicitly prohibit parallel tool batches. An exact
|
|
231
|
+
transcript fixture proves that overlapping checkpoint starts remain rejected. The final clean
|
|
232
|
+
`real-agent-release-final-21` followed every `status` then `next` checkpoint sequentially through
|
|
233
|
+
final acceptance; the complete transcript validates at `250/250` with no overlap.
|
|
234
|
+
|
|
235
|
+
### WF-STABLE-022 — raw real-agent evidence persists one-time C1 credentials
|
|
236
|
+
|
|
237
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
238
|
+
- Severity: Critical
|
|
239
|
+
- Area: real-agent evidence, C1 credentials, release security
|
|
240
|
+
- Evidence: the corrected `real-agent-release-final-21` consumed credential-first handoff, claim,
|
|
241
|
+
and run receipts successfully, but Codex `exec --json` serialized the literal `--claim-token`,
|
|
242
|
+
`--writer-token`, and credential-bearing stdout into the raw session JSONL. The semantic lifecycle
|
|
243
|
+
log remained secret-free, but the raw diagnostic artifact contradicted the stated memory-only
|
|
244
|
+
handling rule.
|
|
245
|
+
- Root cause: raw Codex JSONL was redirected directly to evidence without a streaming redaction
|
|
246
|
+
boundary. A language-model tool call necessarily contains the CLI argument it invokes, even when
|
|
247
|
+
the agent does not echo the value in prose.
|
|
248
|
+
- Candidate evidence: a streaming structural sanitizer removes exact credential fields and CLI
|
|
249
|
+
options before JSONL is persisted, preserves non-secret token metrics, and provides a fail-closed
|
|
250
|
+
post-run inspection mode. Deterministic tests cover command arguments, embedded receipt JSON,
|
|
251
|
+
structured receipts, and already-sanitized evidence. The final clean final-21 used the streaming
|
|
252
|
+
sanitizer from process start for both phases; fail-closed inspection reports zero credential
|
|
253
|
+
findings in both persisted raw JSONL artifacts.
|
|
254
|
+
|
|
255
|
+
### WF-STABLE-023 — claimed strict-review navigation omits its writer lease precondition
|
|
256
|
+
|
|
257
|
+
- Status: Closed-regression in beta.2; clean release E2E verified
|
|
258
|
+
- Severity: Critical
|
|
259
|
+
- Area: claimed C1 review, truthful navigation, writer lease continuity
|
|
260
|
+
- Evidence: sanitized `real-agent-release-final-21` completed one guarded Step and its Core-owned
|
|
261
|
+
commit, then `next` advertised `task step-review` without `writerTokenContract`. The exact first
|
|
262
|
+
call was rejected non-mutating with `TRANSITION_BLOCKED` because claimed posture requires the
|
|
263
|
+
active lease token.
|
|
264
|
+
- Root cause: navigation enumerated always-lease-bound completion actions and claimed `task run`,
|
|
265
|
+
but not the later claimed-C1 mutations that call the same handoff authorization predicate.
|
|
266
|
+
- Candidate evidence: writer-token navigation is now posture-aware for every claimed-C1 action
|
|
267
|
+
that can consume an optional lease, including `task step-review` and `task review-launch`.
|
|
268
|
+
Regressions cover both claimed review boundaries while preserving token-free unclaimed review
|
|
269
|
+
navigation. The final clean final-21 exposed the contract and succeeded on the first call for
|
|
270
|
+
both `task step-review` and `task review-launch`, with zero rejected lifecycle mutations.
|
|
271
|
+
|
|
272
|
+
## Beta.2 current evidence
|
|
273
|
+
|
|
274
|
+
- The first `real-agent-release-final-21` is immutable diagnostic evidence for WF-STABLE-021: its
|
|
275
|
+
lifecycle commands individually succeeded, but packaged validation rejected four overlapping
|
|
276
|
+
checkpoint pairs. It stopped before owner grant and was not resumed.
|
|
277
|
+
|
|
278
|
+
- Final clean `real-agent-release-final-21` used a rebuilt tarball with SHA-256
|
|
279
|
+
`24a7b69b0ada9d922946a8c0c593384d5806d58a35e04fae171d26f83585ac4f` and an isolated
|
|
280
|
+
`final21` marketplace/plugin cache. Phase 1 assembled exactly seven linked Tasks and stopped at
|
|
281
|
+
the autonomy gate; phase 2 completed the sole required guarded Task, strict Step review,
|
|
282
|
+
content-only context refresh, final review, delegated acceptance, Core merge, Milestone
|
|
283
|
+
validation, and delegated Milestone final acceptance. Task
|
|
284
|
+
`TASK-01M04B516YDHY5D1B78S2XEV0S` is `merged` at revision `14`; Milestone
|
|
285
|
+
`MS-01M04B42MC7VCEKTQ7K8ZYK0G1` is `accepted` at revision `5`; accepted head is
|
|
286
|
+
`64a2e58e030dfb95f5f5724fb1825b02143ffaa7`. Final `next` is repository idle with
|
|
287
|
+
`discovery start`. Transcript validation passes `250/250`, both credential scans report zero
|
|
288
|
+
findings, waived Tasks executed is zero, and rejected lifecycle mutations is zero.
|
|
289
|
+
- Post-WF-STABLE-023 full sequential validation on Node `24.17.0` passed `153/153` in
|
|
290
|
+
`644031 ms`. Plugin check, release check, isolated-cache dry-pack, downstream smoke, root
|
|
291
|
+
workflow regression, and `git diff --check` passed. The E2E-tested pre-evidence-doc tarball SHA-1 is
|
|
292
|
+
`4519d05b31fa08b39f5f5f9f9e2b9f0e13941935`.
|
|
293
|
+
|
|
294
|
+
- Post-WF-STABLE-020 sequential package validation passed `149/149` under Node `24.17.0`.
|
|
295
|
+
Current validation accepts the immutable `final-20` phase-1 transcript as `132/132`, while its
|
|
296
|
+
packaged pre-fix validator deterministically rejects it. Rebuilt package dry-pack, plugin check,
|
|
297
|
+
release check, downstream smoke, root regression, and `git diff --check` passed; dry-pack shasum
|
|
298
|
+
is `d5ca042dd1bb90e52c6d5313dafa6730e5d3795f`.
|
|
299
|
+
- Post-WF-STABLE-019 sequential package validation passed `149/149` under Node `24.17.0`.
|
|
300
|
+
Rebuilt package dry-pack, plugin validation, release check, downstream smoke, root workflow
|
|
301
|
+
regression, and `git diff --check` all passed; dry-pack shasum is
|
|
302
|
+
`547166399294368c89ae7c581192cf81a6391638`.
|
|
303
|
+
- Post-WF-STABLE-018 sequential package validation passed `147/147` under Node `24.17.0`.
|
|
304
|
+
Rebuilt package dry-pack with isolated npm cache, plugin validation, release check, downstream
|
|
305
|
+
smoke, root workflow regression, and `git diff --check` all passed; package shasum is
|
|
306
|
+
`04571ca2f51f48661c984e8d16a2e32c336efe64`.
|
|
307
|
+
- Final post-WF-STABLE-015 sequential package validation passed `141/141` under Node `24.17.0`.
|
|
308
|
+
- Package archive, downstream smoke, plugin validation, release check, and root workflow regression
|
|
309
|
+
passed on the rebuilt candidate. One root-regression setup attempt lacked Node on the child-process
|
|
310
|
+
`PATH`; the authoritative rerun with the declared Node 24 environment passed.
|
|
311
|
+
- Exact copied `signal_v4` snapshot replay passed without live-project or live-state writes.
|
|
312
|
+
- Disposable final-6 phase 1 assembled seven Tasks and stopped cleanly at the autonomy boundary.
|
|
313
|
+
Phase 2 authorized and completed the guarded Step, then correctly stopped as invalid evidence
|
|
314
|
+
when strict Step review remained indeterminate.
|
|
315
|
+
- Disposable final-11 assembled all seven Tasks and authorized the Milestone, then stopped on the
|
|
316
|
+
first rejected `task plan-set` because exact `AC-001` inclusion was not discoverable from `next`.
|
|
317
|
+
It is immutable diagnostic evidence for WF-STABLE-015, not release evidence.
|
|
318
|
+
- Disposable final-12 reached delegated Task acceptance and `task merge`, then stopped on the first
|
|
319
|
+
rejected merge because `next` did not advertise mandatory `--writer-token`. It is immutable
|
|
320
|
+
diagnostic evidence for WF-STABLE-016, not release evidence.
|
|
321
|
+
- Disposable final-13 passed clean bootstrap/preflight but the real Codex transport failed before
|
|
322
|
+
the first workflow action. It made no workflow mutation and is external diagnostic evidence, not
|
|
323
|
+
a package-defect or release signal.
|
|
324
|
+
- Disposable final-16 cleared transport, completed initial assembly and the owner grant, then
|
|
325
|
+
stopped on the first rejected `milestone authorize --help`. It is immutable diagnostic evidence
|
|
326
|
+
for WF-STABLE-017, not release evidence.
|
|
327
|
+
- Disposable final-17 completed seven-Task initial assembly with zero rejected mutations and proved
|
|
328
|
+
read-only help plus fresh `next`, but the packaged validator still rejected that help observation.
|
|
329
|
+
It stopped before owner grant and is immutable WF-STABLE-017 diagnostic evidence.
|
|
330
|
+
- Disposable final-18 completed initial assembly through C1 handoff preparation with zero rejected
|
|
331
|
+
lifecycle calls. It then exposed WF-STABLE-018: the exact one-time claim token existed in complete
|
|
332
|
+
stdout but was buried after the large Task/event payload and was not retained by the Delegate.
|
|
333
|
+
The run is immutable diagnostic evidence and is not eligible for continuation or release evidence.
|
|
334
|
+
- Disposable final-19 completed seven-Task assembly, delegated authorization, credential-first
|
|
335
|
+
handoff/claim, and bounded Core `task start`. It then exposed WF-STABLE-019 when claimed
|
|
336
|
+
`task run` was advertised without its already-bound lease precondition and was rejected once.
|
|
337
|
+
The run is immutable diagnostic evidence and is not eligible for continuation.
|
|
338
|
+
- Disposable final-20 completed clean seven-Task phase-1 assembly and autonomy preparation with no
|
|
339
|
+
rejected lifecycle call, then exposed WF-STABLE-020 when transcript validation rejected safe
|
|
340
|
+
top-level help plus fresh `next`. No owner grant was issued; the run is immutable diagnostic
|
|
341
|
+
evidence and is not eligible for continuation.
|
|
342
|
+
- The rebuilt tarball, fresh clean final-acceptance/idle E2E, transcript/security checks, and all
|
|
343
|
+
deterministic/package release gates are green. The independent source/evidence audit completed
|
|
344
|
+
with `PASS`, found no material blocker, and confirmed the beta.2 release recommendation.
|
|
345
|
+
|
|
17
346
|
## Workflow findings closed for beta.1
|
|
18
347
|
|
|
19
348
|
### WF-STABLE-001 — `locks repair` exposes a full writer token
|
|
@@ -115,7 +444,7 @@ Last reviewed: 2026-08-15.
|
|
|
115
444
|
active but non-completable Milestone.
|
|
116
445
|
- Stable-release requirement:
|
|
117
446
|
- ship a canonical `split-required` operator/delegate recovery prompt;
|
|
118
|
-
- require `status
|
|
447
|
+
- require sequential terminal `status` then terminal `next` after every state boundary;
|
|
119
448
|
- distinguish Task creation, replacement linkage, membership evolution, and execution
|
|
120
449
|
reauthorization;
|
|
121
450
|
- prohibit manual state editing and resumption of the failed Step.
|
|
@@ -29,6 +29,8 @@ adoption posture.
|
|
|
29
29
|
используйте внешний точный runner alpha.7 только для `update rescue-preflight`. Продолжать
|
|
30
30
|
можно лишь при `eligible=true`; допустимы только перечисленные им `locks repair` и
|
|
31
31
|
`task step-review`. Этот путь не меняет dependency и не разрешает другие команды alpha.7.
|
|
32
|
+
Для `task step-review` используйте lifecycle-actor из `next` или rescue-preflight; это claimant
|
|
33
|
+
или required actor, а не identity независимого reviewer-процесса.
|
|
32
34
|
После terminal review выполните обычный Knowledge reconcile/rebind, доведите Task до безопасной
|
|
33
35
|
границы и только затем обновляйте package/lock обычным способом.
|
|
34
36
|
|
package/package.json
CHANGED
|
@@ -44,6 +44,7 @@ Current capability set:
|
|
|
44
44
|
- `alpha6-adoption-posture-v1`
|
|
45
45
|
- `alpha6-strict-review-rescue-v1`
|
|
46
46
|
- `milestone-initial-assembly-v1`
|
|
47
|
+
- `milestone-initial-assembly-navigation-v2`
|
|
47
48
|
- `milestone-autonomy-contract-v1`
|
|
48
49
|
- `milestone-autonomous-membership-evolution-v1`
|
|
49
50
|
- `task-c1-derived-worker-actor-v1`
|
|
@@ -75,7 +76,9 @@ version, canonical entity summaries, and the current sidecar baseline hash. Adop
|
|
|
75
76
|
|
|
76
77
|
## Worker Step completion and strict Step Review
|
|
77
78
|
|
|
78
|
-
`task run` dispatches one Step and returns
|
|
79
|
+
`task run` dispatches one Step and returns a first-field `writerLeaseReceipt`, followed by the
|
|
80
|
+
credential-free lease metadata, Task state, and Worker envelope. Consume the receipt before the
|
|
81
|
+
remaining payload and retain its token only in working memory. The Worker
|
|
79
82
|
must leave all changes uncommitted and must not stage, commit, amend, reset, rebase, or
|
|
80
83
|
modify Git history.
|
|
81
84
|
|
|
@@ -84,11 +87,36 @@ While that Step is `in_progress`, repository-level `next` normally returns
|
|
|
84
87
|
`workflow-core` ownership. The coordinator invokes that transition with the current revision
|
|
85
88
|
and writer token. Core then runs configured checks, validates `allowedWrites`, stages the
|
|
86
89
|
changes, creates the atomic commit, and records evidence.
|
|
90
|
+
When `next` also includes `gitMutationPolicy`, obtain bounded permission for that exact
|
|
91
|
+
Git-writing transition before the first call; do not probe and retry after a
|
|
92
|
+
`.git/index.lock` failure. For `task start`, the policy applies only when the coordinator
|
|
93
|
+
chooses `--workspace-owner local`.
|
|
94
|
+
|
|
95
|
+
When `next` also includes `writerTokenContract`, the coordinator must retain the active writer
|
|
96
|
+
lease from `writerLeaseReceipt` and pass it with the advertised option on the first transition call.
|
|
97
|
+
The contract never contains the token value. Do not print, persist, reconstruct, or replace the
|
|
98
|
+
token with a redacted fingerprint; stop before mutation when the active lease is unavailable.
|
|
99
|
+
Satisfy this contract separately from any `gitMutationPolicy` on the same response.
|
|
100
|
+
|
|
101
|
+
`codex-workflow <noun> [action] --help` is a read-only command-discovery route. It exits without
|
|
102
|
+
constructing workflow state or validating lifecycle inputs. Use exact option lists only when the
|
|
103
|
+
response says `exactOptionContractAvailable=true`; otherwise consult this packaged protocol. After
|
|
104
|
+
help, obtain a fresh `next` before invoking the lifecycle transition.
|
|
87
105
|
|
|
88
106
|
If the current Plan Risk Audit marks that Step for strict review, the commit is still
|
|
89
107
|
workflow-owned, but `next` then returns `action: "task step-review"` with the same `stepId`
|
|
90
108
|
and the exact `completionCommit`. Canonical Step completion remains blocked until the strict
|
|
91
109
|
review and reviewer attestation sidecars verify against that exact commit.
|
|
110
|
+
Invoke `task step-review` with the same lifecycle actor advertised by `next`
|
|
111
|
+
(`c1Handoff.claimant` or `requiredActor` when present). The isolated reviewer is launched
|
|
112
|
+
inside Core; do not substitute the reviewer identity into `--actor`. In claimed C1 posture,
|
|
113
|
+
`next.writerTokenContract` is mandatory for both `task step-review` and the later
|
|
114
|
+
`task review-launch`; pass the retained active lease on the first call of each exact action.
|
|
115
|
+
|
|
116
|
+
After submission, a pending Task review is advertised as `action: "task review-launch"`, not
|
|
117
|
+
`task review-record`. That compound route launches the read-only reviewer and atomically
|
|
118
|
+
records the returned review. If claimant-bound mutation is active, pass the same lifecycle
|
|
119
|
+
actor through `--actor`; reviewer identity remains internal to the route.
|
|
92
120
|
|
|
93
121
|
An unrecorded commit is Git history drift. Stop instead of adding another commit or editing
|
|
94
122
|
workflow state manually; recovery remains coordinator-controlled.
|
|
@@ -129,6 +157,12 @@ classifications. A planned new scanner-visible Knowledge file must be declared w
|
|
|
129
157
|
directories, and inferred authority are not declarations; only Core may decide whether the final
|
|
130
158
|
diff is eligible for delegated refresh.
|
|
131
159
|
|
|
160
|
+
For every `task plan-set` navigation, consume `next.taskPlanContract` before building the Plan.
|
|
161
|
+
Its `requiredRequirementIds` and `requiredAcceptanceIds` are exact-membership preconditions, not
|
|
162
|
+
descriptive hints. Preserve each ID verbatim in the corresponding Plan array and use the returned
|
|
163
|
+
Brief hash plus Knowledge Map revision/hash as the planning binding. Missing or stale contract data
|
|
164
|
+
is a stop condition.
|
|
165
|
+
|
|
132
166
|
Use `task context-refresh` only when the same `next` response returns it as the top-level action and
|
|
133
167
|
exposes `contextRefresh` for the exact grant. Pass Task revision, map revision, delegate actor, and
|
|
134
168
|
grant ID. Never run standalone `project-memory reconcile` first; Core blocks that non-atomic route
|
|
@@ -166,11 +200,28 @@ claimed, only the claimant may mutate the Task, and lease-bound mutations must p
|
|
|
166
200
|
bound writer token. Milestone-linked Tasks must be claimed before start, and handback is
|
|
167
201
|
terminal and evidence-bound. When target actor is omitted, Core derives
|
|
168
202
|
`agent:worker:<task-id>`. No thread id is required or accepted as authority.
|
|
203
|
+
The successful prepare response begins with `credentialHandoff`. Consume that receipt before the
|
|
204
|
+
Task/event/bundle payload, retain its token only in working memory, and pass it exactly once to the
|
|
205
|
+
declared `task claim --claim-token` action for the declared target actor. The later bundle remains
|
|
206
|
+
contextual and intentionally contains no second copy of the claim token.
|
|
207
|
+
The successful claim response then begins with `writerLeaseReceipt`. Retain that token only in
|
|
208
|
+
working memory. In claimed C1 posture, fresh `next` exposes `writerTokenContract` on `task run`;
|
|
209
|
+
pass the receipt token through its declared `--writer-token` option on the first run call. The
|
|
210
|
+
successful run returns the refreshed writer receipt for later lease-bound transitions.
|
|
169
211
|
|
|
170
212
|
## Milestone assembly, autonomy, and human gate
|
|
171
213
|
|
|
172
214
|
During initial planning, materialize every linked Task and then call `milestone plan-set` once
|
|
173
215
|
with the complete membership. Execution is blocked while reverse membership is incomplete.
|
|
216
|
+
Before Task 1 and between linked Tasks, follow top-level `next.action = "milestone initial-assembly"`.
|
|
217
|
+
Its `linked-task-assembly.commands` permit `discovery start` and `discovery materialize`; after the
|
|
218
|
+
first linked Task exists, the separate closing option permits `milestone plan-set`. If `status` or `next` fails, stop: never label
|
|
219
|
+
the gap expected and invoke `milestone plan-set` directly.
|
|
220
|
+
|
|
221
|
+
Every required navigation checkpoint is strictly sequential: start `status`, wait until its
|
|
222
|
+
terminal result is recorded, then start `next` and wait for its terminal result. Never issue the
|
|
223
|
+
pair concurrently or through a parallel tool call. The trusted transcript validator treats a
|
|
224
|
+
second invocation before the first terminal result as indeterminate release evidence.
|
|
174
225
|
|
|
175
226
|
After that Plan, one human may prepare and grant a maximum-72-hour Milestone Autonomy Contract:
|
|
176
227
|
|
|
@@ -227,6 +278,10 @@ transition matches the requested command, with the named delegate as actor and t
|
|
|
227
278
|
as `--delegation-grant`. The resulting authorization event records the grant and both actors.
|
|
228
279
|
For `milestone.final_accept`, also pass the current `MSA-*` code; the existing grant replaces
|
|
229
280
|
the later-message requirement, not the state binding.
|
|
281
|
+
Do not pass `--delegation-grant` to ordinary C1 handoff, claim, run, step-complete,
|
|
282
|
+
step-review, merge, or sync-base calls. Those transitions are not authorized by a Milestone
|
|
283
|
+
approval grant unless the same `next` response explicitly advertises an eligible grant for the
|
|
284
|
+
exact transition.
|
|
230
285
|
|
|
231
286
|
Delegated approval does not cover adoption apply or the ordinary semantic Milestone scope-change
|
|
232
287
|
path. Membership-only evolution requires the separate Milestone Autonomy Contract.
|
|
@@ -51,6 +51,13 @@ scanner category. Do not replace the path with a wildcard or directory, do not i
|
|
|
51
51
|
authority, and do not claim delegated-refresh eligibility; Core decides eligibility from the
|
|
52
52
|
resulting repository diff and current authorization state.
|
|
53
53
|
|
|
54
|
+
When `next.action` is `task plan-set` (including the corrective-audit variant), treat
|
|
55
|
+
`next.taskPlanContract` as the exact transition precondition. Copy every
|
|
56
|
+
`requiredRequirementIds` entry into Plan `requirements` and every `requiredAcceptanceIds` entry
|
|
57
|
+
into Plan `acceptance` as exact array members; semantic prose may be added but cannot replace those
|
|
58
|
+
IDs. Bind the Plan to the returned `briefHash` and active `knowledgeMap` revision/hash. Stop if the
|
|
59
|
+
contract is absent or conflicts with the current Task/Knowledge state.
|
|
60
|
+
|
|
54
61
|
When `next` returns top-level `action: task context-refresh`, use only that atomic action for
|
|
55
62
|
the returned Task/map revisions, actor, and grant. Do not run standalone `project-memory reconcile`
|
|
56
63
|
first: Core rejects it because it would create a human-approval gap and strand the Task. A
|
|
@@ -64,6 +71,39 @@ installed package. The only valid continuation is the exact `task replacement-ma
|
|
|
64
71
|
transition (or creation of its one ready Discovery when requested). Never rebind, refresh, replan,
|
|
65
72
|
authorize, or resume the historical Task, and never emulate the membership changes manually.
|
|
66
73
|
|
|
74
|
+
When `next` returns `milestone initial-assembly`, execution is unavailable. Follow only the
|
|
75
|
+
advertised `linked-task-assembly.commands` (`discovery start` and `discovery materialize`) until all
|
|
76
|
+
intended linked Tasks exist. The closing `milestone plan-set` option appears only after at least one
|
|
77
|
+
linked Task exists; use it once with the complete membership. After every boundary, run `status`,
|
|
78
|
+
wait for its terminal success, and only then run `next`; never launch the checkpoint pair in
|
|
79
|
+
parallel or in one parallel tool batch. If either fails, stop; do not
|
|
80
|
+
describe the reverse-membership gap as expected and invoke a direct closing command.
|
|
81
|
+
|
|
82
|
+
When `next` includes `gitMutationPolicy`, obtain bounded permission for that exact Git-writing
|
|
83
|
+
transition before the first call. Do not probe and retry after a `.git/index.lock` failure.
|
|
84
|
+
For `task start`, the policy applies only when choosing `--workspace-owner local`; for
|
|
85
|
+
`task step-complete`, `task merge`, and `task sync-base`, the advertised transition itself
|
|
86
|
+
writes Git metadata.
|
|
87
|
+
|
|
88
|
+
When `next` includes `writerTokenContract`, treat it as an exact first-call precondition. Retain
|
|
89
|
+
the active writer lease from the first-field `writerLeaseReceipt` returned by `task run` and pass it using the advertised `option` for that
|
|
90
|
+
transition. The token is sensitive: never print, summarize, persist, or substitute a redacted
|
|
91
|
+
fingerprint. Stop before mutation if the active lease is unavailable. This input contract is
|
|
92
|
+
independent from `gitMutationPolicy`; satisfy both when both are present.
|
|
93
|
+
|
|
94
|
+
On successful `task handoff-prepare`, consume the first-field `credentialHandoff` before reading
|
|
95
|
+
the Task/event/bundle payload. Retain its one-time token only in working memory and use it exactly
|
|
96
|
+
once with the declared `action` and `option` for the declared `targetActor`. Successful `task claim`
|
|
97
|
+
returns a first-field `writerLeaseReceipt`; retain that lease and pass it to claimed `task run` when
|
|
98
|
+
the fresh `next.writerTokenContract` requires it. Successful `task run` returns the refreshed
|
|
99
|
+
`writerLeaseReceipt`; retain it only until Core releases that lease.
|
|
100
|
+
Never search later payload fields for either credential and never copy credentials into evidence.
|
|
101
|
+
|
|
102
|
+
Command discovery with `codex-workflow <noun> [action] --help` is read-only. Use it only when the
|
|
103
|
+
exact invocation syntax is not already available from `next` and this protocol. Consume declared
|
|
104
|
+
`requiredOptions` and `optionalOptions`; when `exactOptionContractAvailable=false`, consult the
|
|
105
|
+
packaged protocol instead of guessing. Help never replaces a fresh `next` before mutation.
|
|
106
|
+
|
|
67
107
|
## Product Or Workflow Graph Refresh
|
|
68
108
|
|
|
69
109
|
1. Run `graph refresh-request --kind product|workflow --mode moderate`.
|
|
@@ -118,6 +158,9 @@ Never create, broaden, renew, or replace a grant from an agent's own judgment. N
|
|
|
118
158
|
the delegate as the user. When `next` exposes an eligible option, pass its grant ID through
|
|
119
159
|
`--delegation-grant` and use the exact delegate string as `--actor`. The core remains the
|
|
120
160
|
authority for status, expiry, scope, transition, and revocation checks.
|
|
161
|
+
If the same `next` response does not expose an eligible option for that exact transition, do
|
|
162
|
+
not pass `--delegation-grant`. Ordinary C1 handoff, claim, run, step-complete, step-review,
|
|
163
|
+
merge, and sync-base do not inherit a Milestone approval grant.
|
|
121
164
|
|
|
122
165
|
For delegated Milestone final acceptance, the current `MSA-*` code is still required, but a
|
|
123
166
|
new user turn is not: the previously issued grant is the controlling decision. If no eligible
|
|
@@ -156,5 +199,6 @@ returns `safe=true` with a clean checkout, no running Step, and no active writer
|
|
|
156
199
|
- A request changes before evidence is bound.
|
|
157
200
|
- An action would make MCP or the local map authoritative project memory.
|
|
158
201
|
- A requested mutation is not authorized by the package CLI state.
|
|
202
|
+
- A lifecycle `status` or `next` failed; do not continue with a different lifecycle mutation.
|
|
159
203
|
- A human gate was emitted but the user has not approved its exact confirmation code in a
|
|
160
204
|
later message and no exact eligible delegated approval option exists.
|