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

package/docs/problem-briefs/README.md

@@ -0,0 +1,120 @@
+# Workflow v2 — Problem Briefs
+
+This registry reserves 10 problem slots for Workflow v2 redesign/reliability work. Four briefs are
+currently defined; the remaining slots are intentionally unmaterialized.
+
+## Status model
+
+Each brief MUST declare exactly one status in YAML frontmatter:
+
+- `hypothesis` — proposed solution; its problem, design, or implementation boundary still has an
+  unresolved pre-implementation gate.
+- `approved` — the problem and implementation design have sufficient pre-implementation evidence
+  and the brief is accepted for implementation. This status does not claim that the code or its
+  implementation tests already exist.
+- `implemented` — approved design implemented and its required acceptance tests pass.
+
+Status progression is monotonic by default:
+
+`hypothesis → approved → implemented`
+
+A regression or disproven assumption should not silently move a brief backward. Record the reason in the brief's Decision Log and create a new revision if necessary.
+
+## Brief registry
+
+| # | Problem | File | Status |
+|---|---|---|---|
+| 01 | Механически невыполнимый Task Plan может получить execution authorization | `01-pre-implementation-integrity.md` | approved |
+| 02 | STEP не является полезным инкрементом | `02-minimal-step-integrity.md` | hypothesis |
+| 03 | Разный контекст агентов и слишком позднее обнаружение проблем | `03-minimal-agent-context-integrity.md` | hypothesis |
+| 04 | Milestone Task execution не защищён явными зависимостями | `04-task-dependency-and-structural-replacement-integrity.md` | approved |
+| 05 | TBD | — | — |
+| 06 | TBD | — | — |
+| 07 | TBD | — | — |
+| 08 | TBD | — | — |
+| 09 | TBD | — | — |
+| 10 | TBD | — | — |
+
+## Required brief metadata
+
+Every brief should start with:
+
+```yaml
+---
+brief_id: WF2-P01
+problem: "..."
+status: hypothesis
+owner: null
+created_at: 2026-08-23
+approved_at: null
+implemented_at: null
+revision: 1
+---
+```
+
+## Approval and implementation rules
+
+The two gates are deliberately separate.
+
+### Design approval (`hypothesis -> approved`)
+
+A brief may be approved before its implementation exists only when:
+
+- the problem and root cause are supported by current source or reproducible behavior;
+- the proposed authority, data contract, transition routing, compatibility policy, and failure
+  behavior are concrete enough to implement without inventing semantics in code;
+- conflicts and ordering dependencies with other briefs are closed or explicitly deferred behind a
+  fail-closed boundary;
+- the validation plan contains both failure cases and successful controls;
+- any pre-implementation replay required to validate a semantic hypothesis has completed.
+
+Historical completed Tasks are replay inputs only when they are relevant controls. A fresh,
+version-pinned replay may replace historical active-Milestone topology when the brief does not
+claim to recover that topology.
+
+### Implementation acceptance (`approved -> implemented`)
+
+A brief may move from `approved` to `implemented` only after the implementation is merged/installed
+as intended and its declared contract, E2E, regression, compatibility, and fault-injection tests
+pass. Tests that require the proposed code are implementation acceptance evidence; they are not a
+precondition that makes design approval circular.
+
+## Recommended go/no-go
+
+This is an implementation-order recommendation, not a status change or approval record.
+
+| Brief | Decision | Reason and gate |
+|---|---|---|
+| P04-A | **GO to review/merge — candidate green** | Revision 5 passed its 306/306 checkpoint and the final combined P04-A/P01-A 319/319 suite on `codex/p04-task-dependencies`. Keep status `approved` until the candidate is merged/installed and accepted. |
+| P01-A | **GO to review/merge — candidate green** | Revision 5 implements the approved bounded evaluator after P04-A; typecheck, plugin/schema/release validation, 13 focused tests, beta.11 compatibility, and the final combined 319/319 suite pass. Keep status `approved` until merge/install and acceptance. P01-B remains deferred. |
+| P02 | **NO-GO** | Do not implement until its output-to-evidence mapping and semantic-authority proposal pass the fresh/historical replay gate. The brief defines the required contract and current-state routing, but the causal Step hypothesis is still only partially confirmed. |
+| P03 | **NO-GO** | Required category-B evidence is absent. Reconsider only after P04-A and the relevant P01 authority exist and a fresh role-separated replay isolates a real context omission. |
+| P05 / P04-B | **NO-GO / not materialized** | Structural replacement, topology evolution, residual-scope redistribution, and completed-work adoption require a separate brief. P04-A blocks replacement rather than guessing these semantics. |
+
+Recommended implementation sequence:
+
+```text
+P04-A -> P01-A -> validate P02 hypothesis -> validate P03 hypothesis
+                   +-> separately materialize P05/P04-B when replacement is required
+```
+
+The four-brief set is therefore not one implementation-ready batch. Only the first two bounded
+phases have a recommended implementation route; P02 and P03 remain evidence-gated hypotheses.
+
+## Current validation boundary
+
+The isolated Signal pre-M3 replay is recorded in
+[`evidence/signal-v4-pre-m3-replay.md`](evidence/signal-v4-pre-m3-replay.md). It is supporting
+evidence, not approval evidence for all four briefs:
+
+- it confirms several product and verification gaps;
+- it does not reproduce Workflow-materialized role-separated Task execution because a legitimate
+  project-memory human gate stopped the isolated lifecycle;
+- it does not exercise structural replacement;
+- the source Signal repository was not modified;
+- P01-A and P04-A are `approved` combined-branch candidates; P02 and P03 remain `hypothesis`.
+  Candidate code and focused tests do not by themselves satisfy the merge/install implementation gate.
+
+Historical active-Milestone state and old M3 Task identifiers are not mandatory inputs to fresh
+materialization validation. Brief-specific replay requirements must use fresh authority unless a
+brief explicitly needs a historical regression control.

