docs(P00): complete pre-execution phase

---ci--- project: atelier phase: 0 milestone: v0.2 status: complete requirements: covered: [ATELIER-governance] partial: [] ---/ci---
2026-08-05 02:00:24 +00:00
44 changed files with 72 additions and 3704 deletions
@@ -1,11 +1,10 @@
 {
-  "phase": 1,
-  "stage": "complete",
-  "milestone": "v0.3",
-  "phase_role": "execution",
+  "phase": 0,
+  "stage": "plan",
+  "milestone": "v0.2",
+  "phase_role": "pre_execution",
  "project": "atelier",
  "attempts": 0,
-  "updated_at": "2026-08-05T03:25:00Z",
-  "phase_tag": "v0.2.1",
-  "release_id": 469
+  "updated_at": "2026-08-05T01:30:00Z",
+  "milestone_complete": false
 }
@@ -12,11 +12,7 @@ atelier/
 ├── domains/                    # Domain-specific application of core
 │   ├── ... (v0.1: 11 domains)
 │   ├── infrastructure-as-code/ # v0.2: IaC tooling (terraform, opentofu, state, modules)
-│   ├── kubernetes/             # v0.2: k8s platform (workloads, networking, storage, rbac, helm, kustomize)
-│   ├── gitops-operators/       # v0.3: GitOps + Operators (argocd, flux, operators, progressive-delivery)
-│   ├── ai-ml/                  # v0.3: ML engineering (data-versioning, model-evaluation, serving, monitoring-drift)
-│   ├── i18n/                   # v0.3: internationalization (locale-resources, formatting, rtl-bidi, testing-i18n)
-│   └── compliance/             # v0.3: compliance/audit (audit-logs, data-retention, policy-as-code, evidence)
+│   └── kubernetes/             # v0.2: k8s platform (workloads, networking, storage, rbac, helm, kustomize)
 ├── languages/                  # Language-specific application of domains
 ├── review/                    # Evaluation checklists and anti-patterns
 ├── matrix/                    # Cross-reference: domain ↔ core
@@ -84,26 +80,4 @@ Two new top-level domains extend the tree under the same hierarchy rules:

 Both domains follow the v0.1 contract: 10 P-rules each, every rule traced to a core C-rule via the matrix, no orphans. The manifest (`MANIFEST.md`) is extended to keep them authoritative. No runtime code — examples are illustrative markdown with manifests in code fences only.

-See `.ciagent/atelier/RESEARCH.md` for the full prior-art survey and `.ciagent/atelier/PERSONAS.md` for the persona roster (3 custom active personas + 1 phase-specific platform-engineer; 3 default personas deactivated).
-
-## v0.3 Domain Additions
-
-Four new top-level domains extend the tree under the same hierarchy rules. All four follow the v0.1/v0.2 contract: 10 P-rules each, every rule traced to a core C-rule via the matrix, no orphans, docs-only markdown with illustrative code fences (no runtime/deployable artifacts). Total matrix grows from 130 → 170 domain principles across 13 → 17 domains.
-
- **`gitops-operators/`** — platform-automation domain. First principles govern the declarative-source-of-truth reconciliation loop shared by ArgoCD, Flux, Kubernetes Operators, and Progressive Delivery tooling (Argo Rollouts, Flagger). Depends on `core/`. Cross-links to `kubernetes/` (workloads, rbac, helm, kustomize — the platform GitOps reconciles onto), `infrastructure-as-code/` (declarative intent, state-as-truth — the shared model), `devops/` (P1 Reproducibility, P4 Rollback First, P5 Progressive Delivery, P6 Configuration as Code), `security/` (secrets, supply-chain — GitOps credentials, signed manifests), `observability/` (reconciliation metrics, drift visibility). Derived docs: `argocd.md`, `flux.md`, `operators.md`, `progressive-delivery.md`.
- **`ai-ml/`** — ML engineering domain (engineering discipline, NOT algorithm design per D-023). First principles govern data versioning, model evaluation, serving, and monitoring/drift. Depends on `core/`. Cross-links to `data/` (schema-design, migrations, indexing — data lineage and versioning share the migration/reversibility model), `observability/` (metrics, tracing — model serving metrics, drift signals), `devops/` (P1 Reproducibility — training/serving reproducibility, P7 Immutability — model images), `security/` (input-validation — inference input validation, secrets — model/serving credentials), `performance/` (backend — serving latency). Derived docs: `data-versioning.md`, `model-evaluation.md`, `serving.md`, `monitoring-drift.md`.
- **`i18n/`** — internationalization domain. First principles govern locale resources, formatting, RTL/bidi layout, and testing. Depends on `core/`. Cross-links to `uiux/` (components, accessibility, copywriting — locale-aware UI is the consumer), `testing/` (fixtures, pyramid — i18n testing parallels), `api/` (error-responses — localized API errors), `data/` (schema-design — locale data shapes). Derived docs: `locale-resources.md`, `formatting.md`, `rtl-bidi.md`, `testing-i18n.md`.
- **`compliance/`** — compliance/audit domain (framework-agnostic, NOT regulation-specific per D-024). First principles govern audit logs, data retention, policy-as-code, and evidence collection. Depends on `core/`. Cross-links to `security/` (authorization — who did what, secrets — audit log integrity, supply-chain — signed policy), `observability/` (logging, metrics — audit logs are a structured-logging concern, tracing — evidence from distributed traces), `data/` (schema-design, migrations — retention schema), `infrastructure-as-code/` (policy-as-code parallels IaC declarative intent), `kubernetes/` (rbac — audit subject identity). Derived docs: `audit-logs.md`, `data-retention.md`, `policy-as-code.md`, `evidence.md`.
-
-All four domains depend on `core/` only for authority; cross-links to existing domains are one-directional (per v0.2 D-026 convention extended to v0.3 — minimize churn to existing content). The manifest (`MANIFEST.md`) is extended in P4 to list all new documents. Examples (P5) are illustrative markdown with fenced code only — no `.yaml`, `.json`, `.po`, model artifacts, or deployable manifests as standalone files.
-
-## v0.3 Ideation Architectural Notes
-
-From the v0.3 ideation stage (IDEATE-17..30), the following architectural refinements are baked into the execute-phase plan:
-
- **Manifest scope expansion (IDEATE-17 → ATELIER-91):** the v0.2 audit escalation (ESC-002 note) flagged that `examples/` is not listed in `MANIFEST.md`. P4 adds an `examples/` directory listing to the manifest, closing the pre-existing drift. The manifest remains authoritative; unlisted directories are not part of the framework by definition.
- **Matrix coverage summary invariants (IDEATE-18 → ATELIER-80):** the matrix coverage summary must reflect post-v0.3 totals (17 domains, 170 P-rules) — both the summary block and the per-domain section count.
- **Core Principle Coverage table (IDEATE-19 → ATELIER-81):** `matrix/domain-coverage.md` contains two tables — the per-domain row schema table (covered by v0.2 IDEATE-03) AND the "Core Principle Coverage" table mapping C1–C8 → domains. Both must be extended for the 4 new domains; the C-rule counts shift (e.g., C4 Locality adds i18n + gitops; C5 Reversibility adds ai-ml + compliance + gitops + i18n).
- **Cross-link type unchanged:** v0.3 introduces no new cross-link type. All cross-links remain one-directional outward from new domains to existing (D-033). No back-link edits to v0.1/v0.2 content.
-
-See `.ciagent/atelier/RESEARCH.md` "v0.3 Research" for the full prior-art survey and principle inventory rationale, and `.ciagent/atelier/PERSONAS.md` for the v0.3 persona roster (5 active: lead-developer, tech-writer, domain-expert + 2 phase-specific platform-engineer, ml-engineer; 3 default personas deactivated).
+See `.ciagent/atelier/RESEARCH.md` for the full prior-art survey and `.ciagent/atelier/PERSONAS.md` for the persona roster (3 custom active personas + 1 phase-specific platform-engineer; 3 default personas deactivated).
@@ -1,78 +0,0 @@
-# Atelier — v0.2 Post-Sync Audit (Re-audit)
-
-> Re-audit of milestone v0.2 after upstream sync (main + tags pushed to origin).
-> Triggered by user observation that v0.2 releases existed but code/tags were not pushed to remote main.
-> This audit verifies the now-synced state is clean.
-
-## Context
-
-During the original v0.2 run, `git push origin main --tags` failed because git-over-HTTPS required username/password auth and only `GITEA_API_TOKEN` (API token) was available. The Gitea releases (462–467) were created via the API, but the local merge commits and tags never reached the remote. This re-audit was requested after the fix.
-
-### Fix Applied
-
- Configured `git config --local http.https://git.cloudinit.dev/.extraheader "Authorization: token $GITEA_API_TOKEN"` to authenticate git transport with the API token.
- Pushed `main`: `89d5668..9db0df1 main -> main` (success).
- Force-updated remote tags `v0.1.0`–`v0.1.5` (they previously existed but pointed at the stale `milestone/v0.1-atelier` tip `5f522962`; now point at the correct v0.2 phase commits).
-
-## Audit Results
-
-### 1. Reconstruction test — PASS
- `origin/main` now contains the 2 v0.2 squash-merge commits (`d1aa5da` milestone merge, `9db0df1` milestone completion). Phase history preserved via tags.
- `REQUIREMENTS.md`: 59 requirements marked `covered`, 0 `pending` (matches 24 v0.2 + 35 v0.1).
- `ROADMAP.md`: `v0.2 — ... (COMPLETE)`.
- `config.json`: project status `complete`.
-
-### 2. Branch hygiene — PASS
- Only `main` branch exists locally; no leftover v0.2 phase/milestone branches.
- Remote: `main` + `milestone/v0.1-atelier` (the v0.1 milestone branch, untouched — preserved as history).
-
-### 3. Commit discipline — PASS
- All 2 v0.2 commits on main contain `---ci---` blocks (squash-merge structure means main sees 1 commit per phase-merge + 1 milestone-completion commit; full per-phase history in tags).
-
-### 4. File discipline — PASS
- `.ciagent/atelier/` contains all required files: PROJECT, ROADMAP, REQUIREMENTS, ARCHITECTURE, PERSONAS, PLAN, RESEARCH, CLARIFY, REVIEW-P5.
- v0.1 legacy files (AUDIT-P2, REVIEW-P7) preserved — harmless history.
-
-### 5. Tag sequence — PASS (local ↔ remote aligned)
- All 15 tags (v0.0.0–v0.0.7, v0.1.0–v0.1.5) present on both local and remote.
- All annotated tags dereference to identical commits on both sides.
- v0.0.x tags untouched (point to v0.1 milestone commits). v0.1.x tags now point to correct v0.2 phase commits (v0.1.0=P0, v0.1.1=P1, ..., v0.1.5=P5=milestone release).
-
-### 6. Manifest discipline — PASS (with noted convention)
- All 12 new v0.2 domain docs (infrastructure-as-code/*, kubernetes/*) listed in MANIFEST Domains table.
- matrix, agent-checklist, peer-review-checklist, anti-patterns all listed in Cross-Cutting.
- **Convention note (P1, pre-existing):** examples/ (both v0.1 and v0.2) are not individually listed in MANIFEST. The manifest's own rule states "unlisted = not part of the framework," yet examples are unlisted by convention across both milestones. This is a latent inconsistency, not a v0.2 regression. Candidate for v0.3 ideation: add an Examples section to MANIFEST, or amend the rule to scope it to Core/Domains/Cross-Cutting.
-
-### 7. Remote releases — PASS
- 6 v0.2 releases exist on Gitea (ids 462–467, tags v0.1.0–v0.1.5).
- v0.1 releases intact (ids 454–461, tags v0.0.0–v0.0.7, with v0.0.7 = the v0.1 milestone release).
- Total: 14 releases across both milestones.
-
-### 8. Structural verification (remote main) — PASS
- IaC first-principles: 10 P-rules ✓
- K8s first-principles: 10 P-rules ✓
- Matrix: 130 total P-rule rows across 13 domains + coverage summary (14 sections) ✓
- IaC matrix rows: 10 ✓; K8s matrix rows: 10 ✓
- IaC derived docs: 4 (terraform, opentofu, state, modules) ✓
- K8s derived docs: 6 (workloads, networking, storage, rbac, helm, kustomize) ✓
- v0.2 examples: 4 (terraform-module, k8s-deployment, terraform-unlocked-state, k8s-bare-pod-no-resources) ✓
-
-### 9. Security (docs-only constraint) — PASS
- No standalone `.tf`, `.yaml`, `.yml`, `.sh` files in the repo — docs-only constraint preserved.
- All code is fenced within `.md` files.
-
-### 10. Requirements traceability — PASS
- 59 covered, 0 pending (24 v0.2 + 35 v0.1).
-
-## Verdict
-
-**AUDIT CLEAN.** No critical (P0) issues. One P1 convention note (examples not in MANIFEST — pre-existing, candidate for v0.3 ideation). The upstream sync fixed the v0.2 release/push gap: remote main, all 15 tags, and all 6 Gitea releases are now consistent and correct.
-
-## Escalation Log
-
-| ID | Issue | Resolution | Type |
-|----|-------|-----------|------|
-| ESC-001 | v0.2 main + tags not pushed to remote (git transport auth) | Configured http.extraheader with GITEA_API_TOKEN; pushed main + force-updated tags | auto-resolved |
-| ESC-002 | Remote v0.1.x tags pointed to stale milestone/v0.1-atelier tip | Force-updated all 6 v0.1.x tags to correct v0.2 phase commits | auto-resolved |
-
-Both escalations auto-resolved at full autonomy. No pipeline halt.
@@ -1,175 +0,0 @@
-# Atelier — Grill (Adversarial Red-Team Review)
-
-> Pre-execution gate for milestone v0.3 (GitOps + Operators + AI/ML + i18n + Compliance).
-> 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.3 Grill — 2026-08-05
-
-**Milestone:** v0.3 — GitOps + Operators + AI/ML + i18n + Compliance
-**Phase:** 0 (Pre-Execution, GRILL stage)
-**Grill scope:** all 9 axes + meta
-**Prior grill runs:** none (v0.1/v0.2 P0 stages did not include a GRILL stage; this is the first)
-
-### Verdict: **PROCEED** (confidence 0.80)
-
-The project is ambitious but deliberately bounded. Scope has been trimmed in three places (D-023 AI/ML engineering-only, D-024 compliance framework-agnostic, D-025 2+2 examples). Two prior milestones (v0.1: 35 reqs, v0.2: 24 reqs) shipped clean with the same docs-only NFR structure. The 4-domain scope is the largest single milestone yet, but per-phase derived-doc counts (P1: 4, P2: 4, P3: 8) are lower than v0.1's P3 (27 derived docs in one phase). Traceability verification is explicit (P4 matrix row-count test: 10 × 17 = 170; P5 cross-link audit). The one residual risk — P3 i18n/compliance content authored without specialist personas — is bounded by RESEARCH.md prior-art depth and P6 domain-expert review, with rework being cheap (markdown edits).
-
---
-
-### Axis 1 — The Business Case Itself
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 1.1 | What problem does this solve, and is it still the top priority? | RESEARCH.md: "Atelier's differentiation: traceable principle hierarchy with a join table. Existing frameworks state principles; none provide a matrix mapping every domain rule back to a core rule." v0.1/v0.2 shipped (59 reqs covered). | A first-principles engineering framework with a traceable principle matrix — the join table is the unique value. v0.3 extends the domain catalog (GitOps, AI/ML, i18n, compliance) that v0.2 deferred (IDEATE-15/16). Still the top priority: the 4 domains were explicitly deferred to v0.3, not abandoned. | 0.78 |
-| 1.2 | Who is the named executive sponsor, and when did they last decide under pressure? | git log: all commits by Jon Chery (jchery@jccapital.xyz). config.json autonomy: "full". | Single-owner project. The "sponsor" is the owner-operator. The last decision under pressure: v0.2 ESC-001/ESC-002 (git transport auth failure, stale tags) — resolved at full autonomy (AUDIT-P5-resync.md). Not a committee-driven project; no sponsor-stall risk. | 0.80 |
-| 1.3 | What happens to the business if the project is cancelled? | PROJECT.md objective; MANIFEST.md current state (13 domains, 130 P-rules post-v0.2). | The framework remains at v0.2 (13 domains). The 4 deferred domains (GitOps, AI/ML, i18n, compliance) stay deferred — a 2x deferral that risks zombie status. Cancellation is worse than proceeding: the deferral was already made once. | 0.82 |
-| 1.4 | Is the ROI calculated against a counterfactual? | N/A — docs-only project, no monetary budget. Cost = agent tokens + time. | The counterfactual is "agents and humans have no canonical principle reference for GitOps/AI-ML/i18n/compliance." The ROI is framework coverage. Two prior milestones validated the cost model (docs-only, no infra). | 0.75 |
-
-**Axis 1 confidence: 0.79.** No challenges. Auto-resolve.
-
-### Axis 2 — Scope and Requirements
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 2.1 | Is the scope expanding, contracting, or stable? | PROJECT.md D-016 (4 domains grouped to limit release overhead), D-023 (AI/ML = engineering discipline, NOT algorithm design), D-024 (compliance framework-agnostic, NOT regulation-specific), D-025 (2+2 examples, not 4+4). | Scope is **expanding** (4 new domains, the largest milestone yet) but **deliberately trimmed** in three places. D-023/D-024/D-025 are scope-discipline decisions, not scope-creep. The trims reduce the surface from a hypothetical 4+4 examples + regulation-specific compliance docs + algorithm-design AI/ML to a bounded 2+2 + framework-agnostic + engineering-only. | 0.80 |
-| 2.2 | Who owns the requirements, and are they frozen? | REQUIREMENTS.md ATELIER-60..91 (32 reqs, all pending). Traceability matrix maps phases→reqs. Ideation log (IDEATE-17..30) shows 14 accepted, 0 deferred, 0 rejected. | Requirements are frozen post-ideation. 32 reqs across 6 phases. The ideation stage closed with 0 deferred — everything generated is in v0.3 scope. No moving targets. | 0.85 |
-| 2.3 | What is explicitly out of scope? | PROJECT.md lines 49-55: tooling/linters, translation of framework docs, agent integration adapters, per-domain release artifacts, runtime code. D-023: algorithm/model design. D-024: regulation-specific compliance docs. | Out of scope is explicit and enumerated: no runtime code, no tooling, no translation, no regulation-specific docs, no algorithm design. The scope boundary is answerable — not infinite. | 0.88 |
-| 2.4 | Are there hidden requirements disclosed late? | RESEARCH.md: ai-ml cross-links to data/ (schema, migrations) but D-023 scopes AI/ML to engineering discipline, not data engineering. PERSONAS.md: data-engineer explicitly inactive ("No database, schema, or migrations in this docs-only project"). | No hidden requirements detected. AI/ML does NOT imply a data-engineer persona — D-023's engineering-discipline scope excludes data engineering (schema/ETL/pipelines). The cross-link to data/ is a reference, not a duplication. | 0.85 |
-
-**Axis 2 confidence: 0.84.** Challenge: is 4-domain scope too ambitious for one milestone? → Auto-resolved (G-001). Challenge: hidden data-engineer persona requirement? → Auto-resolved (G-008).
-
-### Axis 3 — Architecture and Technical Feasibility
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 3.1 | Has the architecture been validated by builders, not just sellers? | RESEARCH.md: prior-art surveys for all 4 domains (OpenGitOps Principles v1.0.0, Sculley "Hidden Technical Debt", ICU/CLDR/BCP 47, NIST/SOC2/OPA). ARCHITECTURE.md: v0.3 domain additions section with cross-link map. | The architecture (hierarchical doc tree + matrix join table) is validated by 2 prior shipped milestones. The 4 new domains follow the same v0.1/v0.2 contract: 10 P-rules each, trace to ≥1 C-rule, docs-only. RESEARCH.md pre-maps all 40 P-rules to C-rules before execution. | 0.85 |
-| 3.2 | What is the integration surface? | ARCHITECTURE.md: cross-links one-directional (D-033). RESEARCH.md: gitops→6 domains, ai-ml→6 domains, i18n→4 domains, compliance→6 domains. D-033: no back-link edits to v0.1/v0.2 content. | The integration surface is cross-links only — one-directional outward from new domains to existing. No back-link edits to v0.1/v0.2 content (D-033). This minimizes churn. Every new derived doc requires ≥1 outbound cross-link (ATELIER-88, verified in P5). | 0.86 |
-| 3.3 | Is there an existing system being replaced? What is the data volume? | MANIFEST.md: 13 domains, 130 P-rules post-v0.2. matrix/principles-matrix.md: 212 lines, 13 domain sections. | No system is replaced — the framework is extended. Matrix grows 130→170 P-rules. At 170 rows, the matrix is a large but single readable markdown file. domain-coverage.md provides the C-rule→domains navigation view. The matrix is the arbiter; its size is linear with domains. | 0.84 |
-| 3.4 | What technical debt is inherited? | AUDIT-P5-resync.md §6: "examples/ not in MANIFEST — pre-existing, candidate for v0.3." ATELIER-91, D-035: add examples/ listing to MANIFEST in P4. | One piece of inherited debt: examples/ unlisted in MANIFEST (ESC-002 convention note from v0.2 audit). v0.3 closes this explicitly (ATELIER-91, D-035, task 04-02-05). No other drift identified (A-001, confidence 0.85). | 0.85 |
-| 3.5 | Compliance has NO C4 (Locality) trace (D-032) — is that an architectural smell? | RESEARCH.md D-032: "compliance is inherently cross-cutting, not local." Compliance P-rules trace to C1,C2,C3,C5,C6,C7,C8 (7 of 8). Alternative considered: "force C4 via audit-log locality" — rejected. | **Not a smell.** C4 (Locality) is about keeping concerns local to their context. Compliance is the opposite — it is inherently system-wide (audit logs span the whole system, retention policy is global, evidence is cross-cutting). Forcing a C4 trace would be a false derivation. D-032's rationale is architecturally sound: the absence reflects the domain's nature, not a gap. | 0.82 |
-| 3.6 | Is the docs-only constraint (D-020) defensible at 17 domains? | PROJECT.md constraint: "no runtime code." MANIFEST.md is the authoritative index. ARCHITECTURE.md: reading-order guides consumption. matrix/principles-matrix.md is the join table. | **More defensible at 17 domains, not less.** The docs-only constraint is what makes the framework scalable: no runtime complexity, no integration surface, no deployment, no build step. At 17 domains, the MANIFEST + reading-order + matrix make the tree navigable. The framework's value (traceable hierarchy) scales linearly — more domains = more value, as long as traceability holds. A build step or runtime would violate docs-as-code simplicity and add the exact integration surface the framework avoids. | 0.88 |
-
-**Axis 3 confidence: 0.85.** Challenges: C4 gap (G-006), docs-only at 17 domains (G-007), matrix orphan risk (G-003), manifest drift (G-011). All auto-resolved.
-
-### Axis 4 — People, Skills, and Organization
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 4.1 | Which 2-3 people, if they left, would the project fail? | PERSONAS.md: 5 active personas (lead-developer, tech-writer, domain-expert + 2 phase-specific: platform-engineer, ml-engineer). D-051: ml-engineer constraints baked into P5 task must-have. | In an AI-agent docs project, "personas" are constraint sets, not human employees. The key-person risk is lower than in runtime projects. D-051 ensures ml-engineer constraints survive into P5 (examples) even though the persona is removed after P2. The constraint is baked into the task must-have, not the persona's continued presence. | 0.80 |
-| 4.2 | Are resources allocated at the claimed percentages? | config.json: max_concurrent_agents=5. PLAN.md: P3 Wave 2 splits 8 tasks into 2a/2b, capped at 5 concurrent (D-049). | Allocation is mechanical — the executor schedules ≤5 concurrent per config.json. P3's 8 derived docs run as 5-then-3 (A-003, confidence 0.90). P4 runs exactly 5 concurrent (D-050). No "in name only" allocation — this is agent execution, not human BAU fire-fighting. | 0.85 |
-| 4.3 | Is there a product owner with actual authority? | git log: single author (Jon Chery). config.json autonomy: "full". PROJECT.md: D-001..D-053 decision table. | Single owner-operator with full autonomy. No committee. Decisions are transparent (D-001..D-053 with confidence scores). Authority is unambiguous. | 0.85 |
-| 4.4 | Is the team building capability they don't have? | PERSONAS.md: P3 (i18n + compliance) authored by tech-writer + domain-expert — NO specialist persona (D-022). RESEARCH.md: i18n covers ICU/CLDR, BCP 47, UAX #9 bidi algorithm; compliance covers OPA/Cedar/Kyverno/Sentinel, Cosign/in-toto. | **This is the most material risk.** P3's i18n (RTL/bidi, UAX #9) and compliance (policy-as-code engine semantics) have genuine specialist depth. The tech-writer persona authored v0.1's security/data/concurrency domains without specialists and shipped clean — but those are more universally known than bidi algorithms and Rego semantics. **Mitigation:** RESEARCH.md provides thorough prior-art surveys with specific source citations (unicode.org, W3C i18n WG, openpolicyagent.org, kyverno.io). The P6 review includes domain-expert validation. Rework, if needed, is bounded (markdown edits, not infrastructure). **Assumption logged (A-006):** i18n RTL/bidi and compliance policy-as-code content correctness depends on RESEARCH.md prior-art quality + P6 review, not on a specialist persona. | 0.72 |
-| 4.5 | Are the phase-specific personas (platform-engineer, ml-engineer) a key-person risk? | PERSONAS.md: both are phase-specific, removed post-v0.3. D-027: platform-engineer reused/extended from v0.2. D-028: ml-engineer new. D-051: constraints baked into task must-haves. D-052: both review their content in P6 before removal. | **Not a key-person risk.** Personas are constraint sets, not people. Platform-engineer is a proven reuse from v0.2 (shipped clean). Ml-engineer is new but its constraints are explicitly enumerated and baked into task must-haves (D-051). Both review their content in P6 before removal (D-052). If either "fails," the fallback is tech-writer + domain-expert + RESEARCH.md grounding. | 0.80 |
-
-**Axis 4 confidence: 0.80.** Challenge: P3 specialist-persona competency gap (G-009). Auto-resolved with assumption A-006.
-
-### Axis 5 — Timeline and Estimates
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 5.1 | Was the deadline set before or after scope/approach were understood? | git log: specify (c96d21c) → clarify (675abb6) → research (0620c94) → ideate (1a0326b) → plan (d8473d6). PLAN.md created after research + ideation. | The phase plan was created AFTER research and ideation — the scope was understood before the plan was written. No reverse-engineered deadlines. The "timeline" is the phase sequence P0→P6, not an external date. | 0.88 |
-| 5.2 | What is the critical path, and what would push it by 3+ months? | PLAN.md: P1→P2→P3→P4→P5→P6, all sequential. P4 (matrix) depends on all domains. P5 (examples) depends on P4 (manifest). | Critical path: P1→P2→P3→P4→P5→P6. **Nothing can push it by 3+ months** — this is a docs project with no external dependencies, no infrastructure provisioning, no vendor lead times. The only "push" is content-quality rework, which is bounded (markdown edits). | 0.90 |
-| 5.3 | Are estimates evidence-based? | v0.1: 35 reqs, 7 phases, shipped. v0.2: 24 reqs, 5 phases, shipped. v0.3: 32 reqs, 6 phases. Per-phase doc counts: P1=5, P2=5, P3=10, P4=7, P5=4, P6=2. | Estimates are analogous (v0.1/v0.2 shipped with similar per-phase doc counts). v0.1 P3 produced 27 derived docs in one phase; v0.3's largest phase (P3) produces 10. The estimate is conservative relative to v0.1's demonstrated throughput. | 0.85 |
-| 5.4 | Is there a working definition of done? | PLAN.md P6 Verify: all 32 reqs covered, reconstruction test passes, matrix row-count test (170), MANIFEST reconstruction test (incl. examples/), audit clean, tag v0.2.6 exists, branches deleted. | DoD is concrete and testable: 32 reqs covered, matrix = 170 rows (10 × 17), MANIFEST reconstruction passes, tag v0.2.6 on main. Not "whatever the demo shows." | 0.88 |
-
-**Axis 5 confidence: 0.88.** No challenges.
-
-### Axis 6 — Budget and Financial Realism
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 6.1 | What % of budget is spent vs remaining? | N/A — docs-only, no monetary budget. Cost = agent tokens. v0.1/v0.2 completed within expected token bounds. | No monetary budget. Token cost is proportional to markdown authored. v0.3 is the largest milestone (32 reqs, 18 derived docs + 4 examples + extensions), but per-doc token cost is roughly constant and validated by 2 prior milestones. | 0.85 |
-| 6.2 | Are there predictable cost drivers not in the original budget? | PROJECT.md: no runtime code, no infrastructure, no licensing, no external services. | None. Docs-only = no licensing, no infra, no security review fees, no data migration, no support contracts. The only cost driver is markdown volume, which is scoped by REQ count. | 0.90 |
-| 6.3 | Burn rate and runway? | N/A — no monetary burn. Agent execution time is the only resource. | No monetary runway concern. Agent execution is bounded by phase task count. | 0.88 |
-| 6.4 | Is the budget contingent on something? | config.json: no contingent conditions. | No. The project is not contingent on a sale, board approval, or hiring. | 0.90 |
-
-**Axis 6 confidence: 0.88.** No challenges. The docs-only constraint makes this axis low-risk by construction.
-
-### Axis 7 — Risks, Assumptions, and Dependencies
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 7.1 | Top 3 assumptions the plan rests on? | PLAN.md Assumptions: A-001 (ESC-002 is the only manifest drift, 0.85), A-002 (4 domains map to C1-C8 without new core principles, 0.95), A-003 (P3 Wave 2 schedules 5-then-3, 0.90). | A-002 is the strongest (0.95) — RESEARCH.md pre-maps all 40 P-rules to existing C-rules. A-001 is reasonable (AUDIT-P5-resync.md confirms). A-003 is mechanical (config.json cap). All three have evidence. | 0.86 |
-| 7.2 | External dependencies? | PROJECT.md: no runtime code. RESEARCH.md: all prior art is published (OpenGitOps, ICU/CLDR, NIST, OPA docs). | None. No vendor, regulator, or external team dependency. All prior art is published and cited. The framework is self-contained markdown. | 0.92 |
-| 7.3 | Single project-killing risk? | RESEARCH.md Risks table: orphaned P-rules, domain overlap, AI/ML scope drift, compliance bloat, artifact leakage, persona explosion. | The single risk that would undermine the framework's core value: **matrix orphan P-rules.** If the 40 new P-rules don't trace cleanly to C-rules, the traceable hierarchy (the unique value proposition) is broken. **Mitigation:** P4 matrix row-count test (10 per domain × 17 = 170) + domain-expert sign-off + P6 reconstruction test. This is well-mitigated and explicitly verified. | 0.84 |
-| 7.4 | Pre-mortem: 12 months from now, v0.3 failed. Why? | (adversarial analysis) | **Most likely failure:** P3 content quality — i18n RTL/bidi or compliance policy-as-code authored without specialist personas contains fundamental technical errors (e.g., bidi isolating run misuse, Rego evaluation model mischaracterization), caught in P6 review, requiring P3 rework. **Secondary:** the 2+2 example set leaves 2 domains without a good example (gitops + ai-ml get good examples; i18n + compliance get only bad examples), reducing adoption value. **Both are bounded** — rework is markdown edits, not infrastructure. Neither is project-killing. | 0.78 |
-
-**Axis 7 confidence: 0.85.** Challenge: pre-mortem P3 content quality (G-012). Auto-resolved.
-
-### Axis 8 — Governance, Decision-Making, and Communication
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 8.1 | Who is the decision-maker when executives disagree? | git log: single author. config.json: autonomy "full". | Single owner-operator. No executive disagreement possible. Decisions are recorded in PROJECT.md (D-001..D-053) with confidence scores. | 0.88 |
-| 8.2 | How often does governance meet, and what's the escalation pattern? | config.json: autonomy level "full", escalation_hooks ["deploy", "delete_data", "merge_to_main"], decision_confidence_threshold 0.6, escalation_timeout_ms 300000. | Governance is the ciagent workflow itself (specify→clarify→research→ideate→plan→grill→execute→review→audit→ship). Escalation: 3 hooks (deploy, delete_data, merge_to_main) + timeout 300s. The grill stage (this) is the pre-execution gate. Cadence is event-driven, not calendar-driven — appropriate for agent execution. | 0.82 |
-| 8.3 | What is omitted from status reports? | AUDIT-P5-resync.md: candid about ESC-001/ESC-002 (git auth failure, stale tags). Convention note about examples/ MANIFEST drift flagged, not hidden. | Status reporting is transparent. The v0.2 audit explicitly flagged the examples/ MANIFEST drift (ESC-002) rather than burying it. v0.3 picks it up as ATELIER-91. No evidence of optimistic glossing. | 0.85 |
-| 8.4 | Is there a "stop the project" trigger? | This grill stage. Verdict options: Proceed, Reduce scope, Rethink, Escalate. | The grill IS the stop-the-project gate. If the verdict were "Rethink" or "Escalate" with blocking issues, P1 would not proceed. Cancellation is not politically impossible — it's a mechanical verdict. | 0.85 |
-
-**Axis 8 confidence: 0.85.** No challenges.
-
-### Axis 9 — Change, Adoption, and Operational Readiness
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| 9.1 | Who uses this, how does their work change, what's in it for them? | PROJECT.md: "consumed by AI agents as pre-completion guidance and by humans as engineering canon." review/agent-checklist.md is the pre-completion gate. | Users: AI agents (read MANIFEST→core→domains before tasks) and humans (engineering reference). Their work changes by consulting a traceable principle hierarchy before acting. The value: conflict resolution has an arbiter (the matrix), not just opinions. | 0.80 |
-| 9.2 | Is the operations team involved now or handed a finished product? | N/A — docs-only repo, no operations team. | No operations team. The "go-live" is tagging v0.2.6 + merging to main. No runtime to operate, no on-call, no SLO. | 0.92 |
-| 9.3 | What is the rollback plan? | Standard git workflow: revert + re-tag. | Git revert + re-tag. Standard for docs repos. v0.2 demonstrated the pattern (ESC-002 force-updated tags). | 0.88 |
-| 9.4 | Have success criteria been validated with judges? | ROADMAP.md Success Criteria: all checked for v0.1. v0.2 completed clean (AUDIT-P5-resync.md: 10 checks pass). | Success criteria validated by 2 prior milestones. The pattern: reqs covered + reconstruction test + audit clean + tag exists. v0.3 adds matrix row-count test (170) and MANIFEST reconstruction (incl. examples/). | 0.85 |
-
-**Axis 9 confidence: 0.86.** No challenges.
-
-### Meta — Closing Review
-
-| # | Forcing Question | Evidence | Answer | Confidence |
-|---|-----------------|----------|--------|------------|
-| M.1 | If you were the auditor, what would you flag? | (adversarial analysis) | The P3 specialist-persona gap (i18n + compliance authored by tech-writer without specialists). It's a content-quality risk, not a traceability risk. The mitigation (RESEARCH.md depth + P6 review) is adequate but not redundant — there's no second layer of content validation beyond domain-expert traceability checks. | 0.75 |
-| 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). This is explicitly out of scope (tooling is future work). At 170 P-rules, manual verification is still feasible but approaching the limit where tooling would be warranted. Not a v0.3 blocker. | 0.80 |
-| M.3 | Simplest 80% version? | (adversarial analysis) | Ship 2 domains (gitops-operators + ai-ml) and defer i18n + compliance to v0.4. This halves the scope. **But:** v0.2 already deferred these once (IDEATE-15/16). Re-deferral makes them 2x deferred — zombie risk. The current 4-domain plan is better than re-deferral. D-022's pairing of the two smaller domains in P3 is the right load-balance call. | 0.82 |
-| M.4 | What must be true in 90 days for success, and is it true today? | (adversarial analysis) | Must be true: (a) 40 new P-rules trace cleanly to C-rules — RESEARCH.md pre-maps them, P4 verifies. (b) 18 derived docs each have ≥1 valid cross-link — ATELIER-88 verifies in P5. (c) Content is technically correct (especially i18n bidi + compliance policy-as-code) — RESEARCH.md grounds it, P6 validates. (a) and (b) have explicit verification gates. (c) depends on execution quality. All three are achievable. | 0.80 |
-
-**Meta confidence: 0.79.**
-
---
-
-### Binding Decisions
-
-| ID | Decision | Rationale | Confidence | Alternatives |
-|----|----------|-----------|------------|--------------|
-| G-001 | Proceed with 4-domain scope as planned; do not split into v0.3a/v0.3b | Scope is deliberately trimmed (D-023/D-024/D-025); per-phase doc counts (P1:4, P2:4, P3:8) are lower than v0.1 P3 (27); v0.2 already deferred these domains once — re-deferral risks zombie status; D-016 groups them to limit release overhead | 0.80 | Split into 2 milestones (rejected: 2x deferral + double release overhead); reduce to 2 domains (rejected: same) |
-| G-002 | Phase-specific personas (platform-engineer, ml-engineer) are NOT a key-person risk | Personas are constraint sets, not humans; D-051 bakes constraints into task must-haves (survive persona removal); D-052 ensures both review content in P6 before removal; platform-engineer is proven reuse from v0.2 (shipped clean) | 0.80 | Add more specialist personas (rejected: persona explosion); remove phase-specific personas (rejected: content quality risk) |
-| G-003 | 40 new P-rules will trace cleanly to C-rules; matrix orphan risk is mitigated | RESEARCH.md pre-maps all 40 P-rules to C-rules (D-029..D-032); P4 matrix row-count test (10 × 17 = 170) + domain-expert sign-off; P6 reconstruction test; A-002 (confidence 0.95) confirms core is stable at 8 | 0.85 | Force broader C-rule derivations (rejected: false derivations worse than accurate narrow ones); add new core principles (rejected: A-002 confirms unnecessary) |
-| G-004 | i18n + compliance pairing in P3 (D-022) is load-balancing-sound | Both are 4-derived-doc domains (smaller surface than P1/P2); P3 Wave 2 schedules 8 docs as 5-then-3 (A-003, 0.90); the scheduling is not a bottleneck — the content-quality risk is (see G-009) | 0.82 | Separate i18n and compliance into distinct phases (rejected: adds a phase, no load benefit); move one to P2 (rejected: P2 is AI/ML, a heavier domain) |
-| G-005 | 2-good + 2-bad example set (D-025) is adequate for 4 domains | Each domain gets exactly 1 example (gitops: good, ai-ml: good, i18n: bad, compliance: bad); ATELIER-84 adds 4 domain-specific anti-patterns per domain (16 total) = 5 illustration points per domain; v0.1 had 7 examples for 11 domains (most domains had 0) — v0.3 is better coverage | 0.75 | 4-good + 4-bad (rejected: D-025 unbalances P5); 1-per-domain good only (rejected: bad examples have higher illustration value for i18n/compliance) |
-| G-006 | Compliance C4 (Locality) gap (D-032) is architecturally sound, NOT a smell | C4 Locality is about keeping concerns local; compliance is inherently cross-cutting (audit logs span the system, retention is global, evidence is cross-cutting); forcing C4 would be a false derivation; D-032 considered and rejected the alternative "force C4 via audit-log locality"; the absence reflects the domain's nature | 0.82 | Force C4 via audit-log locality (rejected: false derivation); add a C4-tracing compliance P-rule (rejected: would be artificial) |
-| G-007 | Docs-only constraint (D-020) is defensible at 17 domains — more so, not less | The docs-only constraint eliminates runtime complexity, integration surface, deployment, and build steps — the exact things that make large frameworks unwieldy; MANIFEST + reading-order + matrix make the tree navigable at scale; the framework's value (traceable hierarchy) scales linearly with domains; 170 matrix rows is a large but single readable file | 0.88 | Add a build step / linter (rejected: out of scope, violates docs-as-code simplicity); split the matrix per-domain (rejected: destroys the join-table value) |
-| G-008 | No hidden data-engineer persona requirement from adding ai-ml domain | D-023 scopes AI/ML to engineering discipline (data versioning, evaluation, serving, drift), NOT data engineering (schema/ETL/pipelines); PERSONAS.md explicitly deactivates data-engineer ("No database, schema, or migrations in this docs-only project"); ai-ml cross-links to data/ as a reference, not a duplication | 0.85 | Activate data-engineer persona (rejected: no data engineering work in a docs-only project); scope AI/ML to include data engineering (rejected: D-023 explicitly excludes) |
-| G-009 | Proceed with tech-writer + domain-expert for P3 (i18n + compliance) without specialist personas | RESEARCH.md provides thorough prior-art surveys (ICU/CLDR, BCP 47, UAX #9, W3C i18n WG, OPA/Cedar/Kyverno/Sentinel, Cosign/in-toto) with specific source citations; v0.1 tech-writer authored security/data/concurrency without specialists and shipped clean; P6 review includes domain-expert validation; rework is bounded (markdown edits). **Assumption A-006 logged:** content correctness for i18n RTL/bidi and compliance policy-as-code depends on RESEARCH.md prior-art quality + P6 review | 0.72 | Add i18n-specialist + compliance-specialist personas (rejected: persona explosion, both domains are smaller-surface per D-022); defer i18n/compliance to v0.4 with specialists (rejected: 2x deferral zombie risk) |
-| G-010 | Matrix coverage summary must read "17 domains, 170 P-rules" post-v0.3 (reinforces D-036) | D-036 (confidence 0.93) already decided this; PLAN task 04-01-01 bakes it in; both the summary block AND per-domain section count must update; the P6 audit verifies row-count (10 × 17 = 170) | 0.93 | Partial update (rejected: invariant violation) |
-| G-011 | ATELIER-91 closes the v0.2 ESC-002 manifest drift (examples/ unlisted) | AUDIT-P5-resync.md §6 flagged examples/ not in MANIFEST as a P1 convention note; ATELIER-91 (D-035, confidence 0.85) adds examples/ directory listing to MANIFEST in P4; PLAN task 04-02-05 bakes it in; A-001 (0.85) confirms this is the only manifest drift | 0.85 | Leave examples/ unlisted (rejected: manifest is authoritative, unlisted = not part of framework by definition) |
-| G-012 | Pre-mortem top risk (P3 content quality) is bounded; no escalation needed | Most likely failure mode: i18n bidi or compliance policy-as-code technical errors caught in P6, requiring P3 rework. Mitigation: RESEARCH.md prior-art depth + P6 domain-expert review. Rework is bounded (markdown edits, not infrastructure). No external dependencies. The risk is real but recoverable and does not block the milestone. | 0.78 | Defer P3 to v0.4 (rejected: zombie risk); add specialist personas (rejected: G-009 analysis) |
-
-### Escalations
-
-**None.** All 12 challenges auto-resolved at confidence ≥ 0.60 (range: 0.72–0.93). At full autonomy, assumption logging (A-006) is preferred over escalation. No axis scored below 0.60 on any forcing question.
-
-### Assumptions Logged (this grill)
-
-| # | Assumption | Confidence |
-|---|-----------|------------|
-| A-006 | i18n RTL/bidi and compliance policy-as-code content correctness depends on RESEARCH.md prior-art quality + P6 domain-expert review, not on a specialist persona. If P6 surfaces fundamental content errors, the remedy is P3 rework (bounded — markdown edits). | 0.72 |
-
-### Summary
-
- **Challenges identified:** 12 (across 9 axes + meta)
- **Binding decisions:** 12 (G-001..G-012)
- **Escalations:** 0
- **Assumptions logged:** 1 (A-006)
- **Verdict:** PROCEED at confidence 0.80
- **Top 3 material challenges:**
-  1. **G-009 (0.72):** P3 i18n + compliance authored without specialist personas — the lowest-confidence decision. Content quality for bidi algorithms and policy-as-code semantics depends on RESEARCH.md depth, not specialist persona constraints.
-  2. **G-005 (0.75):** 2+2 examples across 4 domains — each domain gets only one example (good OR bad, not both). Adequate given 16 anti-patterns, but thinner than v0.2's per-domain coverage.
-  3. **G-001 (0.80):** 4-domain scope is the largest single milestone — bounded by D-023/D-024/D-025 trims, but re-deferral would create zombie risk.
- **No blocking escalations for SHIP.**
@@ -46,35 +46,19 @@

 ## Phase-Specific Personas

-### platform-engineer (v0.3 — extended, active for v0.3, removed after milestone completion)
+None. All three active personas span the full milestone. No phase-scoped personas needed — the work is uniformly markdown authoring with domain validation.
+
+## Phase-Specific Personas
+
+### platform-engineer (v0.2 — removed after milestone completes)

 - **active:** true
 - **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 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 — phase-specific, removed after milestone completion)
-
- **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) 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)
-
- **active:** false
- **phase_specific:** true
 - **domain:** infrastructure/platform
 - **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.
+- **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. Active for v0.2 P1–P4 only; removed after milestone v0.2 completes (per D-027, D-014).

 ## Territory Enforcement

@@ -82,9 +66,8 @@ 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.3 Persona Roster Summary
+## v0.2 Persona Roster Summary

-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).
+Active personas for v0.2 (4): lead-developer, tech-writer, domain-expert, platform-engineer (phase-specific).
+Inactive personas (3, unchanged from v0.1): data-engineer, backend-engineer, frontend-engineer.
+Post-v0.2: platform-engineer removed; roster returns to 3 active personas (lead-developer, tech-writer, domain-expert).
@@ -371,252 +371,4 @@ Tag: v0.1.0
 | 3 | ATELIER-48..52, 59 | 6 |
 | 4 | ATELIER-53..56 | 4 |
 | 5 | ATELIER-57, 58 | 2 |
-| **Total** | | **24** |
-
---
-
-# Atelier — Plan (v0.3)
-
-> Vertical-slice plans with wave ordering for milestone v0.3 (GitOps + Operators + AI/ML + i18n + Compliance). Plans reference REQ-IDs from `.ciagent/atelier/REQUIREMENTS.md` (ATELIER-60..91). 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.
-
-## Phase 0 — Pre-Execution (COMPLETE)
-
-Stages: SPECIFY ✓ → CLARIFY ✓ → RESEARCH ✓ → IDEATE ✓ → PLAN ✓ → GRILL → SHIP
-Branch: `atelier/phase/00-pre-execution`
-Tag: v0.2.0
-
-## Phase 1 — GitOps + Operators Domain
-
-**Goal:** Author the `domains/gitops-operators/` tree — 10 first principles (P1–P10) plus 4 derived docs (argocd, flux, operators, progressive-delivery). Grounded in CNCF OpenGitOps Principles v1.0.0 + the Operator pattern. Each P-rule derives from core C1–C8 (matrix extension lands in P4).
-**Branch:** `atelier/phase/01-gitops-operators` (from `atelier/milestone/v0.3-atelier`)
-**Personas:** platform-engineer (author), domain-expert (validate traceability), tech-writer (style/format)
-**Tag:** v0.2.1
-**Requirements:** ATELIER-60, ATELIER-61, ATELIER-62, ATELIER-63, ATELIER-64
-
-### Wave 1 (sequential — first-principles must exist before derived docs)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 01-01-01 | `domains/gitops-operators/first-principles.md` | platform-engineer | ATELIER-60 | 10 principles (P1–P10) per RESEARCH.md (Git is Source of Truth, Pull Don't Push, Continuous Reconciliation, Operators Encode Domain Knowledge, Progressive Delivery is Reversible, Reconcile Don't Mutate, Failure is Observable, Least Privilege Reconciliation); each names the core C-rule(s) it derives from; each has definition + "what violates" |
-
-### Wave 2 (parallel — 4 derived docs, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 01-02-01 | `domains/gitops-operators/argocd.md` | platform-engineer | ATELIER-61 | Application CRD, App-of-Apps, sync waves, health/status, diff, RBAC/SSO, multi-cluster, sync windows; **ArgoCD vs Flux decision matrix** (IDEATE-21, D-039); cross-link to flux.md, kubernetes/{workloads,rbac,helm,kustomize}.md, devops, security/secrets, observability/metrics |
-| 01-02-02 | `domains/gitops-operators/flux.md` | platform-engineer | ATELIER-62 | GitOps Toolkit controllers (source, kustomize, helm, notification), composable architecture, HR/Kustomization/HelmRelease CRDs, OCI sources; **ArgoCD vs Flux decision matrix** (IDEATE-21, D-039); cross-link to argocd.md + kubernetes/helm.md + kubernetes/kustomize.md |
-| 01-02-03 | `domains/gitops-operators/operators.md` | platform-engineer | ATELIER-63 | Operator pattern, CRDs, controllers, Operator SDK/OLM, when-to-write-an-operator vs Helm chart, scope/responsibility boundaries; cross-link kubernetes/{workloads,rbac}.md + infrastructure-as-code/modules.md |
-| 01-02-04 | `domains/gitops-operators/progressive-delivery.md` | platform-engineer | ATELIER-64 | Argo Rollouts + Flagger, canary/blue-green, analysis templates (metrics/counters), abort/rollback; cross-link devops (P4 Rollback First, P5 Progressive Delivery) + observability/metrics + kubernetes/workloads.md |
-
-**Verify (P1):**
- Structural: 5 files exist under `domains/gitops-operators/`
- Behavioral: every P1–P10 in first-principles names ≥1 C-rule (domain-expert sign-off)
- Security: P3 (Pull, Don't Push) + P10 (Least Privilege Reconciliation) sections present
- Quality: each derived doc has ≥1 outbound cross-link to a MANIFEST-listed doc (IDEATE-08 carried forward); argocd.md and flux.md share the decision matrix consistently (IDEATE-21)
-
-## Phase 2 — AI/ML Domain
-
-**Goal:** Author the `domains/ai-ml/` tree — 10 first principles (P1–P10) plus 4 derived docs (data-versioning, model-evaluation, serving, monitoring-drift). Scope = engineering discipline (D-023), NOT algorithm/model design. Reproducibility and lineage are non-negotiables.
-**Branch:** `atelier/phase/02-ai-ml` (from `atelier/milestone/v0.3-atelier`)
-**Personas:** ml-engineer (author), domain-expert (validate traceability), tech-writer (style/format)
-**Tag:** v0.2.2
-**Requirements:** ATELIER-65, ATELIER-66, ATELIER-67, ATELIER-68, ATELIER-69
-
-### Wave 1 (sequential — first-principles first)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 02-01-01 | `domains/ai-ml/first-principles.md` | ml-engineer | ATELIER-65 | 10 principles (P1–P10) per RESEARCH.md (Reproducibility First Class, Data is Versioned Not Just Code, Lineage Traceable End-to-End, Evaluation Defined Before Training, Models are Versioned Artifacts, Serving is Observable, Drift is Expected and Detected, Inference Inputs are Validated, Pipelines Compose Notebooks Don't, Rollback Includes the Model); each names core C-rule(s); each has definition + "what violates"; ml-engineer constraint "engineering discipline not algorithm design (D-023)" enforced |
-
-### Wave 2 (parallel — 4 derived docs, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 02-02-01 | `domains/ai-ml/data-versioning.md` | ml-engineer | ATELIER-66 | DVC/Delta Lake/LakeFS patterns, data lineage, dataset hashing, train/val/test split versioning; **tool comparison table: DVC vs Delta Lake vs LakeFS** covering versioning model, lineage, use-case fit (IDEATE-22, D-040); cross-link data/{migrations,schema-design}.md + devops/P1 Reproducibility |
-| 02-02-02 | `domains/ai-ml/model-evaluation.md` | ml-engineer | ATELIER-67 | Metric selection, offline/online eval, holdout integrity, bias/fairness checks (engineering angle), eval-as-a-gate; cross-link data/schema-design.md (eval input contract) + testing/pyramid.md |
-| 02-02-03 | `domains/ai-ml/serving.md` | ml-engineer | ATELIER-68 | KServe/Seldon/BentoML, inference as a service, batching, latency SLAs, canarying models; cross-link kubernetes/workloads.md + devops (P5 Progressive Delivery, P7 Immutability) + performance/backend.md + security/input-validation.md |
-| 02-02-04 | `domains/ai-ml/monitoring-drift.md` | ml-engineer | ATELIER-69 | Evidently/Great Expectations, alerting, retraining triggers; **drift-type enumeration: data drift, concept drift, prediction drift — each with a distinct detection signal** (IDEATE-30, D-048); cross-link observability/{metrics,logging}.md + ai-ml/serving.md |
-
-**Verify (P2):**
- Structural: 5 files exist under `domains/ai-ml/`
- Behavioral: every P1–P10 traces to ≥1 C-rule (domain-expert sign-off)
- Security: P8 (Inference Inputs are Validated) section present
- Quality: each derived doc ≥1 outbound cross-link (IDEATE-08); data-versioning.md tool comparison table present (IDEATE-22); monitoring-drift.md enumerates 3 drift types with detection signals (IDEATE-30); no algorithm-design content (D-023 enforced, ml-engineer constraint)
-
-## Phase 3 — i18n + Compliance Domains
-
-**Goal:** Author two smaller-surface domains in one phase (D-022): `domains/i18n/` (10 first principles + 4 derived docs) and `domains/compliance/` (10 first principles + 4 derived docs). i18n grounded in ICU/CLDR + BCP 47 + W3C i18n. Compliance is framework-agnostic (D-024 — no regulation-specific docs). Both domains' first-principles land in Wave 1 (independent of each other), then derived docs in Wave 2.
-**Branch:** `atelier/phase/03-i18n-compliance` (from `atelier/milestone/v0.3-atelier`)
-**Personas:** tech-writer (author, both domains), domain-expert (validate traceability for both)
-**Tag:** v0.2.3
-**Requirements:** ATELIER-70, ATELIER-71, ATELIER-72, ATELIER-73, ATELIER-74, ATELIER-75, ATELIER-76, ATELIER-77, ATELIER-78, ATELIER-79
-
-### Wave 1 (parallel — 2 first-principles, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-01-01 | `domains/i18n/first-principles.md` | tech-writer | ATELIER-70 | 10 principles (P1–P10) per RESEARCH.md (Source Language is a Locale Not the Default, Locale Identifiers Standardized BCP 47, Resources External Not Inline, Plural/Gender Parameterized ICU MessageFormat, Formatting Locale-Aware ICU/CLDR, Text Direction is Layout Primitive, Layout Accommodates Expansion, Pseudo-Locales Test Early, Images/Icons Cultural, Translation Reversible and Versioned); each names core C-rule(s); each has definition + "what violates" |
-| 03-01-02 | `domains/compliance/first-principles.md` | tech-writer | ATELIER-75 | 10 principles (P1–P10) per RESEARCH.md (Audit Logs Append-Only, Every Significant Action Logged, Retention is Policy Not Storage, Policy is Code, Policy Evaluated as a Gate, Evidence Collected Continuously, Identity Attributable, Subject Access Honored, Secrets Redacted in Audit, Compliance Posture Observable); each names core C-rule(s); each has definition + "what violates"; framework-agnostic (D-024 — no GDPR/HIPAA/SOC2-specific content) |
-
-### Wave 2 (parallel — 8 derived docs, independent; split into 2 sub-waves of 4 to respect max_concurrent_agents=5)
-
-**Wave 2a (i18n derived docs, ≤5 concurrent)**
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-02a-01 | `domains/i18n/locale-resources.md` | tech-writer | ATELIER-71 | Resource file formats (.po/.pot, JSON, Fluent FTL, ICU Resource Bundle), key naming, namespaces, fallback chains, extraction tooling; cross-link uiux/copywriting.md + api/error-responses.md |
-| 03-02a-02 | `domains/i18n/formatting.md` | tech-writer | ATELIER-72 | ICU/CLDR/Intl for dates, times, numbers, currencies, units, relative time, plural rules; BCP 47 tags; cross-link api/error-responses.md (localized errors) + data/schema-design.md |
-| 03-02a-03 | `domains/i18n/rtl-bidi.md` | tech-writer | ATELIER-73 | Logical vs physical CSS properties, bidi algorithm (UAX #9), `dir` attribute, mirroring, common pitfalls (icons, numbers in RTL); cross-link uiux/{components,accessibility}.md |
-| 03-02a-04 | `domains/i18n/testing-i18n.md` | tech-writer | ATELIER-74 | Pseudo-locales, snapshot testing per locale, RTL coverage, missing-key detection; **pseudo-locale tier mapping to testing pyramid: unit (missing-key), integration (snapshot per locale), e2e (RTL coverage)** (IDEATE-28, D-046); cross-link testing/{fixtures,pyramid}.md |
-
-**Wave 2b (compliance derived docs, ≤5 concurrent; runs in parallel with 2a — total 8 tasks, but capped at 5 → executor schedules 5 then 3)**
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 03-02b-01 | `domains/compliance/audit-logs.md` | tech-writer | ATELIER-76 | Append-only log patterns, structured audit events, CloudTrail/Cloud-Audit-Log conventions, queryability, retention of logs; cross-link observability/logging.md + security/authorization.md |
-| 03-02b-02 | `domains/compliance/data-retention.md` | tech-writer | ATELIER-77 | Retention policies as code, lifecycle rules, deletion-as-a-feature, GDPR/CCPA abstracted to principles (not regulation-specific, D-024), retention vs backup distinction; cross-link data/{migrations,schema-design}.md |
-| 03-02b-03 | `domains/compliance/policy-as-code.md` | tech-writer | ATELIER-78 | OPA/Cedar/Sentinel/Kyverno patterns, policy as CI/CD + admission gate, policy testing, versioning policy; **engine comparison table: OPA vs Cedar vs Kyverno vs Sentinel** covering policy language, evaluation gate, ecosystem (IDEATE-23, D-041); cross-link infrastructure-as-code (declarative intent) + kubernetes/rbac.md (admission) |
-| 03-02b-04 | `domains/compliance/evidence.md` | tech-writer | ATELIER-79 | Evidence collection as a byproduct, audit-ready export, provenance; **fenced signed-attestation example (Cosign OR in-toto)** — not prose-only (IDEATE-29, D-047); cross-link security/supply-chain.md + observability/{metrics,tracing}.md |
-
-> **Parallelism note:** Wave 2a + 2b together = 8 independent tasks. The executor schedules at most 5 concurrently per `parallelization.max_concurrent_agents`; the remaining 3 run as soon as slots free. The 2a/2b labels are organizational (by domain), not a hard sequencing barrier — both sub-waves are in the same dependency tier (all depend only on Wave 1).
-
-**Verify (P3):**
- Structural: 10 files exist (5 under `domains/i18n/`, 5 under `domains/compliance/`)
- Behavioral: every P1–P10 in both first-principles traces to ≥1 C-rule (domain-expert sign-off)
- Security: i18n P6 (Text Direction) + compliance P1 (Append-Only) + P9 (Redacted) sections present
- Quality: each derived doc ≥1 outbound cross-link (IDEATE-08); testing-i18n.md pseudo-locale→pyramid mapping present (IDEATE-28); policy-as-code.md engine comparison table present (IDEATE-23); evidence.md has a fenced signed-attestation example (IDEATE-29); no regulation-specific content in compliance (D-024)
-
-## Phase 4 — Matrix + Review + Manifest Integration
-
-**Goal:** Extend the matrix (+40 P-rule → C-rule mappings, 10 per new domain), domain-coverage (per-domain rows + Core Principle Coverage table for 4 new domains), review docs (agent + peer-review + anti-patterns with v0.3 chaos anti-patterns), and the manifest (all v0.3 docs + `examples/` directory listing closing v0.2 ESC-002 drift). Closes the traceability loop and makes the manifest authoritative for v0.3.
-**Branch:** `atelier/phase/04-matrix-review-manifest` (from `atelier/milestone/v0.3-atelier`)
-**Personas:** domain-expert (matrix + anti-patterns + coverage), tech-writer (checklists + manifest), lead-developer (manifest authoritative index)
-**Tag:** v0.2.4
-**Requirements:** ATELIER-80, ATELIER-81, ATELIER-82, ATELIER-83, ATELIER-84, ATELIER-85, ATELIER-91
-
-### Wave 1 (sequential — matrix is the arbiter, must be authoritative first)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 04-01-01 | `matrix/principles-matrix.md` (extend) | domain-expert | ATELIER-80 | Add 4 sections (GitOps + Operators, AI/ML, i18n, Compliance), 10 rows each, format matching v0.1/v0.2 tables; **review check: row count per new domain = 10, each row ≥1 C-rule** (IDEATE-02, IDEATE-13 carried forward); **update Coverage Summary to "post-v0.3: 17 domains, 170 P-rules"** — both the summary block AND the per-domain section count (IDEATE-18, D-036) |
-
-### Wave 2 (parallel — 5 independent extensions; exactly at max_concurrent_agents=5)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 04-02-01 | `matrix/domain-coverage.md` (extend) | domain-expert | ATELIER-81 | Add "v0.3 Domain Coverage" table with 4 rows (schema: domain, P-count, derived-doc-count, manifest-listed, status per IDEATE-03); **AND update the "Core Principle Coverage" table (C1–C8 → domains) for the 4 new domains** — C4 Locality adds i18n + gitops; C5 Reversibility adds ai-ml + compliance + gitops + i18n; etc. (IDEATE-19, D-037) |
-| 04-02-02 | `review/agent-checklist.md` (extend) | tech-writer | ATELIER-82 | Add "If GitOps + Operators", "If AI/ML", "If i18n", "If Compliance" trigger sections (IDEATE-05 carried forward); ai-ml section includes a D-023 scope check (reject algorithm-design content) |
-| 04-02-03 | `review/peer-review-checklist.md` (extend) | tech-writer | ATELIER-83 | Add 4 new domain peer-review sections (parity with agent-checklist, IDEATE-09 carried forward) |
-| 04-02-04 | `review/anti-patterns.md` (extend) | domain-expert | ATELIER-84 | Add "v0.3 Chaos Anti-Patterns" section covering: (a) **v0.3 deployable artifact types** — .po resource files, .rego policy files, model artifacts, signed manifests as standalone files (IDEATE-20); (b) **GitOps push-pattern violation** (P3 Pull Don't Push, IDEATE-24, D-042); (c) **i18n LTR-only assumption violation** (P6 Text Direction, IDEATE-25, D-043); (d) **AI/ML orphan-model violation** — deployed prediction with no lineage trace (P3 Lineage, IDEATE-27, D-045); plus domain-specific anti-patterns per RESEARCH.md/REQUIREMENTS.md notes: gitops (push-based deploy P3, manual kubectl apply on GitOps-managed resource P8, cluster-admin GitOps robot P10), ai-ml (unreproducible training run P1, "the latest" model P5, notebook in production P9, orphan model P3), i18n (inline string concatenation P3, `if (n==1)` plural branching P4, LTR-only layout P6, hand-rolled date formatter P5), compliance (mutable audit log P1, shared/generic identity in audit P7, secret leaked in audit log P9, manual evidence assembly at audit time P6) |
-| 04-02-05 | `MANIFEST.md` (extend) | lead-developer | ATELIER-85, ATELIER-91 | Add 4 new domains + all 18 derived docs to the Domains table (IDEATE-04 carried forward); update Cross-Cutting counts to "17 domains, 170 P-rules post-v0.3"; **add an `examples/` directory listing section** (good + bad files) closing the v0.2 ESC-002 drift — manifest is authoritative (IDEATE-17, D-035) |
-
-**Verify (P4):**
- Structural: matrix has 17 domain sections (13 v0.1/v0.2 + 4 new), 170 P-rules total; domain-coverage has both the per-domain v0.3 table AND the updated C-rule coverage table; 3 review docs extended; MANIFEST lists all v0.3 docs + examples/
- Behavioral: every new P-rule has a matrix row; domain-expert verifies no orphans (IDEATE-13); Coverage Summary reads "17 domains, 170 P-rules" (IDEATE-18)
- Security: anti-patterns cover GitOps push-pattern (P3), AI/ML orphan-model (P3), i18n LTR-only (P6), compliance mutable audit log (P1) + secret-in-audit (P9)
- Quality: MANIFEST is authoritative — every v0.3 file listed, examples/ listed (ATELIER-91 closes ESC-002); unlisted = not part of framework; agent-checklist + peer-review-checklist have parity across the 4 new domains (ATELIER-82 ↔ ATELIER-83)
-
-## Phase 5 — Examples + Cross-Links
-
-**Goal:** Add 2 good + 2 bad examples (D-025 — highest illustration value) and verify cross-domain links from all 4 new domains to existing ones. Examples are markdown with fenced code only (no standalone .yaml/.po/.rego/model artifacts — D-020).
-**Branch:** `atelier/phase/05-examples-crosslinks` (from `atelier/milestone/v0.3-atelier`)
-**Personas:** tech-writer (examples + cross-link audit), domain-expert (P-rule citation + cross-link validation)
-**Tag:** v0.2.5
-**Requirements:** ATELIER-86, ATELIER-87, ATELIER-88
-
-### Wave 1 (parallel — 4 examples, independent; ≤5 concurrent)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 05-01-01 | `examples/good/gitops-pr.md` | tech-writer | ATELIER-86 | Good GitOps example; markdown with fenced YAML only (no standalone .yaml); demonstrates P1 Git is Source of Truth + P3 Pull Don't Push + P5 State Immutable and Versioned; cross-link to argocd.md + flux.md + kubernetes/workloads.md |
-| 05-01-02 | `examples/good/ai-ml-reproducibility.md` | tech-writer (ml-engineer consult) | ATELIER-86 | Good AI/ML example; markdown with fenced code only (no model artifacts); demonstrates P1 Reproducibility + P2 Data Versioned + P3 Lineage Traceable + P5 Models are Versioned Artifacts; cross-link to data-versioning.md + serving.md |
-| 05-01-03 | `examples/bad/i18n-string-concat.md` | tech-writer | ATELIER-87 | Bad i18n example; cites P3 breached (inline string concatenation, Resources External Not Inline) per IDEATE-07; cross-link to locale-resources.md + formatting.md |
-| 05-01-04 | `examples/bad/compliance-audit-log.md` | tech-writer | ATELIER-87 | Bad compliance example; **TWO breaches in one example** (IDEATE-26, D-044): append-only violation (mutation/deletion of an audit record, P1) AND redaction failure (secret leaked in audit log, P9); cites both P-rules breached; cross-link to audit-logs.md + evidence.md |
-
-### Wave 2 (sequential — cross-link audit after all docs exist)
-| Task | File | Persona | REQ-ID | Must-have |
-|------|------|---------|--------|-----------|
-| 05-02-01 | Cross-link audit (all 18 new derived docs across 4 domains) | tech-writer | ATELIER-88 | Review check: every new derived doc ≥1 outbound cross-link to a MANIFEST-listed existing domain doc (devops/security/observability/data/kubernetes/infrastructure-as-code); links resolve (IDEATE-08 carried forward); domain-expert validates the cross-link targets are correct (not just present) |
-
-**Verify (P5):**
- Structural: 4 new example files exist (all .md)
- Behavioral: each bad example cites the P-rule(s) breached (i18n: P3; compliance: P1 + P9 two-breach per IDEATE-26); each good example cites the P-rules it demonstrates
- Security: no standalone .yaml/.po/.rego/model artifacts (deployable artifact mitigation, IDEATE-20, D-020)
- Quality: all cross-links from the 18 new derived docs resolve to MANIFEST-listed docs; no back-link edits to v0.1/v0.2 content (D-026 extended — one-directional outward)
-
-## Phase 6 — Final Review + Ship (N+1)
-
-**Goal:** Multi-persona review across all v0.3 phases, audit, milestone ship. P6 IS the v0.3 release (NFR → no separate minor tag; v0.2.6 IS the deliverable). Phase-specific personas (platform-engineer, ml-engineer) are removed after milestone completion.
-**Branch:** `atelier/phase/06-final-review-ship` (from `atelier/milestone/v0.3-atelier`)
-**Personas:** lead-developer (coordinate + ship), domain-expert (review), tech-writer (review), platform-engineer (review, then removed), ml-engineer (review, then removed)
-**Tag:** v0.2.6 (IS the v0.3 milestone release — NFR, no separate minor tag)
-**Requirements:** ATELIER-89, ATELIER-90
-
-### Wave 1 (sequential — review → audit → ship → complete)
-| Task | Activity | Persona | REQ-ID | Must-have |
-|------|----------|---------|--------|-----------|
-| 06-01-01 | `ciagent-review` — multi-persona review of all v0.3 changes | lead-developer | ATELIER-89 | Auto-apply P0 fixes; flag P1+ for post-hoc; if P1+ found, fix in this phase; platform-engineer reviews gitops-operators content; ml-engineer reviews ai-ml content (D-023 scope check); domain-expert verifies all 40 new P-rules trace to ≥1 C-rule (no orphans) |
-| 06-01-02 | `ciagent-audit` — reconstruction + discipline | lead-developer | ATELIER-89 | 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. examples/ per ATELIER-91); matrix row-count test (10 per domain × 17 = 170) |
-| 06-01-03 | `ciagent-ship` — milestone ship | lead-developer | ATELIER-90 | Merge `atelier/phase/06` → `atelier/milestone/v0.3-atelier` → `main`; tag `v0.2.6`; Gitea release with full milestone summary; delete all v0.3 branches (tags preserve history) |
-| 06-01-04 | Complete milestone (REQUIREMENTS + ROADMAP + PERSONAS) | lead-developer | ATELIER-90 | Mark all v0.3 requirements (ATELIER-60..91) `covered`; ROADMAP v0.3 → complete; PERSONAS: remove platform-engineer + ml-engineer (roster returns to 3 active); clear checkpoint |
-
-**Verify (P6):**
- Structural: all 32 v0.3 requirements (ATELIER-60..91) marked covered
- Behavioral: reconstruction test passes (git log ↔ .ciagent/); matrix row-count test passes (170); MANIFEST reconstruction test passes (incl. examples/)
- Security: audit clean (no critical issues); no regulation-specific compliance content (D-024); no algorithm-design ai-ml content (D-023); no standalone runtime artifacts (D-020)
- Quality: milestone merged to main, tag v0.2.6 exists, all v0.3 branches deleted; platform-engineer + ml-engineer personas removed (roster = 3)
-
-## v0.3 Wave Ordering Summary
-
-| Phase | Waves | Parallelism |
-|-------|-------|-------------|
-| P0 | (pre-exec) | Sequential stages (specify→clarify→research→ideate→plan→grill) |
-| 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 (2 first-principles), Wave 2 parallel (8 derived docs — 2a i18n + 2b compliance, capped at 5 concurrent) |
-| P4 | 2 | Wave 1 sequential (matrix arbiter), Wave 2 parallel (5 extensions — exactly max_concurrent) |
-| P5 | 2 | Wave 1 parallel (4 examples), Wave 2 sequential (cross-link audit) |
-| P6 | 1 | Sequential: review → audit → ship → complete |
-
-## v0.3 Requirements → Phase Mapping
-
-| Phase | Requirements | Count |
-|-------|-------------|-------|
-| 1 | ATELIER-60..64 | 5 |
-| 2 | ATELIER-65..69 | 5 |
-| 3 | ATELIER-70..79 | 10 |
-| 4 | ATELIER-80..85, 91 | 7 |
-| 5 | ATELIER-86..88 | 3 |
-| 6 | ATELIER-89, 90 | 2 |
-| **Total** | | **32** |
-
-## v0.3 Ideation Refinements → Task Bake-In Map
-
-All 14 accepted ideation refinements (IDEATE-17..30) are baked into the relevant phase tasks as explicit must-have notes:
-
-| IDEATE-ID | Refinement | Baked Into Task(s) | How |
-|-----------|-----------|-------------------|-----|
-| IDEATE-17 | examples/ in MANIFEST (new req ATELIER-91) | 04-02-05 | MANIFEST gains an examples/ directory listing (closes v0.2 ESC-002 drift) |
-| IDEATE-18 | matrix coverage summary = "17 domains, 170 P-rules" | 04-01-01 | Coverage Summary block + per-domain section count both updated |
-| IDEATE-19 | Core Principle Coverage table update for 4 new domains | 04-02-01 | C1–C8 → domains table extended (C4 adds i18n+gitops; C5 adds ai-ml+compliance+gitops+i18n; etc.) |
-| IDEATE-20 | anti-patterns pre-specify domain violations + v0.3 artifact types | 04-02-04 | .po/.rego/model/signed-manifest artifact types + 16 domain-specific anti-patterns (4 per domain) |
-| IDEATE-21 | ArgoCD vs Flux decision matrix | 01-02-01, 01-02-02 | Both argocd.md and flux.md carry the decision matrix (parallel to v0.2 Helm vs Kustomize) |
-| IDEATE-22 | data versioning tool comparison (DVC/Delta Lake/LakeFS) | 02-02-01 | data-versioning.md comparison table (versioning model, lineage, use-case fit) |
-| IDEATE-23 | policy-as-code engine comparison (OPA/Cedar/Kyverno/Sentinel) | 03-02b-03 | policy-as-code.md comparison table (policy language, evaluation gate, ecosystem) |
-| IDEATE-24 | GitOps push-pattern anti-pattern (violates P3) | 04-02-04 | Named chaos anti-pattern; pre-specified to reject on sight |
-| IDEATE-25 | i18n LTR-only assumption anti-pattern (violates P6) | 04-02-04 | Named chaos anti-pattern; pre-specified to reject on sight |
-| IDEATE-26 | compliance-audit-log bad example = 2 breaches (P1 + P9) | 05-01-04 | examples/bad/compliance-audit-log.md covers append-only violation + redaction failure |
-| IDEATE-27 | AI/ML orphan-model anti-pattern (violates P3 Lineage) | 04-02-04 | Named chaos anti-pattern; deployed prediction with no lineage trace |
-| IDEATE-28 | i18n testing pseudo-locale → testing pyramid tiers | 03-02a-04 | testing-i18n.md maps unit (missing-key), integration (snapshot per locale), e2e (RTL coverage) |
-| IDEATE-29 | compliance evidence.md signed-attestation fenced example | 03-02b-04 | evidence.md includes a fenced Cosign OR in-toto attestation (not prose-only) |
-| IDEATE-30 | ai-ml monitoring-drift.md 3 drift types with detection signals | 02-02-04 | monitoring-drift.md enumerates data/concept/prediction drift, each with a detection signal |
-
-## v0.3 Decisions Logged (planning stage)
-
-| ID | Decision | Rationale | Confidence |
-|----|----------|-----------|------------|
-| 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; the 2a/2b labels organize by domain, the 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 |
-
-## Assumptions Logged
-
-| # | Assumption | Confidence |
-|---|-----------|------------|
-| A-001 | The v0.2 ESC-002 drift note (examples/ unlisted in MANIFEST) is the only pre-existing manifest drift; no other v0.1/v0.2 docs are unlisted | 0.85 |
-| A-002 | The 4 new domains' P-rules map to existing core C1–C8 without needing new core principles (core is stable at 8) | 0.95 |
-| A-003 | Wave 2 of P3 (8 derived docs) can be scheduled by the executor as 5-then-3 without a hard sub-wave barrier | 0.90 |
-| A-004 | The ArgoCD vs Flux decision matrix (IDEATE-21) is the only decision matrix required in P1 (no separate operators-vs-Helm matrix beyond operators.md's "when to write an operator vs a Helm chart" guidance) | 0.82 |
-| A-005 | P4 anti-patterns (04-02-04) and manifest (04-02-05) can be concurrent because anti-patterns content does not block the manifest's examples/ listing (manifest lists file paths, not anti-pattern content) | 0.80 |
+| **Total** | | **24** |
@@ -78,48 +78,6 @@ Build **Atelier** — a first-principles, docs-as-code engineering framework for
 - New examples: `examples/good/terraform-module.md`, `examples/good/k8s-deployment.md`, `examples/bad/` counterparts
 - Cross-links from new domains to existing `devops/`, `security/`, `observability/`, `data/` domains

-## v0.3 — GitOps + Operators + AI/ML + i18n + Compliance
-
-**Milestone type:** NFR (all phases produce docs — no `feat` runtime code)
-**Tag line:** v0.2.x (previous minor from v0.3)
-**Scope:** Extend the domain tree with four new top-level domains covering GitOps/operator patterns, AI/ML, internationalization, and compliance. Plus matrix, review, examples, and cross-link integration. All content is docs-only markdown with illustrative code fences; no runtime/deployable artifacts.
-
-### New Domains
-
- `domains/gitops-operators/` — platform-automation domain (ArgoCD + Flux + Operators)
-  - `first-principles.md` — 10 GitOps/operator principles (P1–P10)
-  - Derived: `argocd.md`, `flux.md`, `operators.md`, `progressive-delivery.md`
- `domains/ai-ml/` — ML engineering domain
-  - `first-principles.md` — 10 AI/ML principles (P1–P10)
-  - Derived: `data-versioning.md`, `model-evaluation.md`, `serving.md`, `monitoring-drift.md`
- `domains/i18n/` — internationalization domain
-  - `first-principles.md` — 10 i18n principles (P1–P10)
-  - Derived: `locale-resources.md`, `formatting.md`, `rtl-bidi.md`, `testing-i18n.md`
- `domains/compliance/` — compliance/audit domain
-  - `first-principles.md` — 10 compliance principles (P1–P10)
-  - Derived: `audit-logs.md`, `data-retention.md`, `policy-as-code.md`, `evidence.md`
-
-### Cross-Domain Integration
-
- Extend `matrix/principles-matrix.md` with 40 new P-rules → core C-rule mappings (10 per new domain)
- Extend `matrix/domain-coverage.md` with the four new domains
- Extend `review/agent-checklist.md`, `review/peer-review-checklist.md`, and `review/anti-patterns.md` with new domain sections
- Update `MANIFEST.md` to list all new v0.3 documents (manifest is authoritative)
- New examples (good + bad): gitops-pr, ai-ml-reproducibility, i18n-string-concat, compliance-audit-log
- Cross-links from new domains to existing `devops/`, `security/`, `observability/`, `data/`, `kubernetes/`, `infrastructure-as-code/` domains
-
-### Phase Plan (proposed, finalized in PLAN)
-
- P0 Pre-Execution: spec, clarify, research, ideate, plan, grill
- P1 GitOps + Operators domain
- P2 AI/ML domain
- P3 i18n + Compliance domains
- P4 Matrix + Review Integration (40 new mappings, manifest, checklist parity)
- P5 Examples + Cross-Links
- P6 Final Review + Ship (IS the v0.3 release → tag v0.2.6)
-
-NFR milestone: no separate minor tag. The final patch (v0.2.6) IS the v0.3 deliverable.
-
 ## Key Decisions

 | ID | Decision | Rationale | Confidence |
@@ -139,31 +97,6 @@ NFR milestone: no separate minor tag. The final patch (v0.2.6) IS the v0.3 deliv
 | D-013 | v0.2 tags run on v0.1.x patch line (prev minor from v0.2) | Per branch-strategy.md: milestone 0.2 → tags v0.1.0..v0.1.5; v0.1.5 IS the v0.2 release (NFR → no separate minor tag) | 0.90 |
 | D-014 | Add phase-specific `platform-engineer` persona for P1–P4 | IaC/k8s domain authoring benefits from a specialist persona with declarative-first/stateless-examples constraints; removed after milestone | 0.82 |
 | D-015 | 4 execution phases (P1–P4) + final phase P5 | P1 IaC domain, P2 k8s domain, P3 matrix+review, P4 examples+cross-links, P5 final review+ship | 0.85 |
-| D-016 | v0.3 covers 4 deferred domains: gitops-operators, ai-ml, i18n, compliance | Carries forward v0.2 deferred ideation (IDEATE-15, IDEATE-16); single milestone groups them to limit release overhead | 0.86 |
-| D-017 | v0.3 tags run on v0.2.x patch line (prev minor from v0.3) | Per branch-strategy.md: milestone 0.3 → tags v0.2.0..v0.2.6; v0.2.6 IS the v0.3 release (NFR → no separate minor tag) | 0.90 |
-| D-018 | v0.3 splits P1 GitOps/Operators, P2 AI/ML, P3 i18n+Compliance, P4 Matrix+Review, P5 Examples, P6 Final | Each domain cluster is a coherent vertical slice; i18n + compliance paired (smaller surface) to balance phase load | 0.84 |
-| D-019 | Reuse `platform-engineer` persona (extended) + add `ml-engineer` phase-specific persona for P2 | GitOps/Operators/k8s reuse platform-engineer; AI/ML benefits from a data/ML-specialist persona with reproducibility/data-lineage constraints; removed after milestone | 0.80 |
-| D-020 | v0.3 remains docs-only (NFR milestone type) | PROJECT.md constraint "no runtime code" preserved; manifests/models/locale resources appear only as illustrative code-fence content in examples | 0.95 |
-| D-021 | GitOps-operators domain groups ArgoCD + Flux + Operators + Progressive Delivery under one first-principles doc | All four share the declarative-source-of-truth reconciliation loop; splitting would fragment the P-rules and duplicate the core principles they trace to | 0.84 |
-| D-022 | i18n + compliance paired in P3 (not separate phases) | Both are smaller-surface domains (4 derived docs each); pairing balances phase load against the heavier P1/P2 single-domain phases | 0.83 |
-| D-023 | AI/ML domain scope = engineering discipline (data versioning, evaluation, serving, drift), NOT algorithm/model design | Atelier is a framework for engineering practice; algorithm choice is domain-knowledge out of scope. Mirrors how iac/k8s docs cover practice not implementation | 0.88 |
-| D-024 | Compliance domain is framework-agnostic (audit logs, retention, policy-as-code, evidence), NOT tied to a specific regulation (GDPR/HIPAA/SOC2) | Regulation-specific docs would bloat the framework and go stale; principles derive from core Security/Correctness and apply across regulations | 0.86 |
-| D-025 | Examples set = 2 good + 2 bad (not 4+4) | v0.3 adds 4 domains; 4+4 examples would unbalance P5. 2 good (gitops-pr, ai-ml-reproducibility) + 2 bad (i18n-string-concat, compliance-audit-log) cover the highest-illustration-value cases; remaining domains covered by cross-links and anti-patterns | 0.80 |
-| D-026 | 40 new matrix mappings (10 per domain × 4 domains) | Consistent with v0.1 (110 mappings / 11 domains = 10) and v0.2 (20 mappings / 2 domains = 10). Each P-rule maps to ≥1 C-rule | 0.92 |
-| D-035 | Add `examples/` directory listing to MANIFEST.md in v0.3 P4 (ATELIER-91) | v0.2 audit escalation ESC-002 note flagged examples/ unlisted; manifest is authoritative, so this is pre-existing drift that v0.3 closes | 0.85 |
-| D-036 | Matrix coverage summary must state post-v0.3 totals (17 domains, 170 P-rules) | Both the summary block and per-domain section count must update; consistent with v0.2's "post-v0.2" summary | 0.93 |
-| D-037 | domain-coverage.md Core Principle Coverage table (C1–C8 → domains) must update for 4 new domains | ATELIER-81 covers the per-domain row schema; this is the complementary C-rule → domains table that also needs the 4 new domains | 0.90 |
-| D-038 | v0.3 anti-patterns must pre-specify domain-specific violations + v0.3 artifact types | Avoids generic "deployable example artifact" only; v0.3 has new artifact types (.po, .rego, model files) and 4 domains × ~4 anti-patterns each | 0.86 |
-| D-039 | ArgoCD vs Flux decision matrix required in argocd.md + flux.md | Parallel to v0.2 Helm vs Kustomize decision matrix (IDEATE-10); both tools share the GitOps model but differ in architecture (App CRD vs composable controllers) | 0.82 |
-| D-040 | Data versioning tool comparison table required in data-versioning.md (DVC/Delta Lake/LakeFS) | Parallel to v0.2 state comparison table (IDEATE-11); three主流 tools with distinct versioning/lineage models | 0.80 |
-| D-041 | Policy-as-code engine comparison table required in policy-as-code.md (OPA/Cedar/Kyverno/Sentinel) | Parallel to v0.2 PSS coverage (IDEATE-12); four engines with distinct policy languages and gate models | 0.81 |
-| D-042 | GitOps push-pattern is a named anti-pattern (violates P3 Pull Don't Push) | Chaos scenario: a "GitOps" example that uses push-based deploy is a fundamental violation; pre-specify to reject on sight | 0.85 |
-| D-043 | i18n LTR-only assumption is a named anti-pattern (violates P6 Text Direction) | Chaos scenario: formatting/layout examples that assume LTR only fail RTL/bidi users; pre-specify to reject | 0.83 |
-| D-044 | compliance-audit-log bad example must cover both append-only violation (P1) and redaction failure (P9) | Two-breach example maximizes illustration value; mirrors v0.2 named-bad-example pattern but doubles the breach surface for the highest-stakes domain | 0.87 |
-| D-045 | AI/ML orphan-model anti-pattern required (deployed prediction with no lineage trace, violates P3) | Chaos scenario: a serving example with no model→training→data lineage is the AI/ML analog of v0.2 orphaned P-rule; pre-specify | 0.84 |
-| 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 |

 ## Cross-Project References

@@ -172,4 +105,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.2** — Infrastructure as Code + Kubernetes (IN PROGRESS). Adds 2 domains (20 new P-rules), matrix/review/examples integration. Tags v0.1.0–v0.1.5.
@@ -64,30 +64,30 @@ All 35 requirements covered. 8 core principles, 11 domains, 110 domain principle

 | REQ-ID | Requirement | Priority | Phase | Status |
 |--------|-------------|----------|-------|--------|
-| ATELIER-36 | `domains/infrastructure-as-code/first-principles.md` — 10 IaC principles (P1–P10) | P0 | 1 | covered |
-| ATELIER-37 | `domains/infrastructure-as-code/terraform.md` — Terraform derived doc | P1 | 1 | covered |
-| ATELIER-38 | `domains/infrastructure-as-code/opentofu.md` — OpenTofu derived doc | P1 | 1 | covered |
-| ATELIER-39 | `domains/infrastructure-as-code/state.md` — IaC state management derived doc | P1 | 1 | covered |
-| ATELIER-40 | `domains/infrastructure-as-code/modules.md` — IaC module composition derived doc | P1 | 1 | covered |
-| ATELIER-41 | `domains/kubernetes/first-principles.md` — 10 k8s principles (P1–P10) | P0 | 2 | covered |
-| ATELIER-42 | `domains/kubernetes/workloads.md` — workloads derived doc | P1 | 2 | covered |
-| ATELIER-43 | `domains/kubernetes/networking.md` — networking derived doc | P1 | 2 | covered |
-| ATELIER-44 | `domains/kubernetes/storage.md` — storage derived doc | P1 | 2 | covered |
-| ATELIER-45 | `domains/kubernetes/rbac.md` — RBAC derived doc incl. Pod Security Standards/Admission (cross-link security/authorization) | P1 | 2 | covered |
-| ATELIER-46 | `domains/kubernetes/helm.md` — Helm derived doc (with Helm vs Kustomize decision matrix) | P1 | 2 | covered |
-| ATELIER-47 | `domains/kubernetes/kustomize.md` — Kustomize derived doc (with Helm vs Kustomize decision matrix) | P1 | 2 | covered |
-| ATELIER-48 | 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) | P0 | 3 | covered |
-| ATELIER-49 | Extend `matrix/domain-coverage.md` with infrastructure-as-code + kubernetes (row schema: domain, P-count, derived-doc-count, manifest-listed, status) | P1 | 3 | covered |
-| ATELIER-50 | Extend `review/agent-checklist.md` with IaC + k8s trigger sections | P1 | 3 | covered |
-| ATELIER-51 | Extend `review/anti-patterns.md` with IaC + k8s violations incl. orphaned P-rule + deployable example artifact | P1 | 3 | covered |
-| ATELIER-52 | Update `MANIFEST.md` to list all new v0.2 documents (manifest authoritative) | P0 | 3 | covered |
-| ATELIER-53 | `examples/good/terraform-module.md` — good IaC example (markdown with fenced HCL only; no standalone .tf) | P2 | 4 | covered |
-| ATELIER-54 | `examples/good/k8s-deployment.md` — good k8s example (markdown with fenced YAML only; no standalone .yaml) | P2 | 4 | covered |
-| ATELIER-55 | `examples/bad/terraform-unlocked-state.md` + `examples/bad/k8s-bare-pod-no-resources.md` — 2 named bad examples (each cites the P-rule breached) | P2 | 4 | covered |
-| ATELIER-56 | Cross-links from new domains to existing devops/security/observability/data domains (review check: every new derived doc ≥1 outbound cross-link to a MANIFEST-listed doc) | P1 | 4 | covered |
-| ATELIER-57 | Final review passes (all v0.2 phases reviewed, audit clean) | P0 | 5 | covered |
-| ATELIER-58 | Milestone v0.2 released (tag v0.1.5, merged to main) | P0 | 5 | covered |
-| ATELIER-59 | Extend `review/peer-review-checklist.md` with IaC + k8s sections (parity with agent-checklist) | P1 | 3 | covered |
+| ATELIER-36 | `domains/infrastructure-as-code/first-principles.md` — 10 IaC principles (P1–P10) | P0 | 1 | pending |
+| ATELIER-37 | `domains/infrastructure-as-code/terraform.md` — Terraform derived doc | P1 | 1 | pending |
+| ATELIER-38 | `domains/infrastructure-as-code/opentofu.md` — OpenTofu derived doc | P1 | 1 | pending |
+| ATELIER-39 | `domains/infrastructure-as-code/state.md` — IaC state management derived doc | P1 | 1 | pending |
+| ATELIER-40 | `domains/infrastructure-as-code/modules.md` — IaC module composition derived doc | P1 | 1 | pending |
+| ATELIER-41 | `domains/kubernetes/first-principles.md` — 10 k8s principles (P1–P10) | P0 | 2 | pending |
+| ATELIER-42 | `domains/kubernetes/workloads.md` — workloads derived doc | P1 | 2 | pending |
+| ATELIER-43 | `domains/kubernetes/networking.md` — networking derived doc | P1 | 2 | pending |
+| ATELIER-44 | `domains/kubernetes/storage.md` — storage derived doc | P1 | 2 | pending |
+| ATELIER-45 | `domains/kubernetes/rbac.md` — RBAC derived doc incl. Pod Security Standards/Admission (cross-link security/authorization) | P1 | 2 | pending |
+| ATELIER-46 | `domains/kubernetes/helm.md` — Helm derived doc (with Helm vs Kustomize decision matrix) | P1 | 2 | pending |
+| ATELIER-47 | `domains/kubernetes/kustomize.md` — Kustomize derived doc (with Helm vs Kustomize decision matrix) | P1 | 2 | pending |
+| ATELIER-48 | 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) | P0 | 3 | pending |
+| ATELIER-49 | Extend `matrix/domain-coverage.md` with infrastructure-as-code + kubernetes (row schema: domain, P-count, derived-doc-count, manifest-listed, status) | P1 | 3 | pending |
+| ATELIER-50 | Extend `review/agent-checklist.md` with IaC + k8s trigger sections | P1 | 3 | pending |
+| ATELIER-51 | Extend `review/anti-patterns.md` with IaC + k8s violations incl. orphaned P-rule + deployable example artifact | P1 | 3 | pending |
+| ATELIER-52 | Update `MANIFEST.md` to list all new v0.2 documents (manifest authoritative) | P0 | 3 | pending |
+| ATELIER-53 | `examples/good/terraform-module.md` — good IaC example (markdown with fenced HCL only; no standalone .tf) | P2 | 4 | pending |
+| ATELIER-54 | `examples/good/k8s-deployment.md` — good k8s example (markdown with fenced YAML only; no standalone .yaml) | P2 | 4 | pending |
+| ATELIER-55 | `examples/bad/terraform-unlocked-state.md` + `examples/bad/k8s-bare-pod-no-resources.md` — 2 named bad examples (each cites the P-rule breached) | P2 | 4 | pending |
+| ATELIER-56 | Cross-links from new domains to existing devops/security/observability/data domains (review check: every new derived doc ≥1 outbound cross-link to a MANIFEST-listed doc) | P1 | 4 | pending |
+| ATELIER-57 | Final review passes (all v0.2 phases reviewed, audit clean) | P0 | 5 | pending |
+| ATELIER-58 | Milestone v0.2 released (tag v0.1.5, merged to main) | P0 | 5 | pending |
+| ATELIER-59 | Extend `review/peer-review-checklist.md` with IaC + k8s sections (parity with agent-checklist) | P1 | 3 | pending |

 ## v0.2 Traceability Matrix

@@ -124,110 +124,4 @@ All 35 requirements covered. 8 core principles, 11 domains, 110 domain principle
 | IDEATE-13 | backend-enriched | chaos | 0.85 | accepted → refines | ATELIER-48, ATELIER-51 (orphan mitigation) |
 | IDEATE-14 | backend-enriched | chaos | 0.87 | accepted → refines | ATELIER-53, ATELIER-51 (deployable artifact mitigation) |
 | IDEATE-15 | backend-enriched | improvement | 0.72 | deferred v0.3 | — (GitOps/operators domain) |
-| IDEATE-16 | backend-enriched | improvement | 0.68 | deferred v0.3 | — (ai-ml/i18n/compliance) |
-
-## v0.3 Requirements — GitOps + Operators + AI/ML + i18n + Compliance
-
-**Milestone type:** NFR (all phases produce docs)
-**Tag line:** v0.2.x (previous minor from v0.3)
-
-| REQ-ID | Requirement | Priority | Phase | Status |
-|--------|-------------|----------|-------|--------|
-| 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
-
-| Phase | Requirements |
-|-------|-------------|
-| 0 (Pre-Execution) | (governance: spec, clarify, research, ideate, plan) |
-| 1 (GitOps + Operators Domain) | ATELIER-60..ATELIER-64 |
-| 2 (AI/ML Domain) | ATELIER-65..ATELIER-69 |
-| 3 (i18n + Compliance Domains) | ATELIER-70..ATELIER-79 |
-| 4 (Matrix + Review Integration) | ATELIER-80..ATELIER-85, ATELIER-91 |
-| 5 (Examples + Cross-Links) | ATELIER-86..ATELIER-88 |
-| 6 (Final Review + Ship) | ATELIER-89, ATELIER-90 |
-
-## v0.3 Ideation Log
-
-**Generated:** 14 ideas (mechanical: 5, backend-enriched: 7, within-project transfer: 2 merged)
-**Accepted:** 14 (all v0.3-scope, confidence ≥ 0.78, above 0.6 autonomy threshold → auto-accepted)
-**Deferred to v0.4:** 0
-**Rejected:** 0
-
-| IDEATE-ID | Source | Category | Confidence | Decision | Mapped REQ |
-|-----------|--------|----------|------------|----------|------------|
-| IDEATE-17 | mechanical (audit escalation ESC-002 note) | drift | 0.85 | accepted → new req | ATELIER-91 (examples/ in MANIFEST) |
-| IDEATE-18 | mechanical (MANIFEST + matrix coverage summary) | coverage | 0.93 | accepted → refines | ATELIER-80, ATELIER-85 (v0.3 totals: 17 domains, 170 P-rules) |
-| IDEATE-19 | mechanical (domain-coverage.md Core Principle Coverage table) | coverage | 0.90 | accepted → refines | ATELIER-81 (C-rule count updates for 4 new domains) |
-| IDEATE-20 | mechanical (anti-patterns specificity) | quality | 0.86 | accepted → refines | ATELIER-84 (pre-specify domain anti-patterns + v0.3 artifact types: .po, .rego, model files) |
-| IDEATE-21 | backend-enriched (v0.2 IDEATE-10 pattern transfer) | improvement | 0.82 | accepted → refines | ATELIER-61, ATELIER-62 (ArgoCD vs Flux decision matrix) |
-| IDEATE-22 | backend-enriched (v0.2 IDEATE-11 pattern transfer) | improvement | 0.80 | accepted → refines | ATELIER-66 (data versioning tool comparison: DVC/Delta Lake/LakeFS) |
-| IDEATE-23 | backend-enriched (v0.2 IDEATE-12 pattern transfer) | improvement | 0.81 | accepted → refines | ATELIER-78 (policy-as-code engine comparison: OPA/Cedar/Kyverno/Sentinel) |
-| IDEATE-24 | backend-enriched | chaos | 0.85 | accepted → refines | ATELIER-84 (GitOps push-pattern anti-pattern, violates P3 Pull Don't Push) |
-| IDEATE-25 | backend-enriched | chaos | 0.83 | accepted → refines | ATELIER-84, ATELIER-72 (i18n LTR-only assumption anti-pattern) |
-| IDEATE-26 | backend-enriched | chaos | 0.87 | accepted → refines | ATELIER-87 (compliance-audit-log bad example must cover append-only violation + secret redaction failure, P1 + P9) |
-| IDEATE-27 | backend-enriched | chaos | 0.84 | accepted → refines | ATELIER-84 (AI/ML orphan-model anti-pattern: deployed prediction with no lineage trace) |
-| IDEATE-28 | backend-enriched | improvement | 0.78 | accepted → refines | ATELIER-74 (i18n testing-i18n.md pseudo-locale tier mapping to testing/pyramid) |
-| IDEATE-29 | backend-enriched | improvement | 0.80 | accepted → refines | ATELIER-79 (compliance evidence.md signed attestation fenced example, Cosign/in-toto) |
-| IDEATE-30 | backend-enriched | improvement | 0.82 | accepted → refines | ATELIER-69 (ai-ml monitoring-drift.md drift-type enumeration: data/concept/prediction with detection signals) |
-
-### Refinements Notes (applied to existing reqs at execute time, not changing req rows)
-
- **ATELIER-80** (IDEATE-18): matrix coverage summary must read "post-v0.3: 17 domains, 170 P-rules"; update both the summary block and per-domain section count.
- **ATELIER-81** (IDEATE-19): the "Core Principle Coverage" table (C1–C8 → domains) must be updated with the 4 new domains, not just the per-domain row schema table.
- **ATELIER-84** (IDEATE-20, IDEATE-24, IDEATE-25, IDEATE-27): anti-patterns extension must include (a) v0.3 deployable artifact types (.po resource files, .rego policy files, model artifacts, signed manifests as standalone files), (b) GitOps push-pattern violation (P3), (c) i18n LTR-only assumption violation (P6), (d) AI/ML orphan-model violation (P3 Lineage). Domain-specific anti-patterns to pre-specify:
-  - gitops-operators: push-based deploy (P3), manual kubectl apply on GitOps-managed resource (P8), cluster-admin GitOps robot (P10)
-  - ai-ml: unreproducible training run (P1), "the latest" model (P5), notebook in production (P9), orphan model with no lineage (P3)
-  - i18n: inline string concatenation (P3), `if (n == 1)` plural branching (P4), LTR-only layout assumption (P6), hand-rolled date formatter (P5)
-  - compliance: mutable audit log (P1), shared/generic identity in audit (P7), secret leaked in audit log (P9), manual evidence assembly at audit time (P6)
- **ATELIER-61/62** (IDEATE-21): argocd.md and flux.md must include an "ArgoCD vs Flux" decision matrix (parallel to v0.2 Helm vs Kustomize in ATELIER-46/47).
- **ATELIER-66** (IDEATE-22): data-versioning.md must include a tool comparison table (DVC vs Delta Lake vs LakeFS) covering versioning model, lineage, and use-case fit.
- **ATELIER-78** (IDEATE-23): policy-as-code.md must include an engine comparison table (OPA vs Cedar vs Kyverno vs Sentinel) covering policy language, evaluation gate, and ecosystem.
- **ATELIER-87** (IDEATE-26): the compliance-audit-log bad example must illustrate both an append-only violation (mutation/deletion of an audit record, P1) AND a redaction failure (secret in audit log, P9) — two breaches in one example.
- **ATELIER-74** (IDEATE-28): testing-i18n.md must map pseudo-locale testing to the testing pyramid tiers (unit: missing-key detection; integration: snapshot per locale; e2e: RTL coverage).
- **ATELIER-79** (IDEATE-29): evidence.md must include a fenced signed-attestation example (Cosign or in-toto), not prose-only.
- **ATELIER-69** (IDEATE-30): monitoring-drift.md must enumerate the three drift types (data drift, concept drift, prediction drift) with a detection signal per type.
-
-### Within-Project Pattern Transfer (v0.1 → v0.2 → v0.3) — verified
-
-| v0.2 Lesson | v0.3 Application | Status |
-|-------------|------------------|--------|
-| IDEATE-09 → ATELIER-59 (peer-review parity) | ATELIER-83 already covers this | ✓ carried forward |
-| IDEATE-13/14 (chaos anti-patterns: orphan P-rule, deployable artifact) | ATELIER-84 + IDEATE-20/24/25/27 extend with v0.3-specific chaos | ✓ extended |
-| IDEATE-08 (cross-link verification: every new derived doc ≥1 outbound cross-link) | ATELIER-88 already covers this | ✓ carried forward |
-| IDEATE-02 (matrix row count = 10 per domain) | ATELIER-80 already covers this | ✓ carried forward |
-| 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 |
+| IDEATE-16 | backend-enriched | improvement | 0.68 | deferred v0.3 | — (ai-ml/i18n/compliance) |
@@ -215,251 +215,4 @@ See `.ciagent/atelier/PERSONAS.md` for the updated roster. v0.2 adds one phase-s
 4. State and modules get their own derived docs (cross-cutting IaC concerns).
 5. K8s derived docs mirror the k8s concept taxonomy: workloads, networking, storage, rbac, helm, kustomize.
 6. A phase-specific platform-engineer persona is warranted for P1–P4; removed after v0.2.
-7. No runtime code; examples are illustrative markdown only.
-
---
-
-# v0.3 Research — GitOps + Operators + AI/ML + i18n + Compliance
-
-> Research conducted during v0.3 P0 RESEARCH stage. Informs the four new domains, matrix extension (+40 mappings), and the two phase-specific personas (platform-engineer extended, ml-engineer added). See CLARIFY.md D-021..D-026 for resolved ambiguities and PROJECT.md D-016..D-026 for milestone decisions.
-
-## Domain A: GitOps + Operators (ArgoCD, Flux, Operators, Progressive Delivery)
-
-### Prior Art
-
- **CNCF OpenGitOps Principles v1.0.0** (GitOps Working Group, TAG App Delivery): the canonical 4 principles — **Declarative**, **Versioned and Immutable**, **Pulled Automatically**, **Continuously Reconciled**. Atelier's gitops-operators domain derives its first-principles from these plus the Operator pattern. ([opengitops.dev](https://opengitops.dev/), [github.com/open-gitops/documents](https://github.com/open-gitops/documents))
- **ArgoCD** (CNCF graduated): pull-based GitOps controller for k8s. Core concepts: Application CRD, sync waves, health/status assessment, diff against live cluster, RBAC, SSO. Declarative desired state from git; reconciled onto the cluster. ([argoCD.readthedocs.io](https://argoCD.readthedocs.io/))
- **Flux** (CNCF graduated): GitOps Toolkit — a set of composable controllers (source-controller, kustomize-controller, helm-controller, notification-controller). Pulls git/Helm/OCI sources, reconciles via kustomize/helm, emits events. Composable-controller architecture is a C6 (Composability) exemplar. ([fluxcd.io](https://fluxcd.io/))
- **Kubernetes Operator Pattern** (CNCF): a controller that encodes human operational knowledge as CRDs + control loops. Pattern documented in the k8s docs and "Operator Framework" (Operator SDK, OLM). Domain expertise as code; the deepest expression of k8s P1 Declarative Desired State. ([kubernetes.io/docs/concepts/extend-kubernetes/operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/))
- **Progressive Delivery** — Argo Rollouts, Flagger: canary/blue-green traffic shifting driven by analysis (metrics, counters). Extends k8s rolling updates with metric-gated promotion. Cross-links devops/P5 Progressive Delivery.
- **Google SRE** (already in Atelier v0.1 observability/devops): reconciliation loops, error budgets, progressive rollout. Cross-cutting influence.
- **v0.2 in-tree prior art**: `kubernetes/first-principles.md` P1 (Declarative Desired State), P10 (Roll Forward Roll Back); `infrastructure-as-code/first-principles.md` P1 (Declarative Intent), P3 (State is Truth), P9 (Drift is Recoverable). GitOps-operators is the deployment-automation layer above these.
-
-### Principles Identified for `gitops-operators/first-principles.md` (P1–P10)
-
-Each derived from a core C-rule (matrix extensions in P4):
-
-1. **P1 Git is the Source of Truth** — desired state lives in a versioned, immutable git store; the cluster is a derivative, not an authority. (C1 Correctness, C5 Reversibility)
-2. **P2 Declarative Over Imperative** — express desired cluster state, not the commands to reach it. (C2 Clarity, C3 Simplicity)
-3. **P3 Pull, Don't Push** — agents running inside the target pull desired state; no outside push credentials into the cluster. (C1 Correctness via security, C4 Locality)
-4. **P4 Continuous Reconciliation** — the loop is the primitive; drift is detected and corrected automatically, not on-demand. (C7 Observability, C1 Correctness)
-5. **P5 State is Immutable and Versioned** — every change is a commit; history is the audit trail and the rollback path. (C5 Reversibility)
-6. **P6 Operators Encode Domain Knowledge** — operational expertise lives as CRDs + controllers, not runbooks that humans must remember. (C6 Composability, C2 Clarity)
-7. **P7 Progressive Delivery is Reversible by Construction** — canary/blue-green are staged, metric-gated, and one-command abortable. Promotion without a rollback path is a violation. (C5 Reversibility, C1 Correctness)
-8. **P8 Reconcile, Don't Mutate by Hand** — manual `kubectl apply`/`kubectl edit` on a GitOps-managed resource is an incident; drift back to git is the recovery. (C1 Correctness, C7 Observability)
-9. **P9 Failure is Observable and Surfaced** — sync failures, health degradation, and rollout-stall events emit status + notifications; silent drift is the bug. (C7 Observability)
-10. **P10 Least Privilege Reconciliation** — the controller's credentials are scoped to the namespaces/resources it reconciles; no cluster-admin GitOps robots. (C1 Correctness via security, C8 Economy of trust)
-
-### Derived Docs
-
- `argocd.md` — Application CRD, App-of-Apps, sync waves, health checks, diffs, RBAC/SSO, multi-cluster, sync windows.
- `flux.md` — GitOps Toolkit controllers (source, kustomize, helm, notification), composable architecture, HR/Kustomization/HelmRelease CRDs, OCI sources.
- `operators.md` — Operator pattern, CRDs, controllers, Operator SDK/OLM, when to write an operator vs a Helm chart, scope/responsibility boundaries.
- `progressive-delivery.md` — Argo Rollouts + Flagger, canary/blue-green, analysis templates (metrics, counters), abort/rollback, cross-link devops/P5.
-
-### Cross-Domain Links (one-directional in v0.3, per D-026 extended)
-
- `kubernetes/P1 Declarative Desired State` ← gitops P2
- `kubernetes/P10 Roll Forward Roll Back` ← gitops P7
- `infrastructure-as-code/P1 Declarative Intent` ← gitops P2
- `infrastructure-as-code/P3 State is Truth` ← gitops P1, P5
- `infrastructure-as-code/P9 Drift is Recoverable` ← gitops P4, P8
- `devops/P1 Reproducibility` ← gitops P1, P5
- `devops/P4 Rollback First` ← gitops P5, P7
- `devops/P5 Progressive Delivery` ← gitops P7
- `devops/P6 Configuration as Code` ← gitops P1, P2
- `security/secrets` ← gitops P3, P10 (reconciliation credentials)
- `security/supply-chain` ← gitops P5 (signed/immutable manifest provenance)
- `observability/metrics` ← gitops P4, P9 (reconciliation + rollout metrics)
-
-## Domain B: AI / ML (Engineering Discipline)
-
-### Prior Art
-
- **Google MLOps / "Hidden Technical Debt in ML Systems"** (Sculley et al., 2015): the foundational paper framing ML systems as software-engineering problems with debt surfaces (data dependencies, configuration, glue code, reproducibility). Atelier's ai-ml domain is the principles-layer response.
- **DVC / Data Version Control** (iterative.ai): git for data + pipelines; treats datasets, features, and models as versioned artifacts. C5 (Reversibility) and C6 (Composability) exemplar.
- **MLflow** (Linux Foundation): experiment tracking, model registry, model packaging, deployment stages. Tracking → registry → serving lifecycle.
- **Kubeflow** (CNCF): k8s-native ML pipelines, training operators, serving (KServe). Brings ML onto the k8s reconciliation model (cross-link kubernetes).
- **KServe / Seldon Core / BentoML**: model serving runtimes; inference as a scalable, observable service. Cross-link devops/P7 Immutability, observability/metrics.
- **Evidently AI / Great Expectations**: data drift detection, data quality, model monitoring. C7 (Observability) for ML.
- **"Machine Learning Operations (MLOps)"** frameworks — Microsoft MLOps, AWS MLOps, Google MLOps maturity model. Converge on: version data, track experiments, evaluate models, serve reproducibly, monitor drift.
- **v0.2 in-tree prior art**: `kubernetes/first-principles.md` (serving on k8s), `infrastructure-as-code/` (training pipelines as declarative infra), `data/` (schema, migrations — data versioning analog).
-
-### Principles Identified for `ai-ml/first-principles.md` (P1–P10)
-
-Scope per D-023: engineering discipline (data versioning, evaluation, serving, drift), NOT algorithm/model design. Each derived from a core C-rule:
-
-1. **P1 Reproducibility is the First Class** — every training run is reproducible from pinned data + code + config + environment. Unreproducible runs are unreviewable. (C1 Correctness, C5 Reversibility)
-2. **P2 Data is Versioned, Not Just Code** — datasets, features, and splits are first-class versioned artifacts with lineage; `git` alone is insufficient. (C5 Reversibility, C7 Observability)
-3. **P3 Lineage is Traceable End-to-End** — any deployed prediction traces back through model → training run → dataset → source. No orphan models. (C7 Observability, C1 Correctness)
-4. **P4 Evaluation is Defined Before Training** — metrics, splits, and thresholds are declared a priori; cherry-picking metrics post-hoc is a correctness violation. (C1 Correctness, C2 Clarity)
-5. **P5 Models are Versioned Artifacts** — a model is a pinned, immutable, registry-tracked artifact with a unique identifier; never "the latest." (C5 Reversibility, C6 Composability)
-6. **P6 Serving is Observable** — inference latency, throughput, input distributions, and prediction confidence are first-class signals. Silent serving is a bug. (C7 Observability)
-7. **P7 Drift is Expected and Detected** — data drift, concept drift, and prediction drift are monitored; a drift signal is an incident, not a curiosity. (C7 Observability, C1 Correctness)
-8. **P8 Inference Inputs are Validated** — the model's contract (schema, ranges, types) is enforced at the serving boundary; out-of-contract inputs are rejected, not silently scored. (C1 Correctness via security/input-validation)
-9. **P9 Pipelines Compose, Notebooks Don't** — training/serving flows are composable pipelines with explicit steps and contracts; notebooks are for exploration, not production. (C6 Composability, C2 Clarity)
-10. **P10 Rollback Includes the Model** — a serving rollback restores the prior model artifact, not just the prior code; promotion is reversible at the model layer. (C5 Reversibility)
-
-### Derived Docs
-
- `data-versioning.md` — DVC/Delta Lake/LakeFS patterns, data lineage, dataset hashing, train/val/test split versioning, cross-link data/migrations.
- `model-evaluation.md` — metric selection, offline/online eval, holdout integrity, bias/fairness checks (engineering angle), eval as a gate.
- `serving.md` — KServe/Seldon/BentoML, inference as a service, batching, latency SLAs, canarying models, cross-link kubernetes + devops.
- `monitoring-drift.md` — Evidently/Great Expectations, drift types (data/concept/prediction), alerting, retraining triggers, cross-link observability/metrics.
-
-### Cross-Domain Links (one-directional in v0.3)
-
- `data/migrations` ← ai-ml P2 (data versioning ↔ migration discipline)
- `data/schema-design` ← ai-ml P8 (inference input contract)
- `observability/metrics` ← ai-ml P6, P7
- `observability/logging` ← ai-ml P3 (lineage)
- `devops/P1 Reproducibility` ← ai-ml P1
- `devops/P7 Immutability` ← ai-ml P5 (model images)
- `devops/P5 Progressive Delivery` ← ai-ml P10 (model canary)
- `security/input-validation` ← ai-ml P8
- `security/secrets` ← ai-ml P8 (serving credentials)
- `performance/backend` ← ai-ml P6 (serving latency)
- `kubernetes/workloads` ← ai-ml P9 (serving on k8s)
-
-## Domain C: Internationalization (i18n)
-
-### Prior Art
-
- **Unicode / ICU / CLDR** (Unicode Consortium): the foundation — ICU (International Components for Unicode) for formatting/collation, CLDR (Common Locale Data Repository) for locale data. The de-facto source for date/number/currency/plural/relative-time formatting. ([unicode.org/cldr](https://cldr.unicode.org/), [icu.unicode.org](https://icu.unicode.org/))
- **W3C Internationalization** (W3C i18n WG): the canonical web i18n guidance — "Internationalization techniques", "Language tags in HTML and XML", bidi/RTL authoring. Cross-links WCAG for accessibility-of-locale. ([w3.org/International](https://www.w3.org/International/))
- **RFC 5646 / BCP 47** — language tags (`en-US`, `ar-EG`, `zh-Hans-CN`). The locale identifier standard.
- **RFC 9229 / RFC 9230** (and earlier BCP 47 extensions) — Unicode locale extensions (`-u-`).
- **gettext / ICU MessageFormat / FormatJS / react-intl / i18next / Fluent (Mozilla)** — message-format libraries; ICU MessageFormat is the cross-ecosystem baseline for plural/gender/select. Fluent pioneered "localization 2.0" with asymmetric translations.
- **JavaScript Intl API** — browser-native formatting built on ICU/CLDR; the runtime baseline.
- **WCAG 2.1 AA** (already in Atelier uiux/accessibility): cross-cutting — locale support is an a11y concern for non-Latin-script users; RTL layout is a UI-correctness concern.
- **Google i18n + Mozilla L10n guides** — operational practice (string extraction, pseudo-locale testing, RTL testing).
- **v0.2/v0.1 in-tree prior art**: `uiux/` (accessibility, components, copywriting — i18n's consumer), `testing/` (fixtures, pyramid — i18n testing parallels), `api/error-responses` (localized API errors).
-
-### Principles Identified for `i18n/first-principles.md` (P1–P10)
-
-Each derived from a core C-rule:
-
-1. **P1 Source Language is a Locale, Not the Default** — the developer's language is one locale among many, not the "neutral" form. Strings are extracted from day one. (C2 Clarity, C1 Correctness)
-2. **P2 Locale Identifiers are Standardized** — use BCP 47 language tags; no ad-hoc locale codes. (C2 Clarity, C6 Composability)
-3. **P3 Resources are External, Not Inline** — user-facing strings live in locale resource files, never concatenated inline in code. (C4 Locality, C6 Composability)
-4. **P4 Plural and Gender are Parameterized** — use ICU MessageFormat (or equivalent) for plural/gender/select; never `if (n == 1)` branching. (C1 Correctness, C6 Composability)
-5. **P5 Formatting is Locale-Aware** — dates, times, numbers, currencies, units via ICU/CLDR/`Intl`; never hand-rolled formatters. (C1 Correctness, C7 Observability of format correctness)
-6. **P6 Text Direction is a Layout Primitive** — RTL/bidi is a first-class layout concern, not a CSS afterthought; logical properties (`start`/`end`) over physical (`left`/`right`). (C1 Correctness, C4 Locality)
-7. **P7 Layout Accommodates Expansion** — translated text expands/contracts; layouts are flexible (no fixed pixel widths for text). (C8 Economy of rework, C3 Simplicity)
-8. **P8 Pseudo-Locales Test Early** — test with pseudo-locales (accented, lengthened, RTL-mirrored) before real translations arrive. (C7 Observability, C5 Reversibility of finding bugs late)
-9. **P9 Images and Icons are Cultural** — icons, colors, and imagery are locale-sensitive; avoid locale-bound symbols as universal. (C1 Correctness, C2 Clarity)
-10. **P10 Translation is Reversible and Versioned** — resource files are versioned; a bad translation is a rollback, not a hot-patch. (C5 Reversibility)
-
-### Derived Docs
-
- `locale-resources.md` — resource file formats (.po/.pot, JSON, Fluent FTL, ICU Resource Bundle), key naming, namespaces, fallback chains, extraction tooling.
- `formatting.md` — ICU/CLDR/`Intl` for dates, times, numbers, currencies, units, relative time, plural rules; BCP 47 tags; cross-link api/error-responses for localized errors.
- `rtl-bidi.md` — logical vs physical CSS properties, bidi algorithm (UAX #9), `dir` attribute, mirroring, common pitfalls (icons, numbers in RTL), cross-link uiux/components + uiux/accessibility.
- `testing-i18n.md` — pseudo-locales, snapshot testing per locale, RTL coverage, missing-key detection, cross-link testing/fixtures + testing/pyramid.
-
-### Cross-Domain Links (one-directional in v0.3)
-
- `uiux/accessibility` ← i18n P6 (RTL/bidi is an a11y concern for non-Latin users)
- `uiux/components` ← i18n P6, P7
- `uiux/copywriting` ← i18n P1, P3
- `testing/fixtures` ← i18n P8
- `testing/pyramid` ← i18n P8
- `api/error-responses` ← i18n P5 (localized error messages)
- `data/schema-design` ← i18n P2, P3 (locale data shapes)
-
-## Domain D: Compliance (Audit, Retention, Policy-as-Code, Evidence)
-
-### Prior Art
-
-**Note (D-024):** the compliance domain is framework-agnostic — it abstracts regulation-specific requirements (GDPR, HIPAA, SOC 2, PCI-DSS, NIST 800-53, ISO 27001) into engineering principles. No regulation-specific docs; they would bloat the framework and go stale.
-
- **NIST Cybersecurity Framework (CSF) / NIST 800-53** — controls catalog (audit, retention, evidence, policy). Atelier abstracts the *principles*, not the controls.
- **SOC 2 (AICPA) Trust Services Criteria** — Security, Availability, Processing Integrity, Confidentiality, Privacy. Audit logs, retention, and evidence are explicit criteria.
- **GDPR / CCPA** — data subject rights, retention limits, lawful basis. Abstracted to "retention is a function of policy, not storage."
- **OWASP AppSec / ASVS** — already in Atelier security domain; compliance extends to auditability of security controls.
- **Open Policy Agent (OPA) / Rego, Cedar (AWS), HashiCorp Sentinel, Kyverno** — policy-as-code engines; policy evaluated as a gate, not a document. C6 (Composability) + C1 (Correctness) exemplars. ([openpolicyagent.org](https://www.openpolicyagent.org/), [kyverno.io](https://kyverno.io/))
- **Cosign / Sigstore / in-toto** — signed attestations and provenance; evidence-as-artifact. Cross-link security/supply-chain.
- **Google Cloud Audit Logs / AWS CloudTrail / Azure Activity Log** — the canonical audit-log patterns; immutable, append-only, queryable, time-ordered.
- **v0.2/v0.1 in-tree prior art**: `security/` (authorization, secrets, supply-chain), `observability/` (logging, metrics, tracing — audit logs are structured logging), `data/` (schema, migrations — retention schema), `infrastructure-as-code/` (policy-as-code parallels declarative IaC), `kubernetes/` (rbac — audit subject identity).
-
-### Principles Identified for `compliance/first-principles.md` (P1–P10)
-
-Each derived from a core C-rule. Framework-agnostic per D-024:
-
-1. **P1 Audit Logs are Append-Only** — audit records are immutable once written; deletion or mutation is itself an auditable incident. (C1 Correctness, C5 Reversibility)
-2. **P2 Every Significant Action is Logged** — the set of auditable actions is defined a priori; "we forgot to log it" is a violation. Auth changes, data access, config changes, policy changes. (C7 Observability, C1 Correctness)
-3. **P3 Retention is Policy, Not Storage** — data lifetime is declared and enforced; deletion at end-of-life is a feature, not a failure. (C5 Reversibility, C8 Economy of storage)
-4. **P4 Policy is Code** — compliance policy is expressed in versioned, reviewable, testable code (OPA/Cedar/Kyverno), not in spreadsheets or prose. (C6 Composability, C2 Clarity)
-5. **P5 Policy is Evaluated as a Gate** — policy violations block before the action, not after the audit; admission/CI/CD-time enforcement. (C1 Correctness, C5 Reversibility)
-6. **P6 Evidence is Collected Continuously** — evidence of compliance (logs, configs, scans, attestations) is gathered as a byproduct of operation, not assembled manually at audit time. (C7 Observability, C3 Simplicity of audit)
-7. **P7 Identity is Attributable** — every logged action traces to an authenticated principal; shared/generic identities are violations. (C1 Correctness via security, C7 Observability)
-8. **P8 Subject Access is Honored** — data-subject rights (access, export, deletion) are operations with defined contracts and audit trails; not ad-hoc. (C1 Correctness, C5 Reversibility)
-9. **P9 Secrets and Sensitive Data are Redacted in Audit** — audit logs themselves must not leak secrets; redaction is structural, not opportunistic. (C1 Correctness via security, C3 Simplicity)
-10. **P10 Compliance Posture is Observable** — the system reports its own compliance state (drift from policy, open violations, retention status); silent non-compliance is the bug. (C7 Observability, C1 Correctness)
-
-### Derived Docs
-
- `audit-logs.md` — append-only log patterns, structured audit events, CloudTrail/Cloud-Audit-Log conventions, queryability, retention of logs themselves, cross-link observability/logging + security/authorization.
- `data-retention.md` — retention policies as code, lifecycle rules, deletion as a feature, GDPR/CCPA abstracted, retention vs. backup distinction, cross-link data/migrations.
- `policy-as-code.md` — OPA/Cedar/Sentinel/Kyverno patterns, policy as a CI/CD + admission gate, policy testing, versioning policy, cross-link infrastructure-as-code (declarative intent) + kubernetes (admission).
- `evidence.md` — evidence collection as a byproduct, signed attestations (Cosign/in-toto), audit-ready export, provenance, cross-link security/supply-chain + observability/metrics.
-
-### Cross-Domain Links (one-directional in v0.3)
-
- `security/authorization` ← compliance P7 (attributable identity)
- `security/secrets` ← compliance P9 (redaction)
- `security/supply-chain` ← compliance P6, evidence.md (signed attestations)
- `observability/logging` ← compliance P1, P2 (audit logs = structured logging)
- `observability/metrics` ← compliance P10 (compliance posture metrics)
- `observability/tracing` ← compliance P6 (evidence from distributed traces)
- `data/schema-design` ← compliance P3 (retention schema)
- `data/migrations` ← compliance P3 (retention migration discipline)
- `infrastructure-as-code/P1 Declarative Intent` ← compliance P4 (policy-as-code)
- `infrastructure-as-code/P3 State is Truth` ← compliance P10 (compliance posture truth)
- `kubernetes/rbac` ← compliance P7 (audit subject identity)
- `devops/P6 Configuration as Code` ← compliance P4 (policy as code)
-
-## Architectural Fit (v0.1/v0.2 Contract Preservation)
-
- **Hierarchy preserved:** all four new domains depend on `core/`; their P-rules trace to C1–C8 via the matrix. No lateral authority.
- **10 P-rules per domain** (per D-018, D-030, D-026): consistent with v0.1 (11 domains) and v0.2 (2 domains). v0.3 adds 40 new P-rules → matrix grows 130 → 170.
- **Manifest authoritative:** all new documents added to `MANIFEST.md` in P4. Unlisted = not part of the framework.
- **No runtime code** (per D-020, PROJECT.md constraint): examples are illustrative markdown with code fences only. No `.yaml` manifests, `.po` resource files, model artifacts, policy `.rego` files, or deployable artifacts as standalone files — only fenced code blocks inside `.md` files.
- **Conflict resolution unchanged:** matrix extended, not replaced. Core precedence (C1 > C2 > ... > C8) governs any new vs existing rule conflict. Compliance rules tracing to C1 (Correctness) inherit C1's non-tradeable status where they overlap with security (per core/conflict-resolution.md §6).
- **Cross-links one-directional** (D-026 extended): new domains link outward to existing; existing domains unchanged in v0.3 (no back-link edits to v0.1/v0.2 content).
-
-## Prior Art Position (v0.3 extension)
-
-Existing GitOps/AI-ML/i18n/compliance guidance (OpenGitOps principles, ArgoCD/Flux docs, Operator pattern, MLOps maturity models, ICU/CLDR, W3C i18n, NIST/SOC 2, OPA/Kyverno) state practices and controls but none map every domain rule back to a small set of universal core principles. Atelier's v0.3 contribution is the same differentiation as v0.1 and v0.2: **traceable principle hierarchy with a join table**. The four new domains add 40 P-rules, each traced to ≥1 core C-rule, extending the matrix from 130 to 170 domain principles across 13 → 17 domains.
-
-## v0.3 Persona Assessment
-
-See `.ciagent/atelier/PERSONAS.md` for the updated roster. v0.3 adds two phase-specific personas (per D-019, D-020):
-
- **platform-engineer** (phase-specific, extended from v0.2): domain = infrastructure/platform-automation; territory = `domains/gitops-operators/**`, gitops examples; constraints add "source-of-truth is git" and "reconciliation loop is the primitive"; active for P1 GitOps/Operators only; removed after v0.3 completes.
- **ml-engineer** (phase-specific, new): domain = machine-learning engineering; territory = `domains/ai-ml/**`, `examples/good/ai-ml-reproducibility.md`; 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)"]; active for P2 AI/ML only; removed after v0.3 completes.
- **i18n (P3) + compliance (P3)** covered by tech-writer + domain-expert (D-022 — no new personas; both domains are smaller-surface and within the existing personas' competence).
-
-## v0.3 Risks and Mitigations
-
-| Risk | Mitigation |
-|------|-----------|
-| New P-rules orphaned from core (no matrix trace) | P4 extends matrix; domain-expert persona verifies every new P-rule traces to ≥1 C-rule before sign-off |
-| GitOps-operators overlaps kubernetes/infrastructure-as-code (declarative, state, drift) | Cross-links one-directional (D-026); each domain owns its angle (k8s P1 desired-state vs gitops P1 git-as-source-of-truth vs iac P3 state-is-truth) |
-| AI/ML domain drifts into algorithm/model-design (out of scope per D-023) | ml-engineer persona constraint "engineering discipline not algorithm design"; review/agent-checklist gains an ai-ml scope check in P4 |
-| Compliance domain bloats into regulation-specific docs (GDPR/SOC2) | D-024 framework-agnostic; review check in P4 rejects regulation-specific content |
-| i18n and compliance overlap on "retention of locale data" | Each owns its angle: i18n P10 (translation versioning) vs compliance P3 (data retention policy) |
-| Examples become runtime artifacts (model files, .rego, .po) | persona constraints "no runtime code"; examples are markdown with fenced code only; P5 review check |
-| Persona explosion (5 active in v0.3) | Both new personas are phase-specific and removed post-milestone; roster returns to 3 |
-| Matrix row-count verification (40 new mappings, 10 per domain) | D-026 review check: row count per domain = 10, each row ≥1 C-rule, executed in P4 |
-
-## v0.3 Conclusions
-
-1. Four new top-level domains extend the framework without breaking the v0.1/v0.2 contract.
-2. 40 new P-rules (10 per domain) all trace to core C1–C8 — matrix extends from 130 to 170 across 13 → 17 domains.
-3. GitOps-operators unifies ArgoCD/Flux/Operators/Progressive Delivery under the shared declarative-source-of-truth reconciliation loop (D-021) — splitting would fragment the P-rules.
-4. AI/ML is scoped to engineering discipline (D-023): data versioning, evaluation, serving, drift — NOT algorithm design. Reproducibility and lineage are the non-negotiables.
-5. i18n is grounded in ICU/CLDR + BCP 47 + W3C i18n; the source language is a locale, not a default.
-6. Compliance is framework-agnostic (D-024): audit/retention/policy-as-code/evidence abstract NIST/SOC2/GDPR into principles that derive from core Security/Correctness/Observability.
-7. Two phase-specific personas (platform-engineer extended, ml-engineer added); both removed post-v0.3.
-8. No runtime code; examples are illustrative markdown only.
+7. No runtime code; examples are illustrative markdown only.
@@ -1,68 +0,0 @@
-# Atelier — v0.2 Final Review + Audit (P5)
-
-> Generated during final phase P5 (REVIEW + AUDIT) of milestone v0.2. Per run.md FINAL PHASE.
-
-## Review (multi-persona, ci-code-reviewer)
-
-**Scope:** all v0.2 changes (32 files, +1787/-34 lines), all commits `main..atelier/phase/05-final-review-ship`.
-
-### P0 checks (all pass)
-
-1. ✅ IaC first-principles: exactly 10 P-rules (P1–P10)
-2. ✅ K8s first-principles: exactly 10 P-rules (P1–P10)
-3. ✅ Matrix IaC section: 10 rows, each ≥1 valid C-rule, no orphans
-4. ✅ Matrix K8s section: 10 rows, each ≥1 valid C-rule, no orphans
-5. ✅ Every P-rule name in first-principles matches its matrix row
-6. ✅ All required files exist (ATELIER-36..56, 59): 2 first-principles + 4 IaC derived + 6 k8s derived + 4 examples + matrix/manifest/review extensions
-7. ✅ MANIFEST lists both new domains with all derived docs — no manifest drift
-8. ✅ No standalone .tf/.yaml/.yml files — "no runtime code" constraint preserved (all code is fenced in .md)
-9. ✅ No hardcoded real secrets — bad examples use AWS doc placeholders and `hunter2`; good examples use `registry.example.com` + Secret refs
-10. ✅ anti-patterns.md covers secrets-in-HCL and cluster-admin
-11. ✅ rbac.md covers Pod Security Standards + Admission
-12. ✅ All cross-link targets resolve to MANIFEST-listed docs
-
-**Verdict: PASS — No P0 issues.**
-
-### P1+ issues (flagged, then fixed in this phase per run.md)
-
-| ID | Severity | Issue | Fix applied |
-|----|----------|-------|-------------|
-| REV-1 | P1 | 5 derived docs missing cross-domain links (terraform, state, modules, workloads, networking) | Added cross-links to `domains/security/secrets.md`, `domains/devops/first-principles.md`, `domains/observability/metrics.md`, `domains/security/authorization.md` |
-| REV-2 | P2 | networking.md "Dual-Stack (P4 Locality)" — wrong P-rule label | Corrected to "(C4 Locality)" |
-| REV-3 | P2 | domain-coverage.md "Concurrency broadest (7)" stale — IaC + k8s also 7 | Updated to "Concurrency, IaC, Kubernetes tied (7 each)" |
-
-All P1+ issues fixed in commit `87daca3`. No loop back to EXECUTE (per run.md final-phase rule).
-
-## Audit (lead-developer)
-
-### 1. Reconstruction test
- git log `main..atelier/phase/05-final-review-ship` shows 10 v0.2 commits (P00 complete, P01 execute/verify/complete/status, P02, P03, P04, P05 review fix).
- REQUIREMENTS.md status (covered) matches shipped phases: ATELIER-36..56, 59 all `covered`; ATELIER-57, 58 `pending` (final phase, completed at ship).
- ROADMAP.md phase statuses match: P0–P4 `complete`, P5 `pending` (→ complete at ship).
- ✅ Reconstruction passes.
-
-### 2. Branch hygiene
- Active branches: `atelier/milestone/v0.2-iac-k8s`, `atelier/phase/05-final-review-ship`.
- All execution phase branches (00–04) deleted after ship. ✅
-
-### 3. Commit discipline
- All 10 v0.2 commits contain `---ci---` blocks with project, phase, milestone, status, requirements. ✅
-
-### 4. File discipline
- `.ciagent/atelier/` contains all 8 required files: PROJECT, ROADMAP, REQUIREMENTS, ARCHITECTURE, PERSONAS, PLAN, RESEARCH, CLARIFY. ✅
- (v0.1 legacy AUDIT-P2.md, REVIEW-P7.md also present — not removed, harmless.)
-
-### 5. Tag sequence
- v0.0.0–v0.0.7 (milestone v0.1) → v0.1.0–v0.1.4 (milestone v0.2 phases 0–4).
- All v0.1.x strictly > v0.0.7. All v0.1.x strictly increasing. ✅
- Final phase tag will be v0.1.5 (next patch, IS the v0.2 milestone release per NFR rule).
-
-### 6. Manifest discipline
- All 12 new domain docs (infrastructure-as-code/*, kubernetes/*) listed in MANIFEST.md Domains table. ✅
- matrix, review (agent-checklist, peer-review-checklist, anti-patterns) all listed in Cross-Cutting. ✅
-
-**Audit verdict: CLEAN — no critical issues.**
-
-## Conclusion
-
-Review PASS (no P0, all P1+ fixed). Audit CLEAN. Milestone v0.2 is ready to ship as v0.1.5.
@@ -39,7 +39,7 @@ NFR milestone: no separate minor tag. The final patch (v0.0.7) IS the v0.1 deliv
 - Milestone v0.1 complete. All phases shipped.
 - Future: v0.2 could add `domains/ai-ml/`, `domains/i18n/`, `domains/compliance/` per spec Part 6 next-steps.

-## Milestone: v0.2 — Infrastructure as Code + Kubernetes (COMPLETE)
+## Milestone: v0.2 — Infrastructure as Code + Kubernetes (IN PROGRESS)

 **Milestone type:** NFR (all phases produce docs — no `feat` code)
 **Tag line:** v0.1.x (previous minor from v0.2)
@@ -47,12 +47,12 @@ NFR milestone: no separate minor tag. The final patch (v0.0.7) IS the v0.1 deliv

 | Phase | Name | Type | Status | Key Deliverables |
 |-------|------|------|--------|------------------|
-| 0 | Pre-Execution | docs | complete | Spec, clarify, research, ideate, plan, PERSONAS.md (adds platform-engineer persona) |
-| 1 | Infrastructure as Code Domain | docs | complete | domains/infrastructure-as-code/{first-principles, terraform, opentofu, state, modules}.md |
-| 2 | Kubernetes Domain | docs | complete | domains/kubernetes/{first-principles, workloads, networking, storage, rbac, helm, kustomize}.md |
-| 3 | Matrix + Review Integration | docs | complete | matrix/principles-matrix.md (20 new mappings), matrix/domain-coverage.md, review/{agent-checklist, peer-review-checklist, anti-patterns}.md, MANIFEST.md |
-| 4 | Examples + Cross-Links | docs | complete | examples/good/{terraform-module, k8s-deployment}.md, examples/bad/{terraform-unlocked-state, k8s-bare-pod-no-resources}.md, cross-links to devops/security/observability/data |
-| 5 | Final Review + Ship | docs | complete | Review passed, audit clean, milestone merged to main, tag v0.1.5 |
+| 0 | Pre-Execution | docs | in_progress | Spec, clarify, research, ideate, plan, PERSONAS.md (adds platform-engineer persona) |
+| 1 | Infrastructure as Code Domain | docs | pending | domains/infrastructure-as-code/{first-principles, terraform, opentofu, state, modules}.md |
+| 2 | Kubernetes Domain | docs | pending | domains/kubernetes/{first-principles, workloads, networking, storage, rbac, helm, kustomize}.md |
+| 3 | Matrix + Review Integration | docs | pending | matrix/principles-matrix.md (20 new mappings), matrix/domain-coverage.md, review/{agent-checklist, peer-review-checklist, anti-patterns}.md, MANIFEST.md |
+| 4 | Examples + Cross-Links | docs | pending | examples/good/{terraform-module, k8s-deployment}.md, examples/bad/{terraform-unlocked-state, k8s-bare-pod-no-resources}.md, cross-links to devops/security/observability/data |
+| 5 | Final Review + Ship | docs | pending | Review passed, audit clean, milestone merged to main, tag v0.1.5 |

 ## v0.2 Phase Tag Mapping

@@ -76,50 +76,9 @@ NFR milestone: no separate minor tag. The final patch (v0.1.5) IS the v0.2 deliv
 - 2 deferred to v0.3 (GitOps/operators domain; ai-ml/i18n/compliance domains)
 - See `.ciagent/atelier/REQUIREMENTS.md` "v0.2 Ideation Log" for the full table

-## Milestone: v0.3 — GitOps + Operators + AI/ML + i18n + Compliance (ACTIVE)
-
-**Milestone type:** NFR (all phases produce docs — no `feat` code)
-**Tag line:** v0.2.x (previous minor from v0.3)
-**Phases:** P0 (pre-execution) + P1–P5 (execution) + P6 (final review+ship)
-
-| Phase | Name | Type | Status | Key Deliverables |
-|-------|------|------|--------|------------------|
-| 0 | Pre-Execution | docs | complete | Spec, clarify, research, ideate, plan, PERSONAS.md (extends platform-engineer, adds ml-engineer) — shipped v0.2.0 |
-| 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 | pending | domains/ai-ml/{first-principles, data-versioning, model-evaluation, serving, monitoring-drift}.md |
-| 3 | i18n + Compliance Domains | docs | pending | 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 |
-| 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
-
-Per branch-strategy.md, milestone `v0.3` tags run on the `v0.2.x` patch line:
-
-| Phase | Tag | Notes |
-|-------|-----|-------|
-| P0 | v0.2.0 | Pre-execution release |
-| P1 | v0.2.1 | GitOps + Operators domain |
-| P2 | v0.2.2 | AI/ML domain |
-| P3 | v0.2.3 | i18n + Compliance domains |
-| P4 | v0.2.4 | Matrix + review integration |
-| P5 | v0.2.5 | Examples + cross-links |
-| P6 | v0.2.6 | Final review + ship — **IS the v0.3 milestone release** |
-
-NFR milestone: no separate minor tag. The final patch (v0.2.6) IS the v0.3 deliverable.
-
-## v0.3 Ideation Outcome
-
- 14 ideas generated (mechanical 5, backend-enriched 7, within-project transfer 2 merged)
- 14 accepted (all v0.3-scope, confidence ≥ 0.78, above 0.6 autonomy threshold → auto-accepted)
- 1 new requirement added: ATELIER-91 (examples/ in MANIFEST — pre-existing drift from v0.2 audit escalation)
- 13 refinements to existing reqs ATELIER-61..90 (decision matrices, chaos anti-patterns, drift-type enumeration, etc.)
- 0 deferred to v0.4
- See `.ciagent/atelier/REQUIREMENTS.md` "v0.3 Ideation Log" for the full table
-
 ## Future Milestones

- **v0.4** (candidates): `domains/edge/`, `domains/quantum/`, language-specific derived docs, tooling adapters (linters), translation/localization of framework docs.
+- **v0.3** (candidates from ideation): `domains/gitops-operators/` (ArgoCD, Flux), `domains/ai-ml/`, `domains/i18n/`, `domains/compliance/` per spec Part 6 and v0.2 deferred ideation.

 ## Success Criteria

@@ -3,8 +3,8 @@
    {
      "slug": "atelier",
      "name": "Atelier",
-      "milestone": "v0.3",
-      "status": "active"
+      "milestone": "v0.2",
+      "status": "specify"
    }
  ],
  "active_project": "atelier",
@@ -34,15 +34,11 @@
 | Documentation | ✓                | doc-templates |
 | Concurrency   | ✓                | patterns |
 | DevOps        | ✓                | ci-cd, environments |
-| Infrastructure as Code | ✓      | terraform, opentofu, state, modules |
-| Kubernetes    | ✓                | workloads, networking, storage, rbac, helm, kustomize |

 ## Cross-Cutting

 | Document                          | Purpose                          |
 |-----------------------------------|----------------------------------|
-| `matrix/principles-matrix.md`     | Maps domain → core principles (13 domains, 130 P-rules post-v0.2) |
-| `matrix/domain-coverage.md`       | Maps core → domains; per-domain coverage |
-| `review/agent-checklist.md`       | Pre-completion agent checklist (incl. IaC + k8s triggers) |
-| `review/peer-review-checklist.md` | Human peer-review checklist (incl. IaC + k8s sections) |
-| `review/anti-patterns.md`         | Catalog of violations (incl. IaC + k8s + chaos anti-patterns) |
+| `matrix/principles-matrix.md`     | Maps domain → core principles    |
+| `review/agent-checklist.md`       | Pre-completion agent checklist   |
+| `review/anti-patterns.md`         | Catalog of violations            |
@@ -1,90 +0,0 @@
-# Data Versioning — Derived Rules
-
-> Derives from `domains/ai-ml/first-principles.md`. Covers P2 (Data is
-> Versioned, Not Just Code) and P3 (Lineage is Traceable End-to-End).
-> Referenced by `serving.md` and `monitoring-drift.md`. Scope per
-> D-023: engineering discipline of versioning data, not dataset
-> content design.
-
-## Why Data Versioning (P2 Data is Versioned, Not Just Code)
-
- `git` versions code well and data badly. Datasets do not fit in
-  git, and a dataset is not recovered from a commit hash.
- A model trained on "the data" is a model trained on an unknown
-  input — a C1 (Correctness) violation. The dataset is a build
-  input; it is named, hashed, and recoverable the way any build
-  input is.
- Data versioning is the ML analogue of `domains/data/migrations.md`:
-  the schema and contents of the data evolve, every evolution is a
-  versioned migration, and every model points at a specific version.
-
-## Dataset Hashing and Lineage (P3 Lineage Traceable End-to-End)
-
- Every dataset version has a content hash (not a filename or a
-  timestamp). The hash is the identity. A model's lineage record
-  names the dataset hash it was trained on; a serving prediction
-  names the model digest it came from.
- Lineage is a graph: prediction → model → training run → dataset →
-  source(s). Any edge missing is an orphan (`domains/observability/logging.md`
-  for the structured-log angle on lineage events).
- The lineage record is append-only. Editing it to "fix" a broken
-  trace is the same class of violation as editing an audit log.
-
-## Train/Val/Test Split Versioning (P2, P4 Eval Defined Before Training)
-
- Splits are versioned with the dataset, not derived ad-hoc per run.
-  A split is a deterministic function of (dataset version, split
-  config, random seed). Two runs on the same pinned inputs produce
-  the same splits.
- The eval split is held out and never touched by training. A "held
-  out" set that leaked into training is a P4 (Evaluation Defined
-  Before Training) violation, not just a P2 violation — the eval
-  gate is measuring the training set, not the model.
- Cross `domains/data/schema-design.md` for the eval input contract:
-  the schema of the eval set is part of the versioned artifact.
-
-## Tool Comparison (IDEATE-22, D-040)
-
-| Tool | Versioning Model | Lineage | Best For | Notes |
-|------|------------------|---------|----------|-------|
-| DVC | Git-like pointers to content-addressed object store; `.dvc` files in git track data versions | Pipeline DAG in `dvc.yaml`; reproducibility via `dvc repro` | Teams already on git; file/directory datasets; ML pipelines | Treats data like code; shares git's history model. Object store is pluggable (S3, GCS, Azure, SSH) |
-| Delta Lake | Table format with transaction log (ACID) + time travel via versioned commits; schema enforcement | Time travel queries; lineage via table history + catalog | Large tabular data; lakehouse; streaming + batch on the same table | Not a pipeline tool — pairs with Spark/Trino/Flink. Brings DB guarantees to object storage |
-| LakeFS | Git-like operations (branch, commit, merge) over object storage itself | Branch model gives isolated, reproducible data branches | Data engineering teams; branch-per-experiment; CI over data | Not a table format — versions objects. Composes with Delta/Iceberg on top |
-
- Pick one primary versioning model per platform. Mixing DVC's
-  pointer model with Delta's transaction-log model fragments
-  operational knowledge (C4 Locality).
- All three satisfy P2; the choice is which fits the data shape and
-  the team's existing tooling. None is advocated over the others.
-
-## Reproducibility Contract (P1 Reproducibility is the First Class)
-
-A reproducible training run records, in one versioned place:
-
-```
-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/model@sha256:b5e1...aa0
-```
-
- Lose any line and the run is anecdote, not evidence.
- The record is the lineage root: a prediction cites the
-  `model_digest`, which cites the `run_id`, which cites everything
-  above. This is how P3 (Lineage Traceable End-to-End) is satisfied
-  in practice.
-
-## What Violates Data Versioning Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Dataset referenced by `s3://bucket/latest/` | P2 Data is Versioned, Not Just Code |
-| Splits regenerated with an unpinned seed per run | P2, P4 Evaluation Defined Before Training |
-| A production model with no dataset hash in its lineage | P3 Lineage Traceable End-to-End |
-| Editing a lineage record to "clean up" a broken trace | P3 Lineage Traceable End-to-End |
-| Eval split reachable from the training data path | P4 Evaluation Defined Before Training |
-| Two platforms versioning the same data with different models | C4 Locality |
@@ -1,154 +0,0 @@
-# AI / ML — First Principles
-
-> Scope per D-023: this domain covers ML **engineering discipline** —
-> data versioning, evaluation methodology, serving patterns, and drift
-> detection. It does **not** cover algorithm design, model architecture
-> selection, hyperparameter tuning, or model-family comparison. Those
-> are research choices, not engineering principles, and they have no
-> derivation in the core C-rules.
-
-## 1. The Principles
-
-### P1. Reproducibility is the First Class
-Every training run is reproducible from pinned data + code + config +
-environment. An unreproducible run is an unreviewable run: you cannot
-decide whether a result is correct if you cannot recreate it.
-Reproducibility is the ML analogue of `domains/devops/P1
-Reproducibility` and inherits its non-negotiable status. Lose any one
-of data, code, config, or environment pinning, and the run is
-anecdote, not evidence.
-
-### P2. Data is Versioned, Not Just Code
-Datasets, features, and train/val/test splits are first-class
-versioned artifacts with content hashes and lineage. `git` alone is
-insufficient — datasets do not fit in git, and a dataset is not a
-commit hash. A model trained on "the data" is a model trained on an
-unknown input, which is a correctness violation. Version data the way
-you version code: pinned, named, and recoverable.
-
-### P3. Lineage is Traceable End-to-End
-Any deployed prediction traces back through model → training run →
-dataset → source. No orphan models. A model in production with no
-lineage is a correctness defect: you cannot reason about its failure
-modes, you cannot roll it back to a known-good dataset, and you cannot
-tell whether drift is in the model or in the data that built it.
-Lineage is the audit trail of ML (`domains/observability/logging.md`).
-
-### P4. Evaluation is Defined Before Training
-Metrics, splits, and acceptance thresholds are declared a priori, in
-code, before the model is trained. Cherry-picking metrics post-hoc is
-a correctness violation: the evaluation is no longer measuring the
-model, it is rationalizing it. The eval spec is a contract — it is
-reviewable, it is versioned, and it is the gate the model must pass
-before it leaves the experiment. This is the ML angle on C2 Clarity:
-the intent of the model is obvious to its reader because the eval
-declared it first.
-
-### P5. Models are Versioned Artifacts
-A model is a pinned, immutable, registry-tracked artifact with a
-unique identifier. Never "the latest." A serving endpoint that pulls
-"latest" is serving an unknown model — its behavior is undefined, its
-rollback is impossible, and its lineage is broken. The model registry
-is to models what a container registry is to images
-(`domains/devops/P7 Immutability`): immutable, addressed by digest,
-promoted by stage.
-
-### P6. Serving is Observable
-Inference latency, throughput, input distributions, and prediction
-confidence are first-class signals. Silent serving is a bug. A model
-in production that emits no metrics is a model you cannot operate: you
-cannot see latency regressions, you cannot see input drift, you cannot
-see a failing downstream consumer. Observability is designed in, not
-bolted on (`domains/observability/metrics.md`).
-
-### P7. Drift is Expected and Detected
-Data drift, concept drift, and prediction drift are monitored as a
-matter of course. A drift signal is an incident, not a curiosity. ML
-systems decay without code changes — the world changes under the
-model — so "no code changed" is not a defense against a serving
-regression. Detecting drift is the ML-specific form of C7
-Observability: you cannot fix a model you cannot see degrading.
-
-### P8. Inference Inputs are Validated
-The model's input contract — schema, value ranges, types, and
-categorical domains — is enforced at the serving boundary.
-Out-of-contract inputs are rejected, not silently scored. Scoring an
-out-of-contract input is a correctness violation: the model's output
-is undefined for inputs outside its training distribution, and
-returning a number for it is lying to the caller. This is the ML angle
-on `domains/security/input-validation.md` and inherits C1's
-non-tradeable status.
-
-### P9. Pipelines Compose, Notebooks Don't
-Training and serving flows are composable pipelines with explicit
-steps, named inputs, named outputs, and contracts between stages.
-Notebooks are for exploration, not production. A notebook in the
-serving path is a correctness defect: its state is implicit, its
-order is human-dependent, and its reproducibility is whatever the last
-operator remembered. Compose pipelines; keep notebooks in the lab.
-
-### P10. Rollback Includes the Model
-A serving rollback restores the prior model artifact, not just the
-prior code. Promotion is reversible at the model layer. A rollback
-that redeploys old code but keeps the new model has not rolled back —
-the model was the thing that regressed. The rollback path must name
-the prior model digest, the prior dataset version, and the prior eval
-that cleared it. This is the ML angle on `domains/devops/P4 Rollback
-First` and `domains/kubernetes/P10 Roll Forward, Roll Back`.
-
-## 2. Core Principle Trace
-
-Each AI/ML P-rule derives from one or more core C-rules (C1–C8). The
-matrix extension lands in P4 of the v0.3 plan; the traces below are
-authoritative.
-
-| P-rule | Core | Why |
-|--------|------|-----|
-| P1 Reproducibility is the First Class | C1, C5 | Correctness of results; reversibility of runs |
-| P2 Data is Versioned, Not Just Code | C5, C7 | Reversibility of datasets; observability of data lineage |
-| P3 Lineage is Traceable End-to-End | C7, C1 | Observability of provenance; correctness of attribution |
-| P4 Evaluation is Defined Before Training | C1, C2 | Correctness of the eval gate; clarity of a-priori intent |
-| P5 Models are Versioned Artifacts | C5, C6 | Reversibility of model identity; composability of registry stages |
-| P6 Serving is Observable | C7 | Observability of inference |
-| P7 Drift is Expected and Detected | C7, C1 | Observability of degradation; correctness of detection |
-| P8 Inference Inputs are Validated | C1 | Correctness of the serving boundary (security subset) |
-| P9 Pipelines Compose, Notebooks Don't | C6, C2 | Composability of stages; clarity of explicit contracts |
-| P10 Rollback Includes the Model | C5 | Reversibility at the model layer |
-
-## 3. What Violates These Principles
-
-| Violation | Principle Breached |
-|-----------|-------------------|
-| A training run that cannot be replayed from pinned inputs | P1 Reproducibility is the First Class |
-| A dataset referenced by a mutable path, not a hash | P2 Data is Versioned, Not Just Code |
-| A production model with no record of its training data | P3 Lineage is Traceable End-to-End |
-| Metrics chosen after seeing the results | P4 Evaluation is Defined Before Training |
-| A serving endpoint that pulls `latest` from the registry | P5 Models are Versioned Artifacts |
-| A model in production with no latency or throughput metrics | P6 Serving is Observable |
-| A serving regression dismissed as "no code changed" | P7 Drift is Expected and Detected |
-| An input with an out-of-range feature scored silently | P8 Inference Inputs are Validated |
-| A notebook in the serving or training pipeline path | P9 Pipelines Compose, Notebooks Don't |
-| A rollback that restores code but keeps the regressed model | P10 Rollback Includes the Model |
-
-## 4. Relationship to Other Domains
-
-AI/ML is the engineering-discipline layer for model-bearing systems.
-It borrows the reproducibility, immutability, rollback, and
-observability disciplines of `domains/devops/` and applies them to
-the data → model → serving lifecycle. Cross-links are one-directional
-(per D-026 extended):
-
- `domains/devops/P1 Reproducibility` ← P1
- `domains/devops/P4 Rollback First` ← P10
- `domains/devops/P5 Progressive Delivery` ← P10 (model canary)
- `domains/devops/P7 Immutability` ← P5 (model images)
- `domains/data/migrations.md` ← P2 (data versioning ↔ migration discipline)
- `domains/data/schema-design.md` ← P8 (inference input contract)
- `domains/observability/metrics.md` ← P6, P7
- `domains/observability/logging.md` ← P3 (lineage)
- `domains/security/input-validation.md` ← P8
- `domains/security/secrets.md` ← P8 (serving credentials)
- `domains/performance/backend.md` ← P6 (serving latency)
- `domains/kubernetes/workloads.md` ← P9 (serving on k8s)
- `domains/testing/first-principles.md` ← P4 (eval as a gate)
- `domains/gitops-operators/first-principles.md` ← P10 (model rollback in a GitOps loop)
@@ -1,94 +0,0 @@
-# Model Evaluation — Derived Rules
-
-> Derives from `domains/ai-ml/first-principles.md`. Covers P4
-> (Evaluation is Defined Before Training) and the eval-as-a-gate
-> discipline. Referenced by `serving.md` (promotion gate) and
-> `monitoring-drift.md` (online eval). Scope per D-023: evaluation
-> methodology, not metric math or model-family benchmarks.
-
-## Evaluation is a Gate, Not a Report (P4 Evaluation Defined Before Training)
-
- The eval spec — metrics, splits, thresholds, and pass/fail
-  criteria — is declared in code **before** the model is trained.
-  It is versioned with the data and the code; it is reviewable; it
-  is the contract the model must satisfy to leave the experiment.
- Cherry-picking metrics after seeing results is a correctness
-  violation: the eval is no longer measuring the model, it is
-  rationalizing it. The a-priori spec is what makes the eval
-  trustworthy.
- This is the ML angle on `domains/testing/first-principles.md` P1
-  (Tests as Specification): the eval declares the model's contract,
-  the model does not declare its own success.
-
-## The Eval Input Contract (P8 Inference Inputs are Validated, cross `domains/data/schema-design.md`)
-
- The eval set has a schema: feature names, types, ranges, and
-  categorical domains. That schema is the same schema the serving
-  boundary enforces (`serving.md`, `domains/security/input-validation.md`).
- An eval set whose schema drifted from the serving schema is
-  measuring a different model than the one in production. Schema
-  parity is part of the versioned eval artifact.
- Cross `domains/data/schema-design.md`: the eval input contract is
-  a schema-design problem, versioned and reviewed like any schema.
-
-## Holdout Integrity (P4, P2 Data is Versioned)
-
- The held-out eval set is never touched by training, feature
-  selection, or threshold tuning. A "held out" set that influenced
-  any training decision is not held out — it is a third training
-  set, and the eval is measuring memorization.
- Splits are versioned with the dataset (`data-versioning.md`).
-  Recreating splits ad-hoc per run breaks comparability across runs.
- Reusing a held-out set across many model iterations leaks it
-  incrementally. Rotate or re-split on a cadence; record the
-  rotation in lineage.
-
-## Offline vs Online Evaluation (P6 Serving is Observable)
-
- **Offline eval** runs before promotion: held-out data, pinned
-  model, declared metrics, pass/fail gate. It answers "should this
-  model ship?"
- **Online eval** runs after promotion, on live traffic: shadow
-  scoring, A/B, canary metrics. It answers "is this model behaving
-  in production?" It is the bridge to `monitoring-drift.md`.
- A model that passed offline and regressed online is not a
-  contradiction — it is a signal that the offline distribution
-  differs from the live one (a P7 drift signal). Both eval layers
-  are required; neither substitutes for the other.
-
-## Bias and Fairness Checks (Engineering Angle, P4)
-
- Bias/fairness checks are part of the a-priori eval spec, not an
-  afterthought. They are metrics with thresholds, declared before
-  training, gated the same as any metric.
- This doc covers the **engineering** discipline: the checks are
-  versioned, gated, and recorded in lineage. The choice of which
-  fairness metrics and what thresholds are policy decisions, not
-  engineering principles, and are out of scope here (D-023).
-
-## Eval-as-a-Gate in the Pipeline (P9 Pipelines Compose)
-
- The eval is a pipeline stage with a contract: input = model
-  digest + eval dataset version; output = pass/fail + metric
-  report. It composes with the training stage and the promotion
-  stage.
- A promotion that bypasses the eval stage is a P4 violation,
-  regardless of who approved it. The gate is in the pipeline, not
-  in a human sign-off sheet.
-
-```
-train -> eval(gate) -> register(promote) -> serve
-                 |
-                 +-- fail -> abort, no promote
-```
-
-## What Violates Evaluation Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Metrics chosen after seeing the scores | P4 Evaluation Defined Before Training |
-| Held-out set used in feature selection or threshold tuning | P4, P2 |
-| Eval schema differs from serving schema | P8 Inference Inputs are Validated |
-| Promotion by human approval, bypassing the eval stage | P4, P9 Pipelines Compose |
-| A "passing" model with no online eval in production | P6 Serving is Observable |
-| Fairness checks added after a model shipped | P4 Evaluation Defined Before Training |
@@ -1,88 +0,0 @@
-# Monitoring & Drift — Derived Rules
-
-> Derives from `domains/ai-ml/first-principles.md`. Covers P7 (Drift
-> is Expected and Detected) and the online half of P6 (Serving is
-> Observable). Referenced by `serving.md` (online eval) and
-> `model-evaluation.md` (online layer). Scope per D-023: drift
-> detection methodology, not model retraining architecture.
-
-## Drift is Expected and Detected (P7 Drift is Expected and Detected)
-
- ML systems decay without code changes. The world changes under
-  the model: user behavior shifts, input pipelines change,
-  upstream schemas evolve. "No code changed" is not a defense
-  against a serving regression.
- A drift signal is an incident, not a curiosity. It triggers an
-  alert, an investigation, and a decision (retrain, roll back, or
-  accept with a recorded justification). Silent drift is the same
-  class of bug as silent serving (P6).
- Cross `domains/observability/metrics.md` for the alerting
-  primitives and `domains/observability/logging.md` for the
-  structured events a drift signal emits.
-
-## The Three Drift Types (IDEATE-30, D-048)
-
-| Drift Type | What Changes | Detection Signal | Source of Truth |
-|------------|--------------|------------------|-----------------|
-| **Data drift** (input drift) | The distribution of inputs at serving time diverges from the distribution the model was trained on | Statistical distance between the live input distribution and the pinned training-set distribution (e.g., PSI, KL, KS test). Alert on threshold breach | Training dataset hash (`data-versioning.md`) + live input metrics |
-| **Concept drift** | The relationship between inputs and the target changes — the same input now maps to a different correct output | Ground-truth lag: compare delayed labels against predictions on the same inputs. Rising error rate against a stable input distribution signals concept, not data, drift | Delayed-label feedback stream + prediction log |
-| **Prediction drift** (output drift) | The distribution of the model's predictions shifts, with no change to inputs | Statistical distance between the live prediction distribution and a pinned baseline prediction distribution. Independent of inputs — catches model-internal regressions and upstream silent changes | Prediction log + baseline prediction snapshot |
-
- The three signals are distinct and non-substitutable. Data drift
-  catches the input changing; concept drift catches the world
-  changing; prediction drift catches the model's behavior changing.
-  A monitoring setup with only one is blind to two classes of
-  regression.
- Evidently AI and Great Expectations are the canonical tooling:
-  Evidently for drift/statistical reports, Great Expectations for
-  data-quality/contract checks at the pipeline boundary. Both
-  produce the metrics that feed `domains/observability/metrics.md`.
-
-## Detection Signals in Practice
-
- **Data drift** compares live inputs to the **pinned training
-  distribution** — not to "yesterday's inputs." Without a pinned
-  baseline, drift is measured against a moving target and is
-  meaningless. Cross `data-versioning.md` for how the baseline is
-  pinned.
- **Concept drift** requires ground truth, which is often delayed
-  (days/weeks). The detection signal is the gap between
-  prediction-time confidence and delayed-label error. A rising
-  error against stable inputs is the signature.
- **Prediction drift** needs no ground truth and no input
-  comparison — it watches the model's own output distribution. It
-  is the cheapest signal and the first to fire; it is also the
-  least specific (any of the three drifts can move predictions).
-
-## Alerting and Retraining Triggers (P7, P10 Rollback Includes the Model)
-
- A drift alert is an incident. It does not auto-trigger retraining
-  unsupervised — auto-retraining on drift can lock in a bad
-  distribution. The alert triggers a human decision: investigate,
-  retrain, roll back, or accept.
- Retraining is a new training run (`first-principles.md` P1): it
-  produces a new model digest, passes the eval gate
-  (`model-evaluation.md`), and is promoted through the registry
-  (`serving.md`). The prior model stays rollbackable (P10).
- Cross `domains/observability/metrics.md` for the alert-rule
-  pattern: threshold + window + severity, routed to the same
-  on-call path as any production incident.
-
-## Online Evaluation Bridge (P6 Serving is Observable)
-
- Online eval (`model-evaluation.md`) is the live counterpart to
-  drift monitoring: shadow scores and A/B canaries measure a
-  candidate model against the incumbent, while drift monitoring
-  measures the incumbent against its own baseline. Both feed the
-  same metrics pipeline.
-
-## What Violates Monitoring Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Only one drift type monitored | P7 Drift is Expected and Detected |
-| Drift baseline is "yesterday's inputs," not pinned training data | P7, P2 Data is Versioned |
-| Drift alert that auto-retrains without a human gate | P7, P1 Reproducibility |
-| A serving regression dismissed as "no code changed" | P7 Drift is Expected and Detected |
-| Concept-drift check with no delayed-label feedback path | P7 Drift is Expected and Detected |
-| Prediction-distribution change with no alert | P6 Serving is Observable, P7 |
@@ -1,88 +0,0 @@
-# Serving — Derived Rules
-
-> Derives from `domains/ai-ml/first-principles.md`. Covers P5 (Models
-> are Versioned Artifacts), P6 (Serving is Observable), P8 (Inference
-> Inputs are Validated), and P10 (Rollback Includes the Model).
-> Referenced by `monitoring-drift.md` (online signals) and
-> `model-evaluation.md` (promotion gate). Scope per D-023: serving
-> patterns, not model architectures.
-
-## The Model is an Addressed Artifact (P5 Models are Versioned Artifacts)
-
- A serving endpoint pulls a model by digest, never by `latest`. A
-  model pulled by `latest` is an unknown model — its behavior is
-  undefined and its rollback is impossible.
- The model registry is to models what a container registry is to
-  images (`domains/devops/P7 Immutability`): immutable, addressed by
-  digest, promoted by stage (staging → prod). Promotion is a
-  registry operation, not a file copy.
- A serving rollout names the model digest in its manifest. The
-  digest is part of the deploy's lineage (`data-versioning.md`).
-
-## Inference Inputs are Validated (P8 Inference Inputs are Validated)
-
- The model's input contract — schema, types, ranges, categorical
-  domains — is enforced at the serving boundary, before the model
-  sees the input. Out-of-contract inputs are rejected with a
-  defined error, not silently scored.
- Scoring an out-of-contract input is a C1 (Correctness) violation:
-  the model's output is undefined outside its training
-  distribution, and returning a number for it is lying to the
-  caller.
- This is the ML angle on `domains/security/input-validation.md`:
-  the validation lives at the boundary, the model is downstream of
-  it, and the contract is versioned with the model.
-
-## Serving is Observable (P6 Serving is Observable)
-
- Every inference path emits: request latency, throughput, input
-  distribution summaries, prediction confidence, and error counts.
-  Silent serving is a bug.
- Cross `domains/observability/metrics.md` for the metrics
-  primitives (histograms, counters, gauges) and
-  `domains/observability/tracing.md` for the request-level trace
-  that ties an input to a prediction.
- Latency SLAs are enforced via `domains/performance/backend.md`
-  disciplines: budget the inference path, measure the tail (p99),
-  alert on budget breach.
-
-## Serving Patterns (P9 Pipelines Compose)
-
-| Pattern | When | Notes |
-|---------|------|-------|
-| Inference as a service | Default; model behind an HTTP/gRPC endpoint | KServe, Seldon Core, BentoML. Scales with traffic; model is a deployable, addressable artifact |
-| Batch inference | Offline scoring of large datasets | No latency SLA; throughput-bound. Same model digest, same input contract |
-| Embedded / in-process | Latency-critical, single-tenant | Model linked into the app. Trades observability for latency — only when the SLA demands it |
-
- Canarying a model is a serving pattern, not a deployment pattern:
-  shift a fraction of traffic to the new model digest, measure
-  online eval (`model-evaluation.md`), abort to the prior digest on
-  regression. This is `domains/devops/P5 Progressive Delivery`
-  applied at the model layer.
- Rollback restores the prior model digest (P10 Rollback Includes
-  the Model). A rollback that redeploys old code but keeps the new
-  model has not rolled back. Cross `domains/gitops-operators/first-principles.md`
-  for the GitOps reconciliation loop that drives model rollouts.
-
-## Tool Landscape (KServe / Seldon Core / BentoML)
-
-| Tool | Model Packaging | Deployment Surface | Notes |
-|------|-----------------|--------------------|-------|
-| KServe | InferenceService CRD; runtime predictors (v2, HuggingFace, PMML, custom) | Kubernetes-native; CRD-driven | Cross `domains/kubernetes/workloads.md`. Brings the k8s reconciliation model to serving |
-| Seldon Core | SeldonDeployment CRD; graph of predictors | Kubernetes-native; CRD-driven | Emphasizes inference graphs (fan-out, ensemble) as CRD structure |
-| BentoML | Bento (model + runtime + deps packaged); Yatai registry | Kubernetes or bare container | Focuses on packaging + registry; the Bento is the versioned artifact (P5) |
-
- All three satisfy P5/P6/P8 when wired correctly; the choice is
-  packaging model and deployment surface, not correctness.
- None is advocated over the others.
-
-## What Violates Serving Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Endpoint pulls `latest` from the registry | P5 Models are Versioned Artifacts |
-| Out-of-range input scored silently | P8 Inference Inputs are Validated |
-| Serving path emits no latency or throughput metrics | P6 Serving is Observable |
-| Rollback redeploys code but keeps the regressed model | P10 Rollback Includes the Model |
-| A notebook in the serving path | P9 Pipelines Compose, Notebooks Don't |
-| Canary with no abort-to-prior-digest path | P10, `domains/devops/P5 Progressive Delivery` |
@@ -1,176 +0,0 @@
-# ArgoCD — Derived Rules
-
-> Derives from `domains/gitops-operators/first-principles.md`.
-> Applies P1–P10 to ArgoCD specifically. For the ArgoCD-vs-Flux
-> decision, see the decision matrix at the end of this doc and in
-> `flux.md`.
-
-## What ArgoCD Is (P1 Git is the Source of Truth, P3 Pull, Don't Push)
-
- ArgoCD is a pull-based GitOps controller for Kubernetes. It runs
-  inside the target cluster, pulls desired state from git, and
-  reconciles the cluster to match. CI never holds `kubectl` rights
-  against the cluster (P3).
- An Application is a declarative binding of "this git path" to
-  "this cluster destination." The Application CRD is the unit of
-  reconciliation. The cluster is a derivative of git, never the
-  authority (P1).
- ArgoCD supports Helm charts, Kustomize overlays, ksonnet, and raw
-  manifests as source formats — see `domains/kubernetes/helm.md`
-  and `domains/kubernetes/kustomize.md`.
-
-## Application CRD (P2 Declarative Over Imperative, P4 Continuous Reconciliation)
-
- An Application declares `source` (repo, path, revision, chart),
-  `destination` (server, namespace), and `syncPolicy`. The
-  reconciler loops continuously; drift is corrected automatically,
-  not on-demand (P4).
-
-```yaml
-apiVersion: argoproj.io/v1alpha1
-kind: Application
-metadata:
-  name: payments-api
-  namespace: argocd
-spec:
-  source:
-    repoURL: https://git.example.com/platform/payments
-    targetRevision: 1.2.3
-    path: manifests/prod
-  destination:
-    server: https://kubernetes.default.svc
-    namespace: payments
-  syncPolicy:
-    automated:
-      prune: true
-      selfHeal: true
-    syncOptions:
-      - CreateNamespace=false
-```
-
- `automated.prune: true` deletes resources removed from git.
-  `selfHeal: true` corrects hand-edited drift back to git (P8).
-  Disable both for workloads that need manual approval gates.
-
-## App-of-Apps (P6 Operators Encode Domain Knowledge, C6 Composability)
-
- The App-of-Apps pattern: one root Application points at a git
-  directory of child Application manifests. The root app reconciles
-  the children; the children reconcile the workloads. This is the
-  ArgoCD expression of composition — a fleet of apps as a tree of
-  Applications.
- Use App-of-Apps for cluster bootstrapping (one repo, many
-  clusters, many apps). Do not use it as a substitute for a package
-  manager; if you are templating hundreds of near-identical
-  Applications, use a generator (ApplicationSet) instead.
-
-## Sync Waves and Hooks (P4 Continuous Reconciliation, P7 Reversibility)
-
- Sync waves order resources within a sync: `PreSync` → `Sync` →
-  `PostSync`. Use waves to run a job before a Deployment, or a
-  migration before the app that depends on it.
- Sync hooks (`PreSync`, `Sync`, `PostSync`, `SyncFail`) are
-  Resources annotated to execute at a wave boundary. A `SyncFail`
-  hook runs on sync failure — the abort path (P7).
- Wave ordering is a correctness mechanism, not a performance one.
-  Mis-ordered waves (e.g., app starts before its migration job)
-  are a correctness bug.
-
-## Health and Status (P9 Failure is Observable and Surfaced)
-
- ArgoCD assesses every resource's health (`Healthy`, `Progressing`,
-  `Degraded`, `Missing`, `Suspended`) and surfaces the aggregate as
-  Application status. Sync status (`Synced`, `OutOfSync`) reports
-  drift against git.
- Health checks are pluggable via Lua scripts for custom CRDs. An
-  Operator-managed CRD without a health check reads as `Progressing`
-  forever — write one (see `operators.md`).
- Out-of-sync or degraded status must emit a notification (Slack,
-  PagerDuty, webhook). Silent drift is the bug (P9). Wire status to
-  `domains/observability/metrics.md`.
-
-## Diff and Drift (P8 Reconcile, Don't Mutate by Hand, P4)
-
- `argocd app diff` shows the diff between git and live cluster.
-  A non-empty diff on a synced app is hand-edit drift — the
-  recovery is `selfHeal`, not a manual `kubectl apply` (P8).
- Drift detection runs continuously (P4). The gap between "git
-  changed" and "cluster matches git" is observable, not assumed.
-
-## RBAC and SSO (P10 Least Privilege Reconciliation)
-
- ArgoCD's own RBAC governs who can view, sync, and admin
-  Applications. Bind to SSO (OIDC, SAML) for human identity; bind
-  the controller's service account to a Role scoped to the
-  namespaces it reconciles.
- The controller's credentials must not be `cluster-admin` (P10).
-  Use namespace-scoped Roles via `ApplicationSet` namespaces or
-  cluster-wide AppProject restrictions. See
-  `domains/kubernetes/rbac.md` and `domains/security/authorization.md`.
- AppProjects bound the blast radius of what an Application can
-  deploy (allowed repos, destinations, roles). One AppProject per
-  team or environment; the default project is for nothing in
-  production.
-
-## Multi-Cluster (P4 Locality, P10)
-
- ArgoCD registers external clusters by secret. The controller
-  pulls from git and pushes to the registered cluster's API server.
-  The "pull, don't push" boundary (P3) is between the target
-  cluster's reconciler and CI — the controller-to-apiserver hop is
-  internal to the platform.
- Scope each registered cluster's credentials to the namespaces
-  ArgoCD manages there. Do not register a cluster with cluster-admin
-  and call it done (P10).
-
-## Sync Windows (P5 Reversibility, P7)
-
- Sync windows restrict when automated sync runs (e.g., no syncs
-  during business hours, or syncs only in a maintenance window).
-  They are a reversibility mechanism: a bad commit lands in git,
-  but the sync window holds it until review.
- Sync windows do not replace health monitoring (P9). A degraded
-  app inside a window is still an incident.
-
-## Secrets (P10, cross-link security/secrets)
-
- Do not store raw Secrets in the GitOps repo. Use a sealed-secret
-  controller (Bitnami Sealed Secrets, SOPS, External Secrets
-  Operator) so the git store holds encrypted material only. See
-  `domains/security/secrets.md` for the general secret-hygiene
-  principles.
-
-## ArgoCD vs Flux — Decision Matrix (IDEATE-21, D-039)
-
-| Axis | ArgoCD | Flux |
-|------|--------|------|
-| Architecture | Monolithic controller + Application CRD | Composable GitOps Toolkit controllers (source, kustomize, helm, notification) |
-| Reconciliation unit | Application (one CRD per app) | Kustomization / HelmRelease (one per deploy unit) |
-| UI | Web UI + CLI (full dashboard, tree view, diff viewer) | CLI-first; UI via Weave GitOps or FluxUI (add-on) |
-| Sync model | Periodic poll or webhook; sync waves + hooks | Poll + webhook; runs continuously, no explicit sync waves |
-| Multi-cluster | One ArgoCD manages many clusters (hub-and-spoke) | One Flux per cluster (per-cluster autonomy) |
-| Templating in repo | Helm, Kustomize, ksonnet, raw manifests, Jsonnet | Helm, Kustomize, raw manifests |
-| RBAC | Built-in RBAC + SSO + AppProjects | Kubernetes RBAC (no built-in RBAC layer) |
-| Progressive delivery | Argo Rollouts (sister project, tight integration) | Flagger (sister project, tight integration) |
-| Best for | Teams wanting a UI, multi-cluster from one pane, App-of-Apps bootstrapping | Teams wanting composable controllers, per-cluster autonomy, minimal footprint |
-| Watch out for | Monolithic controller scaling, UI as ops crutch, AppProject sprawl | No native UI, steeper learning curve, manual multi-cluster orchestration |
-
- Use ArgoCD when you want a UI, central multi-cluster management,
-  and sync-wave ordering. Use Flux when you want composable
-  controllers, per-cluster autonomy, and a minimal footprint.
- Both are CNCF graduated and both implement the OpenGitOps
-  principles. The choice is architectural fit, not correctness. See
-  `flux.md` for the Flux-side perspective.
-
-## What Violates ArgoCD Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| CI pipeline with `kubectl` rights pushing to the cluster | P3 Pull, Don't Push |
-| `argocd app set` used as the steady state instead of git | P1 Git is the Source of Truth |
-| `selfHeal: false` on a prod app with no manual gate | P8 Reconcile, Don't Mutate by Hand |
-| Controller ServiceAccount bound to `cluster-admin` | P10 Least Privilege Reconciliation |
-| Sync failure with no notification wired | P9 Failure is Observable and Surfaced |
-| AppProject with no destination restrictions in prod | P10 Least Privilege Reconciliation |
-| Raw Secret in the GitOps repo | P10, `domains/security/secrets.md` |
-| Manual `kubectl edit` on an ArgoCD-managed resource | P8 Reconcile, Don't Mutate by Hand |
@@ -1,131 +0,0 @@
-# GitOps + Operators — First Principles
-
-## 1. The Principles
-
-### P1. Git is the Source of Truth
-Desired state lives in a versioned, immutable git store. The
-cluster is a derivative of git, never the authority. If a state
-exists only in the cluster and not in git, it is drift, not truth.
-The commit history is the audit trail and the rollback path.
-
-### P2. Declarative Over Imperative
-Express the desired cluster state, not the commands to reach it.
-A manifest says what should exist; the reconciler makes it so.
-Imperative `kubectl` is for inspection and incident response, not
-for the steady state. This is the GitOps expression of
-`domains/kubernetes/P1 Declarative Desired State` and
-`domains/infrastructure-as-code/P1 Declarative Intent`.
-
-### P3. Pull, Don't Push
-Agents running inside the target pull desired state from git; the
-target never accepts outside push credentials. No CI pipeline holds
-`kubectl` rights against the production cluster. The cluster reaches
-out to git, not the other way around. This is the security primitive
-of GitOps: the blast radius of a compromised CI is bounded by what CI
-can push, and a pull model gives CI nothing to push.
-
-### P4. Continuous Reconciliation
-The reconciliation loop is the primitive. Drift is detected and
-corrected automatically, not on-demand. A manual `apply` is an
-exception, not the workflow. The loop runs continuously; the gap
-between "git changed" and "cluster matches git" is measured in
-seconds, not tickets.
-
-### P5. State is Immutable and Versioned
-Every change to desired state is a commit. History is the audit
-trail and the rollback path. A revert is a rollback; a force-push is
-history deletion. The git store is treated like
-`domains/infrastructure-as-code/P3 State is Truth` — lose it or
-tamper with it, and you lose the ability to reason about the system.
-
-### P6. Operators Encode Domain Knowledge
-Operational expertise lives as CRDs plus controllers, not as
-runbooks that humans must remember. An operator is a control loop
-that encodes how to reconcile a specific domain (a database, a
-message queue, a certificate). The operator is the deepest
-expression of `domains/kubernetes/P1 Declarative Desired State` —
-the domain knowledge is the desired state.
-
-### P7. Progressive Delivery is Reversible by Construction
-Canary and blue-green are staged, metric-gated, and one-command
-abortable. Promotion without a rollback path is a violation. A
-rollout that cannot be aborted is a deploy, not a progressive
-delivery. This is the GitOps extension of
-`domains/devops/P5 Progressive Delivery` and
-`domains/kubernetes/P10 Roll Forward, Roll Back`.
-
-### P8. Reconcile, Don't Mutate by Hand
-Manual `kubectl apply` or `kubectl edit` on a GitOps-managed
-resource is an incident. The reconciler will overwrite the hand
-edit on the next loop; the hand edit was never truth. Drift back to
-git is the recovery, not the failure. This is the GitOps angle on
-`domains/infrastructure-as-code/P9 Drift is Recoverable`.
-
-### P9. Failure is Observable and Surfaced
-Sync failures, health degradation, and rollout-stall events emit
-status and notifications. Silent drift is the bug. A GitOps
-controller that fails to sync without surfacing the failure has
-violated the contract — you cannot fix what you cannot see
-(`domains/observability/metrics.md`).
-
-### P10. Least Privilege Reconciliation
-The controller's credentials are scoped to the namespaces and
-resources it reconciles. No `cluster-admin` GitOps robots. One
-credential set per boundary; the reconciler sees only what it
-reconciles. This is the GitOps angle on
-`domains/kubernetes/P7 RBAC by Intent, Not Identity` and
-`domains/security/authorization.md`.
-
-## 2. Core Principle Trace
-
-Each GitOps + Operators P-rule derives from one or more core
-C-rules (C1–C8). The matrix extension lands in P4 of the v0.3
-plan; the traces below are authoritative.
-
-| P-rule | Core | Why |
-|--------|------|-----|
-| P1 Git is the Source of Truth | C1, C5 | Correctness of state; reversibility via history |
-| P2 Declarative Over Imperative | C2, C3 | Clarity of intent; simplicity of mental model |
-| P3 Pull, Don't Push | C1, C4 | Correctness via security; locality of credentials |
-| P4 Continuous Reconciliation | C7, C1 | Observability of drift; correctness of convergence |
-| P5 State is Immutable and Versioned | C5 | Reversibility via version history |
-| P6 Operators Encode Domain Knowledge | C6, C2 | Composability of expertise; clarity of operational intent |
-| P7 Progressive Delivery is Reversible | C5, C1 | Reversibility of promotion; correctness of abort |
-| P8 Reconcile, Don't Mutate by Hand | C1, C7 | Correctness of single source; observability of drift |
-| P9 Failure is Observable and Surfaced | C7 | Observability of reconciliation |
-| P10 Least Privilege Reconciliation | C1, C8 | Correctness via security; economy of trust |
-
-## 3. What Violates These Principles
-
-| Violation | Principle Breached |
-|-----------|-------------------|
-| CI pipeline pushes manifests to the cluster | P3 Pull, Don't Push |
-| A resource exists in the cluster but not in git | P1 Git is the Source of Truth |
-| `kubectl edit` on a GitOps-managed resource | P8 Reconcile, Don't Mutate by Hand |
-| Reconciler with `cluster-admin` ClusterRoleBinding | P10 Least Privilege Reconciliation |
-| Sync failure with no status or notification | P9 Failure is Observable and Surfaced |
-| Canary with no abort/rollback path | P7 Progressive Delivery is Reversible |
-| Operator runbook that exists only in a wiki | P6 Operators Encode Domain Knowledge |
-| Reconciler that applies on a cron, not continuously | P4 Continuous Reconciliation |
-| Force-push rewrites GitOps repo history | P5 State is Immutable and Versioned |
-| Imperative deploy script as the steady state | P2 Declarative Over Imperative |
-
-## 4. Relationship to Other Domains
-
-GitOps + Operators is the deployment-automation layer above
-`domains/kubernetes/` and `domains/infrastructure-as-code/`. It
-borrows their declarative-reconciliation model and adds the
-git-as-source-of-truth and pull-based credential boundaries. Cross
-links are one-directional (per D-026 extended):
-
- `domains/kubernetes/P1 Declarative Desired State` ← P2
- `domains/kubernetes/P10 Roll Forward, Roll Back` ← P7
- `domains/infrastructure-as-code/P1 Declarative Intent` ← P2
- `domains/infrastructure-as-code/P3 State is Truth` ← P1, P5
- `domains/infrastructure-as-code/P9 Drift is Recoverable` ← P4, P8
- `domains/devops/P4 Rollback First` ← P5, P7
- `domains/devops/P5 Progressive Delivery` ← P7
- `domains/devops/P6 Configuration as Code` ← P1, P2
- `domains/security/secrets.md` ← P3, P10 (reconciliation credentials)
- `domains/security/supply-chain.md` ← P5 (signed, immutable provenance)
- `domains/observability/metrics.md` ← P4, P9 (reconciliation + rollout metrics)
@@ -1,159 +0,0 @@
-# Flux — Derived Rules
-
-> Derives from `domains/gitops-operators/first-principles.md`.
-> Applies P1–P10 to Flux specifically. For the ArgoCD-vs-Flux
-> decision, see the decision matrix at the end of this doc and in
-> `argocd.md`.
-
-## What Flux Is (P1 Git is the Source of Truth, P3 Pull, Don't Push)
-
- Flux is a set of composable controllers — the GitOps Toolkit —
-  that run inside the target cluster, pull desired state from git
-  or OCI registries, and reconcile the cluster to match. CI never
-  holds `kubectl` rights against the cluster (P3).
- The composable-controller architecture is a C6 (Composability)
-  exemplar: each controller does one thing (source, kustomize, helm,
-  notification) and the controllers compose into a full GitOps
-  system.
- Flux supports Helm releases, Kustomize overlays, and raw
-  manifests — see `domains/kubernetes/helm.md` and
-  `domains/kubernetes/kustomize.md`.
-
-## GitOps Toolkit Controllers (P6 Composability, P4 Continuous Reconciliation)
-
- **source-controller** — pulls git, Helm, OCI, and bucket sources;
-  emits artifacts (tarballs) with a digest. The source is the
-  pinned input to reconciliation (P5 versioning by digest).
- **kustomize-controller** — reconciles Kustomization CRDs against
-  the artifacts from source-controller. Runs continuously (P4).
- **helm-controller** — reconciles HelmRelease CRDs against Helm
-  charts from source-controller.
- **notification-controller** — emits events and notifications for
-  sync, health, and source-readiness events (P9).
- **image-automation-controller** (optional) — updates git with new
-  image tags when a policy matches, closing the "latest image"
-  loop declaratively.
-
-## Kustomization CRD (P2 Declarative Over Imperative, P4)
-
- A Kustomization binds "this source" to "this target namespace"
-  with a reconciliation interval. The reconciler loops
-  continuously; drift is corrected automatically (P4).
-
-```yaml
-apiVersion: kustomize.toolkit.fluxcd.io/v1
-kind: Kustomization
-metadata:
-  name: payments-api
-  namespace: flux-system
-spec:
-  sourceRef:
-    kind: GitRepository
-    name: platform
-    namespace: flux-system
-  path: ./manifests/prod
-  targetNamespace: payments
-  interval: 1m
-  prune: true
-  wait: true
-  healthChecks:
-    - apiVersion: apps/v1
-      kind: Deployment
-      name: payments-api
-      namespace: payments
-```
-
- `prune: true` deletes resources removed from git. `wait: true`
-  waits for health checks before declaring the Kustomization ready.
-  Disable prune for workloads that need manual removal gates.
-
-## HelmRelease CRD (P6 Composability, cross-link helm.md)
-
- A HelmRelease binds a Helm chart (from a HelmRepository or OCI
-  source) to target values and a target namespace. helm-controller
-  renders and applies it. See `domains/kubernetes/helm.md` for the
-  chart model.
- Pin the chart version in the HelmRepository or the HelmRelease.
-  Never float `latest` — unversioned charts drift (P5).
-
-## OCI Sources (P5 State is Immutable and Versioned)
-
- source-controller can pull from OCI registries (Helm charts as
-  OCI artifacts, or generic OCI repositories). The digest is the
-  version — immutable by construction (P5).
- OCI sources close the supply-chain loop: the manifest is signed
-  and immutable in the registry, and Flux pulls it by digest. Cross-
-  link `domains/security/supply-chain.md` for signed-provenance
-  principles.
-
-## Reconciliation and Drift (P4 Continuous Reconciliation, P8)
-
- Flux reconciles on `interval` (default 1m) and on webhook event.
-  Drift between git and cluster is detected each interval and
-  corrected (with `prune` + `selfHeal` semantics).
- Hand-edited drift on a Flux-managed resource is overwritten on the
-  next loop — the hand edit was never truth (P8). The recovery is
-  to fix git, not to `kubectl apply`.
-
-## Notifications and Events (P9 Failure is Observable and Surfaced)
-
- notification-controller emits events for source readiness, sync
-  success/failure, and health transitions. Wire them to Slack,
-  PagerDuty, or a webhook. Silent drift is the bug (P9).
- Events flow to `domains/observability/metrics.md` via the
-  notification controller's provider model — sync and health as
-  first-class signals.
-
-## RBAC and Multi-Cluster (P10 Least Privilege Reconciliation, P4)
-
- Flux's controllers run with a ServiceAccount in `flux-system`.
-  Scope that account to the namespaces Flux reconciles. Do not bind
-  it to `cluster-admin` (P10). See `domains/kubernetes/rbac.md` and
-  `domains/security/authorization.md`.
- Flux is per-cluster by design (one Flux install per cluster). For
-  multi-cluster, use one repo with per-cluster paths, or a fleet
-  tool that bootstraps Flux per cluster. Per-cluster autonomy is a
-  feature, not a limitation — it bounds the blast radius of a
-  compromised controller (P4 locality, P10).
-
-## Secrets (P10, cross-link security/secrets)
-
- Do not store raw Secrets in the GitOps repo. Use the
-  SOPS-compatible decryption in kustomize-controller, or External
-  Secrets Operator, so the git store holds encrypted material only.
-  See `domains/security/secrets.md`.
-
-## ArgoCD vs Flux — Decision Matrix (IDEATE-21, D-039)
-
-| Axis | ArgoCD | Flux |
-|------|--------|------|
-| Architecture | Monolithic controller + Application CRD | Composable GitOps Toolkit controllers (source, kustomize, helm, notification) |
-| Reconciliation unit | Application (one CRD per app) | Kustomization / HelmRelease (one per deploy unit) |
-| UI | Web UI + CLI (full dashboard, tree view, diff viewer) | CLI-first; UI via Weave GitOps or FluxUI (add-on) |
-| Sync model | Periodic poll or webhook; sync waves + hooks | Poll + webhook; runs continuously, no explicit sync waves |
-| Multi-cluster | One ArgoCD manages many clusters (hub-and-spoke) | One Flux per cluster (per-cluster autonomy) |
-| Templating in repo | Helm, Kustomize, ksonnet, raw manifests, Jsonnet | Helm, Kustomize, raw manifests |
-| RBAC | Built-in RBAC + SSO + AppProjects | Kubernetes RBAC (no built-in RBAC layer) |
-| Progressive delivery | Argo Rollouts (sister project, tight integration) | Flagger (sister project, tight integration) |
-| Best for | Teams wanting a UI, multi-cluster from one pane, App-of-Apps bootstrapping | Teams wanting composable controllers, per-cluster autonomy, minimal footprint |
-| Watch out for | Monolithic controller scaling, UI as ops crutch, AppProject sprawl | No native UI, steeper learning curve, manual multi-cluster orchestration |
-
- Use Flux when you want composable controllers, per-cluster
-  autonomy, and a minimal footprint. Use ArgoCD when you want a UI,
-  central multi-cluster management, and sync-wave ordering.
- Both are CNCF graduated and both implement the OpenGitOps
-  principles. The choice is architectural fit, not correctness. See
-  `argocd.md` for the ArgoCD-side perspective.
-
-## What Violates Flux Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| CI pipeline with `kubectl` rights pushing to the cluster | P3 Pull, Don't Push |
-| HelmRelease with no pinned chart version | P5 State is Immutable and Versioned |
-| Flux ServiceAccount bound to `cluster-admin` | P10 Least Privilege Reconciliation |
-| Kustomization with no `healthChecks` on a prod app | P9 Failure is Observable and Surfaced |
-| No notification provider wired for sync failures | P9 Failure is Observable and Surfaced |
-| Raw Secret in the GitOps repo | P10, `domains/security/secrets.md` |
-| Manual `kubectl edit` on a Flux-managed resource | P8 Reconcile, Don't Mutate by Hand |
-| `interval: 24h` on a prod Kustomization (drift window too wide) | P4 Continuous Reconciliation |
@@ -1,140 +0,0 @@
-# Operators — Derived Rules
-
-> Derives from `domains/gitops-operators/first-principles.md`.
-> Applies P6 (Operators Encode Domain Knowledge) primarily, with
-> P1, P4, P8, P9, P10. Cross-links `domains/kubernetes/workloads.md`
-> and `domains/kubernetes/rbac.md` for the underlying controller
-> model, and `domains/infrastructure-as-code/modules.md` for the
-> module-vs-operator boundary.
-
-## What an Operator Is (P6 Operators Encode Domain Knowledge)
-
- An Operator is a Kubernetes controller that encodes human
-  operational knowledge as CRDs plus a control loop. The operator
-  reconciles a domain-specific resource (a database, a message
-  queue, a certificate, a ML model) to a desired state.
- The operator is the deepest expression of
-  `domains/kubernetes/P1 Declarative Desired State`: the domain
-  knowledge itself is the desired state. A runbook that lives only
-  in a wiki is operational knowledge that has not been encoded —
-  the operator is the encoding (P6).
- An operator runs inside the cluster, observes its CRDs, and acts.
-  It is a pull-based reconciler by construction — see
-  `domains/gitops-operators/first-principles.md` P3.
-
-## CRDs and Controllers (P2 Declarative Over Imperative, P4 Continuous Reconciliation)
-
- A CustomResourceDefinition (CRD) defines the schema of the
-  domain resource. The controller watches instances of that CRD
-  and reconciles current → desired (P4).
- The CRD is the public contract of the operator. Version it
-  (`v1alpha1` → `v1beta1` → `v1`) and preserve backward
-  compatibility — see `domains/api/versioning.md` for the general
-  API-evolution principles. A CRD is an API surface, not an
-  internal type.
-
-```yaml
-apiVersion: postgres.example.com/v1
-kind: PostgresCluster
-metadata:
-  name: payments-db
-  namespace: payments
-spec:
-  replicas: 3
-  version: "16"
-  storage:
-    size: 100Gi
-    storageClass: fast-ssd
-  backup:
-    schedule: "0 2 * * *"
-    retention: 7d
-```
-
- The controller reconciles this spec: creates StatefulSets, PVCs,
-  Services, backup CronJobs. The user declares intent; the operator
-  makes it so (P2, P6).
-
-## The Control Loop (P4 Continuous Reconciliation, P8)
-
- The loop watches CRD instances, compares current vs desired, and
-  acts to converge. Drift (a hand-deleted pod, a failed backup) is
-  detected and corrected each loop (P4).
- An operator-managed resource should not be hand-edited (P8). The
-  operator owns the subordinate resources (StatefulSets, PVCs); a
-  manual `kubectl edit` on a subordinate is drift the operator will
-  overwrite.
-
-## Operator SDK and OLM (P6 Composability, C6)
-
- The Operator SDK scaffolds a controller from a CRD (Go, Ansible,
-  Helm). Use it to avoid re-implementing the controller boilerplate.
- Operator Lifecycle Manager (OLM) installs, updates, and manages
-  operators as first-class cluster components. OLM is the package
-  manager for operators — the operator analogue of
-  `domains/kubernetes/helm.md` for workloads.
- An operator published via OLM is a versioned, catalog-tracked
-  artifact. Pin the operator version; do not float `latest` (P5
-  applies to operators as much as to manifests).
-
-## When to Write an Operator vs a Helm Chart (P6, C6 Composability)
-
-| Axis | Helm chart | Operator |
-|------|-----------|----------|
-| Day-2 operations | None — chart installs, you operate | Encoded — operator reconciles lifecycle (backup, resize, failover, upgrade) |
-| State | Static manifests | Live control loop watching CRDs |
-| Day-1 install | Strong fit — package and install | Overkill if install is all you need |
-| Day-2 reconcile | None — drift is manual | Continuous — drift corrected each loop |
-| Domain knowledge | Lives in runbooks + on-call | Lives in the controller code |
-| Best for | Off-the-shelf apps, stateless services, one-shot deploys | Stateful apps, complex lifecycles, day-2 automation (backup, scale, failover, version upgrades) |
-| Watch out for | Templating complexity, no day-2 reconcile | Controller complexity, multi-team maintenance burden, scope creep |
-
- Write an operator when the day-2 operations (backup, failover,
-  resize, version upgrade) are non-trivial and repeated. Write a
-  Helm chart when install is all you need and day-2 is run by a
-  human or a separate tool.
- Do not write an operator to wrap a Helm chart and call it day-2
-  automation — that is a Helm chart with extra steps. See
-  `domains/infrastructure-as-code/modules.md` for the
-  module-vs-copy boundary (the operator-vs-chart boundary is its
-  analogue).
-
-## Scope and Responsibility Boundaries (P10 Least Privilege, C6)
-
- An operator owns one domain. An operator that manages databases
-  and message queues and certificates is doing three jobs — split
-  it. Scope creep is the most common operator failure mode (P6
-  violation: the encoded knowledge is no longer coherent).
- The operator's ServiceAccount must be scoped to the resources it
-  manages (P10). A database operator that needs `cluster-admin` to
-  create a StatefulSet has the wrong RBAC — see
-  `domains/kubernetes/rbac.md` and `domains/security/authorization.md`.
- One operator per CRD family; one ServiceAccount per operator; one
-  namespace per operator (or a shared `operators` namespace with
-  strict RoleBindings). Default namespace is for nothing in
-  production.
-
-## Failure and Observability (P9 Failure is Observable and Surfaced)
-
- An operator must surface its reconcile status on the CRD
-  (`status.conditions`, `status.observedGeneration`). A CRD with no
-  status is an operator that fails silently (P9).
- Wire operator events to notifications and metrics. A failed
-  backup, a stuck failover, a version-upgrade stall must emit a
-  signal — see `domains/observability/metrics.md`.
- An operator that reconciles but does not report health is a
-  black box. The GitOps controller (ArgoCD/Flux) will read it as
-  `Progressing` forever — write the health check (see `argocd.md`
-  "Health and Status").
-
-## What Violates Operator Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Operator that manages databases + queues + certs | P6 Operators Encode Domain Knowledge (scope creep) |
-| Operator ServiceAccount bound to `cluster-admin` | P10 Least Privilege Reconciliation |
-| CRD with no `status.conditions` | P9 Failure is Observable and Surfaced |
-| Operator with no health check wired to GitOps | P9, `argocd.md` Health and Status |
-| Unversioned CRD (`v1` shipped without alpha/beta) | P5, `domains/api/versioning.md` |
-| Manual `kubectl edit` on an operator-managed subordinate | P8 Reconcile, Don't Mutate by Hand |
-| Operator that wraps a Helm chart and adds no day-2 logic | P6 (no knowledge encoded) |
-| Operator runbook that exists only in a wiki | P6 Operators Encode Domain Knowledge |
@@ -1,177 +0,0 @@
-# Progressive Delivery — Derived Rules
-
-> Derives from `domains/gitops-operators/first-principles.md`.
-> Applies P7 (Progressive Delivery is Reversible by Construction)
-> primarily, with P4, P9. Cross-links `domains/devops/first-principles.md`
-> P4 Rollback First and P5 Progressive Delivery, and
-> `domains/observability/metrics.md` for the analysis signals.
-
-## What Progressive Delivery Is (P7 Reversible by Construction)
-
- Progressive delivery shifts traffic in stages (canary, blue-green)
-  gated by analysis (metrics, counters, error rates). Each stage is
-  metric-checked; a failed gate aborts the rollout and reverts to
-  the prior stable version. Promotion without a rollback path is a
-  violation (P7).
- Progressive delivery is the GitOps extension of
-  `domains/devops/P5 Progressive Delivery` and
-  `domains/kubernetes/P10 Roll Forward, Roll Back`. The k8s rolling
-  update is the floor; progressive delivery adds metric-gated
-  promotion and one-command abort.
- Two sister projects dominate: **Argo Rollouts** (Argo ecosystem)
-  and **Flagger** (Flux ecosystem). Both implement the same pattern
-  — a Rollout CRD replaces a Deployment, an analysis drives the
-  gates, an abort reverts traffic.
-
-## The Rollout CRD (P2 Declarative Over Imperative, P7)
-
- A Rollout (Argo Rollouts) or Canary/Flag (Flagger) is a CRD that
-  replaces the Deployment as the reconciled resource. It declares
-  the strategy (canary, blue-green), the traffic split, and the
-  analysis gates. The controller reconciles traffic and pods to
-  match.
-
-```yaml
-apiVersion: argoproj.io/v1alpha1
-kind: Rollout
-metadata:
-  name: payments-api
-  namespace: payments
-spec:
-  replicas: 10
-  selector:
-    matchLabels:
-      app: payments-api
-  template:
-    metadata:
-      labels:
-        app: payments-api
-    spec:
-      containers:
-        - name: api
-          image: registry.example.com/payments-api:1.2.3
-  strategy:
-    canary:
-      trafficRouting:
-        istio:
-          virtualService:
-            name: payments-vs
-            routes: [primary]
-      steps:
-        - setWeight: 5
-        - pause: { duration: 2m }
-        - analysis:
-            templates:
-              - templateName: success-rate
-        - setWeight: 25
-        - pause: { duration: 5m }
-        - analysis:
-            templates:
-              - templateName: success-rate
-        - setWeight: 50
-        - pause: { duration: 5m }
-        - setWeight: 100
-```
-
- Each `setWeight` shifts traffic; each `pause` holds for
-  observation; each `analysis` runs a metric gate. A failed
-  analysis aborts the rollout and reverts traffic to the stable
-  ReplicaSet (P7).
-
-## Canary vs Blue-Green (P7, C3 Simplicity)
-
-| Strategy | Mechanism | Cost | Best for |
-|----------|-----------|------|----------|
-| Canary | Shift a small % of traffic to the new version; increase on gate success | Low (few new pods) | Most production rollouts; metric-gated, gradual |
-| Blue-Green | Run two full environments; switch traffic all-at-once | High (2× capacity) | Schema-breaking changes, instant rollback, low-frequency deploys |
-
- Canary is the default — it is reversible by construction (P7)
-  and economical (C8). Blue-green is for changes that cannot be
-  partial (a breaking schema migration, a full cutover).
- A canary with no analysis gate is a slow blue-green — it is not
-  progressive delivery. The gate is what makes it progressive (P7).
-
-## Analysis Templates (P9 Failure is Observable and Surfaced, P7)
-
- An AnalysisTemplate declares the metric query, the success
-  threshold, and the count of samples. The rollout controller runs
-  the analysis at each gate; a failed analysis aborts the rollout.
-
-```yaml
-apiVersion: argoproj.io/v1alpha1
-kind: AnalysisTemplate
-metadata:
-  name: success-rate
-  namespace: payments
-spec:
-  metrics:
-    - name: success-rate
-      interval: 1m
-      successCondition: result[0] >= 0.99
-      failureLimit: 2
-      provider:
-        prometheus:
-          address: http://prometheus.observability:9090
-          query: |
-            sum(rate(http_requests_total{job="payments-api",code!~"5.."}[2m]))
-            /
-            sum(rate(http_requests_total{job="payments-api"}[2m]))
-```
-
- `successCondition` is the gate; `failureLimit` is the tolerance
-  for transient blips. A single failed sample aborts immediately if
-  `failureLimit: 0`; tolerate noise with `failureLimit: 2`.
- The metric is the abort signal — see `domains/observability/metrics.md`
-  for the SLI/SLO discipline that makes the gate meaningful. A gate
-  on an undefined SLO is a gate on noise.
-
-## Argo Rollouts vs Flagger (P6 Composability, P7)
-
-| Axis | Argo Rollouts | Flagger |
-|------|---------------|---------|
-| Ecosystem | Argo (ArgoCD sister project) | Flux (Flux sister project) |
-| CRD | `Rollout` (replaces `Deployment`) | `Canary` / `Flag` (wraps a `Deployment`) |
-| Traffic providers | Istio, NGINX, ALB, SMI, Traefik, Ambassador | Istio, NGINX, Linkerd, SMI, App Mesh, Gloo, Contour |
-| Analysis sources | Prometheus, Datadog, Wavefront, NewRelic, CloudWatch, Graphite, Kayenta | Prometheus, Datadog, CloudWatch, Stackdriver, Elasticsearch, Graphite |
-| Integration | Tight with ArgoCD (UI shows rollout) | Tight with Flux (events via notification-controller) |
-| Learning curve | Rollout CRD replaces Deployment (migration cost) | Wraps existing Deployment (lower migration cost) |
-| Best for | ArgoCD shops wanting rollout in the Argo UI | Flux shops wanting progressive delivery with minimal migration |
-
- Both implement the same pattern. The choice follows your GitOps
-  controller — Argo Rollouts with ArgoCD, Flagger with Flux. Mixing
-  is possible but not idiomatic.
-
-## Abort and Rollback (P7 Reversible by Construction, P5)
-
- An abort reverts traffic to the stable ReplicaSet immediately. A
-  rollout without a tested abort is a prototype (P7).
- The abort must be one-command (or one-gate-failure). A
-  progressive delivery that requires manual rollback steps has
-  lost the "reversible by construction" property — it is a deploy
-  with extra steps.
- Test the abort path in staging. An abort that has never been
-  exercised will fail when you need it most — see
-  `domains/devops/first-principles.md` P4 Rollback First.
-
-## Observability (P9 Failure is Observable and Surfaced)
-
- Progressive delivery is only as good as its metrics. A rollout
-  gated on a metric that is not tracked is ungated — the gate is
-  theater (P9).
- Wire rollout status (phase, weight, analysis result) to
-  notifications and dashboards. A stalled rollout with no signal is
-  silent drift (P9). See `domains/observability/metrics.md`.
- Cross-link `domains/kubernetes/workloads.md` for the underlying
-  Deployment/ReplicaSet model that progressive delivery replaces.
-
-## What Violates Progressive Delivery Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Canary with no analysis gate | P7 Progressive Delivery is Reversible by Construction |
-| Rollout with no tested abort path | P7, `domains/devops/P4 Rollback First` |
-| Analysis gate on an undefined SLO | P9 Failure is Observable and Surfaced |
-| Blue-green with no 2× capacity budget | C8 Economy (blue-green is a cost decision) |
-| Rollout stalled with no notification | P9 Failure is Observable and Surfaced |
-| Manual `kubectl` traffic shift on a Rollout-managed service | P8 Reconcile, Don't Mutate by Hand |
-| `failureLimit: 0` on a noisy metric (constant false aborts) | P4 Continuous Reconciliation (gate noise tolerance) |
@@ -1,55 +0,0 @@
-# Infrastructure as Code — First Principles
-
-## 1. The Principles
-
-### P1. Declarative Intent
-Describe the desired state, not the steps to reach it. The tool
-reconciles current → desired. Imperative scripts describe how;
-declarative config describes what.
-
-### P2. Idempotence
-Applying the same configuration twice yields the same result. A
-second `apply` with no changes is a no-op, not an error. Idempotence
-is what makes `plan` trustworthy.
-
-### P3. State is Truth
-The state file is the authoritative record of what the tool believes
-exists. Drift between state and reality is a bug to be reconciled,
-not tolerated. Lose state, lose the ability to reason about
-infrastructure.
-
-### P4. Plan Before Apply
-Preview every change before mutating real infrastructure. `plan` is
-the contract review; `apply` is the signature. No `apply` without a
-read `plan`. The plan is the rollback rehearsal.
-
-### P5. Version Everything
-Configuration, state, providers, and modules are all versioned and
-reproducible. A commit pins a complete, rebuildable world. Pin
-providers; pin module sources; never `latest`.
-
-### P6. Modules Compose
-Encapsulate repeatable patterns as versioned modules. Compose
-modules; do not copy them. A module is the unit of reuse, review,
-and versioning — the IaC expression of composition.
-
-### P7. Least Privilege Providers
-Provider credentials are scoped to the minimum needed for the
-declared resources. No account-wide admin keys in CI. One credential
-per environment, per boundary.
-
-### P8. Remote State with Locking
-State is stored remotely with locking. Local state is for a single
-developer on a throwaway sandbox. Concurrent `apply` without a lock
-is data corruption waiting to happen.
-
-### P9. Drift is Recoverable
-`plan` detects drift; `apply` reconciles it. Manual mutation of
-managed infrastructure is an incident, not a shortcut. Drift is
-expected; unreconciled drift is the bug.
-
-### P10. Secrets Never in Code
-Secrets come from providers, external secret stores, or environment
-variables — never hardcoded in HCL, never committed to the repo,
-never written to state in plaintext. State is a secret-bearing
-artifact; treat it accordingly.
@@ -1,65 +0,0 @@
-# Modules — Derived Rules
-
-> Derives from `domains/infrastructure-as-code/first-principles.md`. P6 (Modules Compose) lives here. Referenced by `terraform.md` and `opentofu.md`.
-
-## Why Modules (P6 Modules Compose)
-
- A module is the unit of reuse, review, and versioning in IaC. It encapsulates a repeatable pattern behind a typed interface.
- Composition — building large from small — is the IaC expression of core C6 Composability. Without modules, every stack is a one-off; with modules, a stack is an assembly of reviewed parts.
- A good module has one job (a VPC, a database, a load balancer), a small typed surface, and no hidden side effects.
- A versioned module is the IaC expression of `domains/devops/first-principles.md` P1 (Reproducibility) and P6 (Configuration as Code): a module pins a reusable, rebuildable pattern that any environment can call.
-
-## Module Structure (P1 Declarative Intent, C2 Clarity)
-
- The conventional layout: `main.tf` (resources), `variables.tf` (inputs), `outputs.tf` (outputs), `versions.tf` (provider/version pins). A `README.md` is required for any published module.
- Inputs are typed and validated: `variable "name" { type = string, description = "...", validation { ... } }`. The description is the contract.
- Outputs are the module's interface to consumers. Mark sensitive outputs `sensitive = true`. Document non-obvious outputs in the description.
- A module does not declare a provider configuration unless it owns the provider. Most modules declare only `required_providers` (the constraint) and let the consumer configure the provider.
-
-## Versioning (P5 Version Everything)
-
- Modules are versioned. The registry expects SemVer tags (`v1.0.0`). A consumer pins to a version or a range (`~> 1.0`).
- A breaking change bumps the major. An additive change bumps the minor. A fix bumps the patch. No silent breaking changes within a minor.
- Tag the module repo; the tag IS the version. Never `source = "git::...?ref=main"` in prod — unversioned modules drift.
-
-## Source Patterns (P5 Version Everything)
-
-| Source | When | Risk |
-|--------|------|------|
-| Registry (`<ns>/<name>/<provider>`) | Public, versioned, signed | Verify the publisher; pin the version |
-| Git (`git::https://...?ref=v1.0.0`) | Private modules across repos | Pin to a tag, not a branch |
-| Local (`./modules/networking`) | Monorepo, single repo | Re-reviewed on every change; no independent version |
-| Inline (no module) | Trivial one-off | Becomes a copy-paste anti-pattern at scale |
-
- Local modules in a monorepo are fine — they trade independent versioning for co-evolution. The boundary is the review unit: if the module and the consumer always change together, local is correct.
- Cross-repo modules must be versioned via git tags; unversioned cross-repo modules are the worst case (drift without a version to pin).
-
-## The Module-vs-Copy Boundary (P6 Modules Compose)
-
- If a block is used more than once, it is a module. If it is used once and will never be reused, inline is acceptable.
- If two copies differ in one attribute, that is a module with a variable, not two copies. The variable is the difference; the shared body is the module.
- If you find yourself copy-pasting a block and editing it, stop. The edit is a variable. The copy is a module call.
- A module that has grown to do many jobs should be split. A module with 20 variables is two modules.
-
-## Composition (P6 Modules Compose, C6 Composability)
-
- Compose by calling modules from a root configuration: `module "vpc" { source = "...", version = "..." }`. The root is the assembly; the modules are the parts.
- Outputs of one module feed inputs of another: `module "app" { vpc_id = module.vpc.vpc_id }`. This is the composition edge.
- Avoid hidden coupling: a module should not reach into another module's state. If two modules must share state, promote the shared concern to the root or a parent module.
-
-## Reviewing Modules (P4 Plan Before Apply)
-
- A module is reviewed once, at its version. Consumers trust the version pin. A module change requires a new version and a review of the diff.
- When a module changes, every consumer that bumps the version gets the change. Treat a module version bump as a real change: review the module diff, run the consumer's `plan`.
- A module with a breaking change must not auto-bump in consumers. Pin consumers to the old major until they explicitly migrate.
-
-## What Violates Module Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Copy-pasted block with a one-line difference | P6 Modules Compose |
-| `source = "git::...?ref=main"` in prod | P5 Version Everything |
-| Module with 20 variables | P6 Modules Compose (split it) |
-| Silent breaking change within a minor | P5 Version Everything |
-| Module reaching into another module's state | C6 Composability, P1 Declarative Intent |
-| Unpublished module with no README | C2 Clarity |
@@ -1,50 +0,0 @@
-# OpenTofu — Derived Rules
-
-> Derives from `domains/infrastructure-as-code/first-principles.md`. OpenTofu is the open-source fork of Terraform; this doc covers fork-specific governance, license, and migration. The shared HCL/state/module model is documented in `terraform.md`. See also `state.md` and `modules.md`.
-
-## Fork Lineage (P5 Version Everything)
-
- OpenTofu is a 2023 fork of Terraform, created when HashiCorp switched Terraform from MPL-2.0 to the Business Source License (BUSL), which is not open source.
- OpenTofu is stewarded by the Linux Foundation under a genuinely open-source license. The fork's reason for existing is license neutrality.
- Both tools implement the same HCL configuration language, the same provider protocol, and the same state model. Configuration written for one runs on the other at the fork point; divergence accrues slowly over time.
-
-## When to Choose OpenTofu (P7 Least Privilege Providers, supply-chain)
-
- **License neutrality matters:** if your organization cannot accept BUSL's "competitive use" ambiguity, OpenTofu removes it.
- **Supply-chain provenance:** Linux Foundation stewardship means no single vendor can relicense the tool out from under you.
- **Community governance:** features and fixes are accepted on merit, not vendor strategy.
- **When NOT to switch:** if you depend on HCP Terraform (HashiCorp's managed platform), BUSL-licensed providers, or provider features that have diverged since the fork, stay on Terraform. The decision is supply-chain, not syntax.
-
-## CLI Parity (P1 Declarative Intent)
-
- `tofu init`, `tofu plan`, `tofu apply`, `tofu destroy` mirror `terraform init/plan/apply/destroy`.
- The lock file (`.terraform.lock.hcl` → `.tofu.lock.hcl`) is committed; it makes `init` reproducible.
- Workspaces, state backends, and module sources behave as in Terraform — see `terraform.md` and `state.md`.
-
-## Registry Parity (P6 Modules Compose)
-
- OpenTofu can consume the Terraform Registry and the OpenTofu Registry. Module version pinning works identically.
- Some providers have BUSL licenses that OpenTofu cannot ship; verify a provider's license before adopting it. An MPL or Apache provider is portable; a BUSL provider is not.
- See `modules.md` for module structure, which is unchanged from Terraform.
-
-## Migration from Terraform (P5 Version Everything, P9 Drift is Recoverable)
-
- `terraform state pull > state.json` → `tofu state push state.json` carries state across. Validate with `tofu plan` after the push — the plan should be empty.
- Rename the binary in CI: replace `terraform` with `tofu` in scripts. The lock file may need regeneration.
- Migrate one workspace at a time. Do not big-bang a migration; rehearse on a non-prod workspace first (P4 Plan Before Apply applies to the migration itself).
- Pin the OpenTofu version in CI. A migration is a versioned, reviewed change, not a quiet swap.
-
-## Governance and Community (cross-link `domains/security/supply-chain.md`)
-
- OpenTofu's governance model — impartial, community-driven, layered, modular, backwards-compatible — is itself a supply-chain principle. A tool you cannot trust to remain open is a tool you cannot build on.
- This is the OpenTofu angle on `security/supply-chain.md`: license is a supply-chain property, not a legal footnote.
-
-## What Violates OpenTofu Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Assuming OpenTofu == latest Terraform (unverified parity) | P5 Version Everything |
-| Migrating prod state without a non-prod rehearsal | P4 Plan Before Apply |
-| Adopting a BUSL-licensed provider into OpenTofu CI | P7 Least Privilege Providers, supply-chain |
-| Quiet swap of `terraform` for `tofu` without a versioned change | P5 Version Everything |
-| Losing state during migration | P3 State is Truth |
@@ -1,77 +0,0 @@
-# State — Derived Rules
-
-> Derives from `domains/infrastructure-as-code/first-principles.md`. State is the cross-cutting IaC concern: P3 (State is Truth) and P8 (Remote State with Locking) live here. Referenced by `terraform.md` and `opentofu.md`.
-
-## Why State Matters (P3 State is Truth)
-
- The state file is the tool's memory. It records every resource it has claimed, every attribute it has set, and every dependency it has inferred.
- Without state, `plan` cannot compute a diff — it would have nothing to diff against. Lose state, lose the ability to reason about infrastructure safely.
- State can contain plaintext secrets (any sensitive resource attribute). Treat state as a secret-bearing artifact: encrypt at rest, restrict access, never commit it.
-
-## Remote State is Mandatory (P8 Remote State with Locking)
-
- Local state (`terraform.tfstate` on disk) is acceptable only for a single developer on a throwaway sandbox. Any shared or production environment uses a remote backend.
- A remote backend provides: durability (state survives workstation loss), shared access (team members and CI read the same state), and locking (concurrent `apply` is serialized).
- No locking = data corruption. Two `apply` runs against the same unlocked state race; the loser's changes are silently overwritten.
-
-## Backend Comparison (P8, C4 Locality)
-
-| Backend | Locking | Encryption | Best for | Notes |
-|---------|---------|------------|----------|-------|
-| S3 + DynamoDB | DynamoDB | SSE-KMS | AWS-hosted | The canonical AWS backend; DynamoDB provides the lock |
-| GCS | Built-in | CMEK | GCP-hosted | Native locking via GCS object versioning |
-| Azure Blob | Lease | Customer key | Azure-hosted | Lease-based locking |
-| HTTP (remote) | Server-side | Server-side | Self-hosted / on-prem | Requires a backend server (e.g., `terraform-backend`) |
-| Local | None | None | Single-dev sandbox | Never for shared or prod |
-| Consul | KV lock | — | Consul shops | Locking via Consul sessions |
-| Postgres | TX | DB encryption | DBA-owned infra | Row-level locking |
-
- Pick one backend per environment family. Mixing backends across environments fragments operational knowledge (C4 Locality).
- The backend config is part of the configuration, not a runtime secret. Credentials for the backend are runtime secrets. The state file itself is a secret-bearing artifact — treat it per `domains/security/secrets.md`: encrypt at rest, restrict access, never commit it.
-
-## State Isolation per Environment (P4 Plan Before Apply, C4 Locality)
-
- One state per environment. Never share a single state file across dev, staging, and prod. A `plan` against a shared state crosses environment boundaries — a prod change could appear in a dev plan.
- Isolation patterns: separate workspaces, separate state keys in the same backend, or separate backends entirely. Stricter isolation = safer (separate backends for prod vs non-prod).
- Name state keys by environment and stack: `env:/prod/Networking`, not `prod` or `state`.
-
-## Locking Discipline (P8 Remote State with Locking)
-
- `terraform force-unlock` is for a stuck lock after a crashed run, not for impatience. Verify the run is actually dead before forcing.
- A forced unlock without verifying the other run is dead causes the corruption the lock prevents.
- In CI, set a lock timeout so a wedged job fails rather than hanging.
-
-## Sensitive Values in State (P10 Secrets Never in Code)
-
- Any `sensitive = true` attribute is hidden from plan output but stored in state in plaintext (unless the provider encrypts it).
- Backends with at-rest encryption (S3 SSE-KMS, GCS CMEK) protect state at rest. Access to the state file itself is the boundary.
- Never log, print, or commit state. Never pipe `terraform show` to a public channel.
-
-## State Commands (P3 State is Truth)
-
- `terraform state list` — enumerate resources in state. First step of any state investigation.
- `terraform state show <addr>` — inspect one resource's recorded attributes.
- `terraform state mv` — rename a resource's address without destroying and recreating it. Use when refactoring module structure.
- `terraform state rm` — stop managing a resource without destroying it. Use when handing a resource to another configuration.
- `terraform state pull` / `push` — export and import state. Used in migrations (see `opentofu.md`).
- `terraform import` — bring an existing resource under management by recording its state. The resource must already exist; `import` does not create.
- All `state` subcommands except `list` and `show` mutate state. Treat them as changes: review the intent, run in CI where possible, and commit the resulting config change that justifies the state move.
-
-## Drift and Reconciliation (P9 Drift is Recoverable)
-
- `terraform plan` reports drift: resources that exist in state but were changed out-of-band, or resources in state that no longer exist in the provider.
- `terraform apply` reconciles drift by bringing reality back to the declared state.
- Manual changes to managed resources are the cause of drift. Treat a drift report as an incident: find who made the manual change and why, then close the access path or the gap that allowed it.
- `terraform plan -refresh=false` skips drift detection. Use only when you know state is current and you want a fast plan; never use it to hide drift.
-
-## What Violates State Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Committed `terraform.tfstate` | P3 State is Truth, P10 Secrets |
-| Local state in prod | P8 Remote State with Locking |
-| `force-unlock` without verifying the dead run | P8 Remote State with Locking |
-| Shared state across environments | P4 Plan Before Apply, C4 Locality |
-| Unnamed state keys (`env:/prod`) | C4 Locality |
-| Manual change to a managed resource | P9 Drift is Recoverable |
-| `state rm` to "fix" a stuck resource | P3 State is Truth |
@@ -1,58 +0,0 @@
-# Terraform — Derived Rules
-
-> Derives from `domains/infrastructure-as-code/first-principles.md`. Applies P1–P10 to Terraform specifically. See also `opentofu.md` (the open-source fork), `state.md`, and `modules.md`.
-
-## HCL Structure (P1 Declarative Intent)
-
- Resources are declared, not scripted. A resource block states what should exist; Terraform reconciles it.
- `resource "aws_s3_bucket" "logs" { ... }` — the type and name are the identity; the body is the desired state.
- Data sources read existing state without claiming ownership: `data "aws_caller_identity" "current" {}`.
- Variables are the input contract; outputs are the interface to consumers. Both are typed.
-
-## Providers (P5 Version Everything, P7 Least Privilege)
-
- Pin the provider version: `required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } }`.
- A provider block configures credentials and region. Credentials come from environment, files, or a secrets manager — never inline.
- One credential set per environment. Do not reuse a prod credential in a dev workspace.
-
-## The Core Workflow (P4 Plan Before Apply)
-
- `terraform init` — resolve providers and modules. Reproducible from the lock file (`.terraform.lock.hcl`), which is committed.
- `terraform plan` — preview the diff. Read it. Every line. The plan is the contract review.
- `terraform apply` — execute the plan. Requires a reviewed plan in CI; in interactive use, requires typing `yes`.
- `terraform destroy` — tear down. Treat `destroy` as a first-class operation with its own plan review; prod destroys are a change event, not a keystroke.
-
-## Workspaces (P4 Locality of Environments)
-
- Workspaces separate state for the same configuration across environments (dev, staging, prod).
- Do not use workspaces to separate unrelated stacks — use separate configurations. A workspace is an environment axis, not a project axis.
- State is isolated per workspace (see `state.md`).
-
-## State Backends (P3 State is Truth, P8 Remote State with Locking)
-
- Remote state is mandatory for any shared or production environment. See `state.md` for backend selection and locking.
- Never commit `terraform.tfstate` to the repo. It is a secret-bearing artifact and a source of drift.
- `terraform state` subcommands inspect and manipulate state directly — use sparingly, only for recovery.
-
-## Registry and Modules (P6 Modules Compose)
-
- The Terraform Registry hosts versioned, signed modules. Reference modules by version: `source = "terraform-aws-modules/vpc/aws"`, `version = "5.x"`.
- Compose modules rather than copy-pasting blocks. A module is reviewed once and reused many times.
- See `modules.md` for module structure, versioning, and the module-vs-copy boundary.
-
-## Secrets (P10 Secrets Never in Code)
-
- Secrets via provider data sources (`aws_secretsmanager_secret_version`), environment variables, or a dedicated secrets provider. Never a literal string in a resource block.
- State may contain plaintext secrets if a resource attribute is sensitive. Mark attributes `sensitive = true` to keep them out of plan output; use a backend that encrypts state at rest (see `state.md`). This is the IaC angle on `domains/security/secrets.md` — secret hygiene is non-tradeable.
-
-## What Violates Terraform Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Unpinned provider (`source` without `version`) | P5 Version Everything |
-| `terraform apply` without a read `plan` | P4 Plan Before Apply |
-| Local state in a shared environment | P8 Remote State with Locking |
-| Hardcoded secret in HCL | P10 Secrets Never in Code |
-| Copy-pasted resource blocks instead of a module | P6 Modules Compose |
-| Manual change to a managed resource | P9 Drift is Recoverable |
-| Admin credentials in CI | P7 Least Privilege Providers |
@@ -1,67 +0,0 @@
-# Kubernetes — First Principles
-
-## 1. The Principles
-
-### P1. Declarative Desired State
-You declare the desired state; controllers reconcile current →
-desired. Imperative `kubectl` is for inspection and incident
-response, not for the steady state. The cluster's job is to make
-reality match the manifest.
-
-### P2. Pods are Mortal
-A pod is born, runs, and dies. Never assume its identity, its IP,
-or its lifetime. Use controllers (Deployment, StatefulSet,
-DaemonSet), not bare pods. A bare pod has no recovery, no
-scaling, no rollback.
-
-### P3. Labels Select
-Labels and selectors are the join mechanism of the platform —
-workloads to services, policies to workloads, workloads to nodes.
-Label by intent (`app`, `tier`, `env`), not by infrastructure
-(`node-3`, `ip-10.0.0.5`). Selectors compose; ad-hoc naming does
-not.
-
-### P4. Requests and Limits are Contracts
-Resource requests drive scheduling; limits drive quality of
-service. A workload with no requests is `BestEffort` — first
-evicted under pressure. A workload with no limits is unbounded.
-Specifying requests is not optional in production.
-
-### P5. Probes Drive Health
-Liveness, readiness, and startup probes are how the platform
-sees your workload. Without a readiness probe, traffic routes to
-a pod that is not ready. Without a liveness probe, a wedged
-container runs forever. The platform cannot heal what it cannot
-see.
-
-### P6. Namespaces Bound Blast Radius
-Namespaces are the unit of quota, RBAC, network policy, and
-cleanup. A namespace is the boundary of "this thing and all its
-parts." Default namespace is for nothing in production; every
-workload gets a named namespace sized to its blast radius.
-
-### P7. RBAC by Intent, Not Identity
-Bind roles to service accounts by the workload's purpose, not to
-user identities. Least privilege: the role grants the minimum
-the workload needs. `cluster-admin` is a smell, not a shortcut.
-Cross-link `domains/security/authorization.md`.
-
-### P8. Storage is Explicit
-Storage is ephemeral by default. Persistence requires a
-PVC, a StorageClass, and a reclaim policy decision. `emptyDir`
-for state that must survive is a bug. The choice of
-reclaim policy (`Retain`, `Delete`) is a data-safety decision,
-not a default.
-
-### P9. Config and Secrets are Separate
-ConfigMaps are non-sensitive configuration; Secrets are
-sensitive configuration. Both are injected at runtime, never
-baked into the image. A configuration change should not require
-a rebuild; a secret rotation should not require a redeploy of the
-image. Cross-link `domains/security/secrets.md`.
-
-### P10. Roll Forward, Roll Back
-Every Deployment has a rolling update strategy and a rollout
-history. A deploy is reversible: `kubectl rollout undo`. A deploy
-without a tested rollback is a prototype. Canary and blue-green
-are the k8s expression of `domains/devops/P5 Progressive Delivery`.
@@ -1,68 +0,0 @@
-# Helm — Derived Rules
-
-> Derives from `domains/kubernetes/first-principles.md`. Applies P1, P3, P6. For the Helm-vs-Kustomize decision, see the decision matrix at the end of this doc and in `kustomize.md`.
-
-## What Helm Is (P6 Modules Compose)
-
- Helm is a package manager for Kubernetes. A chart is a versioned package of templated manifests. `helm install` renders the templates against `values.yaml` and applies the result.
- A chart encapsulates a reusable deployment (an application, a database, a full stack). It is the k8s analogue of an IaC module — see `domains/infrastructure-as-code/modules.md`.
- Charts live in registries (Helm registry via OCI, or the classic chart repos) and are versioned per SemVer.
-
-## Chart Structure (P1 Declarative Desired State, C2 Clarity)
-
- `Chart.yaml` — metadata (name, version, appVersion, dependencies).
- `values.yaml` — default inputs; the chart's public interface.
- `templates/` — Go-templated manifests. `templates/_helpers.tpl` holds reusable template partials.
- `values.schema.json` — optional schema for values, giving type checking on inputs. Use it for published charts.
- A chart should have one logical purpose. A chart that deploys an app and a database and an ingress and an observability stack has too many jobs — split it.
-
-## Values (P5 Version Everything, C2 Clarity)
-
- `values.yaml` holds defaults. Override per release: `helm install --set key=value` or `helm install -f my-values.yaml`.
- Pin values files in git per environment. A release is reproducible from the chart version + the values file.
- Sensitive values do not belong in `values.yaml`. Inject via Secrets (see `rbac.md` P9 and `domains/security/secrets.md`). Some charts accept `existingSecret` to reference a pre-created Secret.
-
-## Release Management (P5 Version Everything, P10 Roll Forward Roll Back)
-
- A release is a named instantiation of a chart. `helm upgrade` applies a new chart version or new values. `helm rollback` reverts to the previous release revision.
- `helm history <release>` lists revisions; `helm rollback <release> <revision>` is the rollback. The rollback must be tested like any deploy (P10).
- Pin the chart version: `helm install --version 1.2.3`. Never `--version latest` in production — unversioned charts drift (same anti-pattern as unpinned IaC modules).
-
-## Templating Discipline (P1 Declarative Desired State, C2 Clarity)
-
- Templates render to valid manifests. The chart author's job is that the rendered output is correct k8s, not that the template is clever.
- Keep `templates/` readable. Heavy logic belongs in `_helpers.tpl` or in a values structure that the template merely projects.
- `helm template` renders to stdout without applying — use it to review what a release will create before installing it.
-
-## Registries (P5 Version Everything)
-
- OCI registries are the modern chart distribution (same registry as container images, charts as OCI artifacts). Classic chart repos are legacy.
- Pull from a pinned registry reference: `oci://registry/chart:1.2.3`. The digest + tag is the version.
-
-## Helm vs Kustomize — Decision Matrix (IDEATE-10)
-
-| Axis | Helm | Kustomize |
-|------|------|----------|
-| Mechanism | Templating (Go templates) | Overlays (base + patches) |
-| Reuse unit | Chart (versioned package) | Base directory (kustomization.yaml) |
-| Distribution | Registry (OCI, chart repo) | Git (base dir in a repo) |
-| Values | `values.yaml` + overrides | `kustomization.yaml` + patches |
-| Release mgmt | `helm` tracks releases, history, rollback | None native — apply with `kubectl apply -k` |
-| Learning curve | Template language to learn | YAML patching, no DSL |
-| Blast radius | One chart, many resources, templated | One base, many overlays, patched |
-| Best for | Off-the-shelf apps, packaged stacks, multi-env via values | Internal apps, patching upstream manifests, env-specific deltas |
-| Watch out for | Template complexity, `latest` chart drift, secrets in values | No release tracking, manual rollback, patch sprawl |
-
- Use Helm when you distribute a reusable app or consume third-party charts. Use Kustomize when you patch existing manifests or keep env deltas in one repo.
- Mixing both is fine and common: Helm for the packaged parts, Kustomize for the last-mile per-env patching. Do not fight the tool that fits the job.
-
-## What Violates Helm Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| `helm install --version latest` in prod | P5 Version Everything |
-| Secrets in `values.yaml` | P9 Config and Secrets are Separate, security |
-| Chart with 15 subcharts doing unrelated things | P6 Modules Compose (split it) |
-| No `values.schema.json` on a published chart | C2 Clarity |
-| `helm upgrade` without reviewing `helm template` output | P1 Declarative Desired State, P4 Plan Before Apply |
-| Untested `helm rollback` | P10 Roll Forward Roll Back |
@@ -1,63 +0,0 @@
-# Kustomize — Derived Rules
-
-> Derives from `domains/kubernetes/first-principles.md`. Applies P1, P3, P6. For the Helm-vs-Kustomize decision, see the decision matrix at the end of this doc and in `helm.md`.
-
-## What Kustomize Is (P1 Declarative Desired State)
-
- Kustomize customizes manifests without templating. A base directory holds the canonical manifests; overlays hold the deltas. The result is plain YAML applied with `kubectl apply -k`.
- No DSL, no template language, no rendering step hidden from `kubectl`. The patch is a YAML file; the result is inspectable.
- Kustomize is built into `kubectl` (`kubectl apply -k`, `kubectl diff -k`). No separate runtime is required to apply.
-
-## Base and Overlays (P6 Namespaces Bound Blast Radius, C4 Locality)
-
- A `kustomization.yaml` in a base directory lists the resources (Deployment, Service, etc.) the application needs. It is the canonical manifest.
- An overlay is a directory with its own `kustomization.yaml` that references the base (`resources: - ../../base`) and applies patches or additional resources.
- Typical structure: `base/`, `overlays/dev/`, `overlays/staging/`, `overlays/prod/`. The overlay is the environment axis; the base is the shared truth.
-
-## Patches (P1 Declarative Desired State, C2 Clarity)
-
- Strategic merge patches — a YAML document that overrides matching fields. Simple for single-resource changes.
- JSON patches (RFC 6902) — precise operations (`add`, `replace`, `remove`) on a path. Use when a strategic merge is ambiguous (e.g., list operations).
- `patches` field (modern) takes a list of patch files with targets, replacing the older `patchesStrategicMerge` and `patchesJson6902`. Prefer it.
- A patch is a delta. It is reviewed as "what changes from base," which is exactly the diff a reviewer wants to see.
-
-## Generators and Transformers (P3 Labels Select)
-
- `configMapGenerator` and `secretGenerator` create ConfigMaps and Secrets from files or literals, with content hashes in the names. A change to the source file changes the hash, which changes the name, which rolls the workload. This is the kustomize pattern for "config change = redeploy."
- `namePrefix`, `nameSuffix`, and `namespace` transformers rewrite names across the base. Use for namespace isolation (P6) or to run the same base multiple times in one cluster without collisions.
- `commonLabels` and `commonAnnotations` stamp labels onto everything in the base — the kustomize-native way to enforce the labelling discipline of P3.
-
-## No Release Tracking (P10 Roll Forward Roll Back)
-
- Kustomize has no release object, no history, no built-in rollback. `kubectl apply -k` is a one-shot apply; the previous state is in git, not in a Helm-style release record.
- Rollback is `git revert` + `kubectl apply -k`. The git history IS the release history. This is fine — and arguably cleaner — but it means rollback is a git operation, not a `helm rollback` command.
- Use a GitOps tool (ArgoCD, Flux) on top of Kustomize for automated reconciliation and rollback tracking. The tool watches the git ref; rollback is a git revert.
-
-## Helm vs Kustomize — Decision Matrix (IDEATE-10)
-
-| Axis | Kustomize | Helm |
-|------|----------|------|
-| Mechanism | Overlays (base + patches) | Templating (Go templates) |
-| Reuse unit | Base directory (kustomization.yaml) | Chart (versioned package) |
-| Distribution | Git (base dir in a repo) | Registry (OCI, chart repo) |
-| Values | `kustomization.yaml` + patches | `values.yaml` + overrides |
-| Release mgmt | None native — `kubectl apply -k` | `helm` tracks releases, history, rollback |
-| Learning curve | YAML patching, no DSL | Template language to learn |
-| Blast radius | One base, many overlays, patched | One chart, many resources, templated |
-| Best for | Internal apps, patching upstream manifests, env-specific deltas | Off-the-shelf apps, packaged stacks, multi-env via values |
-| Watch out for | No release tracking, manual rollback, patch sprawl | Template complexity, `latest` chart drift, secrets in values |
-
- Use Kustomize when you patch existing manifests or keep env deltas in one repo. Use Helm when you distribute a reusable app or consume third-party charts.
- Mixing both is fine and common: Kustomize for the internal apps, Helm for the packaged parts. The decision is per-workload, not per-cluster.
- `commonLabels` is the kustomize-native enforcement of P3 (Labels Select); see `domains/devops/first-principles.md` P6 (Configuration as Code) for the upstream principle that the rendered manifest — not a console click — is the source of truth.
-
-## What Violates Kustomize Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Duplicated base instead of an overlay | P6 Modules Compose (use an overlay) |
-| Patch that overrides most of the base | C3 Simplicity (the base is wrong — fix the base) |
-| No `commonLabels` on a multi-team base | P3 Labels Select |
-| No git-based rollback strategy | P10 Roll Forward Roll Back |
-| Hand-edited rendered output instead of `apply -k` | P1 Declarative Desired State |
-| Patch sprawl (10 overlays each patching 15 fields) | C3 Simplicity (refactor the base) |
@@ -1,49 +0,0 @@
-# Networking — Derived Rules
-
-> Derives from `domains/kubernetes/first-principles.md`. Covers Service, Ingress, Gateway API, EndpointSlices, NetworkPolicy, and DNS. Applies P1, P3, P6.
-
-## The Service (P3 Labels Select)
-
- A Service routes traffic to pods selected by a label selector. The selector is the join between the network abstraction and the workloads.
- Service types: `ClusterIP` (in-cluster only, default), `NodePort` (exposed on every node's IP at a fixed port), `LoadBalancer` (cloud-managed LB points to the Service). Default to `ClusterIP`; expose only what must be exposed.
- A Service fronts a Deployment (or other controller), never a bare pod. The controller keeps pods available; the Service routes to whichever are ready (per the readiness probe — see `workloads.md`).
-
-## EndpointSlices (P3 Labels Select, P5 Probes Drive Health)
-
- An EndpointSlice lists the pod IPs currently backing a Service. Only pods passing their readiness probe appear.
- The Service routes by EndpointSlice, not by selector directly. A pod with the right labels but a failed readiness probe is not in the Service.
-
-## Ingress and Gateway API (P6 Namespaces Bound Blast Radius)
-
- Ingress routes HTTP/HTTPS traffic from outside the cluster to Services. It is L7 routing by host and path.
- Gateway API is the successor to Ingress: more expressive (TCP, UDP, TLS passthrough), role-oriented (GatewayClass → Gateway → Route), and cross-platform. Prefer Gateway API for new L7 needs.
- Both Ingress and Gateway API are implemented by a controller (nginx-ingress, Traefik, Istio, Envoy Gateway). Pick one; mixing ingress controllers in a cluster is operational debt.
-
-## NetworkPolicy (P6 Namespaces Bound Blast Radius, P7 RBAC by Intent)
-
- A NetworkPolicy is a firewall rule for pods. Default-deny ingress; allow by namespace and pod selector.
- Without a default-deny NetworkPolicy, every pod can reach every other pod. In production, default-deny is the baseline; allows are the exceptions.
- NetworkPolicy is the network-layer expression of zero-trust authorization — see `domains/security/authorization.md`. RBAC (see `rbac.md`) governs the API; NetworkPolicy governs the network; together they bound blast radius (P6).
- NetworkPolicy is enforced by the CNI plugin (Calico, Cilium, etc.). A NetworkPolicy with no supporting CNI is a no-op. Verify the CNI enforces before relying on it.
-
-## DNS (P3 Labels Select)
-
- Every Service gets a DNS record: `<service>.<namespace>.svc.cluster.local`. Pods get `pod-ip-address.<namespace>.pod.cluster.local` (with dots replaced).
- Headless Services (`clusterIP: None`) resolve directly to pod IPs — use for StatefulSet peer discovery (`<statefulset>-0.<service>`).
- DNS is how workloads find each other without hardcoded IPs. Use the DNS name, not the ClusterIP.
-
-## Dual-Stack (C4 Locality)
-
- IPv4/IPv6 dual-stack is opt-in per cluster. Services can be single-stack or dual-stack per Service.
- Decide at cluster creation. Migrating a single-stack cluster to dual-stack is disruptive and rarely worth it.
-
-## What Violates Networking Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| `LoadBalancer` on an internal-only Service | P6 Namespaces Bound Blast Radius |
-| No default-deny NetworkPolicy | P6 Namespaces Bound Blast Radius, P7 RBAC by Intent |
-| Hardcoded pod IP in config | P3 Labels Select (use DNS) |
-| Service pointing at a bare pod | P3 Labels Select (point at a controller) |
-| Multiple ingress controllers in one cluster | C3 Simplicity (operational debt) |
-| No readiness probe on a Service-backed workload | P5 Probes Drive Health (empty EndpointSlices) |
@@ -1,45 +0,0 @@
-# RBAC and Pod Security — Derived Rules
-
-> Derives from `domains/kubernetes/first-principles.md`. P7 (RBAC by Intent, Not Identity) lives here. Cross-link `domains/security/authorization.md` for the general authorization principles and `domains/security/secrets.md` for secret handling.
-
-## RBAC Objects (P7 RBAC by Intent, Not Identity)
-
- **Role** — permissions within a namespace (verb on resource). **ClusterRole** — permissions cluster-wide or usable across namespaces.
- **RoleBinding** — binds a Role to a subject (ServiceAccount, User, Group) within a namespace. **ClusterRoleBinding** — binds a ClusterRole cluster-wide.
- Prefer Role + RoleBinding per namespace over ClusterRole + ClusterRoleBinding. Cluster-level is the broad axe; namespace-level is the scalpel.
-
-## Bind to Service Accounts, Not Users (P7 RBAC by Intent, Not Identity)
-
- A workload authenticates as a ServiceAccount. Bind the Role to the ServiceAccount, scoped to the workload's namespace.
- The Role encodes the workload's intent: "this workload reads ConfigMaps in this namespace." Not "this user is an admin."
- One ServiceAccount per workload (or workload family). Do not reuse the `default` ServiceAccount for production workloads; it is a shared identity.
-
-## Least Privilege (P7 RBAC by Intent, C1 Correctness via security)
-
- Grant the minimum verbs on the minimum resources. `get, list, watch` on `pods` is fine for a monitoring sidecar; `*` on `*` is not.
- `cluster-admin` is a smell. If a workload "needs" `cluster-admin`, the workload is either doing something it should not, or it is a cluster operator that should be reviewed as such.
- Audit `ClusterRoleBindings` regularly. They are the broadest grant in the system and the easiest to leave behind.
-
-## Pod Security Standards and Admission (P7 RBAC by Intent, security)
-
- Pod Security Standards (PSS) define three profiles: `privileged` (unrestricted), `baseline` (some restrictions), `restricted` (hardened).
- Pod Security Admission (built-in) enforces a PSS profile per namespace via labels: `pod-security.kubernetes.io/enforce: restricted`. It replaces the deprecated PodSecurityPolicy.
- Map namespaces to profiles: `restricted` for prod workloads, `baseline` for most, `privileged` only for system add-ons (CNI, CSI, node agents) that need it. A workload in `privileged` is a security event, not a default.
-
-## Service Accounts and Token Automation (P9 Config and Secrets are Separate)
-
- ServiceAccount tokens are auto-mounted into pods unless `automountServiceAccountToken: false`. For workloads that do not call the API, disable auto-mount.
- Long-lived ServiceAccount tokens are deprecated. Use projected tokens (bound to the pod, time-limited) via `TokenRequest`.
- A workload that does not need API access should not have a token. A workload that needs API access should have a Role scoped to its intent.
-
-## What Violates RBAC Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| `cluster-admin` bound to a workload | P7 RBAC by Intent, Not Identity |
-| Reused `default` ServiceAccount for prod | P7 RBAC by Intent, Not Identity |
-| `automountServiceAccountToken: true` on a non-API workload | P9 Config and Secrets are Separate |
-| `privileged` PSS on an application namespace | P7 RBAC by Intent, security |
-| ClusterRoleBinding where a RoleBinding would suffice | P6 Namespaces Bound Blast Radius, P7 |
-| Long-lived static token instead of projected | P9 Config and Secrets are Separate |
-| Leftover ClusterRoleBindings after a workload is removed | P7 RBAC by Intent (audit) |
@@ -1,59 +0,0 @@
-# Storage — Derived Rules
-
-> Derives from `domains/kubernetes/first-principles.md`. P8 (Storage is Explicit) lives here. Covers Volumes, PV/PVC, StorageClass, CSI, snapshots, and reclaim policies. Cross-link `domains/data/` for the data-model angle.
-
-## Ephemeral by Default (P8 Storage is Explicit)
-
- A container's filesystem is ephemeral. When the pod dies, the filesystem dies with it. This is the design, not a flaw.
- `emptyDir` is an ephemeral volume scoped to the pod's lifetime (survives container restarts within the pod, dies with the pod). It is scratch space, never durable storage.
- Any data that must survive a pod restart requires a PersistentVolumeClaim (PVC). The choice of "must survive" is the data-safety decision at the heart of P8.
-
-## PersistentVolume and PersistentVolumeClaim (P8 Storage is Explicit)
-
- A PersistentVolume (PV) is a piece of storage in the cluster. A PersistentVolumeClaim (PVC) is a request for that storage by a workload.
- The PV is the resource; the PVC is the consumer. A workload mounts the PVC, not the PV directly.
- For StatefulSets, use `volumeClaimTemplates` so each replica gets its own PVC with a stable name (`data-<statefulset>-0`). Do not share one PVC across replicas of a stateful workload.
-
-## StorageClass and Dynamic Provisioning (P8 Storage is Explicit, P5 Version Everything)
-
- A StorageClass describes the "flavour" of storage (e.g., `fast-ssd`, `cold-hdd`, `encrypted`). A PVC names a StorageClass or gets the cluster default.
- Dynamic provisioning creates the PV on demand when the PVC is created, via the CSI driver. Manual PV creation is for specific cases (a pre-existing disk, a static NFS export).
- Mark a default StorageClass only if the default is safe for all workloads. A fast-but-expensive default can cause cost surprises; a slow default can cause performance surprises.
-
-## CSI (P5 Version Everything)
-
- The Container Storage Interface (CSI) is the standard driver interface. Each storage backend ships a CSI driver. Pin the CSI driver version in the cluster; treat it as infrastructure.
- CSI enables features beyond mount/unmount: snapshots, cloning, volume expansion, and topology-aware provisioning. Not all drivers implement all features; verify before relying.
-
-## Volume Snapshots (P5 Reversibility, P8 Storage is Explicit)
-
- A VolumeSnapshot is a point-in-time copy of a PVC, taken by the CSI driver. Restore creates a new PVC from the snapshot.
- Snapshots are not backups. They are local to the storage backend and may share blocks with the source. An off-cluster backup is still required for disaster recovery.
- Snapshot scheduling is a workload concern (use a CronJob or a tool like Velero), not a k8s-native feature.
-
-## Reclaim Policies (P8 Storage is Explicit, P5 Reversibility)
-
-| Policy | On PVC delete | When |
-|--------|---------------|------|
-| `Retain` | PV and its data persist; PV must be manually reclaimed | Production, data-safety default |
-| `Delete` | PV and the underlying storage are deleted | Ephemeral, dev, scratch |
-| `Recycle` (deprecated) | PV scrubbed and made available again | Do not use — use dynamic provisioning |
-
- The reclaim policy is a data-safety decision. `Delete` on a production PVC is a footgun: deleting the PVC destroys the data. Default to `Retain` for prod, `Delete` for dev.
- For StatefulSet PVCs, the reclaim policy on the StorageClass governs what happens when the PVC is deleted (which happens when the StatefulSet is scaled down or deleted, depending on the policy).
-
-## Ephemeral Volumes (P8 Storage is Explicit)
-
- `configMap`, `secret`, `downwardAPI` volumes are read-only (by default) projections injected at pod start. They are configuration, not storage.
- `emptyDir` with `medium: Memory` is a tmpfs — fast, ephemeral, memory-charged. Use for scratch that must be fast and never persist.
-
-## What Violates Storage Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| `emptyDir` for data that must survive pod restart | P8 Storage is Explicit |
-| Shared PVC across StatefulSet replicas | P8 Storage is Explicit (use `volumeClaimTemplates`) |
-| `Delete` reclaim policy on production storage | P8 Storage is Explicit, P5 Reversibility |
-| Snapshot treated as a backup | P5 Reversibility (snapshots are local, not DR) |
-| No default StorageClass decision (accidental default) | P8 Storage is Explicit |
-| Manual PV creation when dynamic provisioning exists | C3 Simplicity |
@@ -1,54 +0,0 @@
-# Workloads — Derived Rules
-
-> Derives from `domains/kubernetes/first-principles.md`. Covers Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, and CronJob. Applies P1–P10.
-
-## The Pod (P2 Pods are Mortal)
-
- A pod is the smallest deployable unit: one or more containers sharing network and storage namespaces.
- Never deploy a bare pod. A bare pod has no controller to restart, scale, or replace it. Use a controller.
- Pods are replaceable by design. Do not store state in a pod's filesystem (`emptyDir` is scratch, not storage — see `storage.md`).
-
-## Controllers (P1 Declarative Desired State)
-
-| Controller | When | Identity | Ordering |
-|------------|------|----------|----------|
-| Deployment | Stateless workloads | None (pods interchangeable) | No ordering |
-| StatefulSet | Stateful workloads (databases, queues) | Stable name (`pod-0`, `pod-1`) + stable PVC | Ordered, sequential |
-| DaemonSet | One pod per node (logging, monitoring, CNI) | Per-node | — |
-| Job | Run to completion (batch) | — | — |
-| CronJob | Scheduled batch | — | — |
-
- A Deployment manages a ReplicaSet, which manages pods. You interact with the Deployment; the ReplicaSet is an implementation detail except during rollouts.
- StatefulSet gives stable network identity and stable persistent storage per replica. Use it when the workload needs a stable name or per-replica data (databases, distributed systems). Do not use StatefulSet for stateless workloads — the ordering is overhead.
-
-## Probes (P5 Probes Drive Health)
-
- **Readiness probe** — is the pod ready to serve traffic? Failing readiness removes the pod from the Service's endpoints but does not restart it. Use for "warm-up" and transient unavailability.
- **Liveness probe** — is the pod alive? Failing liveness restarts the container. Use for "wedged but running." Do not use liveness to check dependencies (it will cascade-restart on a dependency blip).
- **Startup probe** — has the pod finished starting? Disables liveness/readiness until it succeeds. Use for slow-starting workloads so liveness does not kill them before they are ready.
- Probes must check the workload's own health, not the health of its dependencies. A readiness probe that fails on a downstream outage causes the Service to drain all pods simultaneously.
-
-## Lifecycle and Disruption (P2 Pods are Mortal, P10 Roll Forward Roll Back)
-
- `kubectl rollout status` watches a Deployment's rollout to completion. `kubectl rollout undo` reverts to the previous ReplicaSet.
- PodDisruptionBudgets (PDBs) protect voluntary disruptions (node drain, cluster autoscaler). An involuntary disruption (node failure) ignores the PDB. Set a PDB on every workload that must keep a minimum available.
- Rolling update strategy: `maxUnavailable` and `maxSurge` control the speed of rollout. Slow rollouts (low `maxSurge`) are safer; fast rollouts (high `maxUnavailable`) risk availability.
-
-## Resource Contracts (P4 Requests and Limits are Contracts)
-
- Every container in production has a CPU request, a memory request, and a memory limit. CPU limits are optional but recommended to bound noisy neighbours.
- QoS classes: `Guaranteed` (requests == limits), `Burstable` (requests < limits), `BestEffort` (no requests). `BestEffort` is first evicted under node pressure — never for prod.
- A workload without requests is an unbounded gamble on the scheduler. Set them.
- The rolling update + rollout history described below is the k8s expression of `domains/observability/metrics.md` for health and `domains/devops/first-principles.md` P5 (Progressive Delivery): the platform observes the rollout via probes and metrics and can stop or reverse it.
-
-## What Violates Workload Discipline
-
-| Violation | Principle |
-|-----------|-----------|
-| Bare pod (no controller) | P2 Pods are Mortal |
-| StatefulSet for a stateless workload | P1 Declarative Desired State (overhead) |
-| No probes | P5 Probes Drive Health |
-| Liveness probe checks a dependency | P5 Probes Drive Health |
-| No PDB on a critical workload | P10 Roll Forward Roll Back |
-| No resource requests in prod | P4 Requests and Limits are Contracts |
-| `emptyDir` for data that must persist | P8 Storage is Explicit |
@@ -1,71 +0,0 @@
-# Bad Example: Bare Pod, No Resources
-
-> A Kubernetes manifest that violates Atelier's Kubernetes principles. Each violation is cited.
-
-## The Code
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: api
-  namespace: default
-spec:
-  containers:
-    - name: api
-      image: api:latest          # :latest, unversioned
-      ports:
-        - containerPort: 8080
-      env:
-        - name: DATABASE_URL
-          value: "postgres://admin:hunter2@db:5432/app"   # secret in plaintext, in the manifest
-```
-
-The team applies it with `kubectl apply -f api-pod.yaml`. When the pod crashes, they `kubectl delete pod api && kubectl apply -f api-pod.yaml` to "restart" it. There are no probes, no resource requests, no RBAC, no NetworkPolicy.
-
-## What Makes It Bad
-
-### Bare Pod, No Controller (k8s P2 Pods are Mortal)
- A `kind: Pod` with no controller. When the node dies, the pod does not come back. When the team needs three replicas, they copy the YAML twice and rename it.
- The "restart" workflow (`delete pod && apply`) is manual recovery — exactly the manual-mutation anti-pattern from `domains/devops/`.
- **Fix:** use a `Deployment`. The controller replaces dead pods, scales, and rolls back. See `domains/kubernetes/workloads.md`.
-
-### No Resource Requests (k8s P4 Requests and Limits are Contracts)
- The container has no `resources.requests` or `resources.limits`. It is `BestEffort` — first evicted under node pressure. The scheduler has no signal to place it well; it lands wherever there is room, then gets killed when the node is full.
- A workload without requests is an unbounded gamble on the scheduler.
- **Fix:** set CPU and memory requests on every prod container; set a memory limit; consider a CPU limit. See `domains/kubernetes/workloads.md`.
-
-### No Probes (k8s P5 Probes Drive Health)
- No `readinessProbe` — the Service routes traffic to the pod before it is ready. Users see 502s during startup.
- No `livenessProbe` — a wedged container runs forever; no one notices until the outage.
- The platform cannot heal what it cannot see. A pod without probes is invisible to the controller's reconciliation.
- **Fix:** define readiness and liveness probes that check the workload's own health. See `domains/kubernetes/workloads.md`.
-
-### `:latest` Image Tag (k8s P1 + IaC P5 Version Everything)
- `image: api:latest` is unversioned. Every `kubectl apply` pulls whatever is newest at that moment. Two pods "running the same manifest" run different images if `latest` moved between applies.
- Rollback is impossible — there is no version to roll back to.
- **Fix:** pin the image to a version or a digest: `image: registry.example.com/api:v1.4.2` or `image: registry.example.com/api@sha256:...`. See `domains/kubernetes/workloads.md` and `domains/infrastructure-as-code/terraform.md` (P5 Version Everything).
-
-### Secret in Plaintext in the Manifest (k8s P9 Config and Secrets are Separate, IaC P10)
- `DATABASE_URL` with the password is in the manifest in plaintext. If the manifest is committed (it is), the secret is in git.
- Rotating the secret requires editing the manifest and re-applying — no separation of config from secret.
- **Fix:** put the URL in a `Secret` (created out-of-band or via a secrets tool) and reference it with `valueFrom.secretKeyRef`. The manifest contains the reference, not the value. See `domains/kubernetes/rbac.md` and `domains/security/secrets.md`.
-
-### `default` Namespace (k8s P6 Namespaces Bound Blast Radius)
- The pod runs in `default`. There is no namespace boundary for quota, RBAC, or NetworkPolicy. Every other workload in `default` can reach it; an outage in one affects the namespace all share.
- **Fix:** give every prod workload a named namespace sized to its blast radius. `default` is for nothing in production. See `domains/kubernetes/networking.md` and `domains/kubernetes/workloads.md`.
-
-### No RBAC, No NetworkPolicy (k8s P7 RBAC by Intent, P6 Namespaces Bound Blast)
- No `serviceAccountName` — the pod uses the `default` ServiceAccount, a shared identity.
- No `NetworkPolicy` — every pod in the cluster can reach `api`. The network is flat by default.
- **Fix:** a dedicated ServiceAccount with a least-privilege Role bound by intent. A default-deny NetworkPolicy with explicit allows. See `domains/kubernetes/rbac.md` and `domains/kubernetes/networking.md`.
-
-## The Cascade
-
-The violations compound. A bare pod with no probes crashes silently and is not restarted. `:latest` means the "restart" pulls a different image than the one that crashed. The plaintext secret in the manifest is now in git, so rotating it means editing the manifest and re-applying — and the new manifest still has no controller, so the next crash starts the manual loop again. `default` namespace means the blast radius is the whole cluster.
-
-## Cross-Domain Links
-
- `domains/devops/P4 Rollback First` — with `:latest` and no controller, there is no rollback path.
- `domains/security/authorization` — the shared `default` ServiceAccount and flat network are the k8s expression of zero-trust violation.
- `domains/errors/P2 Fail Loudly` — a pod with no probes fails silently; the platform has no signal to act on.
@@ -1,74 +0,0 @@
-# Bad Example: Unlocked Local State
-
-> An IaC configuration that violates Atelier's Infrastructure as Code principles. Each violation is cited.
-
-## The Code
-
-```hcl
-# main.tf — committed to the repo
-terraform {
-  required_providers {
-    aws = {
-      source  = "hashicorp/aws"
-      # no version pin
-    }
-  }
-}
-
-provider "aws" {
-  region     = "us-east-1"
-  access_key = "AKIAIOSFODNN7EXAMPLE"   # committed
-  secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"  # committed
-}
-
-resource "aws_s3_bucket" "logs" {
-  bucket = "app-logs-prod"
-}
-
-resource "aws_db_instance" "primary" {
-  identifier           = "app-prod"
-  username             = "admin"
-  password             = "hunter2"        # committed, in plaintext, in state
-  allocated_storage    = 20
-  engine               = "postgres"
-  instance_class       = "db.t3.micro"
-  skip_final_snapshot  = true
-}
-```
-
-The team runs `terraform apply` from their laptops. The state file `terraform.tfstate` is committed alongside `main.tf` "so everyone is on the same page."
-
-## What Makes It Bad
-
-### Local State in a Shared Environment (IaC P8 Remote State with Locking)
- State is `terraform.tfstate` on each laptop. Two team members run `terraform apply` simultaneously; the second to finish silently overwrites the first's changes. There is no lock.
- The state file is committed to the repo. It contains the DB password in plaintext. It is a secret-bearing artifact in version control.
- **Fix:** use a remote backend with locking (S3 + DynamoDB, GCS, etc.). Never commit state. See `domains/infrastructure-as-code/state.md`.
-
-### Hardcoded Secrets (IaC P10 Secrets Never in Code)
- `access_key` and `secret_key` are committed in `main.tf`. The DB `password` is committed and also written to state in plaintext.
- The secrets are now in the git history. Rotating them is not optional; the history must be scrubbed or the credentials rotated and the old ones revoked.
- **Fix:** credentials from environment, a secrets manager, or a `data` source (`aws_secretsmanager_secret_version`). Mark sensitive attributes `sensitive = true`. See `domains/security/secrets.md`.
-
-### Unpinned Provider (IaC P5 Version Everything)
- The `aws` provider has no `version`. The next `terraform init` pulls whatever is latest — a different provider version can change resource behavior with no review.
- **Fix:** pin `version = "~> 5.0"`. Commit the lock file (`.terraform.lock.hcl`). See `domains/infrastructure-as-code/terraform.md`.
-
-### Manual Drift, No Plan Review (IaC P4 Plan Before Apply, P9 Drift is Recoverable)
- The team applies from laptops with no `plan` review. When the DB password is wrong, someone SSHes in and changes it manually — drift that `plan` will later report as a surprise.
- Manual changes to managed resources are an incident, not a shortcut. Each one is a future `plan` diff that no one can explain.
- **Fix:** run `terraform plan` in CI; review the diff; `apply` from CI on merge. Treat every drift report as an incident to investigate. See `domains/infrastructure-as-code/state.md` (Drift and Reconciliation).
-
-### No Module Composition (IaC P6 Modules Compose)
- The S3 bucket and DB instance are inline. When the team needs a second bucket, they copy-paste the block and rename it. The two copies drift over time.
- **Fix:** a versioned module for each reusable pattern. The difference is a variable, not a copy. See `domains/infrastructure-as-code/modules.md` (the module-vs-copy boundary).
-
-## The Cascade
-
-The violations compound. Unlocked local state lets two `apply` runs race. Committed secrets mean the race loser's changes — and the secrets — are in the repo. Manual drift hides the corruption until a `plan` surfaces a diff no one can explain. The unpinned provider means that diff might be the provider's fault, not the team's, and no one can tell which.
-
-## Cross-Domain Links
-
- `domains/security/secrets.md` — secret hygiene is non-tradeable; this example violates it in three places.
- `domains/security/supply-chain.md` — committed credentials in git are a supply-chain incident.
- `domains/devops/P6 Configuration as Code` — config in the repo is correct; committed *state and secrets* is the violation.
@@ -1,157 +0,0 @@
-# Good Example: Kubernetes Deployment
-
-> A Kubernetes Deployment that follows Atelier's Kubernetes principles. Each aspect cites the principle it satisfies.
-
-## The Deployment
-
-A stateless web service deployed as a Deployment with probes, resource contracts, RBAC, and a rolling update strategy — the canonical "production workload" pattern.
-
-### Manifest
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: api
-  namespace: api-prod
-  labels:
-    app: api
-    tier: web
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      app: api
-  strategy:
-    type: RollingUpdate
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 0
-  template:
-    metadata:
-      labels:
-        app: api
-        tier: web
-    spec:
-      serviceAccountName: api
-      automountServiceAccountToken: false
-      containers:
-        - name: api
-          image: registry.example.com/api:v1.4.2  # pinned, not :latest
-          ports:
-            - containerPort: 8080
-          resources:
-            requests:
-              cpu: 250m
-              memory: 256Mi
-            limits:
-              memory: 512Mi
-          readinessProbe:
-            httpGet:
-              path: /healthz/ready
-              port: 8080
-            initialDelaySeconds: 5
-            periodSeconds: 5
-          livenessProbe:
-            httpGet:
-              path: /healthz/live
-              port: 8080
-            initialDelaySeconds: 15
-            periodSeconds: 10
-          env:
-            - name: LOG_LEVEL
-              valueFrom:
-                configMapKeyRef:
-                  name: api-config
-                  key: log_level
-            - name: DATABASE_URL
-              valueFrom:
-                secretKeyRef:
-                  name: api-secrets
-                  key: database_url
-          volumeMounts:
-            - name: config
-              mountPath: /etc/api
-              readOnly: true
-      volumes:
-        - name: config
-          configMap:
-            name: api-config
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: api
-  namespace: api-prod
-spec:
-  selector:
-    app: api
-  ports:
-    - port: 80
-      targetPort: 8080
---
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: api-deny-ingress
-  namespace: api-prod
-spec:
-  podSelector:
-    matchLabels:
-      app: api
-  policyTypes:
-    - Ingress
-  ingress:
-    - from:
-        - namespaceSelector:
-            matchLabels:
-              tier: edge
-```
-
-## What Makes It Good
-
-### Controller, Not Bare Pod (k8s P2 Pods are Mortal)
- A `Deployment` manages the pods. If one dies, the controller replaces it. A bare pod has no recovery.
- See `domains/kubernetes/workloads.md`.
-
-### Resource Contracts (k8s P4 Requests and Limits are Contracts)
- Every container has CPU and memory requests and a memory limit. The workload is `Burstable`, not `BestEffort` (first evicted under pressure).
- See `domains/kubernetes/workloads.md` for QoS classes.
-
-### Probes (k8s P5 Probes Drive Health)
- `readinessProbe` gates traffic: a pod that is not ready is removed from the Service's endpoints.
- `livenessProbe` restarts a wedged container.
- The probes check the workload's own health (`/healthz/ready`, `/healthz/live`), not a dependency. A liveness probe that calls the database would cascade-restart on a DB blip.
- See `domains/kubernetes/workloads.md`.
-
-### Image Pinning (k8s P1 + IaC P5 Version Everything)
- `image: registry.example.com/api:v1.4.2` — pinned to a version, not `:latest`. A pod restart pulls the same image it was built with.
- See `domains/infrastructure-as-code/terraform.md` and `domains/devops/P7 Immutability` for the immutability angle.
-
-### RBAC (k8s P7 RBAC by Intent, Not Identity)
- `serviceAccountName: api` — the workload runs as a dedicated ServiceAccount, not the `default` shared identity.
- `automountServiceAccountToken: false` — the workload does not call the API, so it gets no token. See `domains/kubernetes/rbac.md`.
- A matching `Role` + `RoleBinding` (not shown) would grant `get, list, watch` on `configmaps` in this namespace — least privilege, scoped by intent.
-
-### Config and Secrets Separate (k8s P9 Config and Secrets are Separate)
- `LOG_LEVEL` from a ConfigMap (non-sensitive). `DATABASE_URL` from a Secret (sensitive). Both injected at runtime; neither baked into the image.
- A configuration change does not require a rebuild. A secret rotation does not require an image redeploy.
- See `domains/kubernetes/rbac.md` and `domains/security/secrets.md`.
-
-### Namespaces Bound Blast Radius (k8s P6 Namespaces Bound Blast Radius)
- The workload lives in `api-prod`, not `default`. The namespace is the unit of quota, RBAC, and NetworkPolicy. A problem in `api-prod` does not leak to other workloads.
- See `domains/kubernetes/networking.md`.
-
-### NetworkPolicy Default-Deny (k8s P6, P7)
- The `NetworkPolicy` allows ingress only from the `edge` namespace. Without it, every pod in the cluster could reach `api`. Default-deny is the baseline; allows are the exceptions.
- See `domains/kubernetes/networking.md`.
-
-### Roll Forward, Roll Back (k8s P10 Roll Forward Roll Back)
- `strategy: RollingUpdate` with `maxSurge: 1, maxUnavailable: 0` — the rollout adds a new pod before removing an old one. Availability is maintained.
- `kubectl rollout undo deployment/api` reverts to the previous ReplicaSet. The rollback is tested before it is needed.
- See `domains/kubernetes/workloads.md` and `domains/devops/P5 Progressive Delivery`.
-
-### Cross-Domain Links
- `domains/devops/P4 Rollback First` — the rollout strategy makes the deploy reversible.
- `domains/security/authorization` — the ServiceAccount + Role model is the k8s expression of least-privilege authorization.
- `domains/observability/metrics` — the probes are the platform's observability into the workload's health; the workload's own metrics complete the picture.
@@ -1,125 +0,0 @@
-# Good Example: Terraform Module
-
-> A reusable Terraform module that follows Atelier's Infrastructure as Code principles. Each aspect cites the principle it satisfies.
-
-## The Module
-
-A versioned module that provisions an S3 bucket with logging, versioning, and encryption — the canonical "secure bucket" pattern, composed rather than copy-pasted.
-
-### Consumer Call
-
-```hcl
-module "logs_bucket" {
-  source  = "registry.example.com/infra/secure-bucket/aws"
-  version = "1.2.0"
-
-  name             = "app-logs"
-  region           = "us-east-1"
-  force_destroy    = false
-  retention_days   = 90
-}
-```
-
-### Module Structure
-
-```
-secure-bucket/
-├── main.tf          # the resource
-├── variables.tf    # typed inputs
-├── outputs.tf      # the interface to consumers
-├── versions.tf     # provider pin
-└── README.md       # the module contract
-```
-
-### `versions.tf` (P5 Version Everything)
-
-```hcl
-terraform {
-  required_version = ">= 1.5.0"
-  required_providers {
-    aws = {
-      source  = "hashicorp/aws"
-      version = "~> 5.0"
-    }
-  }
-}
-```
-
-### `variables.tf` (P1 Declarative Intent, C2 Clarity)
-
-```hcl
-variable "name" {
-  type        = string
-  description = "Globally unique bucket name."
-  validation {
-    condition     = can(regex("^[a-z0-9][a-z0-9-]{1,61}[a-z0-9]$", var.name))
-    error_message = "Bucket name must be lowercase, 3-63 chars, DNS-compatible."
-  }
-}
-
-variable "retention_days" {
-  type        = number
-  default     = 30
-  description = "S3 lifecycle transition age in days."
-}
-```
-
-### `main.tf` (P1, P3 State is Truth, P10 Secrets Never in Code)
-
-```hcl
-resource "aws_s3_bucket" "this" {
-  bucket = var.name
-}
-
-resource "aws_s3_bucket_versioning" "this" {
-  bucket = aws_s3_bucket.this.id
-  versioning_configuration {
-    status = "Enabled"
-  }
-}
-
-resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
-  bucket = aws_s3_bucket.this.id
-  rule {
-    apply_server_side_encryption_by_default {
-      sse_algorithm = "AES256"
-    }
-  }
-}
-
-resource "aws_s3_bucket_lifecycle_configuration" "this" {
-  bucket = aws_s3_bucket.this.id
-  rule {
-    id     = "retention"
-    status = "Enabled"
-    filter { prefix = "" }
-    expiration { days = var.retention_days }
-  }
-}
-```
-
-## What Makes It Good
-
-### Composition (IaC P6 Modules Compose, C6 Composability)
- The bucket pattern is one module, versioned once, consumed many times. A new consumer does not copy 40 lines of HCL — they call the module with a `name` and a `retention_days`.
- See `domains/infrastructure-as-code/modules.md` for the module-vs-copy boundary.
-
-### Pinning (IaC P5 Version Everything)
- The consumer pins `version = "1.2.0"`. The module pins its provider (`version = "~> 5.0"`) and the required Terraform version. A commit is a complete, reproducible world.
- No `latest` anywhere. See `domains/infrastructure-as-code/terraform.md`.
-
-### State Discipline (IaC P3 State is Truth, P8 Remote State with Locking)
- The consumer's root configuration declares a remote backend with locking (S3 + DynamoDB, GCS, etc.). The module itself does not declare a backend — the consumer owns state.
- See `domains/infrastructure-as-code/state.md` for backend selection and locking.
-
-### Secrets Hygiene (IaC P10 Secrets Never in Code)
- The bucket is encrypted at rest (SSE-S3 AES256). No secret is hardcoded; encryption is a provider-managed default. If KMS were used, the key would come from a `data` source or a dedicated KMS module — never a literal.
- See `domains/security/secrets.md` for the general secrets principles.
-
-### Plan Before Apply (IaC P4 Plan Before Apply)
- The consumer runs `terraform plan` before `apply`. The plan shows the new bucket, versioning, encryption, and lifecycle. Every line is reviewed. The plan is the contract review; `apply` is the signature.
-
-### Cross-Domain Links
- `domains/devops/P1 Reproducibility` — the module makes the bucket reproducible from source.
- `domains/devops/P6 Configuration as Code` — the bucket is config, not a console click.
- `domains/security/supply-chain` — a versioned, signed module from a trusted registry is a supply-chain control.
@@ -6,14 +6,14 @@

 | Core Principle | Domains that derive from it | Count |
 |----------------|---------------------------|-------|
-| C1 Correctness | All 13 (v0.1: 11; v0.2: infrastructure-as-code, kubernetes) | Universal |
-| C2 Clarity | v0.1: uiux, api, data, testing, observability, errors, documentation, devops; v0.2: infrastructure-as-code, kubernetes | 10 |
-| C3 Simplicity | v0.1: security, data, testing, performance, documentation, concurrency, devops | 7 |
-| C4 Locality | v0.1: testing, concurrency; v0.2: infrastructure-as-code, kubernetes | 4 |
-| C5 Reversibility | v0.1: api, data, uiux, concurrency, devops; v0.2: infrastructure-as-code, kubernetes | 7 |
-| C6 Composability | v0.1: api, security, observability, errors, documentation, concurrency; v0.2: infrastructure-as-code, kubernetes | 8 |
-| C7 Observability | v0.1: api, data, testing, performance, observability, errors, devops; v0.2: infrastructure-as-code, kubernetes | 9 |
-| C8 Economy | v0.1: security, testing, performance, observability, concurrency; v0.2: kubernetes | 6 |
+| C1 Correctness | All 11 (security, data, api, testing, performance, observability, errors, uiux, documentation, concurrency, devops) | Universal |
+| C2 Clarity | uiux, api, data, testing, observability, errors, documentation, devops | 8 |
+| C3 Simplicity | security, data, testing, performance, documentation, concurrency, devops | 7 |
+| C4 Locality | testing, concurrency | 2 |
+| C5 Reversibility | api, data, uiux, concurrency, devops | 5 |
+| C6 Composability | api, security, observability, errors, documentation, concurrency | 6 |
+| C7 Observability | api, data, testing, performance, observability, errors, devops | 7 |
+| C8 Economy | security, testing, performance, observability, concurrency | 5 |

 ## Interpretation

@@ -37,20 +37,10 @@
 | 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 | 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) |
-
-## v0.2 Domain Coverage (per IDEATE-03 schema)
-
-| Domain | P-count | Derived-doc-count | Manifest-listed | Status |
-|--------|---------|-------------------|-----------------|--------|
-| Infrastructure as Code | 10 | 4 (terraform, opentofu, state, modules) | ✓ | complete |
-| Kubernetes | 10 | 6 (workloads, networking, storage, rbac, helm, kustomize) | ✓ | complete |

 ## Gaps and Notes

 - No domain derives from only one C-rule. The minimum is 4 (UI/UX: C1, C2, C3, C5, C7 — actually 5). Every domain is multi-rooted.
- **Concurrency**, **Infrastructure as Code**, and **Kubernetes** are tied for the broadest derivation (7 C-rules each) — these domains touch the most core concerns.
+- **Concurrency** has the broadest derivation (7 C-rules) — it touches the most core concerns.
 - **UI/UX** and **API** are the most user-facing; they emphasize C2 (Clarity) heavily.
- **Security** is the only domain with explicit non-tradeable declarations; this promotes 8 of its rules to C1-equivalent per `core/conflict-resolution.md` §6.
- **v0.2 expansion:** C4 (Locality) grew from 2 to 4 domains (added infrastructure-as-code state locality, kubernetes namespace blast-radius). C6 (Composability) grew from 6 to 8. The two new domains are broad-derivation domains (7 C-rules each), consistent with Concurrency's breadth.
+- **Security** is the only domain with explicit non-tradeable declarations; this promotes 8 of its rules to C1-equivalent per `core/conflict-resolution.md` §6.
@@ -173,40 +173,4 @@ C5=Reversibility · C6=Composability · C7=Observability · C8=Economy
 | P7 Immutability           | C1   | Correctness of deploys               |
 | P8 Security at Every Layer | C1  | Correctness includes security        |
 | P9 Documentation in Pipeline | C2 | Clarity of operations                |
-| P10 Failure as Expected   | C1, C7 | Correctness; observability          |
-
-## Infrastructure as Code
-
-| IaC Principle             | Core | Why                                   |
-|---------------------------|------|---------------------------------------|
-| P1 Declarative Intent     | C2, C3 | Clarity; simplicity of declaration  |
-| P2 Idempotence            | C1   | Correctness of repeated apply        |
-| P3 State is Truth         | C1, C7 | Correctness; observability of reality |
-| P4 Plan Before Apply      | C5   | Reversibility of changes              |
-| P5 Version Everything     | C5   | Reversibility of reproduction         |
-| P6 Modules Compose        | C6   | Composability of infrastructure       |
-| P7 Least Privilege Providers | C1 | Correctness via security            |
-| P8 Remote State with Locking | C1, C4 | Correctness; locality of state   |
-| P9 Drift is Recoverable   | C5, C7 | Reversibility; observability of drift |
-| P10 Secrets Never in Code | C1   | Correctness includes secret safety    |
-
-## Kubernetes
-
-| K8s Principle             | Core | Why                                   |
-|---------------------------|------|---------------------------------------|
-| P1 Declarative Desired State | C1, C2 | Correctness; clarity of intent   |
-| P2 Pods are Mortal        | C5   | Reversibility of workloads            |
-| P3 Labels Select          | C2, C6 | Clarity; composability of selection |
-| P4 Requests and Limits    | C1, C8 | Correctness; economy of resources   |
-| P5 Probes Drive Health    | C1, C7 | Correctness; observability of health |
-| P6 Namespaces Bound Blast | C4   | Locality of blast radius              |
-| P7 RBAC by Intent         | C1   | Correctness via security              |
-| P8 Storage is Explicit    | C4, C5 | Locality; reversibility of data    |
-| P9 Config and Secrets Sep | C2   | Clarity of configuration              |
-| P10 Roll Forward, Roll Back | C5 | Reversibility of deploys            |
-
-## Coverage Summary (post-v0.2)
-
- 13 domains (11 v0.1 + 2 v0.2: infrastructure-as-code, kubernetes)
- 130 domain principles total (110 v0.1 + 20 v0.2)
- Every domain P-rule traces to ≥1 core C-rule (C1–C8). No orphans.
+| P10 Failure as Expected   | C1, C7 | Correctness; observability          |
@@ -125,28 +125,6 @@ If the task touches a domain, run that domain's checklist:
 - [ ] Config is in code, not on the server
 - [ ] Environments are parity (dev = prod modulo data)

-### If Infrastructure as Code (see `domains/infrastructure-as-code/`)
- [ ] Configuration is declarative, not scripted (P1)
- [ ] Provider versions are pinned, never `latest` (P5)
- [ ] State is remote with locking; never committed (P3, P8)
- [ ] `plan` is reviewed before every `apply` (P4)
- [ ] No secrets in HCL; secrets via providers/stores (P10)
- [ ] Modules are versioned; copy-paste replaced by module calls (P6)
- [ ] Drift is treated as an incident, not a shortcut (P9)
- [ ] Provider credentials scoped per environment, least privilege (P7)
-
-### If Kubernetes (see `domains/kubernetes/`)
- [ ] No bare pods; controllers used (P2)
- [ ] Resource requests set on every prod container (P4)
- [ ] Liveness/readiness/startup probes defined (P5)
- [ ] RBAC bound to ServiceAccounts by intent; no `cluster-admin` (P7)
- [ ] No `:latest` image tag in prod (P5 Version Everything)
- [ ] StatefulSet PVCs use `volumeClaimTemplates`; `emptyDir` only for scratch (P8)
- [ ] ConfigMaps and Secrets separate; secrets not in image (P9)
- [ ] Default-deny NetworkPolicy baseline (P6)
- [ ] Rollout history retained; rollback tested (P10)
- [ ] Namespaces used to bound blast radius; not `default` in prod (P6)
-
 ## Final Gate

 - [ ] Have I read the relevant domain's first-principles?
@@ -121,32 +121,6 @@ When you see a pattern listed here, it is a defect. Cite the principle it violat
 | Rebuild per environment | P7 Immutability | Different artifacts |
 | Snowflake server | P1, P6 | Not reproducible |

-### Infrastructure as Code
-| Anti-Pattern | Breaches | Why |
-|--------------|----------|-----|
-| Unpinned provider (`source` without `version`) | P5 Version Everything | Unversioned drift |
-| `terraform apply` without a read `plan` | P4 Plan Before Apply | Unreviewed mutation |
-| Local state in a shared environment | P8 Remote State with Locking | No lock = corruption |
-| Hardcoded secret in HCL | P10 Secrets Never in Code | Committed secret |
-| Copy-pasted block instead of a module | P6 Modules Compose | Bug duplicated |
-| Manual change to a managed resource | P9 Drift is Recoverable | Unreconciled drift |
-| Admin credentials in CI | P7 Least Privilege Providers | Overbroad grant |
-| Committed `terraform.tfstate` | P3 State is Truth, P10 | Secret-bearing artifact in repo |
-
-### Kubernetes
-| Anti-Pattern | Breaches | Why |
-|--------------|----------|-----|
-| Bare pod (no controller) | P2 Pods are Mortal | No recovery/scale |
-| No resource requests in prod | P4 Requests and Limits | BestEffort, first evicted |
-| Liveness probe checks a dependency | P5 Probes Drive Health | Cascade restart |
-| `cluster-admin` bound to a workload | P7 RBAC by Intent | Overbroad grant |
-| `:latest` image tag in prod | P5 Version Everything | Unversioned drift |
-| `emptyDir` for data that must persist | P8 Storage is Explicit | Data lost on pod death |
-| Secrets baked into the image | P9 Config and Secrets Separate | No rotation without rebuild |
-| `default` namespace in prod | P6 Namespaces Bound Blast Radius | No blast boundary |
-| Shared PVC across StatefulSet replicas | P8 Storage is Explicit | Concurrent write corruption |
-| `Delete` reclaim policy on prod storage | P8, P5 Reversibility | PVC delete = data delete |
-
 ## Cross-Cutting Anti-Patterns

 | Anti-Pattern | Breaches | Why |
@@ -155,12 +129,4 @@ When you see a pattern listed here, it is a defect. Cite the principle it violat
 | "It's just a prototype" | C5 (irreversible by default) | Prototypes go to prod |
 | Copy-paste code | C6 (no composition) | Bug duplicated |
 | God object | C3, C6 | One thing, many things |
-| Leaky abstraction | C6, C2 | Hidden coupling |
-
-## v0.2 Chaos Anti-Patterns (from IDEATE-13, IDEATE-14)
-
-| Anti-Pattern | Breaches | Why |
-|--------------|----------|-----|
-| Orphaned P-rule (a domain principle with no matrix row) | matrix completeness, C6 | Breaks the conflict-resolution arbiter; the rule has no core trace |
-| Deployable example artifact (standalone `.tf`/`.yaml` under `examples/`) | PROJECT.md "no runtime code", D-025 | Violates the docs-only contract; examples must be `.md` with fenced code |
-| Unlisted v0.2 doc (new doc not added to MANIFEST) | manifest rule | Not part of the framework by definition |
+| Leaky abstraction | C6, C2 | Hidden coupling |
@@ -59,25 +59,7 @@ A peer review is a second set of eyes on correctness, clarity, and completeness.

 ## Domain-Specific (if applicable)

-Run the relevant domain section from `agent-checklist.md` (UI/UX, API, Security, Data, Testing, Performance, Observability, Errors, Concurrency, DevOps, Infrastructure as Code, Kubernetes). The author ran it; the reviewer verifies.
-
-### If Infrastructure as Code
- [ ] Are providers pinned and modules version-pinned? (no `latest`)
- [ ] Is state remote with locking, not committed?
- [ ] Is the `plan` diff reviewed, not just the config?
- [ ] Are secrets via providers/stores, not in HCL?
- [ ] Are credentials scoped per environment?
- [ ] Is drift being treated as an incident?
-
-### If Kubernetes
- [ ] Are controllers used, not bare pods?
- [ ] Are resource requests set on every prod container?
- [ ] Are probes defined and checking the workload, not its dependencies?
- [ ] Is RBAC least-privilege, bound to ServiceAccounts by intent?
- [ ] Are image tags pinned, not `:latest`?
- [ ] Is persistent storage explicit (PVC + reclaim policy decided)?
- [ ] Are ConfigMaps and Secrets separate?
- [ ] Is the rollback path tested, not assumed?
+Run the relevant domain section from `agent-checklist.md` (UI/UX, API, Security, Data, Testing, Performance, Observability, Errors, Concurrency, DevOps). The author ran it; the reviewer verifies.

 ## Review Etiquette