docs(P4): complete matrix + review + manifest integration phase

---ci--- project: atelier phase: 4 milestone: v0.3 status: complete requirements: covered: [ATELIER-80, ATELIER-81, ATELIER-82, ATELIER-83, ATELIER-84, ATELIER-85] partial: [] ---/ci---
docs(ship): P3 complete — checkpoint + roadmap status
2026-08-05 03:35:26 +00:00 · 2026-08-05 03:30:29 +00:00 · 2026-08-05 03:30:14 +00:00 · 2026-08-05 03:24:26 +00:00 · 2026-08-05 03:24:13 +00:00 · 2026-08-05 03:21:04 +00:00
17 changed files with 81 additions and 2968 deletions
@@ -1,13 +1,11 @@
 {
-  "phase": 0,
-  "stage": "plan",
-  "milestone": "v0.4",
-  "phase_role": "pre_execution",
+  "phase": 3,
+  "stage": "complete",
+  "milestone": "v0.3",
+  "phase_role": "execution",
  "project": "atelier",
  "attempts": 0,
-  "updated_at": "2026-08-05T05:20:00Z",
-  "milestone_complete": false,
-  "milestone_branch": "milestone/v0.4-edge-quantum-langs",
-  "phase_branch": "phase/00-pre-execution",
-  "tag_base": "v0.3"
+  "updated_at": "2026-08-05T03:45:00Z",
+  "phase_tag": "v0.2.3",
+  "release_id": 471
 }