package/docs/problem-briefs/evidence/p01-mechanical-feasibility-corpus.md

@@ -0,0 +1,90 @@
+# P01-A mechanical-feasibility corpus replay
+
+## Boundary and pinned sources
+
+- Workflow repository HEAD: `01ff2e1f10ad8f707dc08219cffcc1013314ae4f`.
+- Workflow root `package.json` at that HEAD contains literal scripts `validate`, `typecheck`,
+  `test`, and the other scripts shown by `git show HEAD:package.json`.
+- Signal pre-M3 control revision: `5e456803698c1eb523ccec32bc77882ed240f49a`.
+- Signal root `package.json` hash at that revision:
+  `d8f91d91f700bdf1593b908b1788e8b49fd5568e58510398343a771e58e5c92b`.
+- Existing Workflow corpus sources:
+  - `tests/plan-integrity-recovery.test.ts` —
+    `3019adee756c03506768ab4a1cf9fbccc9a469552b6fdd217ad43982da0b1144`;
+  - `tests/integration.test.ts` —
+    `9e0ebfc34592516d319010818b05963c659719fb74a6d31acbeb1182c9726a1a`;
+  - `tests/workflow.test.ts` —
+    `e9399e50375ef8a250d61e4232ce3368212756f7280920ad407f3d54e57bfd2b`;
+  - Signal replay journal —
+    `e3909cfd5159daffd4c536042fc517f6555c7dfc3d1322efe5c2c99fd06b9763`.
+
+This is a read-only design replay. It does not execute Plan checks and does not write Workflow or
+Signal state.
+
+## Frozen analyzer grammar used by the replay
+
+### `wf2.root-npm-script@1`
+
+Recognized input is the complete raw check string:
+
+```text
+^npm run ([A-Za-z0-9][A-Za-z0-9:_-]*)$
+```
+
+There is one ASCII space between tokens. Arguments, options, quoting, environment prefixes,
+operators, alternate package managers, `npm test`, and surrounding whitespace are unsupported.
+The analyzer reads only the root `package.json` at the selected commit. If the script is absent,
+write permission to root `package.json` in the current Step or a transitive declared predecessor
+makes the finding `unverified`; otherwise it is `blocked`.
+
+### `wf2.exact-output-path@1`
+
+Recognized input is the complete raw expected-output string `path:<relative-path>`. The path uses
+POSIX separators, is repository-relative, contains no empty, `.` or `..` segment, no glob token,
+and every segment matches `[A-Za-z0-9._-]+`. Prose such as `feature.txt exists.` is unsupported.
+
+An existing path passes. An absent path writable by the responsible Step under the existing
+`allowedWrites` matcher passes the bounded permission check. Otherwise the finding is blocked,
+unless a declared predecessor supplies the exact structured output described below.
+
+### `wf2.exact-predecessor-path@1`
+
+A predecessor supplies a missing consumer path only when it is in the consumer's transitive
+declared Step dependency closure, declares the identical `path:<relative-path>` output, and its
+`allowedWrites` permits that exact normalized path. Ordinal, prose, directory coincidence, and an
+unrelated earlier Step do not count.
+
+Analyzer order is the fixed order above. Findings are canonicalized by Step ID, analyzer ID, raw
+subject, and result. The analyzer-set hash is the SHA-256 of canonical JSON containing those exact
+IDs and versions.
+
+## Replay cases
+
+| Case | Source/control | Classification | Evidence and earliest effect |
+|---|---|---|---|
+| C01 | Workflow HEAD, `npm run validate` | `pass` | Root script exists at the pinned HEAD; no new gate or review. |
+| C02 | `plan-integrity-recovery.test.ts`, `npm run processing:migrations:check`, Step cannot write `package.json` | `blocked` | Script is absent from the pinned root manifest. P01-A would reject authorization before Task start, avoiding the later run failure and Plan-integrity recovery cycle. |
+| C03 | C02 with current/predecessor permission to write root `package.json` | `unverified` | Permission does not prove that the script will be created; no false block and no invented pass. |
+| C04 | Existing Plan checks `npm test` | `unverified` | Deliberately outside the literal `npm run` grammar; existing successful Plans remain authorizable. |
+| C05 | Existing shell checks such as `test -f feature.txt` and `grep ...` | `unverified` | The evaluator does not execute or interpret shell. |
+| C06 | Existing prose outputs such as `feature.txt exists.` or `feature.txt contains ready.` | `unverified` | No bare-string path inference. |
+| C07 | Synthetic `path:feature.txt`, absent at HEAD, responsible Step may write `feature.txt` | `pass` | Exact structured path and current write authority agree. |
+| C08 | Synthetic `path:outside.txt`, absent at HEAD and outside current/prior write authority | `blocked` | The Plan proves that its declared output cannot be materialized within its own write contract. |
+| C09 | Synthetic consumer `path:generated.txt` with an exact declared predecessor output and write permission | `pass` | Exact Step dependency, output, and permission form the complete bounded proof. |
+| C10 | C09 with only prose, ordinal, an unrelated earlier Step, or directory overlap | `blocked` | No provider is inferred. |
+| C11 | Signal pre-M3 `npm run validate` | `pass` | The pinned Signal manifest contains `validate`; the replay journal confirms the command passed. |
+| C12 | Signal OBS-012 narrow typecheck versus project-reference/architecture failure | `pass` for the existing literal script; broader claim `unverified` | P01-A does not claim that one valid script semantically covers other build or architecture boundaries. |
+
+## Result
+
+- Proven blockers: C02, C08, C10. Each is an exact contradiction in the supported grammar.
+- False blockers among successful controls: 0.
+- Unsupported/unverified controls: C03–C06 and the broader semantic claim in C12.
+- Earliest avoided transition: C02 moves detection from post-start execution/remediation to Task
+  authorization.
+- No corpus result requires a new lifecycle stage, corrective-decision value, semantic reviewer,
+  Contract Registry, or P01-B decomposition authority.
+
+Confidence is high for the pinned manifest/script findings and medium-high for corpus coverage. The
+corpus is intentionally conservative: it proves the absence of false blockers for the supported
+forms, not completeness over arbitrary commands or natural-language outputs.

