# Certified Builder Bootstrap

Use this contract only when an accepted loop upgrades the same control plane that will later coordinate its implementation. It prevents candidate code from certifying or launching itself.

## Trust Boundary

The accepted stable Dirtyloops release remains the builder until a replacement builder adapter has passed its own gate. Before that gate, mutation is direct in one prepared coordinator-owned worktree. Read-only helpers and independent reviewers may inspect only after they prove the exact root, symbolic branch, and HEAD. The generated `codex-source-builder-closure` identity exists only to validate this pre-bootstrap source control plane.

The bootstrap output is a backward-compatible stable builder patch, not the candidate Program runtime. Keep these identities separate:

- stable builder release and source commit
- builder adapter package and closure hash
- pinned harness and protocol schema hash
- candidate `program-runtime-adapter/1` identity and certificate
- client-facing `dirtyloops-program/1` identity

A builder certificate never grants candidate runtime or client compatibility.

## Bootstrap Gate

Implement the bootstrap as ordered tracer-bullet leaves:

1. Freeze the builder contract, exact harness executable, protocol method subset, configuration, and schema inputs.
2. Build, independently review, and freeze the external verifier, fault fixtures, and certificate schemas before adapter implementation.
3. Build a stable `BuilderOwnership` module that prepares, verifies, and releases attached symbolic-branch worktrees.
4. Implement the minimal adapter against the frozen contract and verifier while the adapter remains unloaded.
5. Independently review the exact adapter branch diff and return defects to their owning leaf.
6. Prove policy, ownership, mutation, cancellation, terminal-result, acknowledgement, and duplicate-delivery behavior.
7. Prove uncertain launch, restart, reconnect, duplicate delivery, orphan, interrupt race, adoption, ambiguity, and reconciliation behavior.
8. Cut and freeze the exact stable builder release, immutable certificate, package, and executable closure.
9. Install that frozen release and activate it from a fresh coordinator process through one live probe and a no-candidate-import canary.

Each leaf has one owner, one declared write and interface surface, one acceptance boundary, and one independent branch-diff review. A failed certificate returns to the leaf that owns the defect. It does not weaken the gate.

## Certificate And Activation Records

When the accepted plan names a builder bootstrap, later mutable owner launch requires two separate schema-valid records:

- immutable `runtime/builder-certificate.json`, which binds:

  - accepted loop and bootstrap issue
  - stable builder release and source commit
  - adapter ID and adapter contract version
  - harness executable hash and version, configuration, stable method subset, and protocol schema hash
  - verifier, fault-fixture, certificate-schema, ownership-helper, package, artifact, and complete executable-closure hashes
  - mutation and recovery certificate IDs and report hashes

- mutable `runtime/builder-activation.json`, which binds:

  - the immutable certificate hash
  - installed package and complete loaded-closure hashes
  - fresh coordinator identity, activation time, successful live probe receipt, and no-candidate-import canary

Create the immutable certificate through a dedicated write-once operation using exclusive creation. An existing certificate is accepted only when it is byte-identical. Generic generation, update, migration, or conversion transactions protect it and cannot rewrite it. Only activation is mutable.

The run must verify the installed closure against both records before each mutable launch. Post-bootstrap verification uses the frozen installed builder manifest and never the moving candidate source closure. Candidate-only edits do not change the frozen identity. Drift in the adapter, ownership helper, verifier, fixtures, schemas, harness executable, configuration, dependencies, package, certificate, or installed closure revokes activation and returns the loop to direct-only mode. A missing, stale, mismatched, same-process, or prose-only record blocks delegated mutation.

## Parallel Work After Activation

After activation, compile each broad Phase into qualified tracer-bullet Beads leaves before dispatch. Before the candidate Program scheduler and Admission engine exist, call a concurrently runnable set a **builder dispatch set**, not a Wave, and use the stable builder's Beads, review, CI, and close gates. Each leaf declares:

- one concrete outcome and acceptance boundary
- dependencies and its proposed Wave
- owned paths and interfaces, including generated-file ownership
- prepared worktree, symbolic branch, base commit, and integration target
- model, effort, speed, authority, tests, and independent review evidence
- one PR-sized internal contribution and the exact branch diff to review

Several disjoint leaves may run in one approved builder dispatch set. Their branches feed one Program integration branch. The stable builder coordinator integrates reviewed contributions in dependency order and runs combined gates until the candidate Integration coordinator and Admission engine are accepted. The Program publishes exactly one external implementation PR unless the accepted plan grants a different sequence. Internal owner branches never require their own GitHub PR.

## Completion Criterion

The bootstrap is complete only when an independent reviewer verifies the exact frozen diff and certificates, a fresh coordinator proves the installed closure through a live probe, Beads records the activation identity, and the first post-bootstrap Wave can be derived without overlapping path or interface ownership.