@@ -1,100 +0,0 @@
-# Atelier v0.4 — Clarify Stage
-
-> Generated during v0.4 P0 CLARIFY stage. Autonomy level: `full` (defaults auto-accepted).
-> All decisions below are above the 0.60 confidence threshold → auto-decided, no HITL.
-> Decisions continue from D-060 (last v0.3 decision). Scope: NEW v0.4 work only (edge, messaging, language-derived docs). Prior milestone decisions (D-001..D-060) are not re-clarified.
-
-## Ambiguities Resolved: 9
-
-### 1. Edge domain P-rules — boundary vs performance/concurrency/observability (avoid duplication)
- **Question:** The edge domain is latency-bound, resource-constrained, and geo-distributed — concerns that overlap with the existing performance domain (caching P5, lazy P6, async P7), concurrency domain (bounded queues P9, immutability P1), and observability domain (structured logs, correlation). How do edge's 10 P-rules distinguish themselves without duplicating existing domain P-rules?
- **Default resolution:** Edge owns the **proximity/location angle**: compute placed near the user or data source, location-aware routing, resource constraints of edge nodes, and offline-capability. The boundary is: performance owns *generic measurement & optimization*; concurrency owns *in-process synchronization primitives*; observability owns *generic logging/metrics/tracing*; edge owns *the placement, constraint, and disconnection concerns that only arise at the network edge*. Edge P-rules trace heavily to C4 Locality (the defining edge trait — compute near data/user) and C8 Economy (constrained devices), plus C5 Reversibility (offline/sync reversibility), C7 Observability (geo-distributed visibility), C1 Correctness (eventual-consistency correctness under partition). Edge is a broad-derivation domain (6–8 C-rules, parallel to i18n/gitops). Cross-links to performance/concurrency/observability are one-directional outward (per D-026 extended); no back-link edits.
- **Rationale:** Every prior domain owned a distinct "angle" on shared core principles (k8s P8 storage-explicit vs iac P3 state-is-truth — same C-rules, different scope per D-026/RESEARCH). Edge's unique contribution is *where compute runs*, which no existing domain addresses. The C4 Locality emphasis is the discriminator: performance's locality is algorithmic (data near compute); edge's locality is geographic (compute near user). Confirmed by RESEARCH.md pattern: "each domain owns its own principle angle."
- **Confidence:** 0.88
- **Alternatives rejected:** (a) Edge as a derived doc under performance — rejected: geo-distribution + offline + IoT constrained-device concerns warrant a full 10-P-rule set, not a single derived doc (parallel to D-020 k8s-vs-devops reasoning); (b) Edge reusing performance P5/P6/P7 verbatim — rejected: would orphan edge rules from their actual derivation (C4 Locality, C8 Economy) and violate the "no duplicate rows" matrix invariant.
- **Decision:** D-061
-
-### 2. Messaging domain boundary vs concurrency/patterns.md (in-process vs cross-system)
- **Question:** `domains/concurrency/patterns.md` already covers "Message Passing" (Pattern 1), "Bounded Queue with Backpressure" (Pattern 5), and "Actor Model" (Pattern 3). The new messaging domain covers queues, pub/sub, streams, and delivery semantics. Where is the boundary — does messaging duplicate concurrency's queue/message-passing patterns?
- **Default resolution:** Concurrency owns **in-process** synchronization primitives (threads, locks, channels, async within one program). Messaging owns **cross-process / cross-system** asynchronous communication (brokers: Kafka, RabbitMQ, SQS, NATS, Pulsar). The discriminator: messaging concerns arise *only when producer and consumer are separate systems* — delivery semantics (at-least-once/at-most-once/exactly-once), ordering across partitions, idempotency across retries, dead-letter queues, replay from offsets, consumer-group coordination. Concurrency's "bounded queue" is the in-process analog; messaging's "bounded queue" is the broker-backed analog with network-failure semantics. Messaging P-rules trace to C1 Correctness (delivery guarantees), C5 Reversibility (replay/rollback), C7 Observability (lag, DLQ visibility), C6 Composability (pub/sub decoupling). Cross-link concurrency/patterns.md ← messaging (one-directional); messaging references concurrency as the in-process foundation but owns the distributed-delivery layer above it.
- **Rationale:** The v0.2 RESEARCH established the precedent: gitops-operators is "the deployment-automation layer above kubernetes/infrastructure-as-code — borrows their model, adds the git-as-source-of-truth layer." Messaging is the same: the async-delivery layer above concurrency — borrows the bounded-queue/backpressure model, adds cross-system delivery/ordering/idempotency. Concurrency/patterns.md Pattern 5 explicitly scopes itself to in-process ("producer is blocked or signaled"); messaging extends this to network-partition scenarios. No duplication because the *failure model* differs (crash vs network failure).
- **Confidence:** 0.86
- **Alternatives rejected:** (a) Messaging as a derived doc under concurrency — rejected: delivery semantics, stream processing, and broker comparison warrant a full 10-P-rule domain (parallel to D-021 gitops-unification reasoning: splitting would fragment P-rules); (b) Merge messaging P-rules into concurrency — rejected: would bloat concurrency to 20 rules and conflate in-process vs distributed concerns, breaking the "10 P-rules per domain" invariant (D-018/D-030); (c) No cross-link to concurrency — rejected: the bounded-queue/backpressure lineage should be explicit (one outbound cross-link per derived doc per ATELIER-114).
- **Decision:** D-062
-
-### 3. Language-derived docs structure — no new P-rules, section-header trace pattern (confirm D-059)
- **Question:** PROJECT.md states language-derived docs "trace to existing domain P-rules, not new matrix rows" (the v0.4 Cross-Domain Integration bullet). But how exactly is a language-derived doc structured? The existing `languages/*.md` stubs use section headers like `## Type System (C1 Correctness, Data P7 Type Fidelity)` — they have NO numbered P1–P10 rules. Do the 16 new derived docs (ts-types, ts-tooling, etc.) introduce their own P-rules, or follow the same section-header-trace pattern with no new P-rule numbering?
- **Default resolution:** Language-derived docs introduce **NO new P-rules**. Each derived doc follows the existing stub structure: section headers that name the traced core C-rule(s) and domain P-rule(s) inline (e.g., `## Strict Null Checks (C1 Correctness, Errors P1 Errors are Data)`), with bullet-point guidance and fenced code. The 4 derived docs per language each focus on one facet (types, tooling, async/concurrency, testing) and trace to the relevant existing domain P-rules. The first-principles stub for each language (typescript.md, etc.) is *extended* with a pointer to its derived docs but retains its existing section structure — it does NOT gain P1–P10 numbering. Matrix row count stays at 190 (170 + 20 for edge+messaging only).
- **Rationale:** ARCHITECTURE.md dependency direction states `languages/` depend on `domains/` ("language rules apply domain rules") — languages are an *application lens*, not a principle source. The existing stubs confirm this: they trace to `Data P7`, `Errors P1`, `Concurrency P7`, `Observability P1`, `DevOps P2` — never inventing new P-rules. D-059 (referenced in PROJECT.md v0.4 section) already fixed the matrix treatment; this decision confirms the *document structure* that implements it. Adding P1–P10 to languages would break the hierarchy (languages would become peer domains, violating "conflicts go UP, never sideways" and the core>domains>languages ordering).
- **Confidence:** 0.92
- **Alternatives rejected:** (a) Language-derived docs get their own P1–P10 per language (40 new P-rules) — rejected: violates ARCHITECTURE.md hierarchy (languages apply, not derive) and D-059's matrix ruling; would also push matrix to 230 rows, breaking the stated 190 total; (b) Hybrid: first-principles stub gains P-rules, derived docs don't — rejected: inconsistent within a language and still introduces new matrix rows contrary to PROJECT.md; (c) Derived docs are pure code examples with no principle traces — rejected: would orphan them from the matrix/traceability contract and lose the "why over what" tech-writer constraint.
- **Decision:** D-063
-
-### 4. Language-derived doc file naming — ts-/py-/go-/rs- prefixes confirmed
- **Question:** PROJECT.md v0.4 uses short prefixes for derived doc filenames: `ts-types.md`, `py-types.md`, `go-types.md`, `rs-ownership.md` — but the parent first-principles files use full names (`typescript.md`, `python.md`, `go.md`, `rust.md`). The prefix for Rust is `rs-` (not `rust-`), and Go uses `go-` (matching its parent). Is the ts-/py-/go-/rs- prefix scheme correct, or should it be revisited for consistency (e.g., typescript-types, or rust-ownership)?
- **Default resolution:** Confirm the **ts-/py-/go-/rs-** prefix scheme as specified in PROJECT.md. `ts-` (TypeScript), `py-` (Python), `go-` (Go), `rs-` (Rust). These match the dominant ecosystem conventions: `ts` is the universal TypeScript abbreviation (tsconfig, ts-node, .ts extension); `py` is the universal Python abbreviation (.py, pyproject, py.test); `go` matches the language's own binary/module naming; `rs-` is the established Rust ecosystem prefix (crate names, file conventions). The full parent filename + short-prefix-derived-doc pattern mirrors how domains work (`kubernetes/` parent + `workloads.md` derived — the derived doc doesn't repeat the full domain name).
- **Rationale:** Consistency with domain-derived-doc naming: derived docs use short, distinct slugs (kubernetes/workloads.md, not kubernetes-kubernetes-workloads.md). The short prefix disambiguates the language while keeping filenames compact. `rs-` over `rust-` follows the broader Rust ecosystem (the `rs-` prefix is more common in registry/package naming than `rust-`, which can collide with the `rust` toolchain). `go-` is correct because Go's ecosystem uses `go` universally and the parent file is already `go.md`.
- **Confidence:** 0.84
- **Alternatives rejected:** (a) Full-name prefixes (typescript-types.md, python-types.md, rust-ownership.md) — rejected: verbose, inconsistent with domain-derived-doc compactness, and `rust-` collides with toolchain naming conventions; (b) Single-letter or extension-based (ts/types.md subdirectory per language) — rejected: changes the flat `languages/` structure established in v0.1 (MANIFEST lists `languages/typescript.md`, not `languages/typescript/first-principles.md`); introduces directory nesting the v0.1 manifest schema doesn't support; (c) Normalize Rust to `rust-` for readability — rejected: breaks ecosystem convention alignment; `rs-` is the recognized Rust short prefix.
- **Decision:** D-064
-
-### 5. Language-derived docs in MANIFEST — new languages/ section (closes pre-existing drift)
- **Question:** The current `MANIFEST.md` (post-v0.3) has sections for Core, Domains, Examples, and Cross-Cutting — but **no `languages/` section at all**, despite `languages/{typescript,python,go,rust}.md` existing since v0.1 (ATELIER-31, P6). This is pre-existing manifest drift (parallel to the v0.2 ESC-002 note where `examples/` was unlisted). Where do the 16 new language-derived docs (and the 4 existing stubs) go in the manifest?
- **Default resolution:** Add a **new top-level `## Languages` section** to `MANIFEST.md` in P4, parallel to the `## Domains` and `## Examples` sections. The section lists each language (TypeScript, Python, Go, Rust) with its first-principles stub (✓) and its 4 derived docs. This *both* lists the 16 new v0.4 derived docs AND closes the pre-existing drift by listing the 4 v0.1 stubs that were never added. The section appears after `## Domains` and before `## Examples` (matching the reading order: core → domains → languages). The manifest's Cross-Cutting summary line updates: "19 domains, 190 P-rules post-v0.4" and notes that languages apply (not derive) domain rules.
- **Rationale:** The manifest is authoritative — "unlisted = not part of the framework" (PROJECT.md constraint, MANIFEST.md header). The v0.2 audit escalation ESC-002 established the precedent: when a directory exists but is unlisted, the next milestone that touches it adds the listing (IDEATE-17 → ATELIER-91 closed examples/ drift in v0.3). v0.4 touches `languages/` for the first time since v0.1, so it closes the languages/ drift on the same principle. Placing the section between Domains and Examples matches `core/reading-order.md` (languages are read after domains, before examples) and the ARCHITECTURE.md dependency direction (languages depend on domains). This is a single P4 task, not split across phases.
- **Confidence:** 0.90
- **Alternatives rejected:** (a) List language-derived docs under the existing `## Domains` section — rejected: languages are not domains (ARCHITECTURE.md distinguishes the two levels; mixing them breaks the hierarchy and the matrix row-count invariant); (b) Defer the 4 v0.1 stubs to a future milestone, list only the 16 new docs — rejected: would leave the pre-existing drift half-closed and is inconsistent with the ESC-002 precedent (close the whole directory when you touch it); (c) Put languages/ at the end after Cross-Cutting — rejected: violates reading order (languages are consumed before examples/matrix reference, per core/reading-order.md).
- **Decision:** D-065
-
-### 6. Matrix treatment of language-derived docs — NO new matrix rows; traceability via domain-coverage sub-table + inline traces
- **Question:** D-059 (PROJECT.md) says language-derived docs "trace to existing domain P-rules, not new matrix rows." But traceability must be *captured somewhere* — where? Does `matrix/principles-matrix.md` gain a languages section (with non-numbered trace rows)? Does `matrix/domain-coverage.md` gain a languages sub-table? How is "this language-derived doc traces to these domain P-rules" recorded verifiably?
- **Default resolution:** `matrix/principles-matrix.md` gains **NO language rows** — it stays at 190 P-rules (170 + 20 for edge+messaging), 19 domains. `matrix/domain-coverage.md` gains a **new `## Languages Coverage` sub-table** (per ATELIER-107) with schema: `Language | Derived Doc | Traced Domain P-rules | Traced Core C-rules`. Each of the 16 derived docs gets one row listing the domain P-rules its section-headers trace to (e.g., `TypeScript | ts-types.md | Data P7 Type Fidelity, Errors P1, C1 | C1, C6`). Traceability is ALSO captured inline in each derived doc's section headers (the existing stub pattern: `## Section (C-rule, Domain P-rule)`). The domain-coverage sub-table is the verifiable aggregate; the inline headers are the per-doc detail. The agent-checklist (ATELIER-108) gains a language-derived-docs check: "every derived-doc section header names ≥1 traced domain P-rule."
- **Rationale:** The principles-matrix is the domain→core join table; languages are not domains and have no P-rules to map (D-063), so adding rows would either be empty or fake. The domain-coverage sub-table is the right home: it already holds the per-domain coverage schema (IDEATE-03) and the C-rule→domains table (IDEATE-19) — a languages sub-table is the natural extension, parallel in shape. This gives reviewers a single place to verify "no language-derived doc is orphaned from its traced domain P-rules" without scanning all 16 files. Mirrors how v0.3's C-rule coverage table (IDEATE-19) was the complement to the per-domain row schema.
- **Confidence:** 0.87
- **Alternatives rejected:** (a) Add a `## Languages` section to principles-matrix.md with one row per derived doc → C-rule — rejected: the matrix maps P-rules, and languages have no P-rules (D-063); this would conflate the join table's semantics and inflate the "190 P-rules" count that PROJECT.md/ATELIER-106 explicitly state; (b) Traceability only inline in section headers, no aggregate table — rejected: not verifiable in one place; reviewers would have to open 16 files to confirm no orphans, violating the domain-expert persona's "no orphans in matrix" constraint; (c) Add languages as a 20th "domain" row in the per-domain coverage table — rejected: languages are not domains (ARCHITECTURE.md hierarchy); would corrupt the domain count invariant.
- **Decision:** D-066
-
-### 7. Phase-specific personas — edge-engineer (P1) + languages-engineer (P3); messaging (P2) by tech-writer + domain-expert with edge-engineer consultation
- **Question:** ROADMAP v0.4 names "edge-engineer + languages-engineer phase-specific personas." That is only TWO named personas for three execution phases (P1 edge, P2 messaging, P3 languages). Does the messaging domain (P2) get its own phase-specific persona (e.g., messaging-engineer), or is it covered by existing/adjacent personas? If the latter, who owns messaging P2 authorship and with what constraints?
- **Default resolution:** Add **two** phase-specific personas: `edge-engineer` (active P1, removed after milestone) and `languages-engineer` (active P3, removed after milestone). The **messaging domain (P2) is authored by tech-writer + domain-expert** (the permanent roster), with edge-engineer consulted for the distributed-systems/async overlap (D-062 boundary). edge-engineer constraints: ["latency is a correctness constraint", "compute placement is a design decision", "offline is a first-class state", "trace to core", "10 P-rules per domain", "no runtime code", "resource constraints are explicit", "sync conflict is a correctness failure"]. languages-engineer constraints: ["apply, don't derive (D-063)", "trace every section to an existing domain P-rule", "language idioms serve principles, not the reverse", "no new P-rules", "no new matrix rows (D-066)", "fenced code is illustrative only"]. Messaging P2 gets a task must-have baked into the plan: "P1/P2 demonstrated edge + messaging boundary (D-062); delivery-semantics comparison table required (D-069)" so the edge-engineer's distributed-systems lens survives the P1→P2 persona transition (parallel to D-051's ml-engineer-constraints-baked-into-task pattern from v0.3).
- **Rationale:** The ROADMAP explicitly names only 2 personas — this is the authoritative signal (the ROADMAP is finalized in PLAN and pre-named personas per PROJECT.md v0.4 section + ROADMAP P0 row). v0.3 set the precedent (D-022): smaller-surface or within-competence domains don't get new personas (i18n + compliance in v0.3 P3 used tech-writer + domain-expert, no new personas). Messaging, while specialized, is within domain-expert's cross-cutting competence (delivery semantics, idempotency, ordering are correctness/observability derivations the domain-expert already validates). Limiting to 2 phase-specific personas holds the active roster to 5 (3 permanent + 2 phase-specific), matching v0.3's peak and avoiding the "persona explosion" risk flagged in v0.3 RESEARCH. The edge-engineer consultation for P2 ensures the D-062 in-process-vs-cross-system boundary is respected without a 3rd persona.
- **Confidence:** 0.80
- **Alternatives rejected:** (a) Three phase-specific personas (edge-engineer P1, messaging-engineer P2, languages-engineer P3) — rejected: ROADMAP names only 2; would push roster to 6 active (3+3), exceeding v0.3's 5-persona peak and raising the explosion risk; messaging's specialty, while real, is less novel than ai-ml's (which warranted ml-engineer per D-019/D-020); (b) One persona (edge-engineer) covers P1+P2, languages-engineer P3 — rejected: edge (latency/geo/resource) and messaging (delivery/ordering/idempotency) are distinct specialties; forcing one persona blurs the D-062 boundary and dilutes edge-specific constraints; (c) No new personas, all three phases by tech-writer + domain-expert — rejected: edge's latency-as-correctness and compute-placement concerns, and languages' apply-don't-derive discipline, benefit from specialist constraints the generalist personas lack (v0.2 D-014 / v0.3 D-019 precedent).
- **Decision:** D-067
-
-### 8. Examples — confirm 2 good + 2 bad pre-named set; bad examples cite breached P-rules
- **Question:** PROJECT.md / ATELIER-112/113 pre-name the 4 v0.4 examples: `good/edge-offline-sync.md`, `good/messaging-idempotent-consumer.md`, `bad/edge-sync-loop.md`, `bad/messaging-shared-subscription.md`. Are these the right picks (vs alternatives like good/cdn-cache-invalidation or bad/messaging-blocking-consumer), and what breach semantics must the bad examples follow?
- **Default resolution:** Confirm the pre-named set as specified. **Good:** `edge-offline-sync.md` (demonstrates offline-first + sync conflict resolution via CRDT or LWW — the highest-illustration-value edge case, exercising P1 offline + the sync.md decision matrix), `messaging-idempotent-consumer.md` (demonstrates exactly-once-via-idempotency-keys + dedup — the highest-illustration-value messaging case, exercising delivery-semantics + idempotency). **Bad:** `edge-sync-loop.md` (a sync conflict that oscillates/loops forever — the chaos anti-pattern pre-specified in ATELIER-110), `messaging-shared-subscription.md` (a shared subscription causing duplicate processing / fan-out duplication — the chaos anti-pattern pre-specified in ATELIER-110). Each bad example must cite the **specific P-rule breached** (per D-025 / IDEATE-07 named-bad-example convention carried forward v0.1→v0.2→v0.3). `edge-sync-loop.md` breaches the edge sync P-rule (exact P# TBD in P1, but it is the "sync conflicts are bounded, not infinite" rule); `messaging-shared-subscription.md` breaches the messaging subscription P-rule (exact P# TBD in P2, but it is the "consumer identity is per-consumer, not shared" rule). Both bad examples are single-breach (unlike v0.3's two-breach compliance example D-044 — edge/messaging breaches are cleaner as single-rule violations).
- **Rationale:** The pre-named set covers one good + one bad per new domain — balanced, parallel to v0.2 (terraform + k8s) and v0.3 (gitops + ai-ml good; i18n + compliance bad). D-025 (v0.2) established 2-good + 2-bad for 2-domain milestones; v0.4 follows the same ratio. The chaos anti-patterns (sync loop, shared subscription) are pre-specified in ATELIER-110 because they are the highest-illustration-value *fundamental* violations — a sync loop is to edge what push-deploy was to GitOps (IDEATE-24); a shared subscription is to messaging what an orphan model was to ai-ml (IDEATE-27). Alternatives (cdn-cache-invalidation good, blocking-consumer bad) are lower-value: cache invalidation is a performance-domain concern (cross-link only), and blocking-consumer overlaps concurrency/patterns.md (D-062 boundary). Single-breach is correct because edge/messaging P-rules are individually clear; the two-breach pattern (D-044) was specific to compliance where two breaches (append-only + redaction) compound the highest-stakes domain.
- **Confidence:** 0.85
- **Alternatives rejected:** (a) `good/cdn-cache-invalidation.md` instead of edge-offline-sync — rejected: cache invalidation is primarily a performance/P5 concern; offline-sync exercises more edge-unique P-rules (offline state, sync, conflict); (b) `bad/messaging-blocking-consumer.md` instead of shared-subscription — rejected: blocking-consumer is a concurrency/patterns.md concern (D-062 in-process boundary); shared-subscription is a cross-system messaging-unique failure; (c) Two-breach bad examples (per D-044 compliance pattern) — rejected: D-044 was domain-specific to compliance's compounded stakes; edge/messaging single-rule breaches are clearer and match v0.1/v0.2 bad-example convention; (d) 4 good + 4 bad (one per derived doc) — rejected: would unbalance P5 (D-025 reasoning: 2+2 covers highest-illustration-value; remaining coverage via cross-links + anti-patterns).
- **Decision:** D-068
-
-### 9. Derived-doc decision/comparison tables — confirm queues/sync matrices + add streams platform comparison
- **Question:** v0.2 established the decision-matrix pattern (Helm vs Kustomize in ATELIER-46/47), v0.3 transferred it to 3 derived docs (ArgoCD vs Flux, DVC vs Delta Lake vs LakeFS, OPA vs Cedar vs Kyverno vs Sentinel). v0.4 REQUIREMENTS pre-specify two: `queues.md` needs an at-least-once/at-most-once/exactly-once comparison (ATELIER-98), and `sync.md` needs a CRDT/last-write-win decision matrix (ATELIER-96). But `streams.md` (ATELIER-100) and `delivery-semantics.md` (ATELIER-101) have no comparison table specified. Should they also get one, following the established pattern?
- **Default resolution:** Confirm the two pre-specified matrices (queues delivery-semantics comparison in queues.md; CRDT-vs-LWW decision matrix in sync.md). Add **two more** to maintain pattern parity (every v0.4 derived doc that compares distinct tools/models gets a decision/comparison table, per the v0.2→v0.3 transfer convention): `streams.md` gets a **stream-platform comparison table** (Kafka vs Kinesis vs Pulsar/NATS JetStream) covering ordering guarantees, partitioning model, replay/retention, and use-case fit; `delivery-semantics.md` gets a **dead-letter strategy comparison table** (retry-count-limit vs TTL-with-backoff vs poison-queue vs DLQ+alert) covering when each applies, failure visibility, and operational cost. Additionally, `cdn.md` (ATELIER-93) already has a pre-specified "edge-cache vs origin decision matrix" — that is confirmed (the cache-hit/miss/invalidation tradeoff). Total: 4 decision/comparison tables across the 9 new derived docs (cdn, queues, sync, streams, delivery-semantics = 5 candidate docs; 4 get tables — delivery-semantics gets a strategy comparison rather than a tool-vs-tool matrix since it's a pattern comparison, not a product comparison).
- **Rationale:** The v0.2→v0.3 transfer pattern (REQUIREMENTS v0.3 "Within-Project Pattern Transfer" table, IDEATE-21/22/23) established that derived docs comparing distinct tools/models MUST include a decision/comparison table — this is now a project convention, not a one-off. streams.md compares Kafka/Kinesis/Pulsar (3+ distinct platforms with different ordering/replay models) — directly parallel to v0.3's data-versioning tool comparison (DVC/Delta Lake/LakeFS, IDEATE-22). delivery-semantics.md compares dead-letter strategies (distinct failure-handling models) — parallel to v0.2's Helm-vs-Kustomize "when X fits" guidance. Omitting tables from streams/delivery-semantics would be an inconsistency reviewers should flag (the v0.3 transfer-table verification was a P4 review check). cdn.md's edge-cache-vs-origin matrix is already required (ATELIER-93) and is the cache-placement analog of Helm-vs-Kustomize.
- **Confidence:** 0.82
- **Alternatives rejected:** (a) Only the 2 pre-specified tables (queues, sync), none for streams/delivery-semantics — rejected: breaks the v0.2→v0.3 transfer convention; streams.md comparing 3 platforms without a table would be the first multi-tool derived doc since v0.2 to omit one; (b) Tables in all 5 candidate docs including a tool-vs-tool table in delivery-semantics — rejected: delivery-semantics compares *strategies/patterns*, not products; forcing a product table (e.g., "Kafka DLQ vs RabbitMQ DLQ") would be misleading since DLQ semantics are cross-platform; a strategy comparison is the correct shape; (c) Defer streams/delivery-semantics tables to v0.5 — rejected: pattern-parity should land in the milestone that introduces the docs; deferral creates immediate drift (the v0.3 transfer table explicitly verifies within-milestone parity).
- **Decision:** D-069
-
-## Decisions Log
-
-| ID | Decision | Confidence |
-|----|----------|------------|
-| D-061 | Edge domain owns the proximity/location angle (C4 Locality, C8 Economy heavy); performance/concurrency/observability own generic primitives; cross-links one-directional; edge is a broad-derivation domain (6–8 C-rules) | 0.88 |
-| D-062 | Messaging owns cross-process/cross-system async (brokers, delivery semantics); concurrency owns in-process primitives; boundary is the failure model (network vs crash); cross-link concurrency ← messaging | 0.86 |
-| D-063 | Language-derived docs introduce NO new P-rules; follow existing section-header-trace pattern (C-rule + Domain P-rule inline); first-principles stubs extended but retain structure, no P1–P10 numbering | 0.92 |
-| D-064 | Confirm ts-/py-/go-/rs- prefix scheme for language-derived doc filenames (ecosystem convention alignment; mirrors domain-derived-doc compactness) | 0.84 |
-| D-065 | Add new top-level `## Languages` section to MANIFEST.md in P4 (between Domains and Examples); lists 4 stubs + 16 derived docs; closes pre-existing languages/ drift parallel to ESC-002 | 0.90 |
-| D-066 | principles-matrix.md gains NO language rows (stays 190/19 domains); domain-coverage.md gains a `## Languages Coverage` sub-table (Language → Derived Doc → Traced Domain P-rules → Traced C-rules); inline section-headers are per-doc detail | 0.87 |
-| D-067 | Two phase-specific personas: edge-engineer (P1) + languages-engineer (P3); messaging (P2) by tech-writer + domain-expert with edge-engineer consultation; constraints baked into P2 task must-have (D-051 pattern) | 0.80 |
-| D-068 | Confirm pre-named examples (good: edge-offline-sync, messaging-idempotent-consumer; bad: edge-sync-loop, messaging-shared-subscription); bad examples cite specific breached P-rule; single-breach (not D-044 two-breach) | 0.85 |
-| D-069 | 4 decision/comparison tables across v0.4 derived docs: cdn (edge-cache vs origin), queues (delivery semantics), sync (CRDT vs LWW), streams (Kafka vs Kinesis vs Pulsar), delivery-semantics (dead-letter strategy comparison) — pattern parity with v0.2/v0.3 | 0.82 |
-
-## Summary
- 9 ambiguities identified and auto-resolved at full autonomy
- Average confidence: 0.86
- All resolutions grounded in existing project conventions (D-001..D-060, prior domain structure, core C-rules, ARCHITECTURE.md hierarchy, RESEARCH.md prior-art pattern, ESC-002/IDEATE-17 manifest-drift precedent, IDEATE-07/D-025 named-bad-example convention, v0.2→v0.3 decision-matrix transfer pattern, D-051 constraints-baked-into-task persona pattern)
- No decision fell below the 0.60 autonomy threshold → no HITL escalation triggered
- Lowest-confidence decision (D-067, 0.80): messaging P2 persona choice — resolved by deferring to the ROADMAP's explicit 2-persona naming and the D-022 within-competence precedent, with edge-engineer consultation to preserve the D-062 boundary
@@ -1,193 +0,0 @@
-# Atelier — Grill (Adversarial Red-Team Review)
-
-> Pre-execution gate for milestone v0.4 (Edge + Messaging + Language-Derived Docs).
-> Default assumption: the project is unfeasible, over-scoped, and too costly. Not convinced until evidence forces it.
-> Mode: full autonomy. Auto-resolve at confidence ≥ 0.60; escalate only < 0.60 that cannot be auto-resolved.
-
---
-
-## v0.4 Grill — 2026-08-05
-
-**Milestone:** v0.4 — Edge + Messaging + Language-Derived Docs
-**Phase:** 0 (Pre-Execution, GRILL stage)
-**Grill scope:** all 9 axes + meta
-**Prior grill runs:** v0.3 (GRILL.md — PROCEED @ 0.80). v0.1/v0.2 P0 stages did not include a GRILL stage.
-**Autonomy:** full (binding verdicts; no HITL questions)
-**Axes:** 9 review axes (Feasibility, Scope, Cost/Risk, Vertical-slice integrity, Traceability, Decision quality, Persona coverage, Test/Verify, Cross-link/matrix integrity)
-
-### Verdict: **CONDITIONAL PROCEED** (overall confidence 0.83)
-
-The plan is the 4th consecutive NFR milestone using the same proven docs-only contract (v0.1 35 reqs → v0.2 24 reqs → v0.3 32 reqs → v0.4 26 reqs). All three prior milestones shipped clean with identical structure. The 26-req scope is *smaller* than v0.3's 32 reqs, and per-phase doc counts (P1:5, P2:5, P3:20, P4:7, P5:5, P6:2) are within demonstrated throughput. The two new domains (edge, messaging) have well-reasoned boundaries against existing domains (D-061 proximity angle; D-062 cross-process failure model) and the 16-doc language extension is the largest single phase (P3) but introduces **zero** matrix rows (D-063/D-066), so it does not stress the traceability invariant.
-
-The verdict is **CONDITIONAL** rather than clean PROCEED because the red-team verification surfaced **one false premise** baked into the plan and the audit: IDEATE-34/ATELIER-106 refinement asserts a "pre-existing matrix discrepancy (171 vs stated 170)" that must be reconciled before appending the 20 v0.4 rows. Direct verification of `matrix/principles-matrix.md` shows the matrix contains **exactly 170 P-rows** (17 domains × 10 rows each), matching the invariant — the discrepancy does not exist. The reconciliation task (04-01-01) and audit test (06-01-02) are built on a wrong premise. This is non-blocking (the verification step is harmless — it will simply confirm 170) but the task wording is misleading and could cause an executor to "fix" a non-existent problem (e.g., deleting a valid row to hit a phantom 171→170). Two binding conditions below fix this before ship.
-
---
-
-### Axis 1 — Feasibility
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 1.1 | Can P1–P6 actually be delivered with the proposed resources/personas? | PLAN-v0.4.md: 46 tasks across 6 phases. PERSONAS.md: 3 permanent + 2 phase-specific personas, peak 5 active (matches v0.3). Per-phase doc counts: P1=5, P2=5, P3=20, P4=7, P5=5, P6=2. v0.1 P3 shipped 27 derived docs in one phase (RESEARCH-v0.4 §Language-Derived). | Feasible. v0.1 P3 demonstrated 27 derived docs in a single phase; v0.4 P3's 20 language files (4 stubs + 16 derived) is below that watermark, and language-derived docs have a *simpler* structure (section-header-trace, no P1–P10 derivation) than domain derived docs. The 5-persona peak matches v0.3 which shipped clean. | 0.85 |
-| 1.2 | Are edge/messaging P-rules novel enough to not duplicate existing domains (per D-061/D-062)? | RESEARCH-v0.4 §Edge boundary table: edge P6 (geographic/partition cache invalidation) vs `performance/P5 Caching with Intent` (generic C3,C6) — distinct angle. §Messaging boundary table: messaging P6 (broker-backed backpressure, network failure) vs `concurrency/P9 Bounded Queues` (in-process, OOM failure) — distinct failure model. `concurrency/patterns.md` Pattern 5 explicitly scopes to "producer is blocked or signaled" (in-process); messaging extends to network-partition regime. | Novel. The discriminator is sound: edge owns *where compute runs* (geographic locality, C4); performance owns *generic measurement*; concurrency owns *in-process primitives*; messaging owns *cross-process/network-failure-model*. No verbatim duplication. Each domain owns a distinct angle on shared C-rules — the same pattern that distinguished k8s P8 from iac P3 in v0.2 (D-021 precedent). | 0.86 |
-| 1.3 | Is the 16-doc language-derived extension (P3) achievable in one phase? | RESEARCH-v0.4 §Language-Derived: 16 derived docs follow the existing stub's section-header-trace pattern (confirmed in `languages/typescript.md`: `## Type System (C1 Correctness, Data P7 Type Fidelity)`). PLAN-v0.4 P3 Wave 2: 16 tasks at ≤5 concurrent (5-then-5-then-5-then-1, A-008 @ 0.90). D-063: no P1–P10 derivation (apply, don't derive) — lower per-doc effort than domain derived docs. | Achievable. Language-derived docs are structurally simpler than domain derived docs (no first-principles derivation, no matrix rows, no decision matrices — they apply existing P-rules). v0.1 P3 produced 27 derived docs with heavier structure. The 16-doc load is within demonstrated throughput and below v0.1's high-water mark. | 0.83 |
-
-**Axis 1 confidence: 0.85.** No challenges.
-
-### Axis 2 — Scope
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 2.1 | Is v0.4 over-scoped (2 new domains + 16 language docs + matrix + review + examples + cross-links)? Should it split into v0.4 + v0.5? What would you cut? | PROJECT.md v0.4 section: 2 domains (10 P-rules each = 20 matrix rows), 16 language-derived docs (0 matrix rows), matrix/review/examples/manifest extensions. REQUIREMENTS ATELIER-92..117 = 26 reqs. v0.3 had 32 reqs (4 domains, 40 matrix rows) and shipped clean. | **Not over-scoped — smaller than v0.3.** 26 reqs vs v0.3's 32. The 16 language-derived docs are the volume driver but carry zero matrix-row cost (D-063/D-066), so the traceability surface grows by only 20 rows (edge + messaging), the smallest matrix extension since v0.2. Cutting to v0.4a (2 domains) + v0.4b (languages) would double release overhead with no load benefit — P3's 16 docs are simpler per-doc than domain docs. The current single-milestone plan is the right call. | 0.85 |
-| 2.2 | What would you cut if forced? | (adversarial) | The simplest 80% version: ship edge + messaging domains + matrix/review (drop the 16 language-derived docs to v0.5). This halves the doc count. **But:** the language-derived extension closes pre-existing MANIFEST drift (languages/ unlisted since v0.1, per D-065/IDEATE-31) and is the v0.3 ROADMAP "Future Milestones" candidate explicitly assigned to v0.4. Deferring it re-opens the 2x-deferral zombie risk flagged in v0.3 G-001. The 16 docs are low-cost (apply, don't derive) — keeping them is correct. | 0.82 |
-| 2.3 | Who owns the requirements, and are they frozen? | REQUIREMENTS.md v0.4 reqs ATELIER-92..117 (all pending). Ideation log IDEATE-31..43: 13 accepted, 0 deferred, 0 rejected. Traceability matrix maps phases→reqs. | Frozen post-ideation. 26 reqs across 6 phases. 13 accepted refinements baked into task must-haves (no moving targets). The ideation stage closed with 0 deferred. | 0.88 |
-| 2.4 | What is explicitly out of scope? | PROJECT.md lines 49–55: tooling/linters, translation, agent adapters, per-domain release artifacts, runtime code. D-020: docs-only. D-063: no new P-rules for languages. | Explicit and enumerated: no runtime code, no tooling, no translation, no new core principles, no new matrix rows for languages, no standalone `.ts`/`.py`/`.go`/`.rs` artifacts (D-020 + ATELIER-110 artifact-types extension). The scope boundary is answerable. | 0.88 |
-| 2.5 | Are there hidden requirements disclosed late? | IDEATE-32 → ATELIER-117 (ARCHITECTURE.md v0.4 update — architecture-tree drift, detected during ideation). Verified: `.ciagent/atelier/ARCHITECTURE.md` component tree stops at v0.3 (lines 14–19 list only through compliance). | ATELIER-117 is a *detected* hidden requirement, surfaced and added during ideation (not late in delivery). The architecture-tree drift is real (ARCHITECTURE.md has no edge/messaging/languages-derived entries). IDEATE-32 caught it before execution — the correct time to surface it. No undisclosed hidden requirements remain. | 0.85 |
-
-**Axis 2 confidence: 0.86.** No challenges.
-
-### Axis 3 — Cost/Risk
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 3.1 | 46 tasks across 6 phases — what's the riskiest task? | PLAN-v0.4 task inventory: P1 01-01-01 (edge first-principles), P4 04-01-01 (matrix extension), P4 04-01-02 (domain-coverage with Languages sub-table), P3 03-02a..d (16 derived docs). | The riskiest task is **04-01-01 (matrix extension + IDEATE-34 reconciliation)** — but the risk is not the work (appending 20 rows is mechanical); the risk is the **false premise** that the matrix has 171 rows vs stated 170. Direct verification shows the matrix has **exactly 170 rows** (17 × 10). The reconciliation step is built on a wrong premise. **Mitigation:** see binding decision G-014 — the task must verify 170 exists and append 20 to reach 190; it must NOT "fix" a phantom 171→170. | 0.80 |
-| 3.2 | What's the cost of a phase failing mid-way? | NFR milestone, docs-only. All phases produce markdown. No runtime, no infra, no migration. | Cost of a phase failing = re-authoring markdown. P3 (largest) failing mid-way wastes the 16 derived-doc tokens but the work is recoverable (edit + re-run). No cascading infrastructure cost, no data loss, no deployment rollback. Rework is bounded and cheap — the same property that made v0.1/v0.2/v0.3 low-risk. | 0.90 |
-| 3.3 | Predictable cost drivers not in the original budget? | PROJECT.md: no runtime code, no infrastructure, no licensing, no external services. RESEARCH-v0.4 §Risks: 10 risks, all content/traceability (no external cost drivers). | None. Docs-only = no licensing, no infra, no security review fees, no support contracts. Token cost is proportional to markdown volume, scoped by REQ count (26). The only cost driver is markdown authoring, which is bounded. | 0.88 |
-| 3.4 | Single project-killing risk? | RESEARCH-v0.4 §Risks: orphaned P-rules, edge/messaging duplication, language-derived new-P-rule violation, MANIFEST drift, runtime artifacts, persona explosion, matrix row-count, decision-matrix omission. | The single risk that would undermine the framework's core value: **language-derived docs introducing new P-rules** (D-063 violation) or **orphaned from domain P-rules** (D-066 violation). Either breaks the traceable hierarchy (the unique value). **Mitigation:** languages-engineer persona constraint "apply, don't derive" + agent-checklist language-derived scope check (ATELIER-108) + P3 Verify (no new P-rules, every section traces ≥1 domain P-rule) + P4 Languages Coverage sub-table (exactly 16 rows, IDEATE-42) + P6 domain-expert verification. Well-mitigated with multiple layers. | 0.84 |
-
-**Axis 3 confidence: 0.86.** Challenge: IDEATE-34 false premise (G-014). Auto-resolved with binding condition.
-
-### Axis 4 — Vertical-slice integrity
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 4.1 | Is each phase independently shippable per D-053? | PLAN-v0.4 invariants: P1 ships edge self-consistent (matrix in P4); P2 ships messaging self-consistent; P3 ships 16 language docs self-consistent; P4 closes traceability + manifest + architecture; P5 closes examples + cross-links; P6 ships release. Tag sequence v0.3.1→v0.3.6. | Each phase is shippable. P1/P2 ship domains whose P-rules trace to core internally (matrix extension is traceability closure, not internal-consistency). P3 ships language docs whose section-headers trace to existing domain P-rules (the Languages Coverage sub-table that aggregates these lands in P4 — but each derived doc is self-consistent because it traces to already-shipped domain P-rules). P4 closes manifest + matrix + architecture. P5 closes examples + cross-links. This mirrors v0.3's D-053 pattern that shipped clean. | 0.84 |
-| 4.2 | P1 ships edge domain before matrix lands in P4 — acceptable? | D-053 (v0.3): "matrix rows land in P4 — acceptable because the domain is self-consistent; matrix extension is the traceability closure, not a blocker." v0.2/v0.3 both shipped domain phases before P4 matrix extension. | Acceptable. The edge domain's 10 P-rules each name their C-rule derivation *inline* in `first-principles.md` (per PLAN 01-01-01 must-have). The matrix row is the *aggregate* trace; the inline trace is the *per-rule* detail. A domain with correct inline traces is self-consistent even before the matrix row exists. The matrix in P4 is the verifiable closure, not the source of truth. Precedent: v0.2/v0.3 both did this. | 0.86 |
-| 4.3 | P3 ships language docs that trace to domain P-rules — traceable without the matrix update? | D-063/D-066: language-derived docs use section-header-trace pattern (C-rule + Domain P-rule inline). Languages Coverage sub-table lands in P4. `languages/typescript.md` confirms pattern: `## Type System (C1 Correctness, Data P7 Type Fidelity)`. | Traceable without the matrix update. Each language-derived doc's section headers name the traced domain P-rules inline — the traceability is in the doc itself, not the matrix. The Languages Coverage sub-table (P4) is the *aggregate verifiable view*, parallel to how the domain→core matrix is the aggregate view of inline domain traces. A language-derived doc with correct inline section-header traces is self-consistent even before the sub-table exists. | 0.85 |
-| 4.4 | Edge↔messaging cross-links dangle at P1 tag — acceptable? | PLAN 01-02-03 (edge/iot.md): "cross-link `messaging/queues` ... this link dangles until P2, acceptable per D-053, verified bidirectional in P5 ATELIER-114 per IDEATE-40". A-010 @ 0.86. | Acceptable but a genuine temporary broken-link state. edge/iot.md (P1) cross-links messaging/queues.md (P2) — at the v0.3.1 tag, that link 404s. This is acceptable per D-053 (cross-links close in P5) and is the same pattern as v0.3 intra-milestone links. **Mitigation:** P5 cross-link audit (05-02-01) explicitly verifies edge↔messaging links resolve in BOTH directions before P6 ship (IDEATE-40). The temporary dangle is a documented, time-bounded state, not a silent defect. | 0.82 |
-
-**Axis 4 confidence: 0.84.** No blocking challenges.
-
-### Axis 5 — Traceability
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 5.1 | Do all 20 proposed new P-rules trace to ≥1 core C-rule without duplicating existing domain P-rules? | RESEARCH-v0.4 §Edge: P1→C4,C1; P2→C1,C5; P3→C8,C1; P4→C1,C5; P5→C1; P6→C1,C3; P7→C1,C5; P8→C4,C6; P9→C1,C8; P10→C7,C5. §Messaging: P1→C1,C2; P2→C1,C2; P3→C1; P4→C1,C2; P5→C1,C5; P6→C1,C8; P7→C4,C6; P8→C5,C7; P9→C5,C6; P10→C7,C1. All 20 map to ≥1 C-rule. Edge derives 7 C-rules; messaging derives 7 C-rules. `core/first-principles.md` confirms C1–C8 definitions. | All 20 trace to ≥1 C-rule. None duplicates an existing domain P-rule verbatim: edge P6 (geographic cache invalidation, C1/C3) ≠ performance P5 (generic caching, C3/C6) — different angle + different C-rule mix. messaging P6 (broker backpressure, C1/C8) ≠ concurrency P9 (in-process bounded queue, C1/C8) — same C-rules but different failure model (network vs OOM), per D-062. The matrix invariant (every P-rule → ≥1 C-rule, no orphans) holds. | 0.87 |
-| 5.2 | RESEARCH-v0.4 against `core/first-principles.md` — derivations valid? | C1 Correctness (non-negotiable), C4 Locality (decisions near consequences), C5 Reversibility, C8 Economy (constrained resources). Edge P1 "Proximity is the Design Driver" → C4 Locality (compute near user/data) — valid geographic-locality derivation. Edge P3 "Resources are Constrained" → C8 Economy — valid. Messaging P7 "Partitioning is Intentional" → C4 Locality (ordering locality) — valid. | Derivations are valid. Edge's C4 emphasis (geographic locality) is a sound reading of "decisions and consequences live near each other" — geographic proximity is a locality concern. Messaging's C4 (partition-key = ordering locality) is sound. No forced/contrived derivations detected. The C1 emphasis (correctness under partition/network-failure) is correct — partition tolerance is a correctness property, not a performance preference (edge P1 explicitly states this). | 0.85 |
-| 5.3 | RESEARCH-v0.4 against existing domains (concurrency/patterns.md for messaging; performance/observability for edge) — no duplication? | `concurrency/patterns.md` Pattern 1 (Message Passing, in-process channels), Pattern 5 (Bounded Queue, in-process "producer is blocked or signaled"). `performance` P5 Caching (generic C3,C6). RESEARCH-v0.4 §Messaging boundary: messaging owns cross-process broker-backed analog with network-failure semantics. §Edge boundary: edge owns geographic/partition-aware cache invalidation. | No duplication. The failure-model discriminator (D-062) is the cleanest boundary: concurrency fails by OOM/crash (in-process); messaging fails by network partition/broker-restart (cross-system). Edge's cache angle (P6, partition-aware invalidation, C1/C3) is distinct from performance's generic cache (P5, C3/C6). Cross-links are one-directional outward (D-026 extended) — no back-link edits to v0.1/v0.2/v0.3 content. | 0.86 |
-| 5.4 | Will the matrix stay at exactly 190 P-rules post-v0.4 (D-059)? | Direct verification: `matrix/principles-matrix.md` currently has exactly **170 P-rows** (17 domains × 10, per awk count). RESEARCH-v0.4 §Matrix: +20 rows (10 edge + 10 messaging). | **CRITICAL FINDING:** The matrix currently has exactly 170 rows, matching the invariant. IDEATE-34/ATELIER-106 refinement claims a "171 vs stated 170 discrepancy" that must be reconciled — **this discrepancy does not exist**. Post-v0.4 will be 170 + 20 = 190, exactly as planned. The reconciliation step (PLAN 04-01-01, 06-01-02) is built on a false premise. See binding decision G-014. | 0.88 |
-
-**Axis 5 confidence: 0.86.** Challenge: IDEATE-34 false premise (G-014) — auto-resolved with binding condition; does not block but must be corrected in task wording.
-
-### Axis 6 — Decision quality
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 6.1 | Are D-054..D-075 well-grounded? | CLARIFY-v0.4.md D-061..D-069 (avg confidence 0.86, range 0.80–0.92). PLAN-v0.4.md D-070..D-073 (range 0.83–0.88). All above 0.80 except D-067 (0.80, messaging persona). PROJECT.md v0.4 section encodes D-054..D-060 (SPECIFY). | Well-grounded. 15 decisions, average 0.85. All ≥0.80. The lowest is D-067 (0.80 — messaging P2 persona choice) which is explicitly justified by deferring to ROADMAP's 2-persona naming + D-022 within-competence precedent + edge-engineer consultation baked into P2 task must-have (D-051 pattern). No decision is below the 0.80 "well-grounded" bar. | 0.85 |
-| 6.2 | Any low-confidence (<0.80) decisions that should be revisited? | CLARIFY-v0.4.md: D-067 @ 0.80 is the floor. PLAN-v0.4 assumptions A-006..A-010 (0.82–0.95). | None below 0.80. D-067 @ 0.80 is the lowest decision; it is justified by the ROADMAP's explicit 2-persona naming (the authoritative signal) and the D-022 precedent. Revisiting it would require a 3rd phase-specific persona (messaging-engineer), which the RESEARCH explicitly rejected to avoid persona-explosion (roster would hit 6, exceeding v0.3's 5 peak). The constraint-baked-into-task mitigation (PLAN 02-01-01 must-have: "P1/P2 demonstrated edge + messaging boundary (D-062)") preserves the distributed-systems lens without the persona. No revisit needed. | 0.83 |
-| 6.3 | Any decisions contradict prior decisions (D-001..D-053)? | D-053 (vertical-slice integrity) — honored (PLAN invariants line 7). D-020 (docs-only) — honored (PLAN invariants line 13, no `.ts`/`.py`/`.go`/`.rs` artifacts). D-026 (one-directional cross-links) — honored (PLAN 05-02-01 "no back-link edits to v0.1/v0.2/v0.3 content"). D-025 (2+2 examples) — honored (D-068 confirms). | No contradictions. D-053/D-020/D-026/D-025 are all explicitly carried forward. D-063 (no new P-rules for languages) is consistent with ARCHITECTURE.md hierarchy (`languages/` depend on `domains/`). D-066 (no language matrix rows) preserves D-059's 190 total. The v0.4 decisions extend the v0.1→v0.2→v0.3 convention chain without breaking any prior commitment. | 0.88 |
-| 6.4 | Does IDEATE-34 (matrix discrepancy) contradict the actual matrix state? | IDEATE-34 refinement (REQUIREMENTS ATELIER-106 note): "The current matrix has 171 P-rows vs the stated 170 invariant — P4 must reconcile this pre-existing discrepancy." Direct verification: matrix has exactly 170 rows. | **Yes — IDEATE-34 is based on a false premise.** The matrix has 170 rows, not 171. The "reconcile 171→170" instruction in PLAN 04-01-01 and audit 06-01-02 is unfounded. This is a decision-quality defect in the ideation stage: IDEATE-34 (confidence 0.82) asserted a discrepancy without verifying the actual count. **Not a contradiction of a prior decision, but a false factual claim.** See binding decision G-014 — the reconciliation step must be reframed as "verify 170 exists, append 20, confirm 190" — NOT "find and fix a phantom 171st row." | 0.80 |
-
-**Axis 6 confidence: 0.84.** Challenge: IDEATE-34 false premise (G-014).
-
-### Axis 7 — Persona coverage
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 7.1 | Do edge-engineer + languages-engineer + tech-writer + domain-expert + lead-developer cover all P1–P6 authoring needs? | PERSONAS.md: 3 permanent (lead-developer, tech-writer, domain-expert) + 2 phase-specific (edge-engineer P1, languages-engineer P3). PLAN persona assignments: P1 edge-engineer; P2 tech-writer + domain-expert (edge-engineer consult); P3 languages-engineer; P4 domain-expert/tech-writer/lead-developer; P5 edge-engineer + tech-writer + domain-expert; P6 all 5 review. | Coverage is complete. P1 edge (edge-engineer specialist). P2 messaging (tech-writer + domain-expert generalists with edge-engineer consultation for D-062 boundary — baked into task 02-01-01 must-have per D-051 pattern). P3 languages (languages-engineer specialist). P4 matrix/review/manifest/architecture (domain-expert/tech-writer/lead-developer split by artifact type). P5 examples (edge-engineer for edge examples, tech-writer for messaging). P6 all 5 review then remove 2. No phase lacks an assigned author. | 0.84 |
-| 7.2 | Is messaging P2 under-resourced (no phase-specific persona per D-067)? | D-067 @ 0.80: messaging P2 authored by tech-writer + domain-expert with edge-engineer consultation. CLARIFY-v0.4 §7: rejected messaging-engineer persona (roster would hit 6, exceeding v0.3's 5 peak). PLAN 02-01-01 must-have: "edge-engineer consultation baked in (D-067, D-051 pattern): P1/P2 demonstrated edge + messaging boundary (D-062)." | Under-resourced *relative to P1/P3* (which have specialists) but **adequately resourced** for the work. Messaging's specialty (delivery semantics, idempotency, ordering) is within domain-expert's cross-cutting competence (correctness/observability derivations the domain-expert already validates). The edge-engineer consultation + task must-have preserves the D-062 boundary. RESEARCH-v0.4 §Messaging provides thorough prior-art (Kafka, RabbitMQ, NATS, Jepsen, Reactive Streams, CloudEvents). The risk is content-quality (specialist depth) not traceability (domain-expert validates that). Mitigation is adequate per the v0.3 G-009 precedent (i18n/compliance shipped without specialists). | 0.78 |
-| 7.3 | Is there a key-person dependency? | PERSONAS.md: edge-engineer + languages-engineer are phase-specific, removed post-v0.4. D-051 pattern (constraints baked into task must-haves) survives persona removal. | No key-person risk beyond the v0.3-bounded pattern. Personas are constraint sets, not humans. The languages-engineer's "apply, don't derive" constraint (D-063) is baked into P3 task must-haves AND the agent-checklist (ATELIER-108) AND the P3 Verify block. The edge-engineer's "proximity is correctness" constraint (D-061) is baked into P1 task 01-01-01 must-have. If either persona "fails," the constraints survive in the task specs and review checks. | 0.82 |
-
-**Axis 7 confidence: 0.81.** Challenge: messaging P2 under-resourcing (G-015) — auto-resolved; bounded by RESEARCH prior-art + domain-expert validation, parallel to v0.3 G-009.
-
-### Axis 8 — Test/Verify
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 8.1 | Are the per-phase Verify blocks in PLAN-v0.4.md sufficient to catch a broken phase before ship? | PLAN-v0.4 each phase has a Verify block: P1 (structural 5 files, behavioral P1–P10 trace, security P9/P6, quality cross-links + decision matrices + D-061 boundary). P2 (similar + edge↔messaging link resolution post-P2). P3 (20 files, no new P-rules, no P1–P10 on stubs, no runtime artifacts, IDEATE-40 cross-links). P4 (matrix 190, coverage sub-table 16 rows, ARCHITECTURE.md component tree, review parity, MANIFEST authoritative). P5 (4 examples, single-breach citation, bidirectional cross-links). P6 (26 reqs covered, reconstruction, matrix 190, MANIFEST, ARCHITECTURE, audit clean). | Sufficient. Each Verify block has structural + behavioral + security + quality checks tied to specific decisions (D-061/D-062/D-063/D-066/D-068/D-069/IDEATE-40/IDEATE-42). The P4 Verify is the strongest: matrix row-count (190), Languages Coverage sub-table (exactly 16 rows — catches orphan language docs), MANIFEST reconstruction (catches unlisted docs), ARCHITECTURE.md component-tree test (catches architecture-tree drift). P6 audit adds the reconstruction + matrix-count + MANIFEST reconstruction triple-test. | 0.86 |
-| 8.2 | What would slip through? | (adversarial) | (a) **Content correctness** — Verify blocks check structure + traceability + cross-links, not technical accuracy of, e.g., the CRDT-vs-LWW decision matrix in sync.md or the Kafka rebalance-strategy enumeration in streams.md. A technically wrong but well-structured doc passes Verify. Mitigation: P6 domain-expert + edge-engineer/languages-engineer review (D-052), but this is one layer, not redundant. (b) **The IDEATE-34 false premise** — the P4/P6 "reconcile 171→170" check is unverifiable against a non-existent discrepancy; an executor could misinterpret it as "delete a row" (harmful) or "confirm 170" (correct). G-014 fixes the wording. (c) **Edge↔messaging dangling links at P1 tag** — structurally acceptable (D-053) but a real broken-link state until P2; only caught bidirectionally in P5, not at the P1/P2 tags. | 0.78 |
-| 8.3 | Is there a working definition of done? | PLAN-v0.4 P6 Verify: 26 reqs covered, reconstruction test passes, matrix exactly 190 (reconciled), MANIFEST reconstruction (incl. Languages section), ARCHITECTURE.md component-tree test, audit clean, tag v0.3.6, branches deleted, personas removed (roster=3). | DoD is concrete and testable: 26 reqs covered, matrix = 190 rows (10 × 19), MANIFEST reconstruction passes (incl. Languages), tag v0.3.6 on main. Not "whatever the demo shows." The matrix-count test (190) and MANIFEST reconstruction are mechanical, automatable checks. | 0.88 |
-
-**Axis 8 confidence: 0.84.** Challenges: content-correctness gap (inherent to docs projects, bounded by P6 review), IDEATE-34 wording (G-014), dangling links (G-016). All auto-resolved.
-
-### Axis 9 — Cross-link / matrix integrity
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 9.1 | Will the matrix stay at exactly 190 P-rules post-v0.4 (D-059)? | Direct verification: matrix currently has exactly 170 rows. RESEARCH-v0.4 §Matrix: +20 (10 edge + 10 messaging). Languages add 0 (D-063/D-066). | Yes — 170 + 20 = 190. The invariant holds. The IDEATE-34 "171 vs 170" claim is false; see G-014. Post-v0.4 the matrix will have exactly 190 rows (10 per domain × 19), the smallest extension since v0.2. | 0.88 |
-| 9.2 | Will the languages/ sub-table in domain-coverage.md capture all 16 language-derived docs? | ATELIER-107 (IDEATE-42): Languages Coverage sub-table with exactly 16 rows. RESEARCH-v0.4 §Language-Derived sketches the 16-row sub-table (TS quartet + PY quartet + GO quartet + RS quartet). PLAN 04-01-02 must-have: "EXACTLY 16 rows (one per language-derived doc)". P4 Verify: "Languages Coverage sub-table has exactly 16 rows". P6 06-01-01: "domain-expert verifies ... 16 Languages Coverage sub-table rows match the derived docs' actual section-header traces (IDEATE-42)". | Yes — the sub-table is specified at exactly 16 rows, verifiable as a P4 review check, and cross-checked in P6 against the actual section-header traces. The 16 = 4 languages × 4 derived docs. No orphans (every row traced to ≥1 domain P-rule per D-066). The sub-table is the verifiable aggregate; inline section-headers are per-doc detail. | 0.86 |
-| 9.3 | Will the bidirectional edge↔messaging cross-links actually be verified (IDEATE-43/IDEATE-40)? | PLAN 05-02-01 (cross-link audit): "(b) edge↔messaging intra-v0.4 links resolve in BOTH directions — every edge→messaging and messaging→edge link resolves by the P6 ship". P5 Verify: "edge↔messaging intra-v0.4 links resolve bidirectionally (IDEATE-40)". RESEARCH-v0.4 §Review: edge/iot.md → messaging/queues.md (MQTT QoS parallels). | Yes — the P5 cross-link audit (05-02-01) explicitly verifies bidirectional edge↔messaging resolution, AND language-derived docs link to both new (edge/messaging) and existing domains where relevant (e.g., ts-async → messaging/delivery-semantics; go-concurrency → concurrency/patterns + messaging/queues). The audit is a dedicated Wave 2 task after all docs exist, so links are resolvable. The one gap: at the P1 tag (v0.3.1), edge→messaging links dangle (messaging authored in P2) — acceptable per D-053, time-bounded, verified in P5. | 0.84 |
-| 9.4 | MANIFEST integrity — will the Languages section close the pre-existing drift? | MANIFEST.md verified: currently has NO `## Languages` section (sections: Reading Order, Core, Domains, Examples, Cross-Cutting). `languages/{typescript,python,go,rust}.md` exist since v0.1 but are unlisted. D-065/IDEATE-31: add `## Languages` between `## Domains` and `## Examples`. PLAN 04-03-01 must-have: lists 4 stubs + 16 derived docs + Cross-Cutting = "19 domains, 190 P-rules post-v0.4". | Yes — the Languages section is specified to list 4 v0.1 stubs (closing pre-existing drift parallel to ESC-002/ATELIER-91) + 16 new derived docs, positioned per reading order (core→domains→languages→examples). P4 Verify: "MANIFEST is authoritative — every v0.4 file listed, languages/ listed closing pre-existing drift". P6 MANIFEST reconstruction test catches any unlisted doc. | 0.87 |
-
-**Axis 9 confidence: 0.86.** Challenge: dangling links at P1 tag (G-016) — auto-resolved; time-bounded + P5-verified.
-
-### Meta — Closing Review
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| M.1 | If you were the auditor, what would you flag? | (adversarial) | **The IDEATE-34 false premise** — the plan and audit instruct executors to "reconcile a pre-existing 171-vs-170 matrix discrepancy" that does not exist (verified: exactly 170 rows). This is the single most material finding: a verification gate built on a wrong fact. An executor could (a) waste effort hunting a phantom row, or (b) worse, delete a valid row to "fix" 171→170, breaking the invariant. G-014 fixes the wording to "verify 170, append 20, confirm 190." Secondary: content-correctness is one-layer-validated (P6 review only) — inherent to docs projects, bounded. | 0.82 |
-| M.2 | What is the project NOT doing that it should? | PROJECT.md out-of-scope: tooling/linters. | Not doing: automated P-rule→C-rule trace validation (manual domain-expert verification only). At 190 P-rules + 16 language-derived traces, manual verification is approaching the limit where tooling would be warranted — but remains feasible for this milestone. Explicitly out of scope; not a v0.4 blocker. The Languages Coverage sub-table (16 rows) actually *enables* future tooling by making language traces machine-readable. | 0.82 |
-| M.3 | Simplest 80% version? | (adversarial) | Ship edge + messaging domains + matrix/review/manifest/architecture (drop the 16 language-derived docs to v0.5). This cuts P3 entirely (20 files → 0) and reduces the milestone to ~10 reqs. **But:** the language-derived extension closes pre-existing MANIFEST drift (D-065) and is the v0.3 ROADMAP "Future Milestones" candidate explicitly assigned to v0.4. Deferring re-opens the 2x-deferral zombie risk (v0.3 G-001). The 16 docs are low-cost (apply-don't-derive, no matrix rows). Keeping them is the right scope call. | 0.83 |
-| M.4 | What must be true in 90 days for success, and is it true today? | (adversarial) | Must be true: (a) 20 new P-rules trace cleanly to C-rules — RESEARCH-v0.4 pre-maps them, P4 verifies. (b) 16 language-derived docs each trace to ≥1 domain P-rule (no orphans) — P3 Verify + P4 sub-table (16 rows) + P6 cross-check. (c) Content is technically correct (CRDT/LWW, Kafka rebalance, MQTT QoS, delivery semantics) — RESEARCH grounds it, P6 validates. (d) Matrix = exactly 190 — verified today at 170, +20 planned. (a)(b)(d) have explicit verification gates with correct premises (post-G-014). (c) depends on execution quality. All achievable. | 0.83 |
-
-**Meta confidence: 0.83.**
-
---
-
-## Summary Table
-
-| # | Axis | Verdict | Confidence |
-|---|------|---------|------------|
-| 1 | Feasibility | PASS | 0.85 |
-| 2 | Scope | PASS | 0.86 |
-| 3 | Cost/Risk | CONDITIONAL (G-014: fix IDEATE-34 wording) | 0.86 |
-| 4 | Vertical-slice integrity | PASS | 0.84 |
-| 5 | Traceability | CONDITIONAL (G-014: false premise in reconciliation step) | 0.86 |
-| 6 | Decision quality | CONDITIONAL (G-014: IDEATE-34 factual defect) | 0.84 |
-| 7 | Persona coverage | PASS (G-015 noted, bounded) | 0.81 |
-| 8 | Test/Verify | CONDITIONAL (G-014: audit test premise; G-016: dangling links acknowledged) | 0.84 |
-| 9 | Cross-link / matrix integrity | PASS | 0.86 |
-| — | Meta | PASS | 0.83 |
-| **—** | **Overall** | **CONDITIONAL PROCEED** | **0.83** |
-
---
-
-## Binding Decisions
-
-| ID | Decision | Rationale | Confidence | Alternatives |
-|----|----------|-----------|------------|--------------|
-| G-013 | Proceed with v0.4 scope as planned (2 domains + 16 language-derived docs); do NOT split into v0.4/v0.5 | 26 reqs < v0.3's 32 reqs; language-derived docs carry 0 matrix-row cost (D-063/D-066); v0.1 P3 demonstrated 27 derived docs in one phase; deferral re-opens 2x-zombie risk (v0.3 G-001); the 16 docs are the v0.3 ROADMAP "Future Milestones" candidate explicitly assigned to v0.4 | 0.85 | Split into v0.4a (domains) + v0.4b (languages) — rejected: double release overhead, no load benefit; Drop languages to v0.5 — rejected: 2x deferral zombie risk |
-| G-014 | **CONDITION — fix IDEATE-34 false premise before P4 executes.** The matrix currently has exactly 170 P-rows (verified: 17 domains × 10). There is NO "171 vs 170 discrepancy." PLAN task 04-01-01 and audit 06-01-02 must be reworded from "reconcile pre-existing 171→170 discrepancy" to "verify matrix has exactly 170 rows before appending 20; confirm post-append count = 190." The executor must NOT hunt for or delete a phantom 171st row. | Direct verification of `matrix/principles-matrix.md`: `awk '/^## /{...} /^\| P[0-9]/{count++}'` returns 170 total, 15 lines per section header (10 P-rows + header rows), 17 domain sections. IDEATE-34 (confidence 0.82) asserted the discrepancy without verifying the actual count — a factual defect in the ideation stage. The reconciliation instruction is unfounded and risks an executor breaking the invariant by deleting a valid row. | 0.88 | Leave the wording as-is — rejected: an executor could delete a valid row to "fix" a non-existent discrepancy; Remove the reconciliation step entirely — rejected: keeping a verify-170 step is harmless and good practice, just reworded |
-| G-015 | Proceed with tech-writer + domain-expert for messaging P2 without a messaging-engineer persona (confirms D-067) | Messaging's specialty (delivery semantics, idempotency, ordering) is within domain-expert's cross-cutting competence; edge-engineer consultation + task must-have (02-01-01) preserves D-062 boundary; RESEARCH-v0.4 §Messaging provides thorough prior-art (Kafka/RabbitMQ/NATS/Jepsen/Reactive Streams/CloudEvents); v0.3 G-009 precedent (i18n/compliance shipped without specialists); adding a 3rd phase-specific persona would push roster to 6, exceeding v0.3's 5 peak (persona-explosion risk). Assumption A-011 logged: messaging content correctness depends on RESEARCH prior-art + P6 review. | 0.78 | Add messaging-engineer persona — rejected: persona explosion (roster 6 > v0.3 peak 5); Defer messaging to v0.5 — rejected: scope-creep deferral |
-| G-016 | The edge↔messaging dangling cross-link at P1 tag (edge/iot.md → messaging/queues.md) is acceptable per D-053; the P5 audit (05-02-01) MUST verify bidirectional resolution before P6 ship (confirms IDEATE-40) | D-053 established that cross-links close in P5, not at the domain-phase tag; v0.3 had the same intra-milestone dangling-link pattern; the dangle is time-bounded (resolves at P2 tag v0.3.2); P5 audit explicitly checks both directions (IDEATE-40). Not a silent defect — a documented, verified state. | 0.82 | Block P1 ship until messaging exists — rejected: breaks vertical-slice integrity (D-053), serializes independent work; Remove the edge→messaging link from P1 — rejected: loses the MQTT QoS / delivery-semantics parallel, a high-value cross-link |
-| G-017 | CONFIRM D-063/D-066: language-derived docs introduce NO new P-rules and NO new matrix rows; the Languages Coverage sub-table (exactly 16 rows) is the verifiable aggregate | Direct verification of `languages/typescript.md` confirms the section-header-trace pattern (`## Type System (C1 Correctness, Data P7 Type Fidelity)` — no P1–P10 numbering). ARCHITECTURE.md confirms hierarchy (`languages/` depend on `domains/`). Adding P-rules to languages would break the hierarchy and the 190-row invariant. The 16-row sub-table is the right traceability home (parallel to the per-domain row schema). | 0.87 | Add P1–P10 to languages — rejected: breaks hierarchy + matrix invariant; Add language rows to principles-matrix.md — rejected: languages have no P-rules to map (D-063) |
-| G-018 | CONFIRM D-065/IDEATE-31: MANIFEST gains a `## Languages` section closing pre-existing drift since v0.1 (parallel to ESC-002/ATELIER-91) | MANIFEST.md verified: NO `## Languages` section exists despite `languages/{typescript,python,go,rust}.md` existing since v0.1. This is pre-existing drift on the exact ESC-002 precedent (examples/ was unlisted, closed in v0.3). v0.4 touches `languages/` for the first time since v0.1, so it closes the drift. | 0.87 | Defer stubs to a future milestone, list only 16 new docs — rejected: half-closes the drift, inconsistent with ESC-002 precedent; List languages under `## Domains` — rejected: languages are not domains (ARCHITECTURE.md hierarchy) |
-
-### Escalations
-
-**None.** All challenges auto-resolved at confidence ≥ 0.78 (range: 0.78–0.88). At full autonomy, the IDEATE-34 false premise (G-014) is the lowest-confidence finding but is auto-resolvable by rewording the task (not an escalation — it does not require a human decision, just a factual correction). No axis scored below 0.60 on any forcing question.
-
-### Assumptions Logged (this grill)
-
-| # | Assumption | Confidence |
-|---|-----------|------------|
-| A-011 | Messaging P2 content correctness (delivery-semantics, Kafka rebalance, MQTT QoS) depends on RESEARCH-v0.4 prior-art quality + P6 domain-expert/edge-engineer review, not on a specialist messaging-engineer persona. If P6 surfaces fundamental content errors, the remedy is P2 rework (bounded — markdown edits). Parallel to v0.3 A-006 (i18n/compliance without specialists). | 0.78 |
-
-### Conditions for SHIP (CONDITIONAL verdict)
-
-The phase-0 plan is sound and P1 may proceed immediately. The following condition MUST be addressed before P4 executes (it does not block P1/P2/P3):
-
-1. **G-014 (mandatory):** Reword the IDEATE-34/ATELIER-106 reconciliation instructions in PLAN-v0.4 task 04-01-01 and audit task 06-01-02. The matrix currently has exactly 170 rows — there is no 171-vs-170 discrepancy. The task must say "verify matrix has exactly 170 rows; append 20 (10 edge + 10 messaging); confirm post-v0.4 count = 190" — NOT "reconcile a pre-existing 171→170 discrepancy." This is a factual correction to prevent an executor from hunting for or deleting a phantom row. The orchestrator should apply this rewording before P4 (or the P4 executor should interpret "reconcile" as "verify 170 exists" rather than "find a missing row").
-
-No other conditions block ship. The plan is the 4th consecutive NFR milestone using the same proven structure; all prior milestones shipped clean.
-
---
-
-## Overall Verdict
-
-**CONDITIONAL PROCEED** at overall confidence **0.83**.
-
-The v0.4 phase-0 plan (spec → clarify → research → ideate → plan → grill) is sound: the 26-req scope is smaller than v0.3's 32, the two new domains have well-reasoned boundaries (D-061 proximity angle; D-062 cross-process failure model), the 16-doc language extension carries zero matrix-row cost, all 20 new P-rules trace to ≥1 C-rule, and the verification gates (matrix=190, Languages sub-table=16 rows, MANIFEST reconstruction, ARCHITECTURE.md component-tree test, bidirectional edge↔messaging cross-link audit) are concrete and testable.
-
-The single CONDITIONAL is the **IDEATE-34 false premise** (G-014): the plan instructs executors to "reconcile a pre-existing 171-vs-170 matrix discrepancy" that direct verification shows does not exist (the matrix has exactly 170 rows). This is a factual defect in the ideation stage, not a structural flaw. It is non-blocking for P1/P2/P3 (which don't touch the matrix count) and is fixed by rewording the P4/P6 task instructions to "verify 170, append 20, confirm 190" — preventing an executor from breaking the invariant by deleting a valid row to fix a phantom discrepancy.
-
-**P1 may proceed immediately.** The G-014 rewording must land before P4 executes. No escalation to human required (confidence 0.83 ≥ 0.60).
@@ -1,154 +0,0 @@
-# Atelier v0.4 — Ideate Stage
-
-> Generated during v0.4 P0 IDEATE stage. Autonomy level: `full`
-> (decision_confidence_threshold = 0.60 → auto-accept ≥ 0.6, auto-reject
-> below). Interactive mode used internally but auto-decided; no HITL.
-> Ideas continue from IDEATE-30 (last v0.3 idea). Tier 3 (cross-project)
-> skipped silently — only one project in registry (per workflow error
-> recovery). All ideas are within v0.4 scope (ATELIER-92..116 + one new
-> req ATELIER-117).
-
-## Scope
-
-Refine the v0.4 requirements (ATELIER-92..116) and the RESEARCH-v0.4.md
-proposed content, parallel to the v0.2 (IDEATE-01..16) and v0.3
-(IDEATE-17..30) ideation logs. Sources: git-native pattern mining
-(lessons, decisions D-001..D-072, ESC-001/002, compound solutions),
-coverage-gap analysis (pending v0.4 reqs), verification-layer inversion,
-architectural-drift detection (MANIFEST vs actual files, ARCHITECTURE.md
-vs directory tree, matrix row-count invariant), spec-driven improvement,
-backend-enriched best-practice/chaos ideation for edge/messaging/
-languages.
-
-## Counts
-
- **Generated:** 13 ideas (mechanical: 8, backend-enriched: 5)
- **Accepted:** 13 (all v0.4-scope, confidence ≥ 0.79, above 0.6 autonomy threshold → auto-accepted)
- **Skipped:** 0
- **New requirements added:** 1 (ATELIER-117 — ARCHITECTURE.md v0.4 update, from IDEATE-32)
- **Refinements to existing reqs:** 12 (IDEATE-31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43)
- **By tier:** mechanical 8, backend-enriched 5, cross-project 0 (skipped silently — single-project registry)
- **By category:** drift 3, coverage 3, spec 2, quality 2, chaos 1, improvement 2
-
-## Ideas Table
-
-| IDEATE-ID | Source | Category | Confidence | Decision | Mapped REQ |
-|-----------|--------|----------|------------|----------|------------|
-| IDEATE-31 | mechanical (MANIFEST drift, parallel to ESC-002) | drift | 0.86 | accepted → refines | ATELIER-111 (languages/ section must list 4 v0.1 stubs + 16 derived docs) |
-| IDEATE-32 | mechanical (ARCHITECTURE.md vs directory tree) | drift | 0.88 | accepted → new req | ATELIER-117 (update ARCHITECTURE.md for v0.4: component tree + v0.4 section) |
-| IDEATE-33 | mechanical (IDEATE-19 pattern transfer) | coverage | 0.90 | accepted → refines | ATELIER-107 (Core Principle Coverage C1–C8 → domains table update for edge + messaging) |
-| IDEATE-34 | mechanical (matrix row-count invariant) | drift | 0.82 | accepted → refines | ATELIER-106 (verify post-v0.4 = exactly 190; verify current = exactly 170 per grill G-014 — the "171 vs 170" claim was a false premise, corrected) |
-| IDEATE-35 | mechanical (D-069 vs req-row text) | spec | 0.89 | accepted → refines | ATELIER-100, ATELIER-101 (req text must reference streams + dead-letter comparison tables) |
-| IDEATE-36 | mechanical (RESEARCH anti-patterns vs ATELIER-110 text) | quality | 0.85 | accepted → refines | ATELIER-110 (language-derived-doc anti-patterns + .ts/.py/.go/.rs artifact-type extension) |
-| IDEATE-37 | backend-enriched (chaos anti-pattern enumeration) | chaos | 0.86 | accepted → refines | ATELIER-110 (include all 6 RESEARCH chaos anti-patterns: edge sync-loop/TTL-less/blocking-call; messaging shared-sub/blocking-consumer/unbounded-retry) |
-| IDEATE-38 | backend-enriched (IDEATE-28 pattern transfer) | improvement | 0.80 | accepted → refines | ATELIER-94 (offline-first.md maps offline write-queue patterns to testing pyramid tiers) |
-| IDEATE-39 | backend-enriched (IDEATE-29 pattern transfer) | improvement | 0.79 | accepted → refines | ATELIER-101 (delivery-semantics.md fenced idempotency-key dedup-store example, not prose-only) |
-| IDEATE-40 | backend-enriched (intra-milestone cross-link dependency) | chaos | 0.84 | accepted → refines | ATELIER-114 (P5 cross-link audit must verify edge↔messaging intra-v0.4 links resolve in both directions) |
-| IDEATE-41 | backend-enriched (IDEATE-30 pattern transfer) | improvement | 0.81 | accepted → refines | ATELIER-100 (streams.md enumerates consumer-group rebalance strategies: sticky/cooperative/eager) |
-| IDEATE-42 | mechanical (D-066 sub-table verifiability) | coverage | 0.87 | accepted → refines | ATELIER-107 (Languages Coverage sub-table = exactly 16 rows; P4 review check) |
-| IDEATE-43 | mechanical (IDEATE-18 pattern transfer) | coverage | 0.83 | accepted → refines | ATELIER-111 (MANIFEST Cross-Cutting summary = "19 domains, 190 P-rules post-v0.4") |
-
-## Refinements Notes (applied to existing reqs at execute time, not changing req rows)
-
- **ATELIER-106** (IDEATE-34, corrected by grill G-014): matrix coverage summary must read
-  "post-v0.4: 19 domains, 190 P-rules" in BOTH the summary block and
-  the per-domain section count (IDEATE-18 carried forward). P4 must
-  verify the matrix contains exactly 190 P-rows (10 per domain × 19).
-  The current matrix has **exactly 170 P-rows** (17 domains × 10,
-  verified by grill G-014 direct count) — the IDEATE-34 "171 vs 170"
-  claim was a FALSE PREMISE. P4 must verify 170 exists, append 20 rows,
-  and confirm post-v0.4 count = 190. Do NOT hunt for or delete a phantom
-  171st row.
- **ATELIER-107** (IDEATE-33, IDEATE-42): the domain-coverage.md
-  extension must update THREE artifacts: (a) the per-domain row-schema
-  table with edge + messaging rows; (b) the "Core Principle Coverage"
-  table (C1–C8 → domains) for the 2 new domains (C4 Locality grows by
-  edge P1/P8 + messaging P7; C5 Reversibility grows by edge P2/P4/P7/P10
-  + messaging P5/P8/P9; C7 Observability grows by edge P10 + messaging
-  P8/P10; C8 Economy grows by edge P3/P9 + messaging P6; C2 grows by
-  messaging P1/P2/P4) — parallel to v0.3 IDEATE-19; (c) the new
-  `## Languages Coverage` sub-table with EXACTLY 16 rows (one per
-  language-derived doc), verifiable as a P4 review check (no orphans,
-  every derived doc traced to ≥1 domain P-rule).
- **ATELIER-110** (IDEATE-36, IDEATE-37): the anti-patterns extension
-  must include (a) the v0.4 deployable-artifact-types table extended to
-  `.ts`/`.py`/`.go`/`.rs` standalone files (language-derived docs risk,
-  per D-020 docs-only contract); (b) language-derived-doc anti-
-  patterns: introducing a new P-rule (e.g., "TS P1"), orphan section
-  with no domain P-rule trace, runtime standalone artifact, and
-  first-principles stub gaining P1–P10 numbering; (c) all 6 RESEARCH-
-  specified chaos anti-patterns, not just the 4 named in the req-row
-  text — edge: sync conflict loop (P4), TTL-less cache (P6), blocking
-  call on constrained device (P3/P5); messaging: shared subscription
-  (P2/P3), blocking consumer (P6), unbounded retry / no DLQ (P5).
- **ATELIER-100** (IDEATE-35, IDEATE-41): streams.md must include (a)
-  the stream-platform comparison table (Kafka vs Kinesis vs
-  Pulsar/NATS JetStream — ordering, partitioning, replay/retention,
-  use-case fit) per D-069, AND (b) an enumeration of consumer-group
-  rebalance strategies (sticky/cooperative vs eager) as a sub-
-  comparison — each with partition-stop-the-world cost and use-case
-  fit. Parallel to v0.3 IDEATE-30 (drift-type enumeration).
- **ATELIER-101** (IDEATE-35, IDEATE-39): delivery-semantics.md must
-  include (a) the dead-letter strategy comparison table (retry-count-
-  limit vs TTL-with-backoff vs poison-queue vs DLQ+alert) per D-069,
-  AND (b) a fenced idempotency-key dedup-store example (not prose-
-  only) — parallel to v0.3 IDEATE-29 (fenced signed-attestation
-  example). Prose-only delivery-semantics guidance is weak; a fenced
-  consumer-with-dedup-store demonstrates P3 (idempotent consumers)
-  concretely.
- **ATELIER-111** (IDEATE-31, IDEATE-43): the new `## Languages`
-  MANIFEST section must list the 4 v0.1 first-principles stubs
-  (typescript.md, python.md, go.md, rust.md — closing the pre-existing
-  drift since v0.1, parallel to ESC-002/ATELIER-91) AND the 16 new
-  derived docs. The Cross-Cutting summary line must update to exactly
-  "19 domains, 190 P-rules post-v0.4" (IDEATE-18 carried forward).
- **ATELIER-114** (IDEATE-40): the P5 cross-link audit must verify
-  edge↔messaging intra-v0.4 links resolve in BOTH directions, not only
-  new→existing. Edge/iot.md (P1) cross-links messaging/queues.md (MQTT
-  QoS parallels delivery semantics) and messaging/iot.md-style
-  references — but messaging/ docs are authored in P2, so at the P1
-  tag (v0.3.1) those links dangle. This is acceptable per vertical-
-  slice integrity (D-053 — matrix/cross-links close in P4/P5), but the
-  P5 audit (ATELIER-114) must explicitly check that every edge→
-  messaging and messaging→edge link resolves by the P6 ship. The
-  audit must also confirm language-derived docs (P3) link to BOTH
-  new (edge/messaging) and existing domains where relevant (e.g.,
-  ts-async.md → messaging/delivery-semantics; go-concurrency.md →
-  concurrency/patterns + messaging/queues).
- **ATELIER-94** (IDEATE-38): offline-first.md must map offline write-
-  queue / conflict-detection patterns to the testing pyramid tiers
-  (unit: conflict detection on a merge function; integration:
-  reconnect reconcile against a local store; e2e: partition
-  simulation with a fake network) — parallel to v0.3 IDEATE-28 (i18n
-  pseudo-locale → pyramid). Avoids generic "test offline" guidance.
-
-## Within-Project Pattern Transfer (v0.1 → v0.2 → v0.3 → v0.4)
-
-| Prior Lesson | v0.4 Application | Status |
-|--------------|------------------|--------|
-| IDEATE-10/11/12 + 21/22/23 (decision/comparison tables in multi-tool derived docs) | D-069 + IDEATE-35 transfer the pattern to streams.md (Kafka/Kinesis/Pulsar) + delivery-semantics.md (dead-letter strategies) | ✓ transferred |
-| IDEATE-17 (manifest drift closure — examples/ unlisted → ATELIER-91) | IDEATE-31 → ATELIER-111 (languages/ unlisted since v0.1 — closes pre-existing drift on the same ESC-002 precedent) | ✓ transferred |
-| IDEATE-18 (coverage summary totals must update — string + per-domain count) | IDEATE-43 → ATELIER-111 (Cross-Cutting = "19 domains, 190 P-rules post-v0.4") + IDEATE-34 → ATELIER-106 (summary block) | ✓ transferred |
-| IDEATE-19 (Core Principle Coverage C1–C8 → domains table update) | IDEATE-33 → ATELIER-107 (C-rule coverage table extended for edge + messaging with the documented C-count shifts) | ✓ transferred |
-| IDEATE-20 (anti-patterns specificity: domain violations + artifact types) | IDEATE-36 + IDEATE-37 → ATELIER-110 (language-derived anti-patterns + .ts/.py/.go/.rs artifact types + all 6 chaos anti-patterns) | ✓ extended |
-| IDEATE-07 (named bad examples cite the P-rule breached) | ATELIER-113 + D-068 already cover (single-breach, cite specific P-rule) | ✓ carried forward |
-| IDEATE-08 (cross-link verification: every new derived doc ≥1 outbound) | ATELIER-114 already covers; IDEATE-40 extends to edge↔messaging intra-milestone links | ✓ extended |
-| IDEATE-13/14 (chaos: orphan P-rule + deployable artifact) | IDEATE-36 → ATELIER-110 (language orphan-section + standalone .ts/.py/.go/.rs runtime artifact) | ✓ extended |
-| IDEATE-28 (pseudo-locale testing → testing pyramid tiers) | IDEATE-38 → ATELIER-94 (offline write-queue testing → pyramid tiers) | ✓ transferred |
-| IDEATE-29 (fenced signed-attestation example, not prose-only) | IDEATE-39 → ATELIER-101 (fenced idempotency-key dedup-store example) | ✓ transferred |
-| IDEATE-30 (drift-type enumeration: data/concept/prediction + signal each) | IDEATE-41 → ATELIER-100 (rebalance-strategy enumeration: sticky/cooperative/eager + cost each) | ✓ transferred |
-
-## Summary
-
- 13 ideas generated, 13 accepted (confidence ≥ 0.79), 0 skipped.
- 1 new requirement: ATELIER-117 (ARCHITECTURE.md v0.4 update —
-  coverage gap; no existing req covers the architecture-tree drift).
- 12 refinements baked into ATELIER-94, 100, 101, 106, 107, 110, 111,
-  114 — to be honored by the PLAN stage as task must-haves (parallel
-  to v0.3's Refinements Notes → Task Bake-In Map).
- The within-project pattern-transfer convention (decision matrices,
-  manifest-drift closure, coverage-summary totals, C-rule coverage
-  table, chaos anti-patterns, fenced examples, enumerations, pyramid
-  mappings) continues from v0.2→v0.3→v0.4 unchanged.
- Tier 3 (cross-project) skipped silently: single-project registry.
- No idea fell below the 0.60 autonomy threshold → no HITL escalation.
@@ -2,10 +2,7 @@

 > Generated during P0 RESEARCH. Atelier is a documentation-only project;
 > the default runtime persona roster is deactivated. Custom personas
-> reflect the docs-as-code nature of the work. Updated per milestone:
-> v0.4 adds `edge-engineer` (P1) and `languages-engineer` (P3) phase-
-> specific personas (D-067); messaging (P2) is authored by tech-writer
-> + domain-expert with edge-engineer consultation.
+> reflect the docs-as-code nature of the work.

 ## Active Personas

@@ -23,7 +20,7 @@
 - **frameworks:** []
 - **constraints:** ["markdown-first", "examples are mandatory", "why over what", "audience awareness"]
 - **territory:** ["**/*.md", "LICENSE", "CHANGELOG.md", "CONTRIBUTING.md"]
- **reason:** Primary author of all framework markdown content. Owns docs-as-code discipline (Documentation P1). Excludes `.ciagent/**` governance files (owned by lead-developer). For v0.4: co-authors the messaging domain (P2) with domain-expert, per D-067.
+- **reason:** Primary author of all framework markdown content. Owns docs-as-code discipline (Documentation P1). Excludes `.ciagent/**` governance files (owned by lead-developer).

 ### domain-expert
 - **active:** true
@@ -31,7 +28,7 @@
 - **frameworks:** []
 - **constraints:** ["every principle traces to core", "10 principles per domain", "no orphans in matrix"]
 - **territory:** ["core/**", "domains/**", "matrix/**", "review/**", "examples/**"]
- **reason:** Validates domain principle correctness and traceability to core principles. Ensures the matrix is complete and no domain rule is orphaned. For v0.4: co-authors the messaging domain (P2) with tech-writer, consulting edge-engineer for the D-062 boundary, per D-067.
+- **reason:** Validates domain principle correctness and traceability to core principles. Ensures the matrix is complete and no domain rule is orphaned.

 ## Inactive Personas (from default roster)

@@ -49,45 +46,25 @@

 ## Phase-Specific Personas

-### edge-engineer (v0.4 — REMOVE after milestone completion)
+### platform-engineer (v0.3 — extended, active for v0.3, removed after milestone completion)

 - **active:** true
 - **phase_specific:** true
- **domain:** edge computing
- **frameworks:** []
- **constraints:** ["latency-bound first", "resource-constrained examples", "trace to core", "10 P-rules per domain", "no runtime code", "proximity is the distinguishing constraint (D-061)", "offline-capability is non-negotiable"]
- **territory:** ["domains/edge/**", "examples/good/edge-offline-sync.md", "examples/bad/edge-sync-loop.md"]
- **reason:** Per D-067: edge domain authoring (cdn, offline-first, iot, sync) benefits from a specialist persona with the proximity-is-correctness and offline-is-non-negotiable constraints. The distinguishing angle is proximity/location (D-061) — distinct from performance (generic), concurrency (in-process), and observability (generic telemetry). Active for v0.4 P1 (Edge Domain) only; consulted during P2 (Messaging) for the D-062 in-process-vs-cross-system boundary; removed after v0.4 completes; roster returns to 3 active personas.
-
-### languages-engineer (v0.4 — REMOVE after milestone completion)
-
- **active:** true
- **phase_specific:** true
- **domain:** language-specific application
- **frameworks:** []
- **constraints:** ["trace to existing domain P-rules (D-063, D-066) — no new matrix rows", "per-language idioms", "fenced code examples in-language", "10 P-rules per domain does NOT apply to language docs", "manifest gains Languages section (D-065)"]
- **territory:** ["languages/**"]
- **reason:** Per D-067: language-derived extension authoring (16 derived docs across TypeScript, Python, Go, Rust) benefits from a specialist persona enforcing the apply-don't-derive discipline (D-063) and the no-new-matrix-rows invariant (D-066). Languages are an application lens, not a principle source — the existing stubs' section-header-trace pattern is preserved, no P1–P10 numbering is introduced. Active for v0.4 P3 (Language-Derived Extension) only; removed after v0.4 completes; roster returns to 3 active personas.
-
-### platform-engineer (v0.3 — REMOVED after milestone completion)
-
- **active:** false
- **phase_specific:** true
 - **domain:** infrastructure/platform-automation
 - **frameworks:** []
 - **constraints:** ["declarative-first", "stateless examples", "trace to core", "10 P-rules per domain", "no runtime code", "source-of-truth is git", "reconciliation loop is the primitive"]
 - **territory:** ["domains/gitops-operators/**", "examples/good/gitops-pr.md", "examples/bad/* (gitops-related)"]
- **reason:** Per D-019 / D-027: the v0.2 platform-engineer persona was reused and extended for P1 (gitops-operators). Removed after v0.3 completed; roster returns to 3 active personas. The v0.3 gitops-operators content remains owned by tech-writer + domain-expert for cross-link maintenance. v0.4: still inactive.
+- **reason:** Per D-019 / D-027: the v0.2 platform-engineer persona is reused and extended for P1 (gitops-operators), because GitOps/Operators/Progressive Delivery build directly on the k8s + IaC declarative-reconciliation model the persona already embodies. Removed after v0.3 completes; roster returns to 3 active personas. The v0.2 IaC/k8s content remains owned by tech-writer + domain-expert for cross-link maintenance.

-### ml-engineer (v0.3 — REMOVED after milestone completion)
+### ml-engineer (v0.3 — phase-specific, removed after milestone completion)

- **active:** false
+- **active:** true
 - **phase_specific:** true
 - **domain:** machine-learning engineering
 - **frameworks:** []
 - **constraints:** ["reproducibility is non-negotiable", "data lineage is traceable", "trace to core", "10 P-rules per domain", "no runtime code", "engineering discipline not algorithm design (D-023)", "examples are illustrative markdown only"]
 - **territory:** ["domains/ai-ml/**", "examples/good/ai-ml-reproducibility.md"]
- **reason:** Per D-019 / D-020: AI/ML domain authoring (data versioning, model evaluation, serving, monitoring/drift) benefited from a specialist persona with reproducibility and data-lineage constraints. Scope was engineering discipline, NOT algorithm/model design (D-023). Removed after v0.3 completed; roster returns to 3 active personas. v0.4: still inactive.
+- **reason:** Per D-019 / D-020: AI/ML domain authoring (data versioning, model evaluation, serving, monitoring/drift) benefits from a specialist persona with reproducibility and data-lineage constraints the existing tech-writer persona lacks. Scope is engineering discipline, NOT algorithm/model design (D-023). Removed after v0.3 completes; roster returns to 3 active personas.

 ### platform-engineer (v0.2 — REMOVED after milestone completion)

@@ -97,7 +74,7 @@
 - **frameworks:** []
 - **constraints:** ["declarative-first", "stateless examples", "trace to core", "10 P-rules per domain", "no runtime code"]
 - **territory:** ["domains/infrastructure-as-code/**", "domains/kubernetes/**", "examples/good/terraform-module.md", "examples/good/k8s-deployment.md", "examples/bad/*"]
- **reason:** Specialist authoring for IaC/k8s domain content (terraform, opentofu, state, modules, k8s workloads/networking/storage/rbac/helm/kustomize) where the existing tech-writer persona lacks the domain expertise. Was active for v0.2 P1–P4 only; removed after milestone v0.2 completed (per D-027, D-014). Roster returns to 3 active personas. v0.4: still inactive.
+- **reason:** Specialist authoring for IaC/k8s domain content (terraform, opentofu, state, modules, k8s workloads/networking/storage/rbac/helm/kustomize) where the existing tech-writer persona lacks the domain expertise. Was active for v0.2 P1–P4 only; removed after milestone v0.2 completed (per D-027, D-014). Roster returns to 3 active personas.

 ## Territory Enforcement

@@ -105,11 +82,9 @@ Mode: `warn` (per config.json `personas.territory_enforcement`).

 At `warn`, territory violations are logged but not blocked. This is appropriate for a docs project where tech-writer may touch `.ciagent/` files incidentally (e.g., updating ROADMAP status). Strict mode would be appropriate once territories stabilize.

-## v0.4 Persona Roster Summary (active during milestone)
+## v0.3 Persona Roster Summary

-Active personas (3, span full milestone): lead-developer, tech-writer, domain-expert.
-Phase-specific personas (2, active during milestone): edge-engineer (P1 Edge Domain), languages-engineer (P3 Language-Derived Extension) — both removed after v0.4 completion per D-067.
-Messaging (P2) is authored by tech-writer + domain-expert (the permanent roster) with edge-engineer consultation for the distributed-systems/async overlap (D-062 boundary), per D-067. The edge-engineer's distributed-systems lens survives the P1→P2 persona transition via a task must-have baked into the plan (the D-051 constraints-baked-into-task pattern from v0.3): "P1/P2 demonstrated edge + messaging boundary (D-062); delivery-semantics comparison table required (D-069)."
-Inactive default personas (3, unchanged): data-engineer, backend-engineer, frontend-engineer.
-Historical phase-specific personas (3, inactive): platform-engineer (v0.2), platform-engineer (v0.3 extended), ml-engineer (v0.3) — retained as historical record; "v0.4: still inactive" appended to their reasons.
-Peak active roster during v0.4: 5 (3 permanent + 2 phase-specific), matching v0.3's peak and avoiding persona-explosion risk. Roster returns to 3 active personas after v0.4 completion.
+Active personas for v0.3 (5): lead-developer, tech-writer, domain-expert (span full milestone), platform-engineer (phase-specific, P1 gitops-operators), ml-engineer (phase-specific, P2 ai-ml).
+- **Phase assignment:** P1 GitOps/Operators → platform-engineer; P2 AI/ML → ml-engineer; P3 i18n + Compliance → tech-writer + domain-expert (D-022); P4–P5 matrix/review/examples → tech-writer + domain-expert + lead-developer.
+Inactive personas (3, unchanged): data-engineer, backend-engineer, frontend-engineer.
+Post-v0.3: platform-engineer + ml-engineer removed; roster returns to 3 active personas (lead-developer, tech-writer, domain-expert).
@@ -1,285 +0,0 @@
-# Atelier — Plan (v0.4)
-
-> Vertical-slice plans with wave ordering for milestone v0.4 (Edge + Messaging + Language-Derived Docs). Plans reference REQ-IDs from `.ciagent/atelier/REQUIREMENTS.md` (ATELIER-92..117). NFR milestone — all phases produce docs; no `feat` code. Per `parallelization.max_concurrent_agents = 5`, wave parallelism is capped at 5 concurrent tasks; waves larger than 5 are split into sub-waves. Grounded in `RESEARCH-v0.4.md` (proposed P-rules, derived-doc outlines, anti-patterns, examples, matrix rows) and decisions D-054..D-073.
-
-## Plan-Level Invariants
-
- **Vertical-slice integrity (D-053 carried forward):** each phase is independently shippable. P1 ships the edge domain self-consistent (matrix rows land in P4 — the domain is internally consistent; matrix extension is traceability closure, not a blocker). P2 ships messaging self-consistent. P3 ships the 16 language-derived docs self-consistent. P4 closes traceability + manifest + architecture. P5 closes examples + cross-links. P6 ships the release. Edge↔messaging intra-milestone cross-links may dangle at the P1 tag (v0.3.1) because messaging is authored in P2; this is acceptable per D-053 — the P5 audit (ATELIER-114) verifies both directions resolve by the P6 ship (IDEATE-40).
- **Tag sequence:** v0.3.0 (P0) → v0.3.1 (P1) → v0.3.2 (P2) → v0.3.3 (P3) → v0.3.4 (P4) → v0.3.5 (P5) → v0.3.6 (P6 = milestone release). NFR milestone: no separate minor tag; the final patch (v0.3.6) IS the v0.4 deliverable.
- **Persona lifecycle:** edge-engineer + languages-engineer active P1–P5, review their authored content in P6 Wave 1 (D-052 precedent), removed in P6 Wave 2 (roster returns to 3 active). Messaging (P2) authored by tech-writer + domain-expert with edge-engineer consultation (D-067); the edge-engineer's distributed-systems lens survives the P1→P2 transition via a task must-have baked into P2 tasks (D-051 constraints-baked-into-task pattern). Peak active roster during v0.4: 5 (3 permanent + 2 phase-specific).
- **Refinements are execute-time must-haves:** all 12 IDEATE-v0.4.md refinements (IDEATE-31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43) and the refinement notes in REQUIREMENTS.md are baked into the relevant task Must-have columns — they are NOT separate tasks. See the "v0.4 Ideation Refinements → Task Bake-In Map" at the end of this file.
- **Cross-link rule (IDEATE-08 carried forward):** every new derived doc has ≥1 outbound cross-link to a MANIFEST-listed doc. The P5 audit (ATELIER-114) verifies this AND edge↔messaging intra-v0.4 links resolve in both directions (IDEATE-40) AND language-derived docs link to both new (edge/messaging) and existing domains where relevant.
- **Anti-pattern pre-specification (RESEARCH-v0.4 §Review Integration):** 6 chaos anti-patterns are pre-specified to reject on sight — edge: sync-conflict-loop (P4), TTL-less-cache (P6), blocking-call-on-constrained-device (P3/P5); messaging: shared-subscription (P2/P3), blocking-consumer (P6), unbounded-retry (P5). These land in `review/anti-patterns.md` in P4; the 2 named bad examples that demonstrate them (edge-sync-loop, messaging-shared-subscription) land in P5.
- **No runtime code (D-020 carried forward):** all examples and fenced code are illustrative markdown only. The v0.4 deployable-artifact-types table extends to `.ts`/`.py`/`.go`/`.rs` standalone files (forbidden in language-derived docs).
-
-## Phase 0 — Pre-Execution (COMPLETE)
-
-Stages: SPECIFY ✓ → CLARIFY ✓ → RESEARCH ✓ → IDEATE ✓ → PLAN ✓ → GRILL → SHIP
-Branch: `phase/00-pre-execution` (from `milestone/v0.4-edge-quantum-langs`)
-Tag: v0.3.0
-
-## Phase 1 — Edge Domain
-
-**Goal:** Author the `domains/edge/` tree — 10 first principles (P1–P10) plus 4 derived docs (cdn, offline-first, iot, sync). Edge owns the proximity/location angle (D-061): compute near the user/data source, offline as a first-class state, constrained resources declared, sync conflicts bounded, partition-survivable telemetry. Each P-rule derives from core C1–C8 (matrix extension lands in P4).
-**Branch:** `phase/01-edge` (from `milestone/v0.4-edge-quantum-langs`)
-**Personas:** edge-engineer (author), domain-expert (validate traceability), tech-writer (style/format)
-**Tag:** v0.3.1
-**Requirements:** ATELIER-92, ATELIER-93, ATELIER-94, ATELIER-95, ATELIER-96
-
-### Wave 1 (sequential — first-principles must exist before derived docs)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 01-01-01 | `domains/edge/first-principles.md` | edge-engineer | ATELIER-92 | 10 P-rules P1–P10 per RESEARCH-v0.4 §Edge (P1 Proximity is the Design Driver, P2 Offline is a First-Class State, P3 Resources are Constrained and Declared, P4 Sync Conflicts are Bounded Not Infinite, P5 Edge Operations are Idempotent, P6 Cache Invalidation is Explicit, P7 Partial Degradation is Engineered, P8 Geographic Distribution is a First-Class Constraint, P9 Identity is Constrained at the Edge, P10 Edge Observability Survives Partition); each names the core C-rule(s) it derives from; each has definition + "what violates"; broad-derivation domain (7 C-rules: C1, C3, C4, C5, C6, C7, C8); edge-engineer constraints enforced (proximity is the distinguishing constraint per D-061, offline-capability is non-negotiable, latency is a correctness constraint) |
-
-### Wave 2 (parallel — 4 derived docs, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 01-02-01 | `domains/edge/cdn.md` | edge-engineer | ATELIER-93 | CDN/edge-cache placement + invalidation per RESEARCH-v0.4 §Edge (cache key design, TTL vs explicit invalidation, cache-hit/miss/origin-fetch, origin shielding, purge strategies URL vs soft vs surrogate-key, cache poisoning prevention, multi-CDN routing P8); **decision matrix required (D-069): edge-cache vs origin — when to serve from the pop, when to fetch fresh, when to shield the origin**; cross-link `performance/frontend` (generic caching), `security/input-validation` (cache poisoning), `observability/metrics` (cache-hit ratio); ≥1 outbound cross-link to a MANIFEST-listed doc (IDEATE-08) |
-| 01-02-02 | `domains/edge/offline-first.md` | edge-engineer | ATELIER-94 | Offline as a first-class state (P2), local-first storage (IndexedDB/SQLite/on-device), queue-and-forward for writes, conflict detection on reconnect, UI for offline state, service workers per RESEARCH-v0.4 §Edge; **offline write-queue / conflict-detection patterns mapped to testing pyramid tiers (IDEATE-38, ATELIER-94 refinement): unit (conflict detection on a merge function), integration (reconnect reconcile against a local store), e2e (partition simulation with a fake network)**; fenced code: a service-worker cache strategy + an offline-write-queue sketch; cross-link `concurrency/patterns` (bounded buffer = in-process analog), `observability/logging` (local-first logging); ≥1 outbound cross-link (IDEATE-08) |
-| 01-02-03 | `domains/edge/iot.md` | edge-engineer | ATELIER-95 | Constrained devices at the edge per RESEARCH-v0.4 §Edge: device resource classes (P3), constrained protocols (MQTT, CoAP), device identity + provisioning (P9), telemetry from devices (P10), command idempotency (P5), partial-degradation when devices drop (P7); fenced code: an MQTT publish/subscribe payload with QoS levels + a device-provisioning manifest; cross-link `security/secrets` (device credentials), `messaging/queues` (MQTT QoS parallels delivery semantics — one-directional outward; this link dangles until P2, acceptable per D-053, verified bidirectional in P5 ATELIER-114 per IDEATE-40); ≥1 outbound cross-link (IDEATE-08) |
-| 01-02-04 | `domains/edge/sync.md` | edge-engineer | ATELIER-96 | Reconciling divergent state across partitions per RESEARCH-v0.4 §Edge: the sync problem (P4), conflict resolution strategies, CRDTs (state-based + operation-based), last-write-win (LWW) with vector clocks/timestamps, merge semantics, conflict-free vs conflict-tolerant data types; **decision matrix required (D-069): CRDT vs last-write-win — when each applies, the correctness cost, the operational cost**; fenced code: a CRDT register (LWW-element-set) + an LWW-with-vector-clock merge; cross-link `data/migrations` (schema migration under sync), `concurrency/patterns` (immutability aids merge); ≥1 outbound cross-link (IDEATE-08) |
-
-**Verify (P1):**
- Structural: 5 files exist under `domains/edge/`
- Behavioral: every P1–P10 in first-principles names ≥1 C-rule (domain-expert sign-off); broad-derivation 7 C-rules (C1, C3, C4, C5, C6, C7, C8) confirmed
- Security: P9 (Identity is Constrained at the Edge) + P6 (Cache Invalidation is Explicit) sections present
- Quality: each derived doc has ≥1 outbound cross-link to a MANIFEST-listed doc (IDEATE-08); cdn.md carries the edge-cache-vs-origin decision matrix (D-069); sync.md carries the CRDT-vs-LWW decision matrix (D-069); offline-first.md maps offline write-queue to testing pyramid tiers (IDEATE-38); no duplication of performance/concurrency/observability P-rules (D-061 boundary — proximity/location angle only)
-
-## Phase 2 — Messaging Domain
-
-**Goal:** Author the `domains/messaging/` tree — 10 first principles (P1–P10) plus 4 derived docs (queues, pubsub, streams, delivery-semantics). Messaging owns the cross-process / network-failure-model angle (D-062): messages as contracts, explicit delivery semantics, idempotent consumers, bounded backpressure, observable lag. Concurrency owns the in-process analog; cross-link is one-directional outward. Each P-rule derives from core C1–C8 (matrix extension lands in P4).
-**Branch:** `phase/02-messaging` (from `milestone/v0.4-edge-quantum-langs`)
-**Personas:** tech-writer (author), domain-expert (author + validate traceability), edge-engineer (consult — D-067 distributed-systems/async overlap)
-**Tag:** v0.3.2
-**Requirements:** ATELIER-97, ATELIER-98, ATELIER-99, ATELIER-100, ATELIER-101
-
-### Wave 1 (sequential — first-principles first)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 02-01-01 | `domains/messaging/first-principles.md` | tech-writer + domain-expert (edge-engineer consult) | ATELIER-97 | 10 P-rules P1–P10 per RESEARCH-v0.4 §Messaging (P1 Messages are Contracts, P2 Ordering is a Property Not an Assumption, P3 Consumers are Idempotent, P4 Delivery Semantics are Explicit, P5 Dead-Letter Handling is Defined, P6 Backpressure is Bounded, P7 Partitioning is Intentional, P8 Replay and Retention are Configured, P9 Schemas Evolve Compatibly, P10 Messaging is Observable); each names the core C-rule(s) it derives from; each has definition + "what violates"; broad-derivation domain (7 C-rules: C1, C2, C4, C5, C6, C7, C8); **edge-engineer consultation baked in (D-067, D-051 pattern): P1/P2 demonstrated edge + messaging boundary (D-062 — cross-process/network-failure-model, not in-process concurrency); no duplication of concurrency P-rules** |
-
-### Wave 2 (parallel — 4 derived docs, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 02-02-01 | `domains/messaging/queues.md` | tech-writer + domain-expert | ATELIER-98 | Point-to-point async delivery via queues per RESEARCH-v0.4 §Messaging: producer/consumer model, ack/nack, visibility timeouts, redelivery, FIFO vs standard queues, prefetch + concurrency, long polling; **comparison table required (D-069): at-least-once vs at-most-once vs exactly-once — semantics, latency cost, implementation cost, when each fits**; fenced code: a producer/consumer pair with idempotency key + a redelivery+DLQ flow; cross-link `concurrency/patterns` (in-process bounded queue — one-directional outward), `observability/metrics` (lag); ≥1 outbound cross-link (IDEATE-08) |
-| 02-02-02 | `domains/messaging/pubsub.md` | tech-writer + domain-expert | ATELIER-99 | Fan-out via publish/subscribe per RESEARCH-v0.4 §Messaging: topic/subscription model, fan-out semantics, shared vs independent subscriptions (the `messaging-shared-subscription` chaos anti-pattern lives here — pre-specified in P4 ATELIER-110), filtering, ordering across subscriptions; fenced code: a publish + two independent subscriptions; cross-link `messaging/streams` (pub/sub vs stream — durability boundary), `observability/metrics` (per-subscription lag); ≥1 outbound cross-link (IDEATE-08) |
-| 02-02-03 | `domains/messaging/streams.md` | tech-writer + domain-expert | ATELIER-100 | Durable-log messaging + stream processing per RESEARCH-v0.4 §Messaging: partitioned log model, offsets, consumer groups, replay, retention windows, stream processing (windowing, joins, exactly-once via transactions); **stream-platform comparison table required (D-069): Kafka vs Kinesis vs Pulsar/NATS JetStream — ordering guarantees, partitioning model, replay/retention, use-case fit**; **consumer-group rebalance strategy enumeration (IDEATE-41, ATELIER-100 refinement): sticky/cooperative vs eager — each with partition-stop-the-world cost + use-case fit (parallel to v0.3 IDEATE-30 drift-type enumeration)**; fenced code: a consumer-group reading from offsets + a transactional exactly-once producer; cross-link `messaging/delivery-semantics` (exactly-once via transactions), `data/schema-design` (stream schema), `observability/tracing` (cross-partition traces); ≥1 outbound cross-link (IDEATE-08) |
-| 02-02-04 | `domains/messaging/delivery-semantics.md` | tech-writer + domain-expert | ATELIER-101 | Correctness properties of delivery per RESEARCH-v0.4 §Messaging: the three semantics (P4), idempotency (P3), ordering (P2), dead-letter strategies (P5), retry budgets + backoff, poison messages; **dead-letter strategy comparison table required (D-069): retry-count-limit vs TTL-with-backoff vs poison-queue vs DLQ+alert — when each applies, failure visibility, operational cost**; **fenced idempotency-key dedup-store example (IDEATE-39, ATELIER-101 refinement): not prose-only — a fenced consumer-with-dedup-store demonstrates P3 concretely (parallel to v0.3 IDEATE-29 fenced signed-attestation)**; fenced code: an idempotent consumer with a dedup store + a DLQ routing rule; cross-link `concurrency/patterns` (retry/backoff in-process analog), `errors/patterns` (errors as data for message failures), `observability/metrics` (DLQ depth as an alert); ≥1 outbound cross-link (IDEATE-08) |
-
-**Verify (P2):**
- Structural: 5 files exist under `domains/messaging/`
- Behavioral: every P1–P10 traces to ≥1 C-rule (domain-expert sign-off); broad-derivation 7 C-rules (C1, C2, C4, C5, C6, C7, C8) confirmed
- Security: P1 (Messages are Contracts) + P5 (Dead-Letter Handling is Defined) sections present
- Quality: each derived doc ≥1 outbound cross-link (IDEATE-08); queues.md carries the delivery-semantics comparison table (D-069); streams.md carries the stream-platform comparison table (D-069) AND the rebalance-strategy enumeration (IDEATE-41); delivery-semantics.md carries the dead-letter strategy comparison table (D-069) AND a fenced idempotency-key dedup-store example (IDEATE-39); no duplication of concurrency/patterns.md P-rules (D-062 boundary — cross-process/network-failure-model only); edge↔messaging cross-links resolve bidirectionally post-P2 (verified in P5 ATELIER-114 per IDEATE-40)
-
-## Phase 3 — Language-Derived Extension
-
-**Goal:** Extend each `languages/*.md` from a first-principles-only stub to a full derived-doc tree. 4 languages × (extend stub + 4 derived docs) = 16 new derived docs. Language-derived docs introduce NO new P-rules (D-063) and NO new matrix rows (D-066); each section traces to existing domain P-rules via the section-header-trace pattern. The first-principles stub is extended with a pointer to its derived docs but retains its section structure — no P1–P10 numbering (D-063).
-**Branch:** `phase/03-languages-derived` (from `milestone/v0.4-edge-quantum-langs`)
-**Personas:** languages-engineer (author), domain-expert (validate traceability)
-**Tag:** v0.3.3
-**Requirements:** ATELIER-102, ATELIER-103, ATELIER-104, ATELIER-105
-
-### Wave 1 (parallel — 4 first-principles stubs extended, independent; ≤5 concurrent → 4 tasks)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-01-01 | `languages/typescript.md` (extend stub) | languages-engineer | ATELIER-102 | Extend existing first-principles stub with a pointer to its 4 derived docs (ts-types, ts-tooling, ts-async, ts-testing); **retain existing section structure — NO P1–P10 numbering added (D-063)**; existing section-header-trace pattern preserved (e.g., `## Type System (C1 Correctness, Data P7 Type Fidelity)`); languages-engineer constraints enforced (apply don't derive, no new P-rules, no new matrix rows per D-063/D-066) |
-| 03-01-02 | `languages/python.md` (extend stub) | languages-engineer | ATELIER-103 | Extend existing first-principles stub with a pointer to its 4 derived docs (py-types, py-tooling, py-async, py-testing); retain existing section structure — NO P1–P10 numbering (D-063); section-header-trace pattern preserved |
-| 03-01-03 | `languages/go.md` (extend stub) | languages-engineer | ATELIER-104 | Extend existing first-principles stub with a pointer to its 4 derived docs (go-types, go-tooling, go-concurrency, go-testing); retain existing section structure — NO P1–P10 numbering (D-063); section-header-trace pattern preserved |
-| 03-01-04 | `languages/rust.md` (extend stub) | languages-engineer | ATELIER-105 | Extend existing first-principles stub with a pointer to its 4 derived docs (rs-ownership, rs-tooling, rs-async, rs-testing); retain existing section structure — NO P1–P10 numbering (D-063); section-header-trace pattern preserved |
-
-### Wave 2 (parallel — 16 derived docs, grouped by language; ≤5 concurrent → executor schedules 5-then-5-then-5-then-1)
-
-> **Parallelism note:** 16 independent tasks all depend only on Wave 1. The executor schedules at most 5 concurrently per `parallelization.max_concurrent_agents`. The 2a/2b/2c/2d labels organize by language, not a hard sequencing barrier — all sub-waves are in the same dependency tier.
-
-**Wave 2a — TypeScript (4 derived docs, ≤5 concurrent)**
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-02a-01 | `languages/ts-types.md` | languages-engineer | ATELIER-102 | TypeScript type system per RESEARCH-v0.4 §Language-Derived: nominal vs structural typing (branded types), generics, narrowing, utility types, discriminated unions; each section header names ≥1 traced domain P-rule AND core C-rule inline (e.g., `## Nominal vs Structural Typing (C1 Correctness, Data P7 Type Fidelity, API P1 Contract Fidelity)`); fenced TS code in-language (illustrative only, no standalone .ts — D-020); traces to Data P7, API P1, Errors P1, Concurrency P1; ≥1 outbound cross-link to a traced domain doc (IDEATE-08; per IDEATE-40 also cross-link new edge/messaging where relevant, e.g., ts-types → messaging/delivery-semantics if schema-fidelity applies) |
-| 03-02a-02 | `languages/ts-tooling.md` | languages-engineer | ATELIER-102 | TypeScript tooling per RESEARCH-v0.4 §Language-Derived: tsc, ESLint, ts-jest, project references, tsconfig discipline; section headers trace to DevOps P2, DevOps P1, Documentation P1; fenced TS code in-language; ≥1 outbound cross-link (IDEATE-08) |
-| 03-02a-03 | `languages/ts-async.md` | languages-engineer | ATELIER-102 | TypeScript async per RESEARCH-v0.4 §Language-Derived: Promises + AbortSignal, async/await, error handling, cancellation; section headers trace to Concurrency P7, P8, P9, Errors P5; fenced TS code in-language; cross-link `concurrency/patterns` + `messaging/delivery-semantics` (per IDEATE-40 — ts-async → messaging/delivery-semantics where async-retry parallels apply); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02a-04 | `languages/ts-testing.md` | languages-engineer | ATELIER-102 | TypeScript testing per RESEARCH-v0.4 §Language-Derived: Vitest/Jest, mock discipline, type-level tests; section headers trace to Testing P1, P2, P3, P9; fenced TS code in-language; cross-link `testing/pyramid` + `testing/fixtures`; ≥1 outbound cross-link (IDEATE-08) |
-
-**Wave 2b — Python (4 derived docs, ≤5 concurrent; runs in parallel with 2a — total 8 tasks, capped at 5 → executor schedules 5 then 3)**
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-02b-01 | `languages/py-types.md` | languages-engineer | ATELIER-103 | Python type system per RESEARCH-v0.4 §Language-Derived: type hints + Pydantic, mypy/pyright, gradual typing; section headers trace to Data P7, Errors P1, API P1; fenced Python code in-language (no standalone .py — D-020); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02b-02 | `languages/py-tooling.md` | languages-engineer | ATELIER-103 | Python tooling per RESEARCH-v0.4 §Language-Derived: ruff, mypy, poetry, uv, virtualenv discipline; section headers trace to DevOps P2, Documentation P1; fenced Python code in-language; ≥1 outbound cross-link (IDEATE-08) |
-| 03-02b-03 | `languages/py-async.md` | languages-engineer | ATELIER-103 | Python async per RESEARCH-v0.4 §Language-Derived: asyncio, anyio, cancellation, structured concurrency; section headers trace to Concurrency P7, P8, P9; fenced Python code in-language; cross-link `concurrency/patterns` + `messaging/queues` (per IDEATE-40 where applicable); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02b-04 | `languages/py-testing.md` | languages-engineer | ATELIER-103 | Python testing per RESEARCH-v0.4 §Language-Derived: pytest, factory_boy, fixture discipline, parametrize; section headers trace to Testing P1, P2, P3; fenced Python code in-language; cross-link `testing/pyramid` + `testing/fixtures`; ≥1 outbound cross-link (IDEATE-08) |
-
-**Wave 2c — Go (4 derived docs, ≤5 concurrent; same dependency tier as 2a/2b/2d)**
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-02c-01 | `languages/go-types.md` | languages-engineer | ATELIER-104 | Go type system per RESEARCH-v0.4 §Language-Derived: named types, generics, interfaces, type assertion discipline; section headers trace to Data P7, Errors P1, API P1; fenced Go code in-language (no standalone .go — D-020); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02c-02 | `languages/go-tooling.md` | languages-engineer | ATELIER-104 | Go tooling per RESEARCH-v0.4 §Language-Derived: go vet, golangci-lint, go test -race, module discipline; section headers trace to DevOps P2, Concurrency P6; fenced Go code in-language; ≥1 outbound cross-link (IDEATE-08) |
-| 03-02c-03 | `languages/go-concurrency.md` | languages-engineer | ATELIER-104 | Go concurrency per RESEARCH-v0.4 §Language-Derived: goroutines, channels, context, select, sync primitives — Go's distinctive strength earns a dedicated concurrency doc (not go-async); section headers trace to Concurrency P1, P3, P5, P7, P8, P9; fenced Go code in-language; cross-link `concurrency/patterns` + `messaging/queues` (per IDEATE-40 — go-concurrency → concurrency/patterns + messaging/queues where channel/broker analogs apply); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02c-04 | `languages/go-testing.md` | languages-engineer | ATELIER-104 | Go testing per RESEARCH-v0.4 §Language-Derived: table-driven tests, t.Parallel, t.Cleanup, race detector; section headers trace to Testing P1, P2, P3, P9; fenced Go code in-language; cross-link `testing/pyramid` + `testing/fixtures`; ≥1 outbound cross-link (IDEATE-08) |
-
-**Wave 2d — Rust (4 derived docs, ≤5 concurrent; same dependency tier as 2a/2b/2c)**
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-02d-01 | `languages/rs-ownership.md` | languages-engineer | ATELIER-105 | Rust ownership per RESEARCH-v0.4 §Language-Derived: Send/Sync, lifetimes, borrowing, ownership transfer — Rust's distinctive strength earns a dedicated ownership doc (not rs-types); section headers trace to Concurrency P1, P3, Data P7; fenced Rust code in-language (no standalone .rs — D-020); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02d-02 | `languages/rs-tooling.md` | languages-engineer | ATELIER-105 | Rust tooling per RESEARCH-v0.4 §Language-Derived: cargo, clippy, fmt, edition discipline; section headers trace to DevOps P2, Documentation P1; fenced Rust code in-language; ≥1 outbound cross-link (IDEATE-08) |
-| 03-02d-03 | `languages/rs-async.md` | languages-engineer | ATELIER-105 | Rust async per RESEARCH-v0.4 §Language-Derived: tokio, async traits, cancellation, pin; section headers trace to Concurrency P5, P7, P8, P9; fenced Rust code in-language; cross-link `concurrency/patterns` + `messaging/delivery-semantics` (per IDEATE-40 where applicable); ≥1 outbound cross-link (IDEATE-08) |
-| 03-02d-04 | `languages/rs-testing.md` | languages-engineer | ATELIER-105 | Rust testing per RESEARCH-v0.4 §Language-Derived: #[test], proptest, property testing, mock discipline; section headers trace to Testing P1, P2, P3, P9; fenced Rust code in-language; cross-link `testing/pyramid` + `testing/fixtures`; ≥1 outbound cross-link (IDEATE-08) |
-
-> **Parallelism note:** Wave 2a + 2b + 2c + 2d together = 16 independent tasks. The executor schedules at most 5 concurrently per `parallelization.max_concurrent_agents`; the remaining 11 run as slots free. The 2a/2b/2c/2d labels are organizational (by language), not a hard sequencing barrier — all sub-waves are in the same dependency tier (all depend only on Wave 1).
-
-**Verify (P3):**
- Structural: 4 stubs extended + 16 new derived docs exist under `languages/` (20 language files total)
- Behavioral: every derived-doc section header names ≥1 traced domain P-rule AND core C-rule inline (D-063, D-066); no new P-rules introduced; no P1–P10 numbering on language stubs (D-063); domain-expert verifies no orphan sections (every derived doc traces to ≥1 domain P-rule)
- Security: no standalone `.ts`/`.py`/`.go`/`.rs` runtime artifacts (D-020 docs-only contract — fenced code in `.md` only)
- Quality: each derived doc ≥1 outbound cross-link to a traced domain doc (IDEATE-08); language-derived docs link to BOTH new (edge/messaging) and existing domains where relevant (IDEATE-40); the 16 derived docs collectively trace to the domains sketched in RESEARCH-v0.4 §Language-Derived (the Languages Coverage sub-table that captures these traces lands in P4 ATELIER-107)
-
-## Phase 4 — Matrix + Review + Manifest + Architecture Integration
-
-**Goal:** Extend the matrix (+20 P-rule → C-rule mappings, 10 edge + 10 messaging; verify pre-existing 170 rows per G-014, append 20, confirm post-v0.4 is exactly 190), domain-coverage (per-domain rows + Core Principle Coverage table for 2 new domains + new Languages Coverage sub-table with exactly 16 rows), ARCHITECTURE.md (v0.4 section + component tree for edge/messaging/languages-derived), review docs (agent + peer-review + anti-patterns with all 6 chaos anti-patterns + language-derived anti-patterns + .ts/.py/.go/.rs artifact types), and the manifest (new `## Languages` section closing pre-existing drift + post-v0.4 totals). Closes the traceability loop and makes the manifest + architecture authoritative for v0.4.
-**Branch:** `phase/04-matrix-review-manifest` (from `milestone/v0.4-edge-quantum-langs`)
-**Personas:** domain-expert (matrix + coverage + anti-patterns), tech-writer (checklists), lead-developer (manifest + ARCHITECTURE.md — authoritative index + architecture tree)
-**Tag:** v0.3.4
-**Requirements:** ATELIER-106, ATELIER-107, ATELIER-117, ATELIER-108, ATELIER-109, ATELIER-110, ATELIER-111
-
-### Wave 1 (sequential — matrix is the arbiter, must be authoritative first; then coverage; then ARCHITECTURE.md)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 04-01-01 | `matrix/principles-matrix.md` (extend) | domain-expert | ATELIER-106 | Add "Edge" + "Messaging" sections, 10 rows each, format matching v0.1/v0.2/v0.3 tables (rows per RESEARCH-v0.4 §Matrix Integration); **review check: row count per new domain = 10, each row ≥1 C-rule** (IDEATE-02 carried forward); **verify pre-existing count first (IDEATE-34 corrected per G-014, ATELIER-106 refinement): the current matrix has exactly 170 P-rows (17 domains × 10, verified by grill G-014) — confirm 170 exists BEFORE appending the 20 v0.4 rows; do NOT hunt for or delete a phantom 171st row; post-v0.4 count must be exactly 190 (= 170 + 20)**; update Coverage Summary to "post-v0.4: 19 domains, 190 P-rules" in BOTH the summary block AND the per-domain section count (IDEATE-18, IDEATE-43 carried forward) |
-| 04-01-02 | `matrix/domain-coverage.md` (extend) | domain-expert | ATELIER-107 | THREE artifacts updated (IDEATE-33, IDEATE-42, ATELIER-107 refinement): (a) per-domain row-schema table — add Edge + Messaging rows (schema: domain, P-count, derived-doc-count, manifest-listed, status per IDEATE-03); (b) Core Principle Coverage table (C1–C8 → domains) — extend for 2 new domains: C4 Locality grows by edge P1/P8 + messaging P7; C5 Reversibility grows by edge P2/P4/P7/P10 + messaging P5/P8/P9; C7 Observability grows by edge P10 + messaging P8/P10; C8 Economy grows by edge P3/P9 + messaging P6; C2 grows by messaging P1/P2/P4 (parallel to v0.3 IDEATE-19); (c) new `## Languages Coverage` sub-table with EXACTLY 16 rows (one per language-derived doc) — schema: Language \| Derived Doc \| Traced Domain P-rules \| Traced Core C-rules; verifiable as a P4 review check (no orphans, every derived doc traced to ≥1 domain P-rule, per D-066) |
-| 04-01-03 | `ARCHITECTURE.md` (extend) | lead-developer | ATELIER-117 | Extend the component tree with `edge/` + `messaging/` domain entries; add a `## v0.4 Domain Additions` section documenting the two new domains (boundary per D-061/D-062, derived docs, cross-link targets); note the `languages/` derived-doc extension (D-063 apply-don't-derive — no new P-rules, no new matrix rows). Closes architecture-tree drift: the file currently stops at v0.3 with no edge/messaging/languages-derived coverage (IDEATE-32) |
-
-### Wave 2 (parallel — 3 review docs, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 04-02-01 | `review/agent-checklist.md` (extend) | tech-writer | ATELIER-108 | Add 3 trigger sections per RESEARCH-v0.4 §Review Integration: "If Edge (see domains/edge/)" — 10 checks (P1 proximity/latency-as-correctness, P2 offline, P3 constrained resources declared, P4 sync conflicts bounded, P5 idempotent, P6 cache invalidation explicit, P7 partial degradation, P8 geographic distribution, P9 identity constrained, P10 local-first telemetry); "If Messaging (see domains/messaging/)" — 10 checks (P1 messages are contracts, P2 ordering explicit, P3 idempotent consumers, P4 delivery semantics explicit, P5 dead-letter defined, P6 backpressure bounded, P7 partitioning intentional, P8 replay/retention configured, P9 schemas evolve compatibly, P10 observable); "If Language-Derived Docs (see languages/)" — 5 checks (no new P-rules per D-063/D-066; every section header names ≥1 traced domain P-rule AND C-rule inline; fenced code in-language + illustrative only per D-020; first-principles stub retains structure — no P1–P10 numbering; cross-links to traced domain docs present ≥1 outbound per derived doc per ATELIER-114) |
-| 04-02-02 | `review/peer-review-checklist.md` (extend) | tech-writer | ATELIER-109 | Add 3 peer-review sections mirroring the agent-checklist as reviewer-voice questions, plus 3 scope checks (IDEATE-09 parity carried forward): edge scope check (proximity/location/constraint angle, not generic perf or in-process concurrency — D-061); messaging scope check (cross-process/network-failure-model, not in-process concurrency — D-062); language-derived scope check (apply don't derive — no new P-rules, no new matrix rows — D-063, D-066) |
-| 04-02-03 | `review/anti-patterns.md` (extend) | domain-expert | ATELIER-110 | Per RESEARCH-v0.4 §Review Integration + IDEATE-36/37 (ATELIER-110 refinement): (a) **v0.4 deployable-artifact-types table extended to `.ts`/`.py`/`.go`/`.rs` standalone files** (language-derived docs risk, per D-020 docs-only contract); (b) **all 6 RESEARCH-specified chaos anti-patterns** (not just the 4 named in the req-row text) — edge: sync conflict loop (P4, C1/C5 — infinite oscillation is a correctness failure/livelock), TTL-less cache (P6, C1/C3 — stale-forever under partition), blocking call on constrained device (P3/P5, C8/C1 — blocks the node, no timeout, retry unsafe without idempotency); messaging: shared subscription (P2/P3, C1 — breaks ordering + dedup), blocking consumer (P6, C1/C8 — blocks the partition, lag grows), unbounded retry / no DLQ (P5, C1/C5 — infinite retry is a livelock); (c) **language-derived-doc anti-patterns**: introducing a new P-rule (e.g., "TS P1" — violates D-063 + ARCHITECTURE.md hierarchy), orphan section with no domain P-rule trace (violates D-066 + matrix completeness), runtime standalone artifact `.ts`/`.py`/`.go`/`.rs` (violates D-020), first-principles stub gaining P1–P10 numbering (violates D-063); (d) **domain-specific anti-patterns** per RESEARCH-v0.4 §Review Integration — edge 10 (central-region-only deployment, crash-on-disconnect, undeclared resource budget, sync oscillation, non-idempotent edge write, TTL-less cache, crash-on-node-failure, random geographic placement, shared edge-device credential, fire-and-forget telemetry), messaging 10 (schemaless message, undocumented "FIFO", non-idempotent consumer, unstated delivery semantic, no DLQ, unbounded retry budget, default partition key, ephemeral broker, silent schema change, silent backlog) |
-
-### Wave 3 (sequential — MANIFEST after review docs settled; per D-050 precedent anti-patterns + manifest combine under lead-developer so manifest lists file paths after anti-pattern content is settled)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 04-03-01 | `MANIFEST.md` (extend) | lead-developer | ATELIER-111 | Per D-065 + IDEATE-31/43 (ATELIER-111 refinement): (a) add 2 new domains (edge, messaging) + all 10 derived docs to the Domains table; (b) add a new top-level `## Languages` section between `## Domains` and `## Examples` (matching reading order: core → domains → languages → examples) listing the 4 v0.1 first-principles stubs (typescript.md, python.md, go.md, rust.md — closes pre-existing drift since v0.1, parallel to ESC-002/ATELIER-91) AND the 16 new v0.4 derived docs; section note: "Language docs apply (not derive) domain principles. They introduce no new P-rules and no new matrix rows (D-063, D-066)."; (c) update Cross-Cutting summary line to exactly "19 domains, 190 P-rules post-v0.4" (IDEATE-18, IDEATE-43 carried forward) |
-
-**Verify (P4):**
- Structural: matrix has 19 domain sections (17 v0.1/v0.2/v0.3 + 2 new), exactly 190 P-rules (170 pre-existing verified per G-014 + 20 new; NOT 171 reconciled to 170 — the 171 discrepancy was a false premise corrected by grill G-014); domain-coverage has the per-domain v0.4 table AND the updated C-rule coverage table AND the Languages Coverage sub-table (exactly 16 rows); ARCHITECTURE.md has the v0.4 section + component tree; 3 review docs extended; MANIFEST lists all v0.4 docs + the new Languages section
- Behavioral: every new edge + messaging P-rule has a matrix row; domain-expert verifies no orphans (IDEATE-13 carried forward); Coverage Summary reads "19 domains, 190 P-rules" (IDEATE-18/43); Languages Coverage sub-table has exactly 16 rows — every language-derived doc traced to ≥1 domain P-rule (IDEATE-42, D-066); ARCHITECTURE.md component tree matches the directory tree (IDEATE-32)
- Security: anti-patterns cover all 6 chaos anti-patterns (edge sync-loop/TTL-less/blocking-call; messaging shared-sub/blocking-consumer/unbounded-retry) + edge P9 (shared credential) + messaging P1 (schemaless) + language-derived runtime-artifact (.ts/.py/.go/.rs)
- Quality: MANIFEST is authoritative — every v0.4 file listed, languages/ listed closing pre-existing drift (ATELIER-111 per IDEATE-31); unlisted = not part of framework; agent-checklist + peer-review-checklist have parity across edge + messaging + language-derived (ATELIER-108 ↔ ATELIER-109); matrix row-count test passes (exactly 190, reconciled)
-
-## Phase 5 — Examples + Cross-Links
-
-**Goal:** Add 2 good + 2 bad examples (D-068 — pre-named, highest illustration value) and verify cross-domain links from the 2 new domains + 16 language-derived docs to existing ones, AND edge↔messaging intra-v0.4 links resolve in both directions (IDEATE-40). Examples are markdown with fenced code only (no standalone .ts/.py/.go/.rs artifacts — D-020). Bad examples are single-breach citing the specific breached P-rule (D-068).
-**Branch:** `phase/05-examples-crosslinks` (from `milestone/v0.4-edge-quantum-langs`)
-**Personas:** edge-engineer (edge examples), tech-writer (messaging examples + cross-link audit), domain-expert (P-rule citation + cross-link validation)
-**Tag:** v0.3.5
-**Requirements:** ATELIER-112, ATELIER-113, ATELIER-114
-
-### Wave 1 (parallel — 4 examples, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 05-01-01 | `examples/good/edge-offline-sync.md` | edge-engineer | ATELIER-112 | Good edge example per RESEARCH-v0.4 §Examples: demonstrates offline-first + sync conflict resolution via CRDT or LWW — highest-illustration-value edge case; markdown with fenced code (a CRDT register merge + an offline write queue + a reconnect reconcile); P-rules demonstrated: edge P2 (Offline is a First-Class State), P4 (Sync Conflicts are Bounded), P5 (Idempotent), P10 (local-first telemetry); exercises the `sync.md` CRDT-vs-LWW decision matrix; cross-link to `edge/offline-first.md` + `edge/sync.md`; no runtime artifacts |
-| 05-01-02 | `examples/good/messaging-idempotent-consumer.md` | tech-writer | ATELIER-112 | Good messaging example per RESEARCH-v0.4 §Examples: demonstrates exactly-once-via-idempotency-keys + dedup — highest-illustration-value messaging case; markdown with fenced code (an idempotent consumer with a dedup store + a DLQ routing rule); P-rules demonstrated: messaging P3 (Consumers are Idempotent), P4 (Delivery Semantics Explicit), P5 (Dead-Letter Handling), P10 (Observable); exercises the `delivery-semantics.md` idempotency + DLQ guidance; cross-link to `messaging/delivery-semantics.md` + `messaging/queues.md`; no runtime artifacts |
-| 05-01-03 | `examples/bad/edge-sync-loop.md` | edge-engineer | ATELIER-113 | Bad edge example per RESEARCH-v0.4 §Examples + ATELIER-110: a sync conflict that oscillates/loops forever — the pre-specified edge chaos anti-pattern; **single-breach (D-068): cites edge P4 (Sync Conflicts are Bounded, Not Infinite) breached** — prose explains why it is a livelock, not eventual consistency; markdown with fenced code showing the oscillating sync; cross-link to `edge/sync.md` + `review/anti-patterns.md` (the sync-conflict-loop chaos anti-pattern) |
-| 05-01-04 | `examples/bad/messaging-shared-subscription.md` | tech-writer | ATELIER-113 | Bad messaging example per RESEARCH-v0.4 §Examples + ATELIER-110: a shared subscription causing duplicate processing / fan-out duplication — the pre-specified messaging chaos anti-pattern; **single-breach (D-068): primary breach cited is messaging P2 (Ordering is a Property, Not an Assumption); P3 (Consumers are Idempotent) noted as the compounding consequence — the example remains single-breach in its named violation**; markdown with fenced code showing the shared subscription; cross-link to `messaging/pubsub.md` + `review/anti-patterns.md` (the shared-subscription chaos anti-pattern) |
-
-### Wave 2 (sequential — cross-link audit after all docs exist)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 05-02-01 | Cross-link audit (all new derived docs across edge + messaging + languages) | tech-writer | ATELIER-114 | Per IDEATE-08 (carried forward) + IDEATE-40 (ATELIER-114 refinement): (a) every new derived doc (10 domain derived + 16 language-derived = 26) has ≥1 outbound cross-link to a MANIFEST-listed doc; links resolve; (b) **edge↔messaging intra-v0.4 links resolve in BOTH directions** — every edge→messaging and messaging→edge link resolves by the P6 ship (edge/iot.md → messaging/queues.md MQTT QoS parallels; messaging docs that reference edge where relevant); (c) **language-derived docs link to BOTH new (edge/messaging) and existing domains where relevant** (e.g., ts-async.md → messaging/delivery-semantics; go-concurrency.md → concurrency/patterns + messaging/queues); domain-expert validates the cross-link targets are correct (not just present); no back-link edits to v0.1/v0.2/v0.3 content (D-026 extended — one-directional outward) |
-
-**Verify (P5):**
- Structural: 4 new example files exist (all .md)
- Behavioral: each bad example cites the P-rule breached (edge: P4 single-breach; messaging: P2 primary + P3 consequence, single-breach named violation per D-068); each good example cites the P-rules it demonstrates
- Security: no standalone `.ts`/`.py`/`.go`/`.rs` runtime artifacts (deployable artifact mitigation, IDEATE-36, D-020)
- Quality: all cross-links from the 26 new derived docs resolve to MANIFEST-listed docs; edge↔messaging intra-v0.4 links resolve bidirectionally (IDEATE-40); language-derived docs link to both new + existing domains where relevant (IDEATE-40); no back-link edits to v0.1/v0.2/v0.3 content (D-026 extended)
-
-## Phase 6 — Final Review + Ship (N+1)
-
-**Goal:** Multi-persona review across all v0.4 phases, audit, milestone ship. P6 IS the v0.4 release (NFR → no separate minor tag; v0.3.6 IS the deliverable). Phase-specific personas (edge-engineer, languages-engineer) review their authored content in Wave 1 (D-052 precedent), then are removed in Wave 2 (roster returns to 3 active).
-**Branch:** `phase/06-final-review-ship` (from `milestone/v0.4-edge-quantum-langs`)
-**Personas:** lead-developer (coordinate + ship), domain-expert (review), tech-writer (review), edge-engineer (review edge content, then removed), languages-engineer (review language-derived content, then removed)
-**Tag:** v0.3.6 (IS the v0.4 milestone release — NFR, no separate minor tag)
-**Requirements:** ATELIER-115, ATELIER-116
-
-### Wave 1 — Review (sequential — edge-engineer + languages-engineer review their content per D-052 before removal)
-| Task | Activity | Persona | REQ-ID | Must-have |
-|------|----------|---------|--------|-----------|
-| 06-01-01 | `ciagent-review` — multi-persona review of all v0.4 changes | lead-developer | ATELIER-115 | Auto-apply P0 fixes; flag P1+ for post-hoc; if P1+ found, fix in this phase; **edge-engineer reviews edge domain content (D-061 boundary — proximity/location angle, not generic perf/concurrency)**; **languages-engineer reviews language-derived content (D-063 apply-don't-derive scope check — no new P-rules, no P1–P10 numbering, every section traces to a domain P-rule)**; tech-writer + domain-expert review messaging content (D-062 boundary — cross-process/network-failure-model); domain-expert verifies all 20 new P-rules (10 edge + 10 messaging) trace to ≥1 C-rule (no orphans) AND the 16 Languages Coverage sub-table rows match the derived docs' actual section-header traces (IDEATE-42) |
-| 06-01-02 | `ciagent-audit` — reconstruction + discipline | lead-developer | ATELIER-115 | git log matches .ciagent/ files; branch hygiene; commit discipline (every commit has `---ci---` block with `project: atelier`); MANIFEST reconstruction test (every listed doc exists, every existing doc is listed — incl. the new Languages section per ATELIER-111); **matrix row-count test: exactly 190 P-rows (10 per domain × 19 — the pre-existing count was exactly 170 per grill G-014 verification; the IDEATE-34 "171-vs-170 discrepancy" was a false premise, corrected — verify 170 + 20 = 190, NOT 171 + 20)**; ARCHITECTURE.md component-tree test (matches directory tree per ATELIER-117/IDEATE-32) |
-
-### Wave 2 — Ship (sequential — after review; phase-specific personas removed)
-| Task | Activity | Persona | REQ-ID | Must-have |
-|------|----------|---------|--------|-----------|
-| 06-02-01 | `ciagent-ship` — milestone ship | lead-developer | ATELIER-116 | Merge `phase/06` → `milestone/v0.4-edge-quantum-langs` → `main`; tag `v0.3.6`; Gitea release with full milestone summary; delete all v0.4 branches (tags preserve history) |
-| 06-02-02 | Complete milestone (REQUIREMENTS + ROADMAP + PERSONAS) | lead-developer | ATELIER-116 | Mark all v0.4 requirements (ATELIER-92..117) `covered`; ROADMAP v0.4 → complete; **PERSONAS: remove edge-engineer + languages-engineer (roster returns to 3 active per D-067)**; clear checkpoint |
-
-**Verify (P6):**
- Structural: all 26 v0.4 requirements (ATELIER-92..117) marked covered
- Behavioral: reconstruction test passes (git log ↔ .ciagent/); matrix row-count test passes (exactly 190 — reconciled per IDEATE-34); MANIFEST reconstruction test passes (incl. Languages section); ARCHITECTURE.md component-tree test passes (per ATELIER-117/IDEATE-32)
- Security: audit clean (no critical issues); no standalone runtime artifacts (`.ts`/`.py`/`.go`/`.rs` forbidden per D-020); no new P-rules in language-derived docs (D-063); edge/messaging boundaries respected (D-061/D-062)
- Quality: milestone merged to main, tag v0.3.6 exists, all v0.4 branches deleted; edge-engineer + languages-engineer personas removed (roster = 3 active per D-067)
-
-## v0.4 Wave Ordering Summary
-
-| Phase | Waves | Parallelism |
-|-------|-------|-------------|
-| P0 | (pre-exec) | Sequential stages (specify→clarify→research→ideate→plan→grill) — COMPLETE |
-| P1 | 2 | Wave 1 sequential (first-principles), Wave 2 parallel (4 derived docs) |
-| P2 | 2 | Wave 1 sequential (first-principles), Wave 2 parallel (4 derived docs) |
-| P3 | 2 | Wave 1 parallel (4 stubs extended), Wave 2 parallel (16 derived docs — 2a TS + 2b Python + 2c Go + 2d Rust, capped at 5 concurrent) |
-| P4 | 3 | Wave 1 sequential (matrix → coverage → ARCHITECTURE.md), Wave 2 parallel (3 review docs), Wave 3 sequential (MANIFEST after review docs settled) |
-| P5 | 2 | Wave 1 parallel (4 examples), Wave 2 sequential (cross-link audit) |
-| P6 | 2 | Wave 1 sequential (review → audit), Wave 2 sequential (ship → complete) |
-
-## v0.4 Requirements → Phase Mapping
-
-| Phase | Requirements | Count |
-|-------|-------------|-------|
-| 1 | ATELIER-92..96 | 5 |
-| 2 | ATELIER-97..101 | 5 |
-| 3 | ATELIER-102..105 | 4 |
-| 4 | ATELIER-106, 107, 117, 108, 109, 110, 111 | 7 |
-| 5 | ATELIER-112, 113, 114 | 3 |
-| 6 | ATELIER-115, 116 | 2 |
-| **Total** | | **26** |
-
-## v0.4 Ideation Refinements → Task Bake-In Map
-
-All 12 accepted ideation refinements (IDEATE-31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43) + the 1 new requirement (IDEATE-32 → ATELIER-117) are baked into the relevant phase tasks as explicit must-have notes (parallel to v0.3's Refinements Notes → Task Bake-In Map):
-
-| IDEATE-ID | Refinement | Baked Into Task(s) | How |
-|-----------|-----------|-------------------|-----|
-| IDEATE-31 | MANIFEST Languages section lists 4 v0.1 stubs + 16 derived docs (refines ATELIER-111) | 04-03-01 | MANIFEST gains `## Languages` section between `## Domains` and `## Examples`; lists 4 stubs (closes pre-existing drift since v0.1, parallel to ESC-002/ATELIER-91) + 16 derived docs |
-| IDEATE-32 | ARCHITECTURE.md v0.4 update (new req ATELIER-117) | 04-01-03 | ARCHITECTURE.md gains `## v0.4 Domain Additions` section + component tree entries for edge/messaging/languages-derived; closes architecture-tree drift |
-| IDEATE-33 | Core Principle Coverage C1–C8 → domains table update for edge + messaging (refines ATELIER-107) | 04-01-02 | domain-coverage.md C-rule coverage table extended (C4 +edge P1/P8 +messaging P7; C5 +edge P2/P4/P7/P10 +messaging P5/P8/P9; C7 +edge P10 +messaging P8/P10; C8 +edge P3/P9 +messaging P6; C2 +messaging P1/P2/P4) |
-| IDEATE-34 | Matrix post-v0.4 = exactly 190; verify current 170 (corrected per G-014 — the "171 vs 170" claim was a false premise; matrix has exactly 170) (refines ATELIER-106) | 04-01-01, 06-01-02 | P4 verifies 170 exists before appending 20 rows; P6 audit verifies exactly 190 (10 × 19). Do NOT hunt for/delete a phantom 171st row |
-| IDEATE-35 | streams.md + delivery-semantics.md comparison tables required (refines ATELIER-100, 101) | 02-02-03, 02-02-04 | streams.md stream-platform comparison (Kafka/Kinesis/Pulsar); delivery-semantics.md dead-letter strategy comparison |
-| IDEATE-36 | Language-derived-doc anti-patterns + .ts/.py/.go/.rs artifact-type extension (refines ATELIER-110) | 04-02-03 | anti-patterns.md gains language-derived anti-patterns (new P-rule, orphan section, runtime artifact, P1–P10 numbering) + v0.4 artifact types table extended to .ts/.py/.go/.rs |
-| IDEATE-37 | All 6 RESEARCH chaos anti-patterns (refines ATELIER-110) | 04-02-03 | anti-patterns.md includes all 6: edge sync-loop/TTL-less/blocking-call; messaging shared-sub/blocking-consumer/unbounded-retry (not just the 4 named in req-row text) |
-| IDEATE-38 | offline-first.md maps offline write-queue to testing pyramid tiers (refines ATELIER-94) | 01-02-02 | offline-first.md maps unit (conflict detection on merge function), integration (reconnect reconcile vs local store), e2e (partition simulation with fake network) |
-| IDEATE-39 | delivery-semantics.md fenced idempotency-key dedup-store example (refines ATELIER-101) | 02-02-04 | delivery-semantics.md includes a fenced consumer-with-dedup-store (not prose-only) — parallel to v0.3 IDEATE-29 signed-attestation |
-| IDEATE-40 | P5 cross-link audit verifies edge↔messaging intra-v0.4 links both directions (refines ATELIER-114) | 05-02-01 | Cross-link audit checks edge→messaging AND messaging→edge links resolve; language-derived docs link to both new + existing domains where relevant |
-| IDEATE-41 | streams.md enumerates consumer-group rebalance strategies (refines ATELIER-100) | 02-02-03 | streams.md enumerates sticky/cooperative/eager — each with partition-stop-the-world cost + use-case fit (parallel to v0.3 IDEATE-30 drift-type enumeration) |
-| IDEATE-42 | Languages Coverage sub-table = exactly 16 rows (refines ATELIER-107) | 04-01-02, 06-01-01 | domain-coverage.md gains `## Languages Coverage` sub-table with exactly 16 rows; P6 review verifies the 16 rows match the derived docs' actual section-header traces |
-| IDEATE-43 | MANIFEST Cross-Cutting summary = "19 domains, 190 P-rules post-v0.4" (refines ATELIER-111) | 04-03-01 | MANIFEST Cross-Cutting summary line updates to exactly "19 domains, 190 P-rules post-v0.4" (IDEATE-18 carried forward) |
-
-## v0.4 Decisions Logged (planning stage)
-
-| ID | Decision | Rationale | Confidence |
-|----|----------|-----------|------------|
-| D-070 | P3 Wave 2 splits into 2a/2b/2c/2d labels (by language) but all are the same dependency tier | 16 derived docs are all independent post-Wave-1; the 2a/2b/2c/2d labels organize by language, the executor schedules ≤5 concurrent per config.json. Avoids inventing a false dependency between languages (parallel to v0.3 D-049 i18n/compliance 2a/2b split) | 0.88 |
-| D-071 | P4 splits into 3 waves: matrix+coverage+ARCHITECTURE (Wave 1 sequential), review docs (Wave 2 parallel), MANIFEST (Wave 3 sequential after review docs settled) | Matrix is the arbiter (must be authoritative first per v0.2/v0.3 precedent); ARCHITECTURE.md follows coverage so the component tree reflects the matrix; review docs are independent of each other; MANIFEST lists file paths and totals, sequenced after anti-patterns content is settled (D-050 precedent — anti-patterns + manifest combine under lead-developer). Net 3 waves, respecting that ARCHITECTURE.md (ATELIER-117) is a new v0.4 deliverable that must follow the matrix/coverage extension | 0.83 |
-| D-072 | P6 splits into 2 waves: review (Wave 1 — edge-engineer + languages-engineer review their content per D-052 before removal), ship (Wave 2 — tag + merge + remove personas) | Phase-specific personas review their authored content one final time in Wave 1 (D-052 precedent — ensures D-061 edge boundary and D-063 apply-don't-derive are checked by the specialist), then are removed in Wave 2 (roster returns to 3 per D-067). Separating review from ship ensures the specialist review completes before the personas are deactivated | 0.84 |
-
-## Assumptions Logged
-
-| # | Assumption | Confidence |
-|---|-----------|------------|
-| A-006 | The pre-existing matrix has exactly 170 P-rows (verified by grill G-014 direct count); appending 20 yields exactly 190 with no reconciliation needed. The IDEATE-34 "171-vs-170 discrepancy" was a false premise corrected by the grill (parallel to v0.3's matrix-extension assumption A-002) | 0.88 |
-| A-007 | The 4 new domain P-rules (edge + messaging) map to existing core C1–C8 without needing new core principles (core is stable at 8 — carried forward from A-002) | 0.95 |
-| A-008 | Wave 2 of P3 (16 derived docs) can be scheduled by the executor as 5-then-5-then-5-then-1 without a hard sub-wave barrier (carried forward from v0.3 A-003) | 0.90 |
-| A-009 | The Languages Coverage sub-table's 16 rows can be authored in P4 from the P3 derived docs' actual section-header traces (the RESEARCH-v0.4 sketch is the expected trace set; finalized when the derived docs are authored) | 0.85 |
-| A-010 | The edge↔messaging intra-milestone cross-links (edge/iot.md → messaging/queues.md) dangle at the P1 tag (v0.3.1) and resolve once P2 ships (v0.3.2); this is acceptable per D-053 vertical-slice integrity and verified bidirectionally in P5 (IDEATE-40) | 0.86 |
-
-## Milestone Type: NFR
-
-Per branch-strategy.md, this is an NFR milestone (all phases are docs/chore — no `feat` code). NFR milestones produce progressive patches; the final patch (v0.3.6) IS the v0.4 deliverable. No separate minor tag.
@@ -164,11 +164,6 @@ NFR milestone: no separate minor tag. The final patch (v0.2.6) IS the v0.3 deliv
 | D-046 | i18n testing-i18n.md must map pseudo-locale testing to testing pyramid tiers | Avoids generic "test i18n" guidance; maps to unit (missing-key), integration (snapshot per locale), e2e (RTL coverage) | 0.78 |
 | D-047 | compliance evidence.md must include a fenced signed-attestation example (Cosign or in-toto) | Prose-only evidence guidance is weak; a fenced example demonstrates the principle concretely (P6 Evidence Collected Continuously) | 0.80 |
 | D-048 | ai-ml monitoring-drift.md must enumerate 3 drift types (data/concept/prediction) with a detection signal per type | Avoids conflating drift types; each has distinct detection signals and retraining triggers | 0.82 |
-| D-049 | P3 splits Wave 2 into 2a (i18n) + 2b (compliance) labels but both are the same dependency tier | 8 derived docs are all independent post-Wave-1; 2a/2b labels organize by domain, executor schedules ≤5 concurrent per config.json. Avoids inventing a false dependency between i18n and compliance | 0.88 |
-| D-050 | P4 Wave 2 runs exactly 5 concurrent tasks (at the max_concurrent_agents cap) | matrix, coverage, agent-checklist, peer-review-checklist, anti-patterns, manifest = 6 extensions, but anti-patterns (04-02-04) and manifest (04-02-05) are combined under lead-developer for manifest to sequence after anti-patterns content is settled. Net 5 concurrent slots | 0.82 |
-| D-051 | P5 ai-ml-reproducibility.md example authored by tech-writer with ml-engineer consultation (not ml-engineer primary) | ml-engineer is removed after P2 per PERSONAS.md; P5 examples are tech-writer territory. ml-engineer constraints are baked into the task must-have (P1/P2/P3/P5 demonstrated) so the constraint survives the persona | 0.80 |
-| D-052 | P6 review uses platform-engineer + ml-engineer for content review before removal | Phase-specific personas review their authored content one final time in P6 Wave 1, then are removed in 06-01-04. Ensures D-023 (ai-ml scope) and GitOps correctness are checked by the specialist before the roster returns to 3 | 0.84 |
-| D-053 | Vertical-slice integrity: each phase is independently shippable | P1 ships gitops-operators domain docs (matrix rows land in P4 — acceptable because the domain is self-consistent; matrix extension is the traceability closure, not a blocker for the domain's internal consistency). P3 ships 2 domains together (D-022). P4 closes traceability + manifest. P5 closes examples + cross-links. P6 ships the release | 0.86 |

 ## Cross-Project References

@@ -177,51 +172,4 @@ None yet. Atelier is a standalone docs framework.
 ## Milestone History

 - **v0.1** — Initial Framework (COMPLETE). 8 core principles, 11 domains, 110 domain principles, full matrix, 4+3 examples, 4 languages. Tag v0.0.7.
- **v0.2** — Infrastructure as Code + Kubernetes (COMPLETE). Adds 2 domains (20 new P-rules), matrix/review/examples integration. Tags v0.1.0–v0.1.5; v0.1.5 is the v0.2 release.
- **v0.3** — GitOps + Operators + AI/ML + i18n + Compliance (COMPLETE). Adds 4 domains (40 new P-rules), matrix 130→170 across 13→17 domains, review/checklist/anti-patterns integration, 4 new examples, MANIFEST examples/ listing (closes ESC-002). Tags v0.2.0–v0.2.6; v0.2.6 is the v0.3 release.
- **v0.4** — Edge + Messaging + Language-Derived Docs (ACTIVE). Adds 2 new top-level domains (edge, messaging — 20 new P-rules), and extends `languages/` with derived docs per language (typescript, python, go, rust). Matrix 170→190 across 17→19 domains; review/checklist/anti-patterns extended; 4 new examples; MANIFEST gains a `languages/` section. Tags v0.3.0–v0.3.N; final patch IS the v0.4 deliverable.
-
-## v0.4 — Edge + Messaging + Language-Derived Docs
-
-**Milestone type:** NFR (all phases produce docs — no `feat` runtime code)
-**Tag line:** v0.3.x (previous minor from v0.4)
-**Scope:** Extend the domain tree with two new top-level domains covering edge computing and messaging systems, plus extend `languages/` from first-principles-only stubs to full derived-doc trees. All content is docs-only markdown with illustrative code fences; no runtime/deployable artifacts. Closes the "Future Milestones" candidates in the v0.3 ROADMAP (edge domain + language-specific derived docs).
-
-### New Domains
-
- `domains/edge/` — edge computing domain (latency-bound, resource-constrained, geo-distributed)
-  - `first-principles.md` — 10 edge principles (P1–P10)
-  - Derived: `cdn.md`, `offline-first.md`, `iot.md`, `sync.md`
- `domains/messaging/` — messaging systems domain (async, queues, streams, pub/sub)
-  - `first-principles.md` — 10 messaging principles (P1–P10)
-  - Derived: `queues.md`, `pubsub.md`, `streams.md`, `delivery-semantics.md`
-
-### Language-Derived Extension
-
-Extend each `languages/*.md` from a single first-principles stub to a full derived-doc tree mirroring the domain structure (parallel to how `domains/` have first-principles + derived). Each language gets derived docs for the most-relevant domains (4 derived docs per language = 16 total), traced to that language's P-rules and to core C-rules.
-
- `languages/typescript.md` (existing first-principles) + derived: `ts-types.md`, `ts-tooling.md`, `ts-async.md`, `ts-testing.md`
- `languages/python.md` + derived: `py-types.md`, `py-tooling.md`, `py-async.md`, `py-testing.md`
- `languages/go.md` + derived: `go-types.md`, `go-tooling.md`, `go-concurrency.md`, `go-testing.md`
- `languages/rust.md` + derived: `rs-ownership.md`, `rs-tooling.md`, `rs-async.md`, `rs-testing.md`
-
-### Cross-Domain Integration
-
- Extend `matrix/principles-matrix.md` with 20 new P-rules → core C-rule mappings (10 per new domain; the language-derived docs trace to existing domain P-rules, not new matrix rows)
- Extend `matrix/domain-coverage.md` with edge + messaging (row schema unchanged); add a `languages/` coverage sub-table listing each language's derived docs and the domains they trace to
- Extend `review/agent-checklist.md`, `review/peer-review-checklist.md`, and `review/anti-patterns.md` with edge + messaging sections + a language-derived-docs section
- Update `MANIFEST.md` with (a) the 2 new domains, (b) a new `languages/` section listing each language's first-principles + derived docs, (c) post-v0.4 totals (19 domains, 190 P-rules)
- New examples (good + bad): `examples/good/edge-offline-sync.md`, `examples/good/messaging-idempotent-consumer.md`, `examples/bad/edge-sync-loop.md`, `examples/bad/messaging-shared-subscription.md`
- Cross-links from new domains to existing `devops/`, `observability/`, `data/`, `concurrency/`, `kubernetes/`, `infrastructure-as-code/` domains; cross-links from language-derived docs to their traced domain docs
-
-### Phase Plan (proposed, finalized in PLAN)
-
- P0 Pre-Execution: spec, clarify, research, ideate, plan, grill
- P1 Edge domain
- P2 Messaging domain
- P3 Language-Derived Extension (16 derived docs across 4 languages)
- P4 Matrix + Review Integration (20 new mappings, manifest languages/ section, checklist parity)
- P5 Examples + Cross-Links
- P6 Final Review + Ship (IS the v0.4 release → tag v0.3.6)
-
-NFR milestone: no separate minor tag. The final patch (v0.3.6) IS the v0.4 deliverable.
+- **v0.2** — Infrastructure as Code + Kubernetes (COMPLETE). Adds 2 domains (20 new P-rules), matrix/review/examples integration. Tags v0.1.0–v0.1.5; v0.1.5 is the v0.2 release.
@@ -133,38 +133,38 @@ All 35 requirements covered. 8 core principles, 11 domains, 110 domain principle

 | REQ-ID | Requirement | Priority | Phase | Status |
 |--------|-------------|----------|-------|--------|
-| ATELIER-60 | `domains/gitops-operators/first-principles.md` — 10 GitOps/operator principles (P1–P10) | P0 | 1 | covered |
-| ATELIER-61 | `domains/gitops-operators/argocd.md` — ArgoCD derived doc | P1 | 1 | covered |
-| ATELIER-62 | `domains/gitops-operators/flux.md` — Flux derived doc | P1 | 1 | covered |
-| ATELIER-63 | `domains/gitops-operators/operators.md` — Kubernetes Operators derived doc | P1 | 1 | covered |
-| ATELIER-64 | `domains/gitops-operators/progressive-delivery.md` — progressive delivery derived doc | P1 | 1 | covered |
-| ATELIER-65 | `domains/ai-ml/first-principles.md` — 10 AI/ML principles (P1–P10) | P0 | 2 | covered |
-| ATELIER-66 | `domains/ai-ml/data-versioning.md` — data/model versioning derived doc | P1 | 2 | covered |
-| ATELIER-67 | `domains/ai-ml/model-evaluation.md` — evaluation derived doc | P1 | 2 | covered |
-| ATELIER-68 | `domains/ai-ml/serving.md` — model serving derived doc | P1 | 2 | covered |
-| ATELIER-69 | `domains/ai-ml/monitoring-drift.md` — monitoring/drift derived doc | P1 | 2 | covered |
-| ATELIER-70 | `domains/i18n/first-principles.md` — 10 i18n principles (P1–P10) | P0 | 3 | covered |
-| ATELIER-71 | `domains/i18n/locale-resources.md` — locale resource management derived doc | P1 | 3 | covered |
-| ATELIER-72 | `domains/i18n/formatting.md` — formatting (dates/numbers/units) derived doc | P1 | 3 | covered |
-| ATELIER-73 | `domains/i18n/rtl-bidi.md` — RTL/bidi layout derived doc | P1 | 3 | covered |
-| ATELIER-74 | `domains/i18n/testing-i18n.md` — i18n testing derived doc | P1 | 3 | covered |
-| ATELIER-75 | `domains/compliance/first-principles.md` — 10 compliance principles (P1–P10) | P0 | 3 | covered |
-| ATELIER-76 | `domains/compliance/audit-logs.md` — audit logging derived doc | P1 | 3 | covered |
-| ATELIER-77 | `domains/compliance/data-retention.md` — data retention derived doc | P1 | 3 | covered |
-| ATELIER-78 | `domains/compliance/policy-as-code.md` — policy-as-code derived doc | P1 | 3 | covered |
-| ATELIER-79 | `domains/compliance/evidence.md` — evidence collection derived doc | P1 | 3 | covered |
-| ATELIER-80 | Extend `matrix/principles-matrix.md` with 40 new P-rules → core C-rule mappings (10 per new domain; review check: row count per domain = 10, each row ≥1 C-rule) | P0 | 4 | covered |
-| ATELIER-81 | Extend `matrix/domain-coverage.md` with gitops-operators, ai-ml, i18n, compliance (row schema: domain, P-count, derived-doc-count, manifest-listed, status) | P1 | 4 | covered |
-| ATELIER-82 | Extend `review/agent-checklist.md` with 4 new domain trigger sections | P1 | 4 | covered |
-| ATELIER-83 | Extend `review/peer-review-checklist.md` with 4 new domain sections (parity with agent-checklist) | P1 | 4 | covered |
-| ATELIER-84 | Extend `review/anti-patterns.md` with 4 new domain violations incl. orphaned P-rule + deployable example artifact | P1 | 4 | covered |
-| ATELIER-85 | Update `MANIFEST.md` to list all new v0.3 documents (manifest authoritative) | P0 | 4 | covered |
-| ATELIER-86 | `examples/good/gitops-pr.md` + `examples/good/ai-ml-reproducibility.md` — 2 good examples (markdown with fenced code only) | P2 | 5 | covered |
-| ATELIER-87 | `examples/bad/i18n-string-concat.md` + `examples/bad/compliance-audit-log.md` — 2 named bad examples (each cites the P-rule breached) | P2 | 5 | covered |
-| ATELIER-88 | Cross-links from new domains to existing devops/security/observability/data/kubernetes/infrastructure-as-code domains (review check: every new derived doc ≥1 outbound cross-link to a MANIFEST-listed doc) | P1 | 5 | covered |
-| ATELIER-89 | Final review passes (all v0.3 phases reviewed, audit clean) | P0 | 6 | covered |
-| ATELIER-90 | Milestone v0.3 released (tag v0.2.6, merged to main) | P0 | 6 | covered |
-| ATELIER-91 | Add `examples/` directory listing to `MANIFEST.md` (pre-existing drift from v0.2 audit escalation ESC-002 note: examples/ unlisted; manifest is authoritative) | P1 | 4 | covered |
+| ATELIER-60 | `domains/gitops-operators/first-principles.md` — 10 GitOps/operator principles (P1–P10) | P0 | 1 | pending |
+| ATELIER-61 | `domains/gitops-operators/argocd.md` — ArgoCD derived doc | P1 | 1 | pending |
+| ATELIER-62 | `domains/gitops-operators/flux.md` — Flux derived doc | P1 | 1 | pending |
+| ATELIER-63 | `domains/gitops-operators/operators.md` — Kubernetes Operators derived doc | P1 | 1 | pending |
+| ATELIER-64 | `domains/gitops-operators/progressive-delivery.md` — progressive delivery derived doc | P1 | 1 | pending |
+| ATELIER-65 | `domains/ai-ml/first-principles.md` — 10 AI/ML principles (P1–P10) | P0 | 2 | pending |
+| ATELIER-66 | `domains/ai-ml/data-versioning.md` — data/model versioning derived doc | P1 | 2 | pending |
+| ATELIER-67 | `domains/ai-ml/model-evaluation.md` — evaluation derived doc | P1 | 2 | pending |
+| ATELIER-68 | `domains/ai-ml/serving.md` — model serving derived doc | P1 | 2 | pending |
+| ATELIER-69 | `domains/ai-ml/monitoring-drift.md` — monitoring/drift derived doc | P1 | 2 | pending |
+| ATELIER-70 | `domains/i18n/first-principles.md` — 10 i18n principles (P1–P10) | P0 | 3 | pending |
+| ATELIER-71 | `domains/i18n/locale-resources.md` — locale resource management derived doc | P1 | 3 | pending |
+| ATELIER-72 | `domains/i18n/formatting.md` — formatting (dates/numbers/units) derived doc | P1 | 3 | pending |
+| ATELIER-73 | `domains/i18n/rtl-bidi.md` — RTL/bidi layout derived doc | P1 | 3 | pending |
+| ATELIER-74 | `domains/i18n/testing-i18n.md` — i18n testing derived doc | P1 | 3 | pending |
+| ATELIER-75 | `domains/compliance/first-principles.md` — 10 compliance principles (P1–P10) | P0 | 3 | pending |
+| ATELIER-76 | `domains/compliance/audit-logs.md` — audit logging derived doc | P1 | 3 | pending |
+| ATELIER-77 | `domains/compliance/data-retention.md` — data retention derived doc | P1 | 3 | pending |
+| ATELIER-78 | `domains/compliance/policy-as-code.md` — policy-as-code derived doc | P1 | 3 | pending |
+| ATELIER-79 | `domains/compliance/evidence.md` — evidence collection derived doc | P1 | 3 | pending |
+| ATELIER-80 | Extend `matrix/principles-matrix.md` with 40 new P-rules → core C-rule mappings (10 per new domain; review check: row count per domain = 10, each row ≥1 C-rule) | P0 | 4 | pending |
+| ATELIER-81 | Extend `matrix/domain-coverage.md` with gitops-operators, ai-ml, i18n, compliance (row schema: domain, P-count, derived-doc-count, manifest-listed, status) | P1 | 4 | pending |
+| ATELIER-82 | Extend `review/agent-checklist.md` with 4 new domain trigger sections | P1 | 4 | pending |
+| ATELIER-83 | Extend `review/peer-review-checklist.md` with 4 new domain sections (parity with agent-checklist) | P1 | 4 | pending |
+| ATELIER-84 | Extend `review/anti-patterns.md` with 4 new domain violations incl. orphaned P-rule + deployable example artifact | P1 | 4 | pending |
+| ATELIER-85 | Update `MANIFEST.md` to list all new v0.3 documents (manifest authoritative) | P0 | 4 | pending |
+| ATELIER-86 | `examples/good/gitops-pr.md` + `examples/good/ai-ml-reproducibility.md` — 2 good examples (markdown with fenced code only) | P2 | 5 | pending |
+| ATELIER-87 | `examples/bad/i18n-string-concat.md` + `examples/bad/compliance-audit-log.md` — 2 named bad examples (each cites the P-rule breached) | P2 | 5 | pending |
+| ATELIER-88 | Cross-links from new domains to existing devops/security/observability/data/kubernetes/infrastructure-as-code domains (review check: every new derived doc ≥1 outbound cross-link to a MANIFEST-listed doc) | P1 | 5 | pending |
+| ATELIER-89 | Final review passes (all v0.3 phases reviewed, audit clean) | P0 | 6 | pending |
+| ATELIER-90 | Milestone v0.3 released (tag v0.2.6, merged to main) | P0 | 6 | pending |
+| ATELIER-91 | Add `examples/` directory listing to `MANIFEST.md` (pre-existing drift from v0.2 audit escalation ESC-002 note: examples/ unlisted; manifest is authoritative) | P1 | 4 | pending |

 ## v0.3 Traceability Matrix

@@ -230,166 +230,4 @@ All 35 requirements covered. 8 core principles, 11 domains, 110 domain principle
 | IDEATE-03 (domain-coverage row schema) | ATELIER-81 + IDEATE-19 extend with C-rule coverage table update | ✓ extended |
 | IDEATE-07 (named bad examples cite P-rule breached) | ATELIER-87 + IDEATE-26 refine (two-breach example) | ✓ extended |
 | IDEATE-10/11/12 (decision/comparison tables) | IDEATE-21/22/23 transfer the pattern to 3 v0.3 derived docs | ✓ transferred |
-| v0.2 audit ESC-002 note (examples/ not in MANIFEST) | IDEATE-17 → ATELIER-91 | ✓ addressed |
-
-## v0.4 Requirements — Edge + Messaging + Language-Derived Docs
-
-**Milestone type:** NFR (all phases produce docs)
-**Tag line:** v0.3.x (previous minor from v0.4)
-
-| REQ-ID | Requirement | Priority | Phase | Status |
-|--------|-------------|----------|-------|--------|
-| ATELIER-92 | `domains/edge/first-principles.md` — 10 edge principles (P1–P10) | P0 | 1 | pending |
-| ATELIER-93 | `domains/edge/cdn.md` — CDN/edge-cache derived doc (with edge-cache vs origin decision matrix) | P1 | 1 | pending |
-| ATELIER-94 | `domains/edge/offline-first.md` — offline-first derived doc | P1 | 1 | pending |
-| ATELIER-95 | `domains/edge/iot.md` — constrained-device/IoT derived doc | P1 | 1 | pending |
-| ATELIER-96 | `domains/edge/sync.md` — conflict/sync derived doc (CRDT/last-write-win decision matrix) | P1 | 1 | pending |
-| ATELIER-97 | `domains/messaging/first-principles.md` — 10 messaging principles (P1–P10) | P0 | 2 | pending |
-| ATELIER-98 | `domains/messaging/queues.md` — queue derived doc (with at-least-once/at-most-once/exactly-once comparison) | P1 | 2 | pending |
-| ATELIER-99 | `domains/messaging/pubsub.md` — pub/sub derived doc | P1 | 2 | pending |
-| ATELIER-100 | `domains/messaging/streams.md` — stream processing derived doc | P1 | 2 | pending |
-| ATELIER-101 | `domains/messaging/delivery-semantics.md` — delivery semantics derived doc (idempotency, ordering, dead-letter) | P1 | 2 | pending |
-| ATELIER-102 | `languages/typescript.md` extended + `languages/ts-types.md`, `ts-tooling.md`, `ts-async.md`, `ts-testing.md` — 4 TS derived docs | P1 | 3 | pending |
-| ATELIER-103 | `languages/python.md` extended + `languages/py-types.md`, `py-tooling.md`, `py-async.md`, `py-testing.md` — 4 Python derived docs | P1 | 3 | pending |
-| ATELIER-104 | `languages/go.md` extended + `languages/go-types.md`, `go-tooling.md`, `go-concurrency.md`, `go-testing.md` — 4 Go derived docs | P1 | 3 | pending |
-| ATELIER-105 | `languages/rust.md` extended + `languages/rs-ownership.md`, `rs-tooling.md`, `rs-async.md`, `rs-testing.md` — 4 Rust derived docs | P1 | 3 | pending |
-| ATELIER-106 | Extend `matrix/principles-matrix.md` with 20 new P-rules → core C-rule mappings (10 per new domain; review check: row count per domain = 10, each row ≥1 C-rule) — post-v0.4: 19 domains, 190 P-rules | P0 | 4 | pending |
-| ATELIER-107 | Extend `matrix/domain-coverage.md` with edge + messaging (per-domain row schema) + add `languages/` coverage sub-table (language → derived docs → traced domains) | P1 | 4 | pending |
-| ATELIER-108 | Extend `review/agent-checklist.md` with edge + messaging trigger sections + a language-derived-docs section | P1 | 4 | pending |
-| ATELIER-109 | Extend `review/peer-review-checklist.md` with edge + messaging + language-derived sections (parity with agent-checklist) | P1 | 4 | pending |
-| ATELIER-110 | Extend `review/anti-patterns.md` with edge + messaging violations incl. orphaned P-rule + deployable example artifact; pre-specify domain chaos anti-patterns (edge: sync conflict loop, TTL-less cache; messaging: shared subscription, blocking consumer) | P1 | 4 | pending |
-| ATELIER-111 | Update `MANIFEST.md` to list new v0.4 domains + new `languages/` section (first-principles + derived docs per language) + post-v0.4 totals | P0 | 4 | pending |
-| ATELIER-112 | `examples/good/edge-offline-sync.md` + `examples/good/messaging-idempotent-consumer.md` — 2 good examples (markdown with fenced code only) | P2 | 5 | pending |
-| ATELIER-113 | `examples/bad/edge-sync-loop.md` + `examples/bad/messaging-shared-subscription.md` — 2 named bad examples (each cites the P-rule breached) | P2 | 5 | pending |
-| ATELIER-114 | Cross-links from new domains to existing devops/observability/data/concurrency/kubernetes/infrastructure-as-code domains; cross-links from language-derived docs to their traced domain docs (review check: every new derived doc ≥1 outbound cross-link to a MANIFEST-listed doc) | P1 | 5 | pending |
-| ATELIER-115 | Final review passes (all v0.4 phases reviewed, audit clean) | P0 | 6 | pending |
-| ATELIER-116 | Milestone v0.4 released (tag v0.3.6, merged to main) | P0 | 6 | pending |
-| ATELIER-117 | Update `ARCHITECTURE.md` for v0.4 — extend the component tree with `edge/` + `messaging/` domain entries, add a `## v0.4 Domain Additions` section documenting the two new domains (boundary per D-061/D-062, derived docs, cross-link targets), and note the `languages/` derived-doc extension (D-063 apply-don't-derive). Closes architecture-tree drift: the file currently stops at v0.3 with no edge/messaging/languages-derived coverage (IDEATE-32). | P1 | 4 | pending |
-
-## v0.4 Traceability Matrix
-
-| Phase | Requirements |
-|-------|-------------|
-| 0 (Pre-Execution) | (governance: spec, clarify, research, ideate, plan) |
-| 1 (Edge Domain) | ATELIER-92..ATELIER-96 |
-| 2 (Messaging Domain) | ATELIER-97..ATELIER-101 |
-| 3 (Language-Derived Extension) | ATELIER-102..ATELIER-105 |
-| 4 (Matrix + Review Integration) | ATELIER-106..ATELIER-111, ATELIER-117 |
-| 5 (Examples + Cross-Links) | ATELIER-112..ATELIER-114 |
-| 6 (Final Review + Ship) | ATELIER-115, ATELIER-116 |
-
-## v0.4 Ideation Log
-
-**Generated:** 13 ideas (mechanical: 8, backend-enriched: 5)
-**Accepted:** 13 (all v0.4-scope, confidence ≥ 0.79, above 0.6 autonomy threshold → auto-accepted)
-**Skipped:** 0
-**New requirements added:** 1 (ATELIER-117 — ARCHITECTURE.md v0.4 update, from IDEATE-32)
-**Refinements to existing reqs:** 12 (IDEATE-31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43)
-**Deferred to v0.5:** 0
-**Rejected:** 0
-
-| IDEATE-ID | Source | Category | Confidence | Decision | Mapped REQ |
-|-----------|--------|----------|------------|----------|------------|
-| IDEATE-31 | mechanical (MANIFEST drift, parallel to ESC-002) | drift | 0.86 | accepted → refines | ATELIER-111 (languages/ section must list 4 v0.1 stubs + 16 derived docs) |
-| IDEATE-32 | mechanical (ARCHITECTURE.md vs directory tree) | drift | 0.88 | accepted → new req | ATELIER-117 (update ARCHITECTURE.md for v0.4: component tree + v0.4 section) |
-| IDEATE-33 | mechanical (IDEATE-19 pattern transfer) | coverage | 0.90 | accepted → refines | ATELIER-107 (Core Principle Coverage C1–C8 → domains table update for edge + messaging) |
-| IDEATE-34 | mechanical (matrix row-count invariant) | drift | 0.82 | accepted → refines | ATELIER-106 (verify post-v0.4 = exactly 190; verify current = exactly 170 per grill G-014 — the "171 vs 170" claim was a false premise, corrected) |
-| IDEATE-35 | mechanical (D-069 vs req-row text) | spec | 0.89 | accepted → refines | ATELIER-100, ATELIER-101 (req text must reference streams + dead-letter comparison tables) |
-| IDEATE-36 | mechanical (RESEARCH anti-patterns vs ATELIER-110 text) | quality | 0.85 | accepted → refines | ATELIER-110 (language-derived-doc anti-patterns + .ts/.py/.go/.rs artifact-type extension) |
-| IDEATE-37 | backend-enriched (chaos anti-pattern enumeration) | chaos | 0.86 | accepted → refines | ATELIER-110 (include all 6 RESEARCH chaos anti-patterns: edge sync-loop/TTL-less/blocking-call; messaging shared-sub/blocking-consumer/unbounded-retry) |
-| IDEATE-38 | backend-enriched (IDEATE-28 pattern transfer) | improvement | 0.80 | accepted → refines | ATELIER-94 (offline-first.md maps offline write-queue patterns to testing pyramid tiers) |
-| IDEATE-39 | backend-enriched (IDEATE-29 pattern transfer) | improvement | 0.79 | accepted → refines | ATELIER-101 (delivery-semantics.md fenced idempotency-key dedup-store example, not prose-only) |
-| IDEATE-40 | backend-enriched (intra-milestone cross-link dependency) | chaos | 0.84 | accepted → refines | ATELIER-114 (P5 cross-link audit must verify edge↔messaging intra-v0.4 links resolve in both directions) |
-| IDEATE-41 | backend-enriched (IDEATE-30 pattern transfer) | improvement | 0.81 | accepted → refines | ATELIER-100 (streams.md enumerates consumer-group rebalance strategies: sticky/cooperative/eager) |
-| IDEATE-42 | mechanical (D-066 sub-table verifiability) | coverage | 0.87 | accepted → refines | ATELIER-107 (Languages Coverage sub-table = exactly 16 rows; P4 review check) |
-| IDEATE-43 | mechanical (IDEATE-18 pattern transfer) | coverage | 0.83 | accepted → refines | ATELIER-111 (MANIFEST Cross-Cutting summary = "19 domains, 190 P-rules post-v0.4") |
-
-### Refinements Notes (applied to existing reqs at execute time, not changing req rows)
-
- **ATELIER-106** (IDEATE-34, corrected by grill G-014): matrix coverage summary must read
-  "post-v0.4: 19 domains, 190 P-rules" in BOTH the summary block and
-  the per-domain section count (IDEATE-18 carried forward). P4 must
-  verify the matrix contains exactly 190 P-rows (10 per domain × 19).
-  The current matrix has **exactly 170 P-rows** (17 domains × 10,
-  verified by grill G-014 direct count) — the IDEATE-34 "171 vs 170"
-  claim was a FALSE PREMISE. P4 must verify 170 exists, append 20 rows,
-  and confirm post-v0.4 count = 190. Do NOT hunt for or delete a phantom
-  171st row.
- **ATELIER-107** (IDEATE-33, IDEATE-42): the domain-coverage.md
-  extension must update THREE artifacts: (a) the per-domain row-schema
-  table with edge + messaging rows; (b) the "Core Principle Coverage"
-  table (C1–C8 → domains) for the 2 new domains (C4 Locality grows by
-  edge P1/P8 + messaging P7; C5 Reversibility grows by edge P2/P4/P7/P10
-  + messaging P5/P8/P9; C7 Observability grows by edge P10 + messaging
-  P8/P10; C8 Economy grows by edge P3/P9 + messaging P6; C2 grows by
-  messaging P1/P2/P4) — parallel to v0.3 IDEATE-19; (c) the new
-  `## Languages Coverage` sub-table with EXACTLY 16 rows (one per
-  language-derived doc), verifiable as a P4 review check (no orphans,
-  every derived doc traced to ≥1 domain P-rule).
- **ATELIER-110** (IDEATE-36, IDEATE-37): the anti-patterns extension
-  must include (a) the v0.4 deployable-artifact-types table extended to
-  `.ts`/`.py`/`.go`/`.rs` standalone files (language-derived docs risk,
-  per D-020 docs-only contract); (b) language-derived-doc anti-
-  patterns: introducing a new P-rule (e.g., "TS P1"), orphan section
-  with no domain P-rule trace, runtime standalone artifact, and
-  first-principles stub gaining P1–P10 numbering; (c) all 6 RESEARCH-
-  specified chaos anti-patterns, not just the 4 named in the req-row
-  text — edge: sync conflict loop (P4), TTL-less cache (P6), blocking
-  call on constrained device (P3/P5); messaging: shared subscription
-  (P2/P3), blocking consumer (P6), unbounded retry / no DLQ (P5).
- **ATELIER-100** (IDEATE-35, IDEATE-41): streams.md must include (a)
-  the stream-platform comparison table (Kafka vs Kinesis vs
-  Pulsar/NATS JetStream — ordering, partitioning, replay/retention,
-  use-case fit) per D-069, AND (b) an enumeration of consumer-group
-  rebalance strategies (sticky/cooperative vs eager) as a sub-
-  comparison — each with partition-stop-the-world cost and use-case
-  fit. Parallel to v0.3 IDEATE-30 (drift-type enumeration).
- **ATELIER-101** (IDEATE-35, IDEATE-39): delivery-semantics.md must
-  include (a) the dead-letter strategy comparison table (retry-count-
-  limit vs TTL-with-backoff vs poison-queue vs DLQ+alert) per D-069,
-  AND (b) a fenced idempotency-key dedup-store example (not prose-
-  only) — parallel to v0.3 IDEATE-29 (fenced signed-attestation
-  example). Prose-only delivery-semantics guidance is weak; a fenced
-  consumer-with-dedup-store demonstrates P3 (idempotent consumers)
-  concretely.
- **ATELIER-111** (IDEATE-31, IDEATE-43): the new `## Languages`
-  MANIFEST section must list the 4 v0.1 first-principles stubs
-  (typescript.md, python.md, go.md, rust.md — closing the pre-existing
-  drift since v0.1, parallel to ESC-002/ATELIER-91) AND the 16 new
-  derived docs. The Cross-Cutting summary line must update to exactly
-  "19 domains, 190 P-rules post-v0.4" (IDEATE-18 carried forward).
- **ATELIER-114** (IDEATE-40): the P5 cross-link audit must verify
-  edge↔messaging intra-v0.4 links resolve in BOTH directions, not only
-  new→existing. Edge/iot.md (P1) cross-links messaging/queues.md (MQTT
-  QoS parallels delivery semantics) and messaging/iot.md-style
-  references — but messaging/ docs are authored in P2, so at the P1
-  tag (v0.3.1) those links dangle. This is acceptable per vertical-
-  slice integrity (D-053 — matrix/cross-links close in P4/P5), but the
-  P5 audit (ATELIER-114) must explicitly check that every edge→
-  messaging and messaging→edge link resolves by the P6 ship. The
-  audit must also confirm language-derived docs (P3) link to BOTH
-  new (edge/messaging) and existing domains where relevant (e.g.,
-  ts-async.md → messaging/delivery-semantics; go-concurrency.md →
-  concurrency/patterns + messaging/queues).
- **ATELIER-94** (IDEATE-38): offline-first.md must map offline write-
-  queue / conflict-detection patterns to the testing pyramid tiers
-  (unit: conflict detection on a merge function; integration:
-  reconnect reconcile against a local store; e2e: partition
-  simulation with a fake network) — parallel to v0.3 IDEATE-28 (i18n
-  pseudo-locale → pyramid). Avoids generic "test offline" guidance.
-
-### Within-Project Pattern Transfer (v0.1 → v0.2 → v0.3 → v0.4) — verified
-
-| Prior Lesson | v0.4 Application | Status |
-|--------------|------------------|--------|
-| IDEATE-10/11/12 + 21/22/23 (decision/comparison tables in multi-tool derived docs) | D-069 + IDEATE-35 transfer the pattern to streams.md (Kafka/Kinesis/Pulsar) + delivery-semantics.md (dead-letter strategies) | ✓ transferred |
-| IDEATE-17 (manifest drift closure — examples/ unlisted → ATELIER-91) | IDEATE-31 → ATELIER-111 (languages/ unlisted since v0.1 — closes pre-existing drift on the same ESC-002 precedent) | ✓ transferred |
-| IDEATE-18 (coverage summary totals must update — string + per-domain count) | IDEATE-43 → ATELIER-111 (Cross-Cutting = "19 domains, 190 P-rules post-v0.4") + IDEATE-34 → ATELIER-106 (summary block) | ✓ transferred |
-| IDEATE-19 (Core Principle Coverage C1–C8 → domains table update) | IDEATE-33 → ATELIER-107 (C-rule coverage table extended for edge + messaging with the documented C-count shifts) | ✓ transferred |
-| IDEATE-20 (anti-patterns specificity: domain violations + artifact types) | IDEATE-36 + IDEATE-37 → ATELIER-110 (language-derived anti-patterns + .ts/.py/.go/.rs artifact types + all 6 chaos anti-patterns) | ✓ extended |
-| IDEATE-07 (named bad examples cite the P-rule breached) | ATELIER-113 + D-068 already cover (single-breach, cite specific P-rule) | ✓ carried forward |
-| IDEATE-08 (cross-link verification: every new derived doc ≥1 outbound) | ATELIER-114 already covers; IDEATE-40 extends to edge↔messaging intra-milestone links | ✓ extended |
-| IDEATE-13/14 (chaos: orphan P-rule + deployable artifact) | IDEATE-36 → ATELIER-110 (language orphan-section + standalone .ts/.py/.go/.rs runtime artifact) | ✓ extended |
-| IDEATE-28 (pseudo-locale testing → testing pyramid tiers) | IDEATE-38 → ATELIER-94 (offline write-queue testing → pyramid tiers) | ✓ transferred |
-| IDEATE-29 (fenced signed-attestation example, not prose-only) | IDEATE-39 → ATELIER-101 (fenced idempotency-key dedup-store example) | ✓ transferred |
-| IDEATE-30 (drift-type enumeration: data/concept/prediction + signal each) | IDEATE-41 → ATELIER-100 (rebalance-strategy enumeration: sticky/cooperative/eager + cost each) | ✓ transferred |
+| v0.2 audit ESC-002 note (examples/ not in MANIFEST) | IDEATE-17 → ATELIER-91 | ✓ addressed |
@@ -88,9 +88,9 @@ NFR milestone: no separate minor tag. The final patch (v0.1.5) IS the v0.2 deliv
 | 1 | GitOps + Operators Domain | docs | complete | domains/gitops-operators/{first-principles, argocd, flux, operators, progressive-delivery}.md — shipped v0.2.1 |
 | 2 | AI/ML Domain | docs | complete | domains/ai-ml/{first-principles, data-versioning, model-evaluation, serving, monitoring-drift}.md — shipped v0.2.2 |
 | 3 | i18n + Compliance Domains | docs | complete | domains/i18n/{first-principles, locale-resources, formatting, rtl-bidi, testing-i18n}.md, domains/compliance/{first-principles, audit-logs, data-retention, policy-as-code, evidence}.md — shipped v0.2.3 |
-| 4 | Matrix + Review Integration | docs | complete | matrix/principles-matrix.md (+40 mappings), matrix/domain-coverage.md (incl. C-rule coverage table update), review/{agent-checklist, peer-review-checklist, anti-patterns}.md, MANIFEST.md (+ examples/ listing per ATELIER-91) — shipped v0.2.4 |
-| 5 | Examples + Cross-Links | docs | complete | examples/good + examples/bad for 4 domains, cross-links to devops/security/observability/data/k8s/iac — shipped v0.2.5 |
-| 6 | Final Review + Ship | docs | complete | Review passed, audit clean, milestone merged to main, tag v0.2.6 |
+| 4 | Matrix + Review Integration | docs | pending | matrix/principles-matrix.md (+40 mappings), matrix/domain-coverage.md (incl. C-rule coverage table update), review/{agent-checklist, peer-review-checklist, anti-patterns}.md, MANIFEST.md (+ examples/ listing per ATELIER-91) |
+| 5 | Examples + Cross-Links | docs | pending | examples/good + examples/bad for 4 domains, cross-links to devops/security/observability/data/k8s/iac |
+| 6 | Final Review + Ship | docs | pending | Review passed, audit clean, milestone merged to main, tag v0.2.6 |

 ## v0.3 Phase Tag Mapping

@@ -119,44 +119,7 @@ NFR milestone: no separate minor tag. The final patch (v0.2.6) IS the v0.3 deliv

 ## Future Milestones

- **v0.4** (ACTIVE): `domains/edge/`, `domains/messaging/`, `languages/`-derived docs (typescript/python/go/rust → 4 derived docs each).
- **v0.5** (candidates): `domains/quantum/`, tooling adapters (linters), translation/localization of framework docs.
-
-## Milestone: v0.4 — Edge + Messaging + Language-Derived Docs (ACTIVE)
-
-**Milestone type:** NFR (all phases produce docs — no `feat` code)
-**Tag line:** v0.3.x (previous minor from v0.4)
-**Phases:** P0 (pre-execution) + P1–P5 (execution) + P6 (final review+ship)
-
-| Phase | Name | Type | Status | Key Deliverables |
-|-------|------|------|--------|------------------|
-| 0 | Pre-Execution | docs | active | Spec, clarify, research, ideate, plan, PERSONAS.md (adds edge-engineer + languages-engineer phase-specific personas) |
-| 1 | Edge Domain | docs | pending | domains/edge/{first-principles, cdn, offline-first, iot, sync}.md |
-| 2 | Messaging Domain | docs | pending | domains/messaging/{first-principles, queues, pubsub, streams, delivery-semantics}.md |
-| 3 | Language-Derived Extension | docs | pending | languages/ × 4 → first-principles + 4 derived docs each (16 derived docs) |
-| 4 | Matrix + Review Integration | docs | pending | matrix/principles-matrix.md (+20 mappings, 170→190), matrix/domain-coverage.md (+ languages/ sub-table), review/{agent-checklist, peer-review-checklist, anti-patterns}.md, MANIFEST.md (languages/ section) |
-| 5 | Examples + Cross-Links | docs | pending | examples/good + examples/bad for 2 domains, cross-links to devops/observability/data/concurrency/kubernetes/infrastructure-as-code + language→domain links |
-| 6 | Final Review + Ship | docs | pending | Review passed, audit clean, milestone merged to main, tag v0.3.6 |
-
-## v0.4 Phase Tag Mapping
-
-Per branch-strategy.md, milestone `v0.4` tags run on the `v0.3.x` patch line:
-
-| Phase | Tag | Notes |
-|-------|-----|-------|
-| P0 | v0.3.0 | Pre-execution release |
-| P1 | v0.3.1 | Edge domain |
-| P2 | v0.3.2 | Messaging domain |
-| P3 | v0.3.3 | Language-derived extension |
-| P4 | v0.3.4 | Matrix + review integration |
-| P5 | v0.3.5 | Examples + cross-links |
-| P6 | v0.3.6 | Final review + ship — **IS the v0.4 milestone release** |
-
-NFR milestone: no separate minor tag. The final patch (v0.3.6) IS the v0.4 deliverable.
-
-## v0.4 Ideation Outcome
-
-(Populated during P0 IDEATE stage.)
+- **v0.4** (candidates): `domains/edge/`, `domains/quantum/`, language-specific derived docs, tooling adapters (linters), translation/localization of framework docs.

 ## Success Criteria

@@ -3,7 +3,7 @@
    {
      "slug": "atelier",
      "name": "Atelier",
-      "milestone": "v0.4",
+      "milestone": "v0.3",
      "status": "active"
    }
  ],
@@ -43,29 +43,29 @@

 ## Examples

-> Examples are illustrative markdown with fenced code only (no standalone runtime artifacts per D-020 / D-025). The `examples/` directory listing closes the v0.2 ESC-002 drift (IDEATE-17, ATELIER-91). P5 authored the v0.3 examples and promoted all entries from `pending` to `✓` (verified — every listed file exists).
+> Examples are illustrative markdown with fenced code only (no standalone runtime artifacts per D-020 / D-025). The `examples/` directory listing closes the v0.2 ESC-002 drift (IDEATE-17, ATELIER-91). P5 examples populate this section.

 | Path | Status | Notes |
 |------|--------|-------|
-| `examples/good/` | ✓ | Good-example directory — 8 examples (v0.1 + v0.2 + v0.3) |
-| `examples/bad/` | ✓ | Bad-example directory — 7 examples (v0.1 + v0.2 + v0.3) |
-| `examples/good/api-endpoint.md` | ✓ | v0.1 example — good REST endpoint |
-| `examples/good/react-component.md` | ✓ | v0.1 example — good React component |
-| `examples/good/db-schema.md` | ✓ | v0.1 example — good DB schema |
-| `examples/good/error-handler.md` | ✓ | v0.1 example — good error handler |
-| `examples/bad/god-object.md` | ✓ | v0.1 example — bad god object |
-| `examples/bad/silent-error.md` | ✓ | v0.1 example — bad silent error |
-| `examples/bad/leaky-abstraction.md` | ✓ | v0.1 example — bad leaky abstraction |
-| `examples/good/terraform-module.md` | ✓ | v0.2 example — good IaC module |
-| `examples/good/k8s-deployment.md` | ✓ | v0.2 example — good k8s deployment |
-| `examples/bad/terraform-unlocked-state.md` | ✓ | v0.2 example — bad unlocked state |
-| `examples/bad/k8s-bare-pod-no-resources.md` | ✓ | v0.2 example — bad bare pod |
-| `examples/good/gitops-pr.md` | ✓ | v0.3 example — good GitOps PR |
-| `examples/good/ai-ml-reproducibility.md` | ✓ | v0.3 example — good reproducible training run |
-| `examples/bad/i18n-string-concat.md` | ✓ | v0.3 example — bad i18n string concat |
-| `examples/bad/compliance-audit-log.md` | ✓ | v0.3 example — bad audit log (P1 + P9 breaches) |
+| `examples/good/` | (pending P5) | Good-example directory — to be populated by v0.3 P5 |
+| `examples/bad/` | (pending P5) | Bad-example directory — to be populated by v0.3 P5 |
+| `examples/good/api-endpoint.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/good/react-component.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/good/db-schema.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/good/error-handler.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/bad/god-object.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/bad/silent-error.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/bad/leaky-abstraction.md` | (pending P5) | v0.1 example — to be listed when P5 back-fills |
+| `examples/good/terraform-module.md` | (pending P5) | v0.2 example — to be listed when P5 back-fills |
+| `examples/good/k8s-deployment.md` | (pending P5) | v0.2 example — to be listed when P5 back-fills |
+| `examples/bad/terraform-unlocked-state.md` | (pending P5) | v0.2 example — to be listed when P5 back-fills |
+| `examples/bad/k8s-bare-pod-no-resources.md` | (pending P5) | v0.2 example — to be listed when P5 back-fills |
+| `examples/good/gitops-pr.md` | (pending P5) | v0.3 example — to be authored in P5 |
+| `examples/good/ai-ml-reproducibility.md` | (pending P5) | v0.3 example — to be authored in P5 |
+| `examples/bad/i18n-string-concat.md` | (pending P5) | v0.3 example — to be authored in P5 |
+| `examples/bad/compliance-audit-log.md` | (pending P5) | v0.3 example — to be authored in P5 |

-> **Note:** The `examples/` section was established in P4 with entries pre-listed as `pending P5`. P5 authored the 4 v0.3 examples and promoted all entries to `✓` after verifying every listed file exists on disk. The manifest remains authoritative — unlisted = not part of framework.
+> **Note:** The `examples/` section structure is established here (P4) so P5 can populate it. Files marked "pending P5" do not yet exist; they will be authored in Phase 5 and promoted from `pending` to `✓` upon completion. Listing them here as `pending` makes the manifest authoritative about what *will* exist and prevents drift.

 ## Cross-Cutting

@@ -1,222 +0,0 @@
-# Bad Example: Compliance Audit Log (Two Breaches)
-
-> An audit logging implementation that violates **two** Atelier
-> compliance principles in one example (per IDEATE-26, D-044):
-> **P1** (Audit Logs are Append-Only) — a mutable audit log with
-> routine `DELETE`/`UPDATE` "cleanup" — and **P9** (Secrets and
-> Sensitive Data are Redacted in Audit) — a database password leaked
-> into an audit record. Each violation is cited, then fixed.
-
-## The Code
-
-```python
-# audit_log.py — the audit sink, stored in a mutable Postgres table
-import psycopg2, datetime
-
-# P1 VIOLATION: the audit log is a regular mutable table. There is no
-# write-once protection, no immutable bucket, no hash-chaining.
-# Any DB user with UPDATE/DELETE can rewrite history.
-CREATE_TABLE = """
-CREATE TABLE audit_log (
-    id           BIGSERIAL PRIMARY KEY,
-    timestamp    TIMESTAMPTZ NOT NULL,
-    event        TEXT NOT NULL,
-    actor        TEXT NOT NULL,
-    target       TEXT,
-    payload      JSONB,
-    request_id   TEXT
-);
-- No row-level immutability. No trigger preventing UPDATE/DELETE.
-"""
-
-def write_event(event, actor, target=None, payload=None, request_id=None):
-    conn = psycopg2.connect(os.environ["DATABASE_URL"])
-    conn.execute(
-        "INSERT INTO audit_log (timestamp, event, actor, target, payload, request_id) "
-        "VALUES (%s, %s, %s, %s, %s, %s)",
-        (datetime.datetime.utcnow(), event, actor, target,
-         json.dumps(payload), request_id),
-    )
-
-# P1 VIOLATION (continued): "cleanup" that mutates the audit log.
-# A routine job deletes records older than 30 days to "save space"
-# and updates records to "fix typos in the actor field."
-def cleanup_audit_log():
-    conn = psycopg2.connect(os.environ["DATABASE_URL"])
-    # DELETE — an audit record is destroyed. This is tampering,
-    # dressed as housekeeping.
-    conn.execute("DELETE FROM audit_log WHERE timestamp < NOW() - INTERVAL '30 days'")
-    # UPDATE — an audit record is rewritten. The "fix" is the
-    # violation; the original actor is lost.
-    conn.execute("UPDATE audit_log SET actor = 'admin' WHERE actor LIKE 'svc-%'")
-```
-
-```python
-# The call site that leaks a secret into the audit log.
-def read_config(key):
-    # ... fetches a secret from the secrets manager ...
-    value = secrets_manager.get(key)   # e.g. the raw DB password
-    # P9 VIOLATION: the raw secret value is written into the audit
-    # payload. The append-only log is now a secret store.
-    write_event(
-        event="config.read",
-        actor="api-server",
-        target={"kind": "secret", "id": key},
-        payload={"value": value},            # <- the secret, in plaintext
-        request_id=req.id,
-    )
-    return value
-```
-
-The resulting audit record:
-
-```json
-{
-  "id": 48213,
-  "timestamp": "2026-08-05T09:12:03Z",
-  "event": "config.read",
-  "actor": "api-server",
-  "target": {"kind": "secret", "id": "db-password"},
-  "payload": {"value": "p@ssw0rd-sup3r-s3cr3t-plaintext"},
-  "request_id": "req_91c2"
-}
-```
-
-A week later, the `cleanup_audit_log` job `DELETE`s this record (it
-is older than 30 days in the team's "retention" — which is actually a
-storage-economy decision, not a policy), and `UPDATE`s every
-`svc-*` actor to `admin`. The secret was in the log for a week,
-readable by anyone with `SELECT` on the table; now the record of it
-having been there is gone.
-
-## What Makes It Bad
-
-### Breach 1 — Mutable Audit Log (Compliance P1 Audit Logs are Append-Only)
- The audit log is a regular mutable Postgres table. `DELETE FROM
-  audit_log WHERE timestamp < ...` and `UPDATE audit_log SET actor =
-  ...` both succeed. The log is a draft, not a record.
- Routine `DELETE` as "cleanup" is the cardinal P1 violation: the
-  deletion of an audit record is itself an auditable incident, not a
-  housekeeping task. "We deleted old records to save space" is a P3
-  (Retention is Policy, Not Storage) violation *and* a P1 violation —
-  the retention decision is driven by storage cost, and the
-  mechanism is tampering.
- The `UPDATE` that rewrites `svc-deploy` → `admin` destroys
-  attribution (a P7 violation stacked on the P1 violation): the
-  original actor is lost, and the replacement (`admin`) is a shared
-  identity that could be any of ten engineers.
- **Fix:** the audit sink is append-only *by construction*, not by
-  policy. Write-once storage (WORM bucket, immutable log stream,
-  hash-chained ledger) enforces immutability at the substrate.
-  Retention is a declared policy with a meta-audit of deletions; a
-  human does not run ad-hoc `DELETE` jobs.
-
-  ```python
-  # Fix: write to an append-only sink (illustrative — S3 Object Lock,
-  # WORM bucket, or a hash-chained ledger). The API has no update /
-  # delete path; the storage refuses mutation.
-  def write_event(event, actor, target=None, payload=None, request_id=None):
-      record = {
-          "timestamp": datetime.datetime.now(datetime.timezone.utc).isoformat(),
-          "event": event,
-          "actor": actor,            # the authenticated principal, not "admin"
-          "target": target,
-          "payload": redact(payload), # see Breach 2 fix
-          "request_id": request_id,
-          "prev_hash": last_hash(),   # hash-chaining: tampering breaks the chain
-      }
-      record["hash"] = sha256(canonical_json(record))
-      append_only_sink.write(record)  # WORM storage; no update/delete API exists
-
-  # Fix: retention is a declared, reviewed policy — not an ad-hoc DELETE.
-  # When an audit segment ages out, the deletion is itself meta-audited
-  # in a higher-tier log with the rule that authorized it.
-  # (See domains/compliance/data-retention.md and audit-logs.md.)
-  ```
- See `domains/compliance/audit-logs.md` (Audit Logs are Append-Only)
-  and `domains/compliance/first-principles.md` P1.
-
-### Breach 2 — Secret Leaked in Audit Log (Compliance P9 Secrets and Sensitive Data are Redacted in Audit)
- `payload={"value": value}` writes the raw DB password into the
-  audit record. The append-only log is now a secret store: anyone
-  with `SELECT` on `audit_log` can read production credentials. The
-  log is harder to secure than the secrets manager it read from.
- Once the secret is in an append-only log, the remediation is
-  expensive — rotate the secret *and* rewrite the log's access scope
-  (you cannot edit the record; it is append-only). Redaction must
-  happen *at the logging boundary, before the record is written*, not
-  by opportunistic scrubbing after the fact.
- The redaction policy here is "nothing" — there is no rule for
-  which fields are redacted, by what mechanism, in which event type.
-  A redaction rule that lives in no one's head and no code is a P9
-  violation waiting to happen (and it happened).
- **Fix:** redaction is structural, applied at the logging boundary
-  before the record reaches the append-only sink. The policy is
-  itself auditable (which fields, by what rule, in which event).
-
-  ```python
-  # Fix: redaction at the boundary. Log the FACT of the action
-  # (a secret was read), never the CONTENT of the secret.
-  REDACTED_FIELDS = {"value", "token", "password", "authorization", "secret"}
-
-  def redact(payload):
-      if not isinstance(payload, dict):
-          return "[REDACTED:non-object]"
-      out = {}
-      for k, v in payload.items():
-          if k.lower() in REDACTED_FIELDS or "secret" in k.lower():
-              out[k] = "[REDACTED:secret]"
-          else:
-              out[k] = v
-      out["_redaction"] = "secret-value-policy/v1"  # the rule is auditable
-      return out
-
-  # The fixed audit record:
-  # {
-  #   "event": "config.read",
-  #   "actor": "api-server",            # the authenticated principal
-  #   "target": {"kind": "secret", "id": "db-password"},
-  #   "payload": {"value": "[REDACTED:secret]"},
-  #   "_redaction": "secret-value-policy/v1",
-  #   "request_id": "req_91c2"
-  # }
-  # The fact of the read is logged; the secret never enters the log.
-  ```
- See `domains/compliance/audit-logs.md` (Redaction at the Boundary)
-  and `domains/compliance/first-principles.md` P9. Cross
-  `domains/security/secrets.md` — the audit-side redaction is the
-  complement of secret management.
-
-## The Cascade (Two Breaches Compound)
-
-The two violations compound destructively. The secret enters the
-mutable log (P9 breach), where it sits readable by any `SELECT`-holder
-for a week. Then the `cleanup` job `DELETE`s the record (P1 breach) —
-destroying the evidence that the secret was ever logged, while the
-secret itself has already been exposed to every reader of the table.
-The `UPDATE` that rewrites `svc-deploy` → `admin` (a P7 attribution
-breach stacked on the P1 breach) means that even if a copy of the
-record survived, the actor who triggered the secret read is no longer
-identifiable. The team cannot answer "who read the DB password and
-when" — the log that would answer it was mutated, and the secret it
-leaked is now in the wild. This is the worst-case interaction of P1
-and P9: a secret leak with no attributable actor and no surviving
-record.
-
-## Cross-Domain Links
-
- `domains/compliance/audit-logs.md` — the append-only guarantee and
-  the redaction-at-boundary rule this code violates.
- `domains/compliance/first-principles.md` — P1 (Append-Only) and P9
-  (Redacted) are the two breached principles; P7 (Attributable) is
-  breached by the `UPDATE` rewrite.
- `domains/compliance/evidence.md` — an audit log that can be
-  `DELETE`d is not admissible evidence; the append-only guarantee is
-  what makes it admissible.
- `domains/compliance/data-retention.md` — retention is a declared
-  policy with meta-audited deletions, not an ad-hoc `DELETE` job.
- `domains/security/secrets.md` — redaction at the logging boundary
-  is the audit-side complement of secret management.
- `domains/observability/logging.md` — audit logs are structured
-  logging with an append-only guarantee; the logging primitives
-  compose here.
@@ -1,175 +0,0 @@
-# Bad Example: i18n String Concatenation
-
-> A checkout component that violates Atelier's i18n principles. Each
-> violation is cited, then fixed.
-
-## The Code
-
-```typescript
-// Checkout.tsx — the cardinal i18n violation
-function CartSummary({ itemCount, name, total, currency, date }) {
-  // P3 VIOLATION: inline string concatenation. The source-language
-  // word order ("Welcome, {name}! You have {n} items") is baked into
-  // code. Every locale with different word order is broken.
-  const welcome = "Welcome, " + name + "!";
-
-  // P4 VIOLATION: hand-rolled plural branching. `if (n === 1)` encodes
-  // exactly English's one/other rule. Arabic (six categories), Russian
-  // (three), Polish (three) are all wrong.
-  const items =
-    itemCount === 1 ? "1 item" : itemCount + " items";
-
-  // P5 VIOLATION: hand-rolled currency + date formatting. "$" + total
-  // is wrong for de-DE (symbol, grouping, placement). The date
-  // `getMonth() + 1 + "/" + getDay()` is US-only (mm/dd/yyyy).
-  const price = "$" + total.toFixed(2);
-  const d = new Date(date);
-  const dateStr = (d.getMonth() + 1) + "/" + d.getDate() + "/" + d.getFullYear();
-
-  return (
-    <div>
-      <h1>{welcome}</h1>
-      <p>{items} · {price} · {dateStr}</p>
-    </div>
-  );
-}
-```
-
-```typescript
-// The "resource" file — a custom CSV the team hand-rolled.
-// locale,en_us
-// welcome_prefix,Welcome,
-// item_singular,item
-// item_plural,items
-//
-// This is a P3 violation on its own: a custom format no standard
-// tool (xgettext, i18next, FormatJS) can extract from or compose with.
-```
-
-The team runs their first i18n test against real Arabic translations —
-after the string freeze, after the translator was paid. The Arabic
-build renders `"Welcome, محمد!"` with the name on the wrong side of
-the comma, `"1 items"` for a single item (Arabic has six plural
-categories, not two), and the price as `"$1,234.56"` (Arabic-Egypt
-formats as `"١٬٢٣٤٫٥٦ ج.م.‏"`). Every screen is a rewrite, not a patch.
-
-## What Makes It Bad
-
-### Inline String Concatenation (i18n P3 Resources are External, Not Inline)
- `"Welcome, " + name + "!"` bakes English word order into code. In
-  Japanese the name comes first (`ようこそ、محمدさん！`); in Arabic the
-  structure differs again. The concatenation is invisible to the
-  extraction pipeline (`xgettext`, `i18next-parser`) — the translator
-  never sees it as a unit, and the string cannot be versioned or
-  rolled back as a whole.
- The custom `.csv` "resource" store is a second P3 violation: no
-  standard tool reads it, it carries no plural grammar, and it cannot
-  compose with the ICU formatting layer.
- **Fix:** strings live in a standard locale resource file, addressed
-  by key. Code calls `t("welcome", { name })`; the resource carries
-  the parameterized message.
-
-  ```json
-  // en-US.json (ICU MessageFormat)
-  {
-    "checkout.welcome": "Welcome, {name}!",
-    "checkout.cart.summary": "{count, plural, one {# item} other {# items}} · {price} · {date}"
-  }
-  ```
-
-  ```json
-  // ar-EG.json — six plural categories per CLDR; the code is identical
-  {
-    "checkout.welcome": "أهلاً بك، {name}!",
-    "checkout.cart.summary": "{count, plural, zero {لا عناصر} one {عنصر واحد} two {عنصران} few {# عناصر} many {# عنصرًا} other {# عنصر}} · {price} · {date}"
-  }
-  ```
- See `domains/i18n/locale-resources.md` (Resources are the Boundary)
-  and `domains/i18n/first-principles.md` P3.
-
-### Hand-Rolled Plural Branching (i18n P4 Plural and Gender are Parameterized)
- `itemCount === 1 ? "1 item" : itemCount + " items"` encodes
-  English's one/other rule and nothing else. Arabic has six
-  categories (zero, one, two, few, many, other); Russian has three
-  (one, few, many); Polish has three with different boundaries. A
-  two-branch `if` is a C1 (Correctness) violation masquerading as a
-  shortcut — it returns a wrong answer for every non-English locale.
- **Fix:** the count goes to ICU MessageFormat; the formatter
-  consults `Intl.PluralRules` for the active locale; the resource
-  carries the variant for that category. The code passes the count,
-  nothing more.
-
-  ```typescript
-  // The code passes the count; the resource + formatter pick the form.
-  t("checkout.cart.summary", { count: itemCount, price, date });
-  // Intl.PluralRules("ar-EG").select(1) === "one" -> "عنصر واحد"
-  // Intl.PluralRules("ar-EG").select(2) === "two" -> "عنصران"
-  // Intl.PluralRules("ar-EG").select(5) === "few" -> "٥ عناصر"
-  ```
- See `domains/i18n/locale-resources.md` (Plural and Gender in
-  Resources) and `domains/i18n/formatting.md` (Plural Rules).
-
-### Hand-Rolled Currency and Date Formatting (i18n P5 Formatting is Locale-Aware)
- `"$" + total.toFixed(2)` hardcodes the US dollar symbol, US
-  grouping (`,`), and US placement (symbol before the number). In
-  `de-DE` the euro formats as `"1.234,56 €"` (symbol after, dot
-  grouping). In `ar-EG` the pound formats as `"١٬٢٣٤٫٥٦ ج.م.‏"`
-  (Arabic-Indic digits, different grouping).
- `(d.getMonth() + 1) + "/" + d.getDate() + "/" + d.getFullYear()`
-  produces `11/7/2024` — US `mm/dd/yyyy`. Most of the world reads
-  `dd/mm/yyyy`; ISO is `yyyy-mm-dd`. A hand-rolled date formatter
-  encodes one locale's convention and silently produces wrong output
-  for every other.
- **Fix:** `Intl.NumberFormat` and `Intl.DateTimeFormat` with a BCP
-  47 locale tag. CLDR is the source of truth; `Intl` is the runtime.
-
-  ```typescript
-  new Intl.NumberFormat("ar-EG", { style: "currency", currency: "EGP" })
-    .format(1234.56); // "١٬٢٣٤٫٥٦ ج.م.‏"
-  new Intl.DateTimeFormat("ar-EG", { dateStyle: "medium" })
-    .format(new Date(date)); // "٧ نوفمبر ٢٠٢٤"
-  ```
- See `domains/i18n/formatting.md` (the Intl surface, dates, numbers,
-  currencies) and `domains/i18n/first-principles.md` P5.
-
-### Source Language Treated as the Default (i18n P1 Source Language is a Locale)
- The component has no resource layer at all for the source locale —
-  English is "just the strings in the code." When the first second
-  locale arrives, the fix is a rewrite (extract every string,
-  restructure every concatenation), not a patch. The source language
-  is `en-US`, a locale among many — it is not `null`.
- **Fix:** extract source strings into `en-US.json` from day one,
-  even before a second locale exists. The resource layer is the
-  boundary from the first commit.
- See `domains/i18n/first-principles.md` P1 and
-  `domains/uiux/copywriting.md`.
-
-## The Cascade
-
-The violations compound. Inline concatenation makes strings invisible
-to the extraction pipeline, so the translator never receives them as
-units — they reconstruct them by reading the code. Hand-rolled
-plurals return wrong answers for every non-English locale, so the
-Arabic build ships `"1 items"` for a single item. Hand-rolled
-formatting produces US-shaped output everywhere, so the price and
-date are wrong for `de-DE`, `ar-EG`, `zh-Hans-CN`, and every other
-locale. And because the first i18n test ran against real translations
-(a P8 violation — pseudo-locales should have surfaced all of this
-while the fix was still cheap), the defects are found after the
-string freeze, after the translator was paid, and after the release
-date was promised. The fix is now a re-translation and a re-release,
-not a commit.
-
-## Cross-Domain Links
-
- `domains/i18n/locale-resources.md` — the resource layer this code
-  lacks; the standard formats (`.po`, JSON, Fluent, ICU Resource
-  Bundle) it should have used.
- `domains/i18n/formatting.md` — the `Intl`/ICU/CLDR formatting this
-  code should call instead of hand-rolling.
- `domains/i18n/first-principles.md` — P3, P4, P5, and P8 (pseudo-
-  locales test early).
- `domains/uiux/copywriting.md` — copy lives in resources, not in
-  code.
- `domains/api/error-responses.md` — the same parameterized-message
-  discipline applies to localized API errors.
@@ -1,226 +0,0 @@
-# Good Example: AI/ML Reproducible Training Run
-
-> A training run that follows Atelier's AI/ML principles. Each aspect
-> cites the principle it satisfies. Scope per D-023: this is
-> engineering discipline (reproducibility, versioning, lineage,
-> serving), **not** algorithm or model design — no architecture
-> choice, hyperparameter tuning, or model-family comparison appears
-> here.
-
-## The Run
-
-A training run `2026-08-05T09:12:00Z#run-42` produces model
-`registry/payments-fraud@sha256:b5e1...aa0`. Every input that shaped
-the model is pinned, named, and recoverable; the eval was declared
-before training; the model is an addressed artifact in a registry;
-the rollback path names the prior model and the prior dataset.
-
-### The Reproducibility Contract
-
-```yaml
-# lineage/run-42.yaml — the lineage root, committed alongside the code
-run_id:        2026-08-05T09:12:00Z#run-42
-dataset:       s3://ml-data/train@sha256:7f3a...e21
-splits:        dvc.yaml@commit a1b2c4d
-code:          git@a1b2c4d
-config:        configs/train.yaml@commit a1b2c4d
-environment:   ghcr.io/org/train-img@sha256:9c2d...f88
-eval_spec:     configs/eval.yaml@commit a1b2c4d
-model_digest:  registry/payments-fraud@sha256:b5e1...aa0
-status:        passed  # eval gate passed -> eligible for promotion
-```
-
- Lose any line and the run is anecdote, not evidence. The record is
-  the lineage root: a prediction cites the `model_digest`, which
-  cites this `run_id`, which cites everything above.
-
-### Data is Versioned (DVC, content-hashed)
-
-```ini
-# dvc.yaml — the split config is versioned in git, the data in the
-# content-addressed object store. Both are pinned by commit + hash.
-stages:
-  prepare:
-    cmd: python src/prepare.py --input data/raw --out data/splits
-    deps:
-      - data/raw
-      - src/prepare.py
-    outs:
-      - data/splits/train.parquet
-      - data/splits/val.parquet
-      - data/splits/test.parquet
-    # The dataset hash (sha256:7f3a...e21) is recorded in the lineage
-    # contract above. "s3://ml-data/latest" would be a P2 violation.
-```
-
-```bash
-# The dataset is pinned by content hash, not by a mutable path.
-$ dvc get s3://ml-data/train --rev sha256:7f3a...e21
-# The split is a deterministic function of (dataset version, split
-# config, random seed). Two runs on the same pinned inputs produce
-# the same splits.
-```
-
-### Code and Config are Versioned (git)
-
-```yaml
-# configs/train.yaml@commit a1b2c4d — versioned with the code
-# (No algorithm/hyperparameter content is illustrated here — this is
-#  the engineering discipline of pinning the config, not the model
-#  design inside it. Per D-023, algorithm choice is out of scope.)
-seed: 42
-splits:
-  train: data/splits/train.parquet
-  val:   data/splits/val.parquet
-  test:  data/splits/test.parquet   # held out, never touched by training
-```
-
-### Environment is Pinned (container digest)
-
-```dockerfile
-# The training environment is an image addressed by digest, not :latest.
-# ghcr.io/org/train-img@sha256:9c2d...f88
-FROM python:3.11-slim
-# dependencies pinned in requirements.txt with hashes
-COPY requirements.txt .
-RUN pip install --no-cache-dir -r requirements.txt
-```
-
-```text
-# requirements.txt — pinned + hash-pinned (pip-compile / pip-audit)
-dvc==3.50.2 \
-    --hash=sha256:1c8a...e7
-mlflow==2.16.0 \
-    --hash=sha256:9b2f...a1
-# No unpinned ranges. A rerun pulls the exact same wheels.
-```
-
-### Evaluation is Defined Before Training (P4)
-
-```yaml
-# configs/eval.yaml@commit a1b2c4d — committed BEFORE training runs.
-# The metrics, splits, and pass/fail thresholds are a-priori; they
-# are the contract the model must satisfy to leave the experiment.
-metrics:
-  - name: precision_at_threshold
-    threshold: ">= 0.92"
-  - name: recall_at_threshold
-    threshold: ">= 0.85"
-  - name: false_positive_rate
-    threshold: "<= 0.03"
-split: data/splits/test.parquet   # held out, never in training
-gate: all_metrics_pass            # AND of all thresholds; no cherry-pick
-# The eval schema equals the serving input contract (serving.md P8):
-# feature names, types, ranges match the production boundary exactly.
-```
-
- Metrics chosen after seeing scores would be a P4 violation: the eval
-  would be rationalizing, not measuring. See
-  `domains/ai-ml/model-evaluation.md`.
-
-### The Model is a Versioned Artifact (MLflow registry)
-
-```bash
-# After the eval gate passes, the model is registered as an immutable
-# artifact addressed by digest, then promoted by stage.
-$ mlflow models register \
-    --name payments-fraud \
-    --model-uri runs:/run-42/model \
-    --description "run-42, dataset sha256:7f3a...e21, eval passed"
-# registry/payments-fraud@sha256:b5e1...aa0
-# Stages: None -> Staging -> Production. Promotion is a registry
-# operation, not a file copy. Never "latest".
-```
-
-### The Pipeline Composes (P9)
-
-```text
-# The training flow is a pipeline with explicit stages and contracts,
-# not a notebook. Each stage has named inputs and named outputs.
-prepare(dataset@hash) -> split(dvc.yaml) -> train(config, env@digest)
-  -> eval(eval.yaml, test@hash) -> [gate: pass] -> register(model@digest)
-                                  |
-                                  +-> [gate: fail] -> abort, no promote
-# A notebook in this path would be a P9 violation: implicit state,
-# human-dependent order, unreproducible.
-```
-
-## What Makes It Good
-
-### Reproducibility is First Class (AI/ML P1, C1, C5)
- data + code + config + environment are all pinned. A second
-  engineer on a second laptop checks out commit `a1b2c4d`, pulls the
-  dataset by hash, pulls the image by digest, and reproduces the run
-  bit-for-bit. The run is reviewable because it is recreatable.
- See `domains/ai-ml/first-principles.md` P1 and
-  `domains/devops/first-principles.md` P1 Reproducibility.
-
-### Data is Versioned, Not Just Code (AI/ML P2, C5, C7)
- The dataset is `s3://ml-data/train@sha256:7f3a...e21`, not
-  `s3://ml-data/latest`. A model trained on "the data" is a model
-  trained on an unknown input — a C1 violation. DVC pins the data the
-  way git pins the code.
- See `domains/ai-ml/data-versioning.md` (dataset hashing, the DVC /
-  Delta Lake / LakeFS comparison) and `domains/data/migrations.md`.
-
-### Lineage is Traceable End-to-End (AI/ML P3, C7, C1)
- prediction → model → run-42 → dataset → source. Every edge is
-  named; no orphan model. A serving regression traces back to the
-  exact dataset and code that built the model, which is how drift is
-  diagnosed (data drift vs concept drift vs prediction drift).
- See `domains/ai-ml/data-versioning.md` (lineage record) and
-  `domains/observability/logging.md`.
-
-### Evaluation Defined Before Training (AI/ML P4, C1, C2)
- `eval.yaml` was committed before `train` ran. The gate is
-  `all_metrics_pass`; a failing metric aborts promotion. Cherry-
-  picking a metric post-hoc is a correctness violation — the eval
-  would no longer measure the model.
- See `domains/ai-ml/model-evaluation.md` (eval-as-a-gate) and
-  `domains/testing/first-principles.md` (tests as specification).
-
-### Models are Versioned Artifacts (AI/ML P5, C5, C6)
- The model is `registry/payments-fraud@sha256:b5e1...aa0`, promoted
-  Staging → Production. A serving endpoint that pulled `latest` would
-  be serving an unknown model with no rollback. The registry is to
-  models what a container registry is to images.
- See `domains/ai-ml/serving.md` (the model is an addressed artifact)
-  and `domains/devops/first-principles.md` P7 Immutability.
-
-### Rollback Includes the Model (AI/ML P10, C5)
- If production regresses, the rollback restores the prior model
-  digest `registry/payments-fraud@sha256:a1c4...f09` AND the prior
-  serving code. A rollback that redeploys old code but keeps the new
-  model has not rolled back — the model was the thing that regressed.
- See `domains/ai-ml/serving.md` (Rollback Includes the Model) and
-  `domains/devops/first-principles.md` P4 Rollback First.
-
-## What This Example Does NOT Do (And Why That's Good)
-
- Does **not** reference the dataset by a mutable path —
-  `s3://ml-data/latest` would be a P2 violation.
- Does **not** choose metrics after seeing scores — that is a P4
-  violation (rationalizing, not measuring).
- Does **not** pull `latest` from the model registry — that is a P5
-  violation (unknown model, no rollback).
- Does **not** contain algorithm/architecture/hyperparameter content
-  — per D-023, those are research choices, not engineering
-  principles, and have no derivation in the core C-rules.
- Does **not** run from a notebook — a notebook in the pipeline path
-  is a P9 violation (implicit state, unreproducible).
-
-## Cross-Domain Links
-
- `domains/ai-ml/data-versioning.md` — the DVC pinning, the lineage
-  record, the tool comparison (DVC / Delta Lake / LakeFS).
- `domains/ai-ml/serving.md` — the model is promoted as an addressed
-  artifact; the serving boundary validates inputs against the same
-  schema as the eval.
- `domains/ai-ml/model-evaluation.md` — the eval-as-a-gate that this
-  run must pass before promotion.
- `domains/devops/first-principles.md` P1 Reproducibility — the
-  non-negotiable this run inherits.
- `domains/data/migrations.md` — data versioning parallels schema
-  migration discipline.
- `domains/observability/logging.md` — the lineage record is a
-  structured, append-only log of provenance.
@@ -1,197 +0,0 @@
-# Good Example: GitOps Pull Request
-
-> A pull request that changes ArgoCD Application manifests following
-> Atelier's GitOps + Operators principles. Each aspect cites the
-> principle it satisfies.
-
-## The PR
-
-A PR titled `promote payments-api 1.2.3 to prod` opened against the
-GitOps repo `platform/gitops`. It changes the `targetRevision` of the
-payments-api Application from `1.2.2` to `1.2.3`, adds a sync-wave
-annotation to a new migration Job, and tightens the AppProject's
-destination allow-list. CI runs plan/diff; nothing pushes to the
-cluster.
-
-### The Commit
-
-```yaml
-# manifests/prod/payments-api.yaml — the only file changed
-apiVersion: argoproj.io/v1alpha1
-kind: Application
-metadata:
-  name: payments-api
-  namespace: argocd
-  finalizers:
-    - resources-finalizer.argocd.argoproj.io
-spec:
-  source:
-    repoURL: https://git.example.com/platform/payments
-    targetRevision: 1.2.3          # was 1.2.2 — pinned, not latest
-    path: manifests/prod
-  destination:
-    server: https://kubernetes.default.svc
-    namespace: payments
-  syncPolicy:
-    automated:
-      prune: true
-      selfHeal: true
-    syncOptions:
-      - CreateNamespace=false
-      - PrunePropagationPolicy=foreground
-```
-
-```yaml
-# manifests/prod/payments-db-migration.yaml — new file, wave-ordered
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: payments-db-migrate-1.2.3
-  namespace: payments
-  annotations:
-    argocd.argoproj.io/sync-wave: "-1"   # PreSync: run before the app
-spec:
-  backoffLimit: 0
-  ttlSecondsAfterFinished: 86400
-  template:
-    spec:
-      restartPolicy: OnFailure
-      serviceAccountName: payments-migrator
-      containers:
-        - name: migrate
-          image: registry.example.com/payments/migrate:1.2.3
-          args: ["up", "--to", "1.2.3"]
-```
-
-```yaml
-# projects/payments.yaml — AppProject tightened in the same PR
-apiVersion: argoproj.io/v1alpha1
-kind: AppProject
-metadata:
-  name: payments
-  namespace: argocd
-spec:
-  sourceRepos:
-    - https://git.example.com/platform/payments
-  destinations:
-    - server: https://kubernetes.default.svc
-      namespace: payments            # prod-app can only deploy to payments ns
-  clusterResourceWhitelist:
-    - group: ""
-      kind: Namespace                # allowed to create its own namespace
-  roles:
-    - name: payments-team
-      policies:
-        - p, proj:payments:payments-team, applications, sync, payments/*, allow
-```
-
-### The CI Pipeline (runs on the PR, before merge)
-
-```text
-# .github/workflows/gitops-plan.yml (illustrative steps)
- name: validate manifests
-  run: argocd app manifests manifests/prod/ | kubeconform -strict
-
- name: diff against live cluster (read-only, no apply)
-  run: argocd app diff payments-api --server $ARGOCD_SERVER --auth-token $READ_ONLY_TOKEN
-  # CI holds a READ-ONLY ArgoCD token. It never holds kubectl rights.
-  # A non-empty diff is the PR's proposed change, rendered for review.
-
- name: opa gate (admission policy pre-check)
-  run: opa eval -i manifests/prod/ -d policies/ "data.k8s.admission.deny"
-  # Policy violations fail the PR before merge, not after deploy.
-```
-
-## What Makes It Good
-
-### Git is the Source of Truth (GitOps P1, C1 Correctness)
- The promotion is a commit. The cluster's desired state is a
-  derivative of this repo; the repo is the authority. If the change is
-  wrong, `git revert` is the rollback — the recovery path is the
-  history.
- See `domains/gitops-operators/first-principles.md` P1 and
-  `domains/gitops-operators/argocd.md` (Application CRD).
-
-### Pull, Don't Push (GitOps P3, C4 Locality)
- CI holds a **read-only** ArgoCD token for `app diff`. It holds no
-  `kubectl` rights against the production cluster. The cluster's
-  ArgoCD controller pulls the merged commit; nothing pushes to the
-  cluster. A compromised CI token can read, not deploy.
- See `domains/gitops-operators/argocd.md` (RBAC and SSO) and
-  `domains/gitops-operators/flux.md` for the same pull boundary from
-  the Flux side.
-
-### State is Immutable and Versioned (GitOps P5, C5 Reversibility)
- `targetRevision: 1.2.3` — the Application pins a specific chart
-  revision, not `latest`. The commit that changed it is a permanent
-  record; `git revert` restores `1.2.2` and ArgoCD's `selfHeal`
-  converges the cluster back. No force-push; history is the audit
-  trail.
- See `domains/gitops-operators/first-principles.md` P5 and
-  `domains/infrastructure-as-code/state.md` (State is Truth).
-
-### Sync Waves Order Correctness (GitOps P4, C1)
- The migration Job carries `argocd.argoproj.io/sync-wave: "-1"` so
-  it runs in `PreSync` before the payments-api Deployment that
-  depends on the new schema. Wave ordering is a correctness
-  mechanism, not performance — the app starting before its migration
-  is a correctness bug.
- See `domains/gitops-operators/argocd.md` (Sync Waves and Hooks).
-
-### Reconcile, Don't Mutate by Hand (GitOps P8)
- `selfHeal: true` + `prune: true` means a hand-edited drift on a
-  managed resource is overwritten on the next loop. The fix for drift
-  is a new commit, not `kubectl edit`. The PR author does not SSH into
-  the cluster to "fix" anything.
- See `domains/gitops-operators/argocd.md` (Diff and Drift) and
-  `domains/gitops-operators/first-principles.md` P8.
-
-### Least Privilege Reconciliation (GitOps P10, C8 Economy)
- The AppProject `payments` restricts the Application to the
-  `payments` namespace and the `payments` repo. The controller's
-  ServiceAccount (not shown) is bound to a namespace-scoped Role, not
-  `cluster-admin`. The PR *tightens* the allow-list — least privilege
-  is a direction, not a one-time setting.
- See `domains/gitops-operators/argocd.md` (RBAC and SSO) and
-  `domains/kubernetes/rbac.md`.
-
-### Policy is a Gate (Compliance P5, cross-link)
- The `opa eval` step runs the admission policy against the proposed
-  manifests before merge. A violation fails the PR; the non-compliant
-  state is never realized. Detection is not enforcement; this is
-  enforcement.
- See `domains/compliance/policy-as-code.md` and
-  `domains/devops/ci-cd.md`.
-
-### Failure is Observable (GitOps P9)
- A sync failure or health degradation on `payments-api` emits
-  ArgoCD status (`Degraded` / `OutOfSync`) and a notification. Silent
-  drift is the bug; this PR does not disable notifications.
- See `domains/gitops-operators/argocd.md` (Health and Status) and
-  `domains/observability/metrics.md`.
-
-## What This PR Does NOT Do (And Why That's Good)
-
- Does **not** run `kubectl apply` from CI — that is the push pattern,
-  a P3 violation (see `examples/bad/` for the anti-pattern).
- Does **not** use `argocd app set` as the steady state — the change
-  is in git, not in an imperative command's history.
- Does **not** store raw Secrets in the GitOps repo — secrets arrive
-  via Sealed Secrets / SOPS / External Secrets, encrypted in git.
- Does **not** float `targetRevision: latest` — the Application pins
-  a version; "latest" is an unknown model of the system.
-
-## Cross-Domain Links
-
- `domains/gitops-operators/argocd.md` — the Application CRD, sync
-  waves, RBAC/AppProjects, and the pull model.
- `domains/gitops-operators/flux.md` — the same PR pattern from the
-  Flux side (Kustomization CRD, per-cluster autonomy).
- `domains/kubernetes/workloads.md` — the Deployment/Job the
-  Application reconciles.
- `domains/kubernetes/rbac.md` — the ServiceAccount + Role the
-  controller and the migration Job run as.
- `domains/compliance/policy-as-code.md` — the OPA gate is a
-  compliance-as-a-gate enforcement point.
- `domains/devops/P4 Rollback First` — `git revert` is the rollback;
-  `selfHeal` is the convergence.
@@ -34,9 +34,9 @@
 | Performance | C1, C3, C6, C7, C8 | Economy + measurement |
 | Observability | C1, C2, C6, C7, C8 | Self-referential (P7 derives from C7) |
 | Errors | C1, C2, C5, C6, C7 | Errors as data + reversibility |
-| Documentation | C1, C2, C3, C5, C6, C8 | Docs-as-code + living docs; economy of process (P1) |
+| Documentation | C1, C2, C3, C5, C6 | Docs-as-code + living docs |
 | Concurrency | C1, C3, C4, C5, C6, C7, C8 | Broadest derivation; locality (C4) unique |
-| DevOps | C1, C2, C3, C5, C7, C8 | Reproducibility + rollback; economy of effort (P2) |
+| DevOps | C1, C2, C3, C5, C7 | Reproducibility + rollback |
 | Infrastructure as Code | C1, C2, C3, C4, C5, C6, C7 | Declarative + state + composition; broadest derivation alongside Concurrency |
 | Kubernetes | C1, C2, C4, C5, C6, C7, C8 | Declarative + reversibility + economy; broad derivation (7 C-rules) |
 | GitOps + Operators | C1, C2, C3, C4, C5, C6, C7, C8 | Source-of-truth + reconciliation + pull-locality + least privilege; broadest derivation (8 C-rules, tied with i18n) |
Author	SHA1	Message	Date
Jon Chery	61043dea1b	docs(P4): complete matrix + review + manifest integration phase ---ci--- project: atelier phase: 4 milestone: v0.3 status: complete requirements: covered: [ATELIER-80, ATELIER-81, ATELIER-82, ATELIER-83, ATELIER-84, ATELIER-85] partial: [] ---/ci---	2026-08-05 03:35:26 +00:00
Jon Chery	44a7049860	docs(ship): P3 complete — checkpoint + roadmap status ---ci--- project: atelier phase: 3 milestone: v0.3 status: complete phase_tag: v0.2.3 release_id: 471 ---/ci---	2026-08-05 03:30:29 +00:00
Jon Chery	7dfd3cdc6c	docs(P3): complete i18n + compliance domains phase ---ci--- project: atelier phase: 3 milestone: v0.3 status: complete requirements: covered: [ATELIER-70, ATELIER-71, ATELIER-72, ATELIER-73, ATELIER-74, ATELIER-75, ATELIER-76, ATELIER-77, ATELIER-78, ATELIER-79] partial: [] ---/ci---	2026-08-05 03:30:14 +00:00
Jon Chery	c026c8930b	docs(ship): P2 complete — checkpoint + roadmap status ---ci--- project: atelier phase: 2 milestone: v0.3 status: complete phase_tag: v0.2.2 release_id: 470 ---/ci---	2026-08-05 03:24:26 +00:00
Jon Chery	32edb19c96	docs(P2): complete ai-ml domain phase ---ci--- project: atelier phase: 2 milestone: v0.3 status: complete requirements: covered: [ATELIER-65, ATELIER-66, ATELIER-67, ATELIER-68, ATELIER-69] partial: [] ---/ci---	2026-08-05 03:24:13 +00:00
Jon Chery	ab1289a9d9	docs(ship): P1 complete — checkpoint + roadmap status ---ci--- project: atelier phase: 1 milestone: v0.3 status: complete phase_tag: v0.2.1 release_id: 469 ---/ci---	2026-08-05 03:21:04 +00:00
Jon Chery	47674969a1	docs(P1): complete gitops-operators domain phase ---ci--- project: atelier phase: 1 milestone: v0.3 status: complete requirements: covered: [ATELIER-60, ATELIER-61, ATELIER-62, ATELIER-63, ATELIER-64] partial: [] ---/ci---	2026-08-05 03:20:48 +00:00
Jon Chery	ce36db0579	docs(ship): P0 complete — checkpoint + roadmap status ---ci--- project: atelier phase: 0 milestone: v0.3 status: complete phase_tag: v0.2.0 release_id: 468 ---/ci---	2026-08-05 03:17:10 +00:00
Jon Chery	b7da50f56e	docs(P00): complete pre-execution phase — v0.3 ---ci--- project: atelier phase: 0 milestone: v0.3 status: complete requirements: covered: [ATELIER-60..91 governance: spec, clarify, research, ideate, plan, grill] partial: [] ---/ci---	2026-08-05 03:16:41 +00:00