feat(positioning): production-systems program, alpha to omega

.codex/plans/2026-08-09-production-systems-program.md

@@ -0,0 +1,85 @@
+# Production-Systems Program — implementation plan
+
+Date: 2026-08-09
+
+Owner: Anthony
+
+Implementation owner: cross-agent Limen conduct graph
+
+Canonical graph: `institutio/positioning/program.yaml`
+
+## Objective
+
+Turn the owner’s demonstrated ability to build systems that build products into an evidence-backed
+production-systems identity, a proof-led public front door, a bounded commercial offer, a qualified
+inbound and delivery system, and ultimately a governed product-to-operator handoff loop. Preserve
+valid live-profile evidence while correcting stale research, unsupported implications, and unclear
+prominence decisions.
+
+## Implementation shape
+
+The program is represented once in the tracked manifest and projected idempotently into GitHub as:
+
+- one root issue;
+- fifteen phase issues, P00 through P14;
+- 111 atomic work issues with explicit dependencies, repository/path scope, capabilities, dynamic
+  reasoning class, effect boundary, human gates, deliverables, acceptance, executable receipt
+  predicate, return evidence, and rollback path;
+- one milestone and three dedicated labels;
+- one deterministic issue-number map and generated human-readable index;
+- thirteen validated execution chunks with assigned conductor models and copy/paste relay prompts.
+
+The GitHub graph is a coordination projection, not a lease. Every mutation leaf is claimed by a
+registered native lane through the conduct broker. Under the owner’s 2026-08-09 override, every
+root/phase/leaf has an exact model and effort assignment validated against the live Codex catalog.
+An unavailable assignment fails blocked and requires reviewed reassignment; there is no silent
+fallback table.
+
+## Sequence
+
+1. P00 establishes the program control plane, validates it, projects GitHub issues, and proves one
+   non-Codex broker canary.
+2. P01 repairs the wall-clock-sensitive CI test and lands the existing truth/custody foundations in
+   PRs 2136 and 2141.
+3. P02 inventories the complete live estate, creates evidence packets, audits LAVREA percentile
+   inference, and adjudicates stale research claim by claim.
+4. P03–P04 settle the production-systems identity and bounded offers.
+5. P05–P06 produce flagship proof and design progressive disclosure while P11 builds the secure
+   delivery operating system on its own parallel branch.
+6. P07–P09 build and verify public surfaces, create safe capture, and stage or owner-publish
+   proof-led material only through named gates.
+7. P10-W01 through W07 build conversion before the pilot. P12-W01 and W02 then unlock P10-W08 while
+   the remaining P12 evidence work proceeds; P10 and P12 close together without a phase deadlock.
+8. P13 inventories product candidates and pilots a legally and operationally bounded domain-operator
+   handoff or records an evidence-backed no-go.
+9. P14 returns every result to the claims and decision systems, proves rollback, and requires two
+   unchanged Omega passes before the root closes.
+
+## Completion contract
+
+Each leaf first meets its human-readable acceptance condition. The executor then runs a
+task-specific, non-circular command and posts a marked structured receipt to the leaf issue. The
+leaf’s executable predicate, `python3 scripts/positioning-program.py --verify-work <WORK-ID>`, fails
+unless that receipt is current, successful, authorized, exact-head-bound, evidence-linked, and
+rollback-aware. Phase and root closure require their complete child set; Omega additionally
+revalidates every leaf receipt and two unchanged whole-program state digests.
+
+## Current publication transaction
+
+1. Validate the local graph, generated payload sizes, receipt contract, and scoped repository gates.
+2. Commit and push the isolated `codex/production-systems-program` branch.
+3. Open a draft pull request before remote issue creation so the implementation has a durable code
+   owner.
+4. Apply the idempotent GitHub projection and write all resulting issue identities back to the
+   tracked map and index.
+5. Verify exact remote parity, commit the back-links, push the updated branch, and cross-link the
+   root issue and draft pull request.
+6. Begin execution at the sole ready leaf; do not bypass phase or work dependencies.
+
+## Recovery
+
+The projection never closes or reopens issues, merges, sends, publishes, spends, changes DNS, signs,
+or edits `tasks.yaml`. A failed projection reruns safely from stable markers. A manifest change
+invalidates stale acceptance receipts by digest. A bad public claim is quarantined at the claims
+ledger; a bad release returns to the last known-green release; a failed offer or handoff returns its
+outcome to the appropriate decision ledger before any narrative revision.