promote: dev history slice 1 of 4

docs/operations/luna-max-handoff-2026-08-02.md

@@ -0,0 +1,85 @@
+# Luna Max implementation handoff
+
+Observed at (UTC): `2026-08-02T14:16:09Z`
+
+## Repository state
+
+- Canonical repository/worktree: `databreeze-platform/.worktrees/luna-max-orchestration`
+- Branch: `feat/foundation-identity-completion`
+- Upstream: `origin/feat/foundation-identity-completion`
+- Branch base / remote `dev`: `783a4710c0aa2a2808d78ad7f0643e6731150bd7`
+- Remote `main`: `3ed3d77d0281ef239d0509c81ded447d8fffd213`
+- Completed orchestration commit: `62e10cddeda3cd6d49a3c78795a420b7c58331fc`
+- Open feature PR: none
+- Open promotion PR: none
+- CodeRabbit invocation for this batch: `0`
+- Normal batch count before this handoff record: `1` commit and `8` changed files
+
+## Active execution state
+
+- Active batch: `B01 — Foundation verification and identity completion`
+- Next task: `FND-003 — Close local infrastructure gaps`
+- Batch target: 70 atomic commits; allowed range 30–85; repository hard maximum 99
+- Promotion changed-file target: at most 260; review stop gate: 280
+- Requirement ledger remains conservative: 608 `planned`, 3 `partial`, 0 `verified`
+- Verified foundation task evidence: `FND-001`, `FND-002`
+- Integrated but incompletely evidenced foundation work: `FND-003..007`
+
+## Delivered planning outcome
+
+- Added `docs/plans/004-luna-max-execution-plan.md` with 15 dependency-safe delivery batches covering all 153 unfinished orchestration tasks exactly once.
+- Updated the execution ledger to version 2 with the current promotion checkpoint, `activeBatchId`, exact batch dependencies, branch names, commit budgets, changed-file limits, exit gates, and conservative foundation task states.
+- Extended the orchestration checker to reject missing/duplicate task ownership, batch dependency cycles, undersized normal batches, 100-or-more commit maxima, changed-file limits above 260, undocumented batch drift, and an active batch that does not contain the next task.
+- Updated the resume runbook with batch-state recovery, sequential package-manager operation, `EBUSY`/`EEXIST` recovery, and the exact Luna Max bootstrap contract.
+- Corrected the stale plan-package filename in `docs/plans/README.md`.
+
+## Verification evidence
+
+Passed from the isolated worktree after sequential bootstrap:
+
+- `corepack pnpm install --frozen-lockfile`
+- `uv sync --locked --offline` in `services/engine`
+- `corepack pnpm repo:check`
+- `corepack pnpm repo:build`
+- `git diff --check`
+- Orchestration checker: 19 plans, 155 tasks, 15 batches, 611 requirements, next `FND-003`, active `B01`
+- Repository CLI tests: 74 passed
+- Orchestration tests: 13 passed
+- Python engine tests: 92 passed
+- Turborepo tests: 21 successful tasks
+- Turborepo builds: 12 successful tasks
+- TypeScript/Python/Kotlin contract parity: 28 cases
+
+Environment gates intentionally remain open:
+
+- OpenTofu is unavailable on this workstation; static AWS checks pass, but pinned `fmt/init/validate` and reviewed plan evidence remain required.
+- Docker Desktop/Compose v2 was unavailable during the foundation implementation; live health, collision, disk-pressure, Redis persistence, and restart checks remain required for `FND-003`.
+- GitHub protected release-environment reviewers and branch restrictions require administrator evidence.
+- Android instrumentation/emulator and signed packaging remain later release gates.
+
+## Resume instructions
+
+Run sequentially:
+
+```powershell
+git fetch --all --prune
+git switch feat/foundation-identity-completion
+git pull --ff-only origin feat/foundation-identity-completion
+corepack pnpm install --frozen-lockfile
+Push-Location services/engine
+uv sync --locked --offline
+Pop-Location
+corepack pnpm orchestration:check
+corepack pnpm requirements:check
+```
+
+Then read `AGENTS.md`, `docs/plans/002-complete-execution-orchestration.md`, `docs/plans/003-luna-handoff-runbook.md`, `docs/plans/004-luna-max-execution-plan.md`, the Plan 010/020 documents, and the selected trace records. Resume `FND-003` from its live-environment gate; reconcile existing merged behavior before writing replacement code.
+
+Do not open a PR yet. Continue atomic `B01` work on this branch until it reaches at least 30 commits, targeting about 70. The feature PR goes to `dev` without CodeRabbit; the later `dev` to `main` promotion receives the single full CodeRabbit review.
+
+## Rollback and preserved state
+
+- Revert the handoff-record commit to remove only this status record.
+- Revert `62e10cddeda3cd6d49a3c78795a420b7c58331fc` to remove the Luna batch plan, ledger version 2, and its validation changes as one independent unit.
+- No infrastructure was applied, no database was migrated, no customer data was read, and no feature flag changed.
+- Ignored `node_modules`, `.venv`, `dist`, and tool caches are disposable worktree products; tracked files are clean after the containing handoff commit.

docs/plans/000-platform-program.md

@@ -43,6 +43,8 @@ Child plans are written and approved before their product slice begins. Each nam
 
 docs/plans/requirement-traceability.json records all 611 IDs with requested trace fields, one primary plan/task, release status, and verified paths only after evidence exists.
 
+`docs/plans/004-luna-max-execution-plan.md` packages the unfinished orchestration tasks into 15 dependency-safe delivery batches. Normal batches contain 30–99 atomic commits, target about 70, keep promotion diffs at or below 260 changed files, and use the `feat/*` or `fix/*` → `dev` → reviewed `main` flow below.
+
 ## Branch, commit, and review policy
 
 - `main` contains stable releases. `dev` is the integration branch.

docs/plans/002-complete-execution-orchestration.md

@@ -4,7 +4,7 @@
 
 **Goal:** Finish all 611 DataBreeze requirements through dependency-ordered, independently reversible tasks and preserve enough verified state that a new model can resume without guessing.
 
-**Architecture:** The numbered child plans remain the requirement owners. This document adds the execution DAG, atomic task boundaries, parallel-work rules, cross-plan gates, failure handling, and handoff contract that bind those child plans into one program. `execution-orchestration.json` is the machine-readable control record; `requirement-traceability.json` remains the requirement-to-code-and-evidence authority.
+**Architecture:** The numbered child plans remain the requirement owners. This document adds the execution DAG, atomic task boundaries, parallel-work rules, cross-plan gates, failure handling, and handoff contract that bind those child plans into one program. `004-luna-max-execution-plan.md` packages unfinished tasks into reviewable delivery batches, `execution-orchestration.json` is the machine-readable control record, and `requirement-traceability.json` remains the requirement-to-code-and-evidence authority.
 
 **Tech Stack:** pnpm/Turborepo and strict TypeScript, NestJS/Fastify, PostgreSQL 17 with Prisma, Redis 7.4, S3-compatible storage, Electron, Kotlin/Compose, Python 3.13, OpenAPI/JSON Schema, OpenTofu/AWS Singapore, GitHub Actions, and CodeRabbit.
 
@@ -33,8 +33,9 @@ Read sources in this order when they disagree:
 3. Normative requirements under `docs/specs/` and `docs/specs/requirement-index.json`.
 4. Product and architecture documents under `docs/product/` and `docs/architecture/`.
 5. The requirement-owning child plan under `docs/plans/`.
-6. This orchestration plan and `execution-orchestration.json`.
-7. Existing code and historical implementation reports.
+6. This orchestration plan.
+7. `004-luna-max-execution-plan.md` and `execution-orchestration.json`.
+8. Existing code and historical implementation reports.
 
 Code is evidence of work, not evidence of full requirement completion. Use these states consistently:
 
@@ -57,11 +58,15 @@ The ledger also uses these plan/task states; they are not requirement statuses a
 
 Never infer `verified` from a merged PR, a green unit test, file existence, or a previous model's prose.
 
+The numbered child plans own requirement scope and release obligations. Their early generated `Paths` examples are not repository path authority. Section 4 of this document supersedes generic aggregate names such as `identity-audit-entitlements`, `production-readiness`, or hyphenated Python processor directories; use the module-owned roots and deterministic platform keys below.
+
 ## 2. Recorded checkpoint
 
-This plan was prepared on 2026-08-02 from remote `dev` at `b21642b` and remote `main` at `8ac8bca`; promotion PR 8 had merged and no PR was open. The requirement manifest contained 611 records: 444 P0, 154 P1, 13 P2; 608 were `planned` and 3 were `partial`.
+This plan was reconciled on 2026-08-02 from remote `dev` at `783a4710c0aa2a2808d78ad7f0643e6731150bd7` and remote `main` at `3ed3d77d0281ef239d0509c81ded447d8fffd213`; promotion PR 20 had merged and no PR was open. The requirement manifest contained 611 records: 444 P0, 154 P1, 13 P2; 608 were `planned` and 3 were `partial`.
+
+Merged PRs 1–23 establish substantial engineering, IAM/AUD/BUA, IAE/DSM, JRA, and DSO code. PR 19 delivered the normal 73-commit foundation batch to `dev`; PR 20 promoted it to `main`; PRs 21–23 carried validated promotion-review fixes back through `dev`. Plans 010–050 must therefore start with evidence reconciliation, not blind reimplementation. Plans 060–500 remain unverified and must be treated as planned until their gates pass.
 
-Merged PRs 1–8 establish substantial engineering, IAM/AUD/BUA, IAE/DSM, JRA, and DSO code. Plans 010–050 must therefore start with evidence reconciliation, not blind reimplementation. Plans 060–500 remain unverified and must be treated as planned until their gates pass.
+The active execution packet is `B01` in `004-luna-max-execution-plan.md`, starting with `FND-003` on `feat/foundation-identity-completion`. The packet preserves the requested 30–99 commit rule, targets about 70 commits, and carries the implementation forward without opening a documentation-only PR.
 
 The hashes above are an audit anchor, not a branch lock. Every session must fetch and recompute live state; update the ledger checkpoint only as part of a committed task/PR handoff so session-local observations do not create meaningless dirty files.
 

docs/plans/003-luna-handoff-runbook.md

@@ -5,7 +5,7 @@ Use this runbook to resume DataBreeze after a model, machine, branch, or hosted-
 ## Start-of-session algorithm
 
 1. Locate the canonical `databreeze-platform` repository; do not implement in the legacy `Databreeze` directory.
-2. Read repository `AGENTS.md` files, `docs/plans/README.md`, `002-complete-execution-orchestration.md`, `execution-orchestration.json`, the selected child plan, and the requirement records it owns.
+2. Read repository `AGENTS.md` files, `docs/plans/README.md`, `002-complete-execution-orchestration.md`, `004-luna-max-execution-plan.md`, `execution-orchestration.json`, the selected child plan, and the requirement records it owns.
 3. Fetch before trusting any recorded hash:
 
    ```powershell
@@ -38,8 +38,9 @@ Use this runbook to resume DataBreeze after a model, machine, branch, or hosted-
    ```
 
    If the offline Python cache is unavailable, use the documented online locked sync; do not alter the lock merely to make bootstrap pass.
-8. Select `nextTaskId` only if every dependency is verified and no open PR or dirty worktree already owns it. Otherwise follow the table below and record the corrected next task.
-9. State the selected task, assumptions, entry gate, expected files, tests, and stop conditions before mutation. If delegation is explicitly authorized, assign only disjoint paths with explicit integration ownership.
+8. Select `activeBatchId` and `nextTaskId` only if every dependency is verified and no open PR or dirty worktree already owns them. Verify that the active batch contains the next task and that its current commit/file budgets remain safe. Otherwise follow the table below and record the corrected batch and task.
+9. State the selected batch/task, assumptions, entry gate, expected files, tests, commit/file budget, and stop conditions before mutation. If delegation is explicitly authorized, assign only disjoint paths with explicit integration ownership.
+10. Run package-manager operations sequentially within a worktree. Never start concurrent `pnpm install`, check, test, or build commands that share the same `node_modules` tree.
 
 ## Resume-state decision table
 
@@ -57,6 +58,7 @@ Use this runbook to resume DataBreeze after a model, machine, branch, or hosted-
 | Dependency is only `implemented`, not `verified` | Finish its tests/evidence/review gate before the dependent task | Treating merged code as a verified dependency |
 | Baseline fails before task edits | Diagnose and document whether environment or repository caused it; repair in a `fix/*` unit or stop if unsafe | Attributing the failure to the new task or weakening the gate |
 | Migration/schema or generated-contract drift exists | Reconcile canonical sources, regeneration, migrations, and compatibility before feature work | Editing generated clients or database state manually |
+| Package installation/check reports `EBUSY` or `EEXIST` in `node_modules/.pnpm` | Another package-manager process used the same worktree or a previous one was interrupted | Stop concurrent package-manager processes, preserve tracked files, rerun one frozen install sequentially, then rerun the failed gate; never delete tracked files or alter the lock to bypass it |
 | Required production/signing/business credential is unavailable | Complete all credential-independent code/tests/runbooks and stop at the explicit external gate | Using personal/untracked credentials or claiming release readiness |
 
 ## Atomic task execution loop
@@ -89,7 +91,8 @@ For each `#### TASK-ID —` item in `002-complete-execution-orchestration.md`:
 
 10. Inspect generated/runtime debris before commit. Do not commit `.venv`, `node_modules`, Gradle state, build output, logs, caches, secrets, local databases, Terraform state, or test reports unless the repository explicitly tracks a sanitized fixture.
 11. Commit one independently reversible outcome with a semantic message. Do not combine contracts, an unrelated fix, and a different feature just to increase commit count.
-12. Push after each stable task boundary. Update the ledger/checkpoint only with verified facts and leave a handoff record if stopping.
+12. Recount the active batch against its base. Do not open a normal PR below 30 commits; target about 70, stop accepting new tasks at 90, and never exceed 99. Split before the promotion diff reaches 280 changed files; the packet target is 260.
+13. Push after each stable task boundary. Update the ledger/checkpoint only with verified facts and leave a handoff record if stopping.
 
 ## Pull-request and CodeRabbit protocol
 
@@ -145,6 +148,7 @@ Remote dev / main:
 Open feature PR / promotion PR:
 CodeRabbit invocation count, invocation timestamp (UTC), and review URL:
 Active plan / task ID:
+Active delivery batch / commit count / changed-file count:
 Requirement IDs and statuses changed:
 Completed commits (hash — outcome):
 Checks run and exact results:
@@ -165,11 +169,11 @@ The record supplements Git; it cannot claim `verified` without traceable test/re
 Copy this into the first Luna session and replace only the bracketed values discovered from live Git:
 
 ```text
-You are resuming DataBreeze in the canonical databreeze-platform repository. Do not trust chat checkpoints until you fetch and verify Git/PR state. Read every applicable AGENTS.md plus docs/plans/README.md, docs/plans/002-complete-execution-orchestration.md, docs/plans/003-luna-handoff-runbook.md, docs/plans/execution-orchestration.json, the selected child plan, and its requirement-traceability records.
+You are resuming DataBreeze in the canonical databreeze-platform repository. Do not trust chat checkpoints until you fetch and verify Git/PR state. Read every applicable AGENTS.md plus docs/plans/README.md, docs/plans/002-complete-execution-orchestration.md, docs/plans/003-luna-handoff-runbook.md, docs/plans/004-luna-max-execution-plan.md, docs/plans/execution-orchestration.json, the selected child plan, and its requirement-traceability records.
 
 Live verified checkpoint: branch [BRANCH], HEAD [HEAD], origin/dev [DEV], origin/main [MAIN], open feature PR [FEATURE_PR_OR_NONE], open dev→main promotion PR [PROMOTION_PR_OR_NONE]. Run the orchestration checker and the documented clean baseline before edits. Preserve all user changes and use an ignored worktree if isolation is needed.
 
-Resume task [TASK_ID] only after proving its dependency/entry gate. Follow test-first atomic delivery: canonical contracts when the interface changes, failing domain/state tests, PostgreSQL migration/tenant/transaction/outbox tests when durable state changes, implementation through ports, vertical client/adapter coverage when the task involves client behavior, safe telemetry/recovery, traceability evidence, scoped checks, repo:check, repo:build, diff review, and one reversible commit. For documentation-only or other non-durable/non-client tasks, record why those conditional tests do not apply. Do not mark merged code verified without all evidence.
+Resume batch [BATCH_ID] and task [TASK_ID] only after proving their dependency/entry gates, branch ownership, and commit/file budgets. Follow test-first atomic delivery: canonical contracts when the interface changes, failing domain/state tests, PostgreSQL migration/tenant/transaction/outbox tests when durable state changes, implementation through ports, vertical client/adapter coverage when the task involves client behavior, safe telemetry/recovery, traceability evidence, scoped checks, repo:check, repo:build, diff review, and one reversible commit. For documentation-only or other non-durable/non-client tasks, record why those conditional tests do not apply. Do not mark merged code verified without all evidence. Run pnpm installation/check/test/build commands sequentially within one worktree.
 
 Git flow is fixed: feat/* or fix/* → PR to dev with hosted checks and no CodeRabbit; merge preserving atomic commits; immediately open dev→main; request exactly one CodeRabbit full review there; reproduce every comment, fix only valid findings, document rejected ones, never request a second review on that PR. Prefer 30–70 commits, hard cap 99, and do not invoke the promotion review over 280 changed files.