package/docs/problem-briefs/evidence/signal-v4-pre-m3-replay.md

@@ -0,0 +1,246 @@
+# Signal v4 pre-M3 replay journal
+
+## Experiment boundary
+
+- Purpose: validate the problem briefs by replaying the original Milestone 3 from a pre-M3 Signal revision.
+- Source repository: `/Users/home-pc/htdocs/projects/signal_v4` (read-only for this experiment).
+- Isolated implementation checkout: `/private/tmp/signal-v4-pre-m3-replay.1YfIMr/repo`.
+- Pre-M3 revision: `5e456803698c1eb523ccec32bc77882ed240f49a` (`chore: update codex workflow v2 to 2.0.0-alpha.6`).
+- Product and Workflow state in the source repository must not be changed.
+- Workflow blockers are evidence. They may be bypassed only in the isolated checkout, without patching Workflow, so that the product Milestone can continue to completion.
+
+## Why this is the pre-M3 revision
+
+Confirmed evidence:
+
+1. The first surviving approval transcript for the original M3 Coordinator records repository HEAD `5e456803698c1eb523ccec32bc77882ed240f49a` on `main`.
+2. The first M3 implementation commit, `1ab23cba9d4c098a879fa23599b7aec84ff2bfea`, has `5e456803698c1eb523ccec32bc77882ed240f49a` as its direct parent.
+3. The original Discovery and Milestone were created only after the Coordinator had started from that revision.
+
+Confidence: high.
+
+## Original user input used for replay
+
+The original Coordinator task itself is no longer present as a normal archived task. Its first user message survives verbatim in the Guardian approval transcript:
+
+`/Users/home-pc/.codex/sessions/2026/08/14/rollout-2026-08-14T06-02-44-019ffe38-d070-7971-9b3c-f9ea6643f077.jsonl`
+
+The input was:
+
+> Работай как delegate-координатор Workflow V2 для одного Milestone.
+> Delegate actor: agent:deputy
+> Delegation grant: DGR-01KZYFTXAW8C87Z7W07G3C9GR4
+> Milestone ID: AUTO
+> Требования пользователя: Сделать совместный Brainstorm для декомпозиции Milestone 3.
+> Все команды и координацию Codex-чатов выполняешь ты. Начни с AGENTS.md, project-local gateway handshake, doctor, status и next. Выполни delegation show для DGR-ID и до мутаций проверь project, active status, delegate, scope, transitions и expiresAt. Не создавай, не продлевай и не расширяй grant.
+> Для AUTO проведи Discovery; не materialize Milestone при blocking unknowns. Не принимай новые продуктовые решения и не расширяй scope: при смысловой неопределённости спроси меня. Подготовь Milestone и тонкие Tasks. Применяй grant только если текущий next вернул exact delegatedApprovalOptions для DGR-ID и transition. Actor всегда agent:deputy, никогда user.
+> Required Tasks выполняй последовательно. Для каждой можешь открыть отдельный Codex-чат с Task delegate prompt, тем же actor и DGR-ID. Не запускай два writer на одном checkout. Worker и Reviewer grant не используют: approval выполняет delegate-координатор после evidence.
+> После merge всех Tasks выполни Milestone validation. Final acceptance делай только при exact milestone.final_accept option и с текущим MSA-code в том же turn. Иначе остановись перед human gate. В конце покажи status, authorization event, grant/transition и проверки.
+
+This is used as the Discovery instruction. Later replacement prompts, existing M3 Task names, canceled-task plans, and accepted M3 implementation commits are excluded from the replay input. They may be used only after implementation for comparison.
+
+Confidence: high that the text is verbatim; medium-high that it is the earliest M3 user input, because the original parent task is absent and the evidence survives inside its first approval transcript rather than as the parent task itself.
+
+## Observation log
+
+### OBS-001 — The original delegated authority is not replayable
+
+- Phase: initial Workflow handshake.
+- Evidence: the isolated state registered project `ee2efa9432300ce6e3efba9e`; `delegation show --id DGR-01KZYFTXAW8C87Z7W07G3C9GR4` returned `NOT_FOUND`.
+- Classification: experiment-boundary limitation, not a Workflow defect.
+- Reason: the original grant belonged to historical external state and was intentionally not copied or recreated. Repository identity and workflow authority are not portable to a new checkout/state root.
+- Bypass: continue product implementation outside Workflow after recording the point at which delegated lifecycle mutations become unavailable.
+- Brief relevance: none by itself; it must not be misreported as P03 or P04 evidence.
+
+### OBS-002 — The first input is insufficient for product-complete M3 Discovery
+
+- Phase: Discovery.
+- Evidence: the first input asks only for a brainstorm/decomposition of “Milestone 3”. `docs/README.md` explicitly defers concrete signal formats, prompts, and parsers. `docs/domain/services/processing-decision.md` additionally defers concrete signal formats, prompts, provider models, extraction algorithms, normalization rules, deterministic validation rules, decision policy, retry timing, persistence DDL, live integrations, credentials, and deployment topology.
+- Classification: blocking product-input gap under the original `AGENTS.md` rule “Do not invent product facts”.
+- Root cause: the first user message identifies a Milestone ordinal, not its product semantics. The repository supplies architectural invariants but not enough product examples or accepted signal semantics to prove a product-complete formalizer.
+- Bypass for this experiment: implement a credential-free synthetic architecture slice using explicit test-only candidates and deterministic fixtures. Do not claim that the slice proves real signal semantics.
+- Brief relevance: the gap is not caused by P01-P04 and must not be used as evidence for them.
+
+### OBS-003 — Pre-M3 baseline is healthy except for the local image-build environment
+
+- Phase: baseline validation.
+- Evidence: `npm run validate` passed install metadata, CI policy, format, lint, typecheck, architecture, contracts, MTProto checks, unit tests (736 passed, 52 skipped), all 29 builds, real PostgreSQL, real RabbitMQ, and the reliable-ingest vertical slice.
+- Failure: `container:check` stopped while Docker was resolving `node:24.17.0-bookworm-slim`; the build timed out before a Dockerfile or product-code failure was reported.
+- Classification: environment/infrastructure limitation. The required container gate is not proven and must be rerun after implementation.
+- Brief relevance: a global validation runner already exists in this pre-M3 revision (`npm run validate`), so the earlier P01 claim must distinguish “no Task-specific composite acceptance command” from “no repository-wide validation command”.
+
+### OBS-004 — Historical alpha.6 initial assembly blocks after the first linked Task
+
+- Phase: historical-package control run.
+- Evidence: with the pre-M3 declared package `2.0.0-alpha.6`, the first linked Task materialized successfully. Every attempt to materialize Tasks 2–7 then failed with `MILESTONE_SCOPE_INCOMPLETE`, naming Task 1 as an orphan and requiring a scope change.
+- Root cause: alpha.6 enforces reverse membership immediately but has no initial-assembly navigation exception, so a multi-Task Milestone cannot be assembled in one planning window.
+- Classification: confirmed historical Workflow defect, already addressed by the current `milestone-initial-assembly-navigation-v2` capability.
+- Bypass: do not patch alpha.6 and do not perform repeated human-gated scope changes. Re-run the experiment with the current beta.11 package over the same pre-M3 product tree.
+- Brief relevance: historical supporting evidence for structural membership problems, but not a current P04 reproduction.
+
+### OBS-005 — Current fresh-project navigation blocks before the mutation that bootstraps it
+
+- Phase: beta.11 initial checkpoint.
+- Evidence: against a nonexistent isolated state root, `status` and `next` return `PROJECT_REGISTRATION_MISSING` plus `ADOPTION_MISSING`, `action=blocked`, and no repair or `discovery start` navigation. The beta.11 test `first Discovery bootstraps registration when the configured state root does not exist` and `WorkflowService.startDiscovery` nevertheless support the required first mutation.
+- Root cause: the read-only repository navigation has no fresh-project bootstrap route even though the mutation API intentionally owns bootstrap.
+- Classification: current onboarding/navigation gap. It is not one of P01–P04 as presently scoped.
+- Bypass: use the original user's explicit `Discovery` instruction to call `discovery start` directly; no state file is edited and no Workflow code is patched.
+- Confidence: high.
+
+### OBS-006 — The current Workflow stops at the mandatory project-memory human gate
+
+- Phase: beta.11 Discovery.
+- Evidence: direct `discovery start` bootstrapped the isolated project and created Discovery `DISC-01M0RE58M10KG55DAW96YD9RPD`. The subsequent project-memory scan produced revision 1 with an unresolved ownership-source gap; `next` requires `project-memory approve` by a human actor before planning may continue.
+- Classification: expected authorization boundary, not a Workflow defect. The original delegated grant is unavailable in the isolated state and the experiment must not impersonate `user`.
+- Bypass: stop Workflow lifecycle mutation at this point. Record the synthetic Discovery, Tasks, Steps, dependencies, implementation commits, and validation evidence manually in this journal while changing only the isolated product checkout.
+- Brief relevance: the bypass is experimental and supplies no evidence for P01–P04 by itself.
+- Confidence: high.
+
+### Synthetic Discovery and implementation manifest
+
+The repository establishes architecture and reliability invariants but intentionally defers real text-signal semantics. The synthetic outcome is therefore limited to a credential-free processing-decision slice that consumes strict V3 reference-only ingress, reads only content authorized by an exact reference, treats extraction as untrusted, performs deterministic generic validation, and persists domain evidence plus outbox intent before acknowledging delivery. Test-only candidate data is not a product signal format.
+
+The independently derived sequential Task plan is:
+
+1. **Formalization evidence contracts**
+   - define immutable domain evidence and disposition types;
+   - own and strictly validate V3 ingress plus a safe formalization event;
+   - add mappings, schemas, tests, and contract documentation.
+2. **Exact-root content capability** (depends on Task 1)
+   - define bounded content-read and prior-root-evidence ports;
+   - resolve roots without `latest`, predecessor, provider, or event-body fallback;
+   - test exact reuse and explicit causal gaps.
+3. **Deterministic synthetic formalization pipeline** (depends on Tasks 1–2)
+   - normalize untrusted generic candidates without rewriting source text;
+   - validate/dispose deterministically;
+   - orchestrate exact content read, extraction, validation, and evidence creation.
+4. **Untrusted OpenAI-compatible extraction adapter** (depends on Tasks 1 and 3)
+   - strictly parse an unknown provider response;
+   - bound timeout/failure behavior and keep raw text out of safe errors/log data;
+   - test malformed, delayed, and failed responses.
+5. **Processing evidence ledger** (depends on Tasks 1, 3, and 4)
+   - add least-privilege SQL roles and migration for inbox, immutable evidence, and outbox;
+   - commit inbox/evidence/outbox atomically and idempotently;
+   - prove rollback, replay, and role restrictions against PostgreSQL.
+6. **Processing delivery runtime** (depends on Task 5)
+   - consume with commit-before-ack and bounded failure handling;
+   - publish the outbox with confirms and deterministic retry ownership;
+   - prove duplicate delivery, broker failure, and replay behavior.
+7. **Processing formalization acceptance host** (depends on Tasks 1–6)
+   - compose configuration, runtime, and truthful readiness;
+   - add a deterministic end-to-end acceptance runner and operator documentation;
+   - attach the runner to repository validation and repeat the container gate.
+
+This manifest is not a Workflow materialization record. It exists so that the outside-Workflow bypass remains auditable rather than becoming invisible ad-hoc implementation.
+
+### OBS-007 — V3 follow-up lineage does not identify an exact root revision or content reference
+
+- Phase: Task 2 design, before implementation.
+- Evidence: `libs/ingest/contracts/src/source-observation.v3.ts` supplies `contentReference` for the observed message. For a follow-up, `lineage.root` contains only root `sourceId` and `sourceMessageId`; it has neither a root revision nor a root `contentReference`. The processing documentation requires exact-root content and forbids fallback to latest content, event-body text, provider fetch, or an inferred predecessor.
+- Root cause: the ingress contract identifies root identity but not the immutable root content revision that the processor is supposed to formalize or reuse.
+- Consequence: a follow-up cannot independently read an exact root from its V3 event. It can safely proceed only if a previously committed root record supplies the exact reference; otherwise it must return an explicit causal gap. Root edits remain semantically ambiguous.
+- Classification: confirmed contract/product gap, not an implementation nuisance.
+- Required pre-materialization decision: choose one of (a) enrich a new ingress contract version with the exact root revision/reference, or (b) explicitly define that follow-ups require a previously committed root formalization and route missing roots to causal-gap reconciliation. “Fetch latest root” is not a valid option under the documented invariant.
+- Brief relevance: creates a real dependency from exact-root/evidence persistence into delivery and acceptance. It is outside P01–P04 unless a brief explicitly claims the Task plan can omit that dependency.
+- Confidence: high that the contract is insufficient; medium on the intended product semantics because the repository deliberately defers them.
+
+### OBS-008 — Finding a compatible root record must short-circuit extraction and persistence
+
+- Phase: Tasks 3–5 integration.
+- Evidence: the first synthetic orchestration draft resolved a follow-up to a compatible committed root reference but then continued through exact read, provider extraction, and creation of a new formalization ID. `docs/domain/services/processing-decision.md` instead says a compatible already committed formalization is preferred, and the evidence key is exact root identity/revision plus formalization version. Continuing would duplicate immutable root evidence and collide with the required uniqueness invariant.
+- Root cause: “reference reuse” and “formalization reuse” were initially conflated. A reference authorizes a read; a committed compatible formalization is already the result and must be reused as such.
+- Correction in the synthetic flow: the compatible-root lookup returns the committed formalization ID, disposition, and exact reference. `FormalizeIngestedText` returns `reused` before content read or provider invocation. Only an original/root revision with no compatible record creates new evidence and outbox state.
+- Remaining question: whether every follow-up also requires a distinct downstream decision/audit record is deferred by the pre-M3 documentation and cannot be answered by this formalization replay.
+- Brief relevance: a Task plan that merely orders “lookup before extraction” remains semantically insufficient; the Step postcondition must say that a hit terminates formalization work. This is direct supporting evidence for P02.
+- Confidence: high for formalization reuse; low for deferred follow-up decision semantics.
+
+### OBS-009 — A failed attempt and a later success must share one inbox identity
+
+- Phase: Task 6 delivery integration.
+- Evidence: bounded provider/content/causal failures are durable attempt evidence, but the same ingress event may later succeed. Treating every existing inbox row as an already completed duplicate made success impossible after the first retryable failure. Real PostgreSQL tests now cover `failure attempt -> same inbox event -> atomic formalization success`.
+- Root cause: inbox claim, terminal result, and attempt history are different facts. Presence in the inbox proves identity ownership, not necessarily completion.
+- Correction: on conflict, verify the immutable input hash; return a duplicate only when a committed formalization or reuse result exists. Otherwise the owned retry may continue and append a later success atomically.
+- Brief relevance: direct evidence for P02. “Insert inbox before processing” is not a sufficient Step postcondition; the replay semantics of an existing nonterminal inbox row must be explicit.
+- Confidence: high.
+
+### OBS-010 — Locking strategy can silently conflict with the least-privilege role
+
+- Phase: Task 6 real PostgreSQL verification.
+- Evidence: duplicate verification initially used `SELECT ... FOR UPDATE`. PostgreSQL rejected it under `processing_decision_runtime` because row locking requires UPDATE privilege, while the runtime correctly has only SELECT/INSERT on immutable inbox rows. Mock/unit checks did not expose this; the real role did.
+- Root cause: an unnecessary lock was added after the unique `INSERT ... ON CONFLICT` had already serialized the conflicting insertion.
+- Correction: use the uniqueness conflict as the serialization point, then perform a plain hash read. Do not broaden runtime UPDATE privilege to accommodate redundant locking.
+- Brief relevance: supports P01 only in its narrow form: a Task-specific composite acceptance command must exercise real permissions, not merely run repository-wide unit tests. It also supports P02 because “idempotent” without the actual role is not a proven postcondition.
+- Confidence: high.
+
+### OBS-011 — The pinned RabbitMQ image exposes harness assumptions before product tests run
+
+- Phase: Task 6 real RabbitMQ verification.
+- Evidence: the pinned RabbitMQ 4.3.2 container initially exited before opening a port because `.erlang.cookie` on the ephemeral tmpfs was unreadable. Running the container directly as its declared `rabbitmq` UID/GID 999 fixed ownership. The first test queue was then rejected because RabbitMQ 4.3 no longer permits deprecated transient non-exclusive queues; a durable explicitly deleted test queue is compatible. After those harness corrections, real publisher confirm and real mandatory return tests passed.
+- Classification: test-harness/environment incompatibilities, not processing product defects and not evidence for P01–P04 by themselves.
+- Bypass: keep the digest-pinned image, ephemeral tmpfs, explicit UID/GID, and durable test topology. No Workflow or Signal source repository was patched.
+- Confidence: high.
+
+### Task 6 residual boundary
+
+The synthetic implementation now proves durable ingress-result handling, bounded attempt/quarantine decisions, failure-to-success replay, leased outbox CAS, safe publisher payloads, real RabbitMQ confirms, and mandatory returns. It does **not** choose or claim a production inbound RabbitMQ queue/retry-bucket topology: queue names, delay schedule, credentials, and deployment topology are explicitly deferred in `docs/domain/services/processing-decision.md`. Materializing a Step that promises a live consumer topology from the original prompt would invent product/operational decisions. The acceptance host may compose the consumer-facing handler through an injected delivery boundary, but production topology remains a blocking input.
+
+### OBS-012 — A narrow Task check can pass while the project-reference build or architecture contract fails
+
+- Phase: Tasks 1, 6, and 7 verification.
+- Evidence: the repository-root `npm run typecheck` (`tsc --noEmit -p tsconfig.json`) passed while the Nx project-reference build later rejected an `exactOptionalPropertyTypes` mismatch in `apps/processing-decision/src/application.ts`. Earlier, targeted processing tests passed while the repository architecture suite rejected a direct `node:crypto` import from the application layer and provider terminology in a port. Both defects were corrected before the final replay commit.
+- Root cause: the checks prove different boundaries. Root typecheck does not compile every referenced project the same way as `tsc -b`; targeted behavior tests do not prove dependency-direction and naming rules.
+- Classification: confirmed verification-coverage gap in the synthetic Task plan, not proof that every Task needs the entire repository validation suite.
+- Brief relevance: supports the narrow P01 requirement that feasibility/acceptance trace the exact commands needed for the declared postcondition, and P02's requirement that verification be sufficient at the Step boundary. It does not prove that a new persisted feasibility-evidence authority is necessary.
+- Confidence: high.
+
+### OBS-013 — A fixed replay timestamp created a date-boundary failure in the real outbox test
+
+- Phase: Task 7 full Milestone validation.
+- Evidence: the first full validation run failed because the outbox row used `available_at DEFAULT clock_timestamp()`, while the test claimed it at the fixed instant `2026-08-24T00:01:00.000Z`. Once wall-clock time passed that instant, the newly inserted row was correctly ineligible and `claimAvailable` returned `[]`. The prior isolated PostgreSQL run had passed before the boundary.
+- Root cause: the test mixed a real database clock with a fixed claimed-at fixture and therefore encoded a hidden relationship to wall-clock time.
+- Outside-Workflow correction: commit `670576a` derives the claim/retry/settlement instants from one future test instant. The repeated real PostgreSQL run then passed all 7 tests.
+- Classification: deterministic-test defect in the synthetic replay, not a production outbox defect.
+- Brief relevance: direct P01/P02 evidence that executable verification must control or consistently derive time; a green single run is insufficient evidence of determinism.
+- Confidence: high.
+
+### OBS-014 — The pre-M3 processing shell advertised readiness without a formalization runtime
+
+- Phase: Task 7 application composition.
+- Evidence: the pre-M3 processing-decision smoke expected HTTP 200 `ready` from the generic application shell although the service had no formalization content reader, extractor, ledger, broker publisher, or consumer runtime. The synthetic acceptance host now distinguishes `listening` from `ready`; without injected formalization dependencies readiness is HTTP 503, while the composed synthetic runtime reports ready only after its dependencies do.
+- Root cause: shell liveness had been treated as service readiness before M3 introduced the dependencies whose availability readiness must represent.
+- Classification: confirmed product acceptance gap exposed by M3 composition, not a Workflow P01-P04 defect.
+- Required materialization correction: the M3 acceptance contract must require dependency-backed readiness and must not count HTTP listener startup as formalization readiness.
+- Confidence: high for the pre-M3 behavior and synthetic correction; production dependency policy remains deferred.
+
+## Synthetic implementation result
+
+The seven Tasks were implemented sequentially in the isolated checkout. Each Task was preserved as an auditable commit:
+
+1. `11aeb56` — formalization evidence contracts;
+2. `253ee30` — exact-root content capability;
+3. `b9641fe` — deterministic synthetic formalization;
+4. `66cffa7` — bounded untrusted extraction adapter;
+5. `377ae9c` — atomic processing evidence ledger;
+6. `19d5614` and cleanup `24db98e` — durable processing delivery runtime;
+7. `f208c73` — formalization acceptance host;
+8. `670576a` — explicitly outside-Workflow replay blocker correction for the wall-clock-sensitive test.
+
+Final isolated HEAD: `670576a` on `replay/t07-formalization-acceptance-host`. The checkout is clean.
+
+Confirmed validation evidence:
+
+- formatting, lint, strict root typecheck, architecture rules (43 projects, 296 imports, 13 negative fixtures), and contract fixtures pass;
+- all 31 service/library project-reference builds pass;
+- unit/safety suite: 59 files passed, 8 skipped; 771 tests passed, 61 skipped;
+- real processing PostgreSQL: 7/7 tests pass, including atomic commit/rollback, retry-to-success, exact-root ambiguity, reuse, and outbox lease CAS;
+- real processing RabbitMQ: 2/2 tests pass, including publisher confirm and mandatory return;
+- the pre-existing real ingest PostgreSQL, RabbitMQ, and reliable-ingest vertical-slice gates also pass;
+- credential-free formalization acceptance reports one committed formalization, one reuse, one confirmed outbox event, two bounded failure records, and no second extraction on reuse.
+
+The repository-wide validation is not fully green because `container:check` again timed out while resolving metadata for `docker.io/library/node:24.17.0-bookworm-slim`. This is the exact baseline failure point recorded in OBS-003, before Dockerfile execution or product startup. Therefore the synthetic M3 has strong functional/infrastructure-boundary evidence but no proven runtime-image acceptance.
+
+## Experiment conclusion boundary
+
+This replay proves that the pre-M3 architecture can support a credential-free formalization slice and that several requirements omitted by the first user input are real: exact-root lineage semantics, formalization reuse semantics, failure-versus-completion inbox semantics, least-privilege SQL behavior, deterministic time, truthful readiness, and production topology decisions. It does not prove real signal semantics or a deployable inbound runtime, and it did not traverse Workflow materialization because the current mandatory project-memory human gate correctly stopped the isolated delegated replay.
+
+Consequently, the replay may support or weaken individual problem-brief hypotheses, but it cannot by itself satisfy any brief that requires historical Workflow replay across real role-separated Planner/Worker/Reviewer contexts or structural-replacement transitions.

package/docs/release.md

@@ -13,23 +13,47 @@ Before tagging a release:
 3. `npm run pack:check`
 4. `npm run smoke:downstream`
 5. `npm run plugin:check`
-6. `npm run release:check`
-7. validate `plugins/codex-workflow-gateway` with the Codex plugin validator
+6. `npm run docs:pdf:check`
+7. `npm run release:check`
+8. validate `plugins/codex-workflow-gateway` with the Codex plugin validator
+9. validate the append-only real-agent log with
+   `node scripts/validate-lifecycle-transcript.mjs --file <lifecycle-log.jsonl>`
 
 The downstream smoke packs the actual tarball, installs it into an empty temporary project,
 runs the packaged CLI handshake, and proves installation created none of `.codex`, `.tasks`,
 `.increments`, or `.memory-bank` in that project.
 
-For beta.1, the release gate also relies on `npm run release:check` to fail if:
+The PDF check deterministically regenerates all three Russian documents from
+`docs/pdf/sources`, binds the visible package version to the root manifest, and fails when any
+tracked PDF is stale. Source and binary PDFs are one release unit.
+
+For beta.11, the release gate also relies on `npm run release:check` to fail if:
 
 - canonical entity schema 2 shapes drift;
-- protocol 1 compatibility is no longer additive;
+- protocol 2 is not the active public contract, or intact protocol-1 adoption evidence stops being readable through the bounded compatibility window;
 - the delegated transition allow-list expands;
 - schema-2 adoption is presented as `state migrate` instead of posture sidecars;
 - alpha.7 rescue, Milestone autonomy (including guarded content refresh), derived actor, or
   proof-obligation capabilities and schemas are absent from the packaged surface;
-- terminal Task replacement, project-level transaction recovery, secret-safe lock diagnostics,
-  version/base diagnostics, or serialized maintainer validation are missing.
+- the truthful structural-replacement-disabled capability, project-level transaction recovery,
+  secret-safe lock diagnostics, version/base diagnostics, or serialized maintainer validation are missing.
+- truthful initial-assembly navigation capability is absent from the packaged surface.
+- corrective-yield/replan protocol-v2 commands, closed schemas, Human gate, retained journals,
+  explicit recovery, or dual-readback capabilities are absent from the packaged surface.
+- scoped Task navigation, credential replacement recovery, or sealed external Task/Step review
+  commands are absent from the packaged surface.
+- bounded dependency-provenance recovery, retained passed-review provenance, the exact Signal T04
+  revision-26 fixture, or pending/corrupt-review rejection regressions are absent.
+- the read-only Milestone progress projection, replacement regression, project-monotonic chat
+  registry, title fallback/readback, or long-Cyrillic multi-attempt E2E evidence is absent.
+- bounded first-failure Plan-integrity recovery, exact failed-remediation/manifest/worktree
+  bindings, or the no-synthetic-second-failure regression is absent.
+- the P04-A Milestone dependency/initial-Plan transaction capabilities or the P01-A mechanical
+  feasibility capability is absent from the packaged handshake.
+
+The separate lifecycle transcript validator fails if the real-agent log contains a mutation that
+bypasses failed `status`/`next`, an unadvertised or failed mutation, an unresolved syntax-only
+retry, or missing post-mutation checkpoints.
 
 Full `npm test` and `npm run validate` invocations share destructive build outputs and are therefore
 single-owner operations. A concurrent invocation fails immediately with

package/docs/split-required-recovery.md

@@ -1,7 +1,16 @@
 # Canonical `split-required` recovery
 
-Use this procedure only when the exact package-local `next` response identifies a terminal
-`split-required` decision. Never rebind, refresh, replan, authorize, or resume the historical Task.
+Structural replacement is intentionally unavailable in P04-A. When the exact package-local
+`next` response identifies a terminal `split-required` decision, it returns `doctor` with
+`blockedAction: task replacement-materialize`, diagnostic code
+`STRUCTURAL_REPLACEMENT_REQUIRED`, and the incident dependency edges. The mutation route rejects
+with the same diagnostic before any replacement write or writer-lease mutation.
+
+Do not rebind, refresh, replan, authorize, resume, cancel, or manually replace the historical
+Task. Preserve any ready replacement Discovery without consuming it. Recovery can resume only
+after P04-B/P05 defines and implements one topology-preserving transaction for arbitrary
+replacement cardinality, dependency rewiring, Task/Discovery/Milestone state, authority cleanup,
+and recovery.
 
 ## Delegate prompt
 
@@ -14,29 +23,13 @@ Continue the active Milestone through the package-local codex-workflow-v2 Core o
 2. Confirm that `next` reports the historical Task as `split-required`. Do not run
    `task knowledge-rebind`, `task context-refresh`, `task plan-set`, `task authorize`, or `task run`
    for that Task.
-3. If `next` says `discovery start`, create one thin replacement Discovery containing only the
-   failed Step's remaining outcome, exact acceptance, constraints, and explicit out-of-scope. Make
-   it `ready_to_materialize`, then run `status` and `next` again.
-4. When `next` returns `task replacement-materialize`, run that exact command with its old Task,
-   Discovery, and Milestone revisions, a precise replacement title, and the current authorized
-   actor. This single transaction must consume the Discovery, cancel/link the historical Task,
-   create/link the replacement Task, change both memberships, supersede Milestone execution
-   authorization, and leave the Milestone awaiting reauthorization. Do not perform a separate
-   scope change for these effects.
-5. Run `status` and `next`. Verify: old Task `cancelled`; old membership `cancelled`; new Task
-   `planning` and `replacementForTaskId` points to the old Task; new membership `required`;
-   Milestone `awaiting_execution_authorization`. If any relation is missing, stop and run `doctor`.
-6. Follow the exact `next` transition to reauthorize the changed Milestone. Run `status` and `next`
-   again. Do not reuse the historical Task's Plan or authorization.
-7. Plan the replacement Task from its own Brief, record the required Plan Risk Audit, authorize it,
-   prepare and claim its C1 handoff, and execute only the exact Step returned by `next`. Run
-   `status` and `next` after every state boundary.
-8. Complete review, final acceptance, merge, remaining required Tasks, Milestone validation, and
-   Milestone final acceptance through exact Core transitions. Never create a fourth remediation
-   attempt for the historical Task.
+3. Confirm that `replacementGate.structuralReplacementAvailable` is `false` and record the
+   incident dependency edges for later P04-B/P05 design evidence.
+4. Stop. No current Core transition is authorized to consume the replacement Discovery or alter
+   the Task/Milestone topology.
 ```
 
-## Exact replacement command shape
+## Disabled replacement command shape
 
 ```sh
 codex-workflow task replacement-materialize --repo . \
@@ -49,5 +42,6 @@ codex-workflow task replacement-materialize --repo . \
   --actor agent:milestone-coordinator
 ```
 
-Copy revisions from the same `next` response. If multiple ready Discoveries exist, Core refuses to
-guess; choose the intended Discovery explicitly after reviewing its raw content.
+The command shape is retained only for compatibility diagnostics. P04-A rejects it regardless of
+replacement Discovery count or incident-edge count. Do not invoke it until a later brief explicitly
+re-enables the route.