feat: add transactional recipe founder path

CHANGELOG.md

@@ -35,15 +35,48 @@ All notable changes follow Keep a Changelog and Semantic Versioning.
   freezing, and strict provider-event settlement.
 - A source-qualified Node.js 24, Next.js 16, and React 19.2 web-recipe decision
   for the Wave 4B greenfield path.
+- One exact bundled Node.js 24.18.1, npm 11.16.0, Next.js 16.3.4, React 19.2.8,
+  and Playwright 1.62.1 web recipe with native format, lint, type, unit,
+  integration, browser, build, package, and CI gates.
+- Deterministic separately approved greenfield and compatible-adoption plans,
+  transactional apply, generated-file ownership in `mill.lock`, manual detach
+  planning, and isolated adoption branches.
+- Attended lock/image-bound dependency preparation plus `run next`, resumable
+  `start`, and two-step `ship --draft` founder commands over existing lifecycle
+  authority.
 
 ### Changed
 
 - Dependabot preserves the qualified Node type and TypeScript major boundaries;
   incompatible major upgrades require an intentional toolchain qualification.
 - Executable JSON Schemas are generated from runtime contract inputs and checked
   for exact drift in the native gate.
+- Repository apply now uses target-scoped exclusion, no-replace reservation, and
+  final atomic Git-authority publication; dependency snapshots bind npm/registry
+  identity, validate lock origins and installed-tree content, stop and clean up
+  on cancellation, and founder start binds the selected PRD before spend.
 - New baseline qualifications and runs require task-packet version 2 with exact
   continuity authority; version 1 remains byte-stable for in-flight resume.
+- OCI command scratch is explicit and limited to comma-free top-level tmpfs
+  directories; dependency inputs remain exact-lock-bound and read-only.
+- Repository plans use one non-self-referential approval identity recorded in
+  the returned plan and `mill.lock`; founder resume selects preflight and
+  dependency work from the persisted lifecycle stage.
+- Recipe tasks require named behavior-specific oracles; integration plans bind
+  the generator version and canonical target, adoption binds exact lock/oracle
+  bytes, and dependency snapshots derive identity from frozen lock copies.
+- Canonical target identity is digest-bound, final greenfield publication never
+  replaces a late-created target, adoption blocks symbolic links and
+  credential-like files, and integration writes reject unsafe ancestors.
+- Generated impact and task risk now follows affected invariant criticality,
+  medium/high risk requires non-normal scenario evidence, and active-run
+  admission is serialized with run creation.
+- Founder resume preflights exact remote-review and interrupted recovery before
+  spending its bounded repair, and integration approvals must be active ISO
+  timestamps.
+- Recipe integration rejects cross-outcome scenarios, duplicate acceptance
+  references, unprovable invariant modes, builder-writable PRDs, `.npmrc`, and
+  non-root or credential/query-bearing npm lock-source bypasses.
 
 ### Deprecated
 
@@ -55,6 +88,8 @@ All notable changes follow Keep a Changelog and Semantic Versioning.
 
 ### Fixed
 
+- Complete SHA-512 integrity parsing and CommonMark punctuation escaping close
+  truncated-integrity and product-title interpretation gaps.
 - Exact-version recovery, DCO parsing, per-job workflow bounds, JSON usage
   errors, malformed-contract classification, operator-tool discovery, Node
   readiness, valid `..name` paths, Git-root lock authority, JSON help isolation,
@@ -105,6 +140,10 @@ All notable changes follow Keep a Changelog and Semantic Versioning.
   expired effect authority cannot strand readback or truthful closure.
 - Worker exit evidence and active-process clearing now commit atomically, so a
   controller crash after process exit leaves a safely reconcilable invocation.
+- Recipe verification uses a read-only workspace skeleton with individually
+  bound source entries, bounded writable scratch and browser shared memory,
+  delayed-mount cleanup handling, and fail-closed occupied or unrepresentable
+  mount targets.
 
 ### Security
 

README.md

@@ -14,10 +14,13 @@ published eventually as `@davidahmann/mill` to avoid collision with the existing
 
 Wave 4A adds source-backed planning contracts, stable product invariants,
 approved per-slice impact, scenario-specific semantic evidence, and durable
-worker admission. Its planning commands are deliberately read-only: today an
-operator supplies the structured proposal, while Wave 4B will coordinate the
-qualified planner and transactionally apply the first Node.js 24/Next.js 16 web
-recipe.
+worker admission. Wave 4B adds one exact Node.js 24/Next.js 16 web recipe,
+transactional greenfield and compatible-adoption integration, lock-bound
+dependency preparation, offline read-only recipe verification, manual detach
+planning, and resumable founder commands. Planning remains deliberately honest:
+in this pre-alpha, an operator supplies the structured proposal that Mill
+assesses and freezes; live autonomous research and proposal generation are not
+implemented.
 
 Mill's v1 boundary is deliberately narrow:
 
@@ -44,6 +47,84 @@ node dist/cli.js inspect --prd product/PRD.md
 node dist/cli.js adopt --scan-only
 ```
 
+## Onboard one supported repository
+
+The first supported recipe is exact: Node.js 24.18.1, npm 11.16.0, Next.js
+16.3.4, React 19.2.8, TypeScript 6.0.3, and Playwright 1.62.1 in a digest-pinned
+OCI image. Mill itself uses Node.js 24.20.0; the recipe patches follow the
+contents of its verifier image.
+
+First run the read-only specification assessment and copy its exact approval
+digest. Then preview a greenfield or adoption plan. Apply is a second explicit,
+attended operation bound to that exact plan:
+
+```sh
+node dist/cli.js --json plan specification \
+  --prd product/PRD.md --sources product/sources.yaml \
+  --proposal product/proposal.yaml
+
+node dist/cli.js --json new my-product --dry-run \
+  --prd product/PRD.md --sources product/sources.yaml \
+  --proposal product/proposal.yaml --approve-product sha256:<product> \
+  --repository-id <uuid> --approved-by <identity> --approved-at <iso-time> \
+  --author-name <name> --author-email <email>
+
+node dist/cli.js --json new my-product --apply --attended \
+  --prd product/PRD.md --sources product/sources.yaml \
+  --proposal product/proposal.yaml --approve-product sha256:<product> \
+  --approve-plan sha256:<integration-plan> --repository-id <uuid> \
+  --approved-by <identity> --approved-at <iso-time> \
+  --author-name <name> --author-email <email>
+```
+
+For an existing compatible repository, use `adopt --plan` and then
+`adopt --apply --attended` with the same authority fields. Adoption supports
+only the exact recipe-compatible Next.js tuple, blocks conflicting repository
+truth, a missing or drifted recipe-native oracle closure, or unsafe Git state.
+The adoption boundary compares the exact qualified dependency lock, runtime,
+native scripts, and oracle bytes; existence alone is never compatibility. It
+creates an isolated branch and leaves the operator checkout unchanged; arbitrary
+existing test graphs are not inferred. Adoption also blocks symbolic links and
+credential-like files, including `.npmrc`, rather than allowing generated writes
+or builder context to follow them. The approved PRD must remain outside the
+generated `app`, `public`, and `src` builder scopes. Greenfield apply stages the
+complete target and, only after qualification succeeds, reserves the absent path
+without replacement. It copies non-authoritative files first and atomically
+installs the complete `.git` directory last; the target is not a repository
+before that final boundary. The integration approval digest is a
+non-self-referential identity over the approved target, including its
+canonical-path digest, product, recipe, policy, and every non-lock file action.
+`mill.lock` is deterministically derived from and records that same digest. An
+approved blueprint selecting any other recipe, version, or runtime blocks. The
+plan also exposes and binds the exact Mill generator package/version. Greenfield
+paths are canonicalized beneath the selected root, and any symbolic link or
+non-directory ancestor blocks before staging or registry access. Approval
+timestamps must be exact ISO datetimes that are already active, never
+future-dated declarations.
+
+Dependency installation is a distinct attended step with disclosed npm-registry
+network and disabled lifecycle scripts. The config declares npm and the exact
+`https://registry.npmjs.org` origin; preparation rejects resolved lock entries
+outside that HTTPS origin, credential-bearing or query-bearing URLs, entries
+without a complete SHA-512 source identity, and unsupported links/workspaces.
+The root `package-lock.json` consumed by `npm ci` must be included and is always
+the lock graph validated, regardless of other bound locks. Mill copies lock
+inputs first, keys and validates the frozen copies, and rechecks them after
+installation before atomic publication. Its marker binds and revalidates the
+installed dependency-tree bytes and filesystem shape before reuse and
+verification. Cancellation stops the installer process group and completes
+container cleanup. Preparation requires both attendance and build trust at the
+exported runtime boundary. Later verification has no network and never writes
+source:
+
+```sh
+node dist/cli.js --json dependencies prepare --attended
+node dist/cli.js --json detach plan
+```
+
+`detach plan` reports Mill-only files to remove and downstream-owned files to
+retain or review. It does not mutate the repository.
+
 ## Run one attended local task
 
 A build-enabled downstream repository supplies `mill.yaml`, a task packet, and
@@ -76,6 +157,34 @@ node dist/cli.js --json review --task product/tasks/TASK.yaml --run <run-id>
 node dist/cli.js --json status --run <run-id>
 ```
 
+A managed repository may instead select exactly one ready outcome and use the
+founder wrappers:
+
+```sh
+node dist/cli.js --json qualify --baseline \
+  --task product/tasks/<outcome>.yaml
+node dist/cli.js --json run next --approve sha256:<baseline> --attended
+node dist/cli.js --json start --prd product/PRD.md --attended
+node dist/cli.js --json ship --draft \
+  --task product/tasks/<outcome>.yaml --run <run-id>
+# Inspect the returned proposal, then:
+node dist/cli.js --json ship --draft \
+  --task product/tasks/<outcome>.yaml --run <run-id> \
+  --approve sha256:<delivery-plan> --attended
+```
+
+`start` proves the selected PRD and task authority before registry or model
+spend, including identical product-plan, product-contract, impact, and
+acceptance sets. It inventories every nonterminal run, even when a newer run is
+already terminal, then resumes the sole matching durable lifecycle. New-run
+admission repeats that check under the writer lease that creates the run.
+`run next` applies the same authority comparison before it can create a run.
+With `--draft-pr`, `start` prepares and returns the exact draft-PR plan digest;
+`ship --draft --approve` remains the separate attended mutation. A later `start`
+can resume remote readback and closure without requiring Codex or repeating
+dependency preparation. It still cannot mark ready, merge, or deploy. The expert
+lifecycle commands remain available for inspection and recovery.
+
 `run` creates the candidate on a Mill-owned branch in a disposable worktree; it
 does not modify the operator checkout. `resume` reconciles an interrupted
 controller only when no recorded execution can still be active, or performs the
@@ -193,10 +302,11 @@ excluded material untracked and outside the repository.
 
 Not published. Local attended delivery and the bounded draft-PR lifecycle are
 implemented, and the first disposable real-Codex/GitHub canary was human-merged,
-verified on resulting main, and truthfully finalized. Product-continuity and
-worker-admission contracts are implemented. Transactional recipe application,
-retrofit, the founder `start` coordinator, stronger hostile-host containment,
-genesis release, and generalized stack-compatibility claims remain pending their
+verified on resulting main, and truthfully finalized. Product continuity, worker
+admission, transactional application of one exact web recipe, compatible
+adoption, and the resumable founder path are implemented. Autonomous planning,
+stronger hostile-host worker containment, longitudinal qualification, genesis
+release, and generalized stack-compatibility claims remain pending their
 explicit gates.
 
 ## License

WORKFLOW.md

@@ -9,7 +9,8 @@ bookkeeping, closure, tests, or docs into micro-PRs.
 3. Exact commit to draft PR, reconciliation, and closure.
 4. Product continuity, one greenfield web recipe, retrofit, and founder golden
    path. Wave 4A establishes the read-only contracts and durable worker
-   boundary; Wave 4B applies them transactionally.
+   boundary; Wave 4B applies them transactionally through exact product and
+   integration approvals.
 5. Audits, clean-room qualification, genesis distribution, and public alpha.
 
 For each wave:
@@ -36,6 +37,30 @@ it does not prevent readback or closure of an effect already attempted. A
 current candidate may add future oracles, but those changed oracles do not
 independently certify that same candidate.
 
-Current Factory skills are optional maintainer-side bootstrap tools. Their
-prompts, profiles, artifacts, or state are not Mill runtime or product
-dependencies. Native repository commands remain sufficient and authoritative.
+Factory skills may be used externally as optional maintainer-side delivery
+tools, but Mill does not track a Factory profile, verifier, pack, or runtime
+dependency. Mill's native repository commands, Git workflow, and GitHub checks
+remain sufficient and authoritative for development and shipping.
+
+For greenfield or adoption onboarding, first assess and explicitly approve the
+source-backed product proposal, then inspect and separately approve the exact
+repository integration plan. Greenfield apply publishes no target until the
+recipe's full native gate passes. Adoption apply writes one isolated branch and
+does not alter the operator checkout. Registry access is a separate attended
+dependency-preparation effect; later candidate verification has no network and
+mounts source read-only.
+
+A recipe-generated task may cite command evidence only through a named oracle
+declared by that exact recipe and selected by the approved scenario. The oracle
+binds its delivered behavior and evidence paths. Greenfield path ancestors,
+adoption lock/oracle bytes, the generator version, trust mode, and attendance
+are revalidated at the exported apply/effect boundary rather than trusted from
+the CLI wrapper.
+
+After onboarding, `run next` selects exactly one ready approved outcome. `start`
+may resume that outcome through the existing run, verify, review, delivery
+observation, and closure states. `ship --draft` remains a wrapper over the same
+exact proposal-digest and attended GitHub effect boundary. Wrappers do not mark
+a draft ready, merge, deploy, or create a second lifecycle. Selection compares
+the plan, product contract, impact, acceptance IDs, and task exactly and scans
+all nonterminal runs, not only the newest record, before any spend.