|
| 1 | +# Bitcode Spec V34 Delta |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +- Version: `V34` |
| 6 | +- V34 state: Gate 1 deployment-roadmap opening is active over promoted V33 canon |
| 7 | +- Current canonical/latest target: `V33` |
| 8 | +- Prior canonical anchor: `BITCODE_SPEC_V33.md` |
| 9 | +- Prior generated proof appendix: `BITCODE_SPEC_V33_PROVEN.md` |
| 10 | +- Generated structured artifact inventory: draft V34 specifying artifacts `.bitcode/v34-spec-family-report.json`, `.bitcode/v34-canonical-input-report.json`, and later deployment-depth artifacts as gates close |
| 11 | +- Source parity state: Gate 1 opens V34 deployment-depth parity; source-side deployment contracts are drafted but not closed until their gates close |
| 12 | +- Spec companion: `BITCODE_SPEC_V34.md` |
| 13 | +- Notes companion: `BITCODE_SPEC_V34_NOTES.md` |
| 14 | +- Parity companion: `BITCODE_SPEC_V34_PARITY_MATRIX.md` |
| 15 | +- Generated proof appendix: `BITCODE_SPEC_V34_PROVEN.md` only after V34 promotion |
| 16 | +- Scope: V34 draft delta for deployment depth over promoted V33 commercial interface canon |
| 17 | + |
| 18 | +## Why V34 exists |
| 19 | + |
| 20 | +V33 promoted commercial interface depth across MCP API, ChatGPT App, public API, package-owned schemas, interface authorization, Read license and AssetPack rights contracts, compatibility matrices, telemetry/proof hooks, consumer UX proof, and promotion readiness. |
| 21 | +That made external interface boundaries source-safe and contract-owned. |
| 22 | + |
| 23 | +V34 exists because those interfaces and the Reading/BTD system must now be operator-deployable with explicit runtime truth. |
| 24 | +Deployment cannot be a dashboard assumption: host capability, environment lane, distributed execution receipts, storage posture, migration approvals, secret rotation, observer/broadcaster/repair jobs, rollback, upgrade, rehearsal, and promotion readiness must be specified and tested as Bitcode protocol reality. |
| 25 | + |
| 26 | +## Accepted V34 decisions |
| 27 | + |
| 28 | +- V33 remains active canon during V34 drafting. |
| 29 | +- V34 gate branches are opened from `version/v34` and merged back only when their gate acceptance criteria are closed. |
| 30 | +- V34 owns deployment-depth: `DeploymentHostCapabilityCatalog`, `EnvironmentLaneContract`, `DistributedExecutionRuntimeReceipt`, `DeploymentStoragePosture`, `MigrationApprovalGate`, `SecretRotationPlan`, `RuntimeObserverRepairJob`, `RollbackUpgradeRepairPlaybook`, `DeploymentReadinessRehearsal`, and `DeploymentPromotionReadinessReport`. |
| 31 | +- V34 deployment contracts must be package-owned before they are exposed by route handlers, workers, MCP tools, ChatGPT App actions, observers, broadcasters, repair jobs, or UI status surfaces. |
| 32 | +- Environment lanes distinguish local, regtest, signet, staging-testnet, public testnet, mainnet-ready dry run, and value-bearing mainnet; value-bearing mainnet remains blocked. |
| 33 | +- Distributed execution receipts are required for long-running Reading pipeline, ledger, wallet, settlement, proof, object-storage, and repair work. |
| 34 | +- Source-bearing AssetPack storage, proof artifacts, audit logs, and rollback material must have explicit storage posture and disclosure policy. |
| 35 | + |
| 36 | +## Explicitly deferred |
| 37 | + |
| 38 | +- V35 owns broad telemetry/documentation programs, dashboards, alert runbooks, public docs breadth, incidents, operator guides, and rollout material beyond V34 deployment contracts. |
| 39 | +- V36 owns deeper Exchange market behavior. |
| 40 | +- V37 owns deeper website Conversations product behavior. |
| 41 | +- Production-mainnet value-bearing launch remains explicitly blocked until a future promoted canon admits it. |
| 42 | +- Bridge chain-of-record implementation remains out of V34. |
| 43 | +- V34 does not reopen BTD supply law, Reading pipeline product law, or V33 interface contract law. |
| 44 | + |
| 45 | +## Pre-Implementation Sequence |
| 46 | + |
| 47 | +1. Open `version/v34` from promoted `main`. |
| 48 | +2. Open `v34/gate-1-deployment-roadmap-opening` from `version/v34`. |
| 49 | +3. Create the V34 SPEC, DELTA, NOTES, and PARITY family while preserving `BITCODE_SPEC.txt -> V33`. |
| 50 | +4. Refresh `SPECIFICATIONS_ROADMAP.md` so V33 is active canon, V34 is draft target, and V35-V37 scopes remain coherent. |
| 51 | +5. Retarget gate-quality and canon-quality workflow posture checks to V33 active / V34 draft. |
| 52 | +6. Add `check:v34-gate1` and a V34 Gate 1 checker. |
| 53 | +7. Define V34 gates, acceptance criteria, carryforward parity rows, and post-V34 roadmap responsibilities. |
| 54 | +8. Validate spec family, canonical inputs, canon posture, workflows, roadmap truth, README/docs, and diff hygiene. |
| 55 | +9. Push the gate branch and open a pull request to `version/v34`. |
| 56 | + |
| 57 | +## Commit-Body Direction |
| 58 | + |
| 59 | +V34 gate commit bodies should describe the closed gate, specification changes, implementation surfaces, tests, proof commands, and accepted boundaries. |
| 60 | +The eventual V34 promotion commit body must name all closed V34 gates, generated deployment proof artifacts, host capability and lane contracts, runtime receipt evidence, storage posture evidence, deployment approval evidence, rehearsal proof, and the `BITCODE_SPEC.txt` pointer change from `V33` to `V34`. |
| 61 | +It must explicitly defer V35 telemetry/documentation breadth, V36 Exchange depth, V37 Conversations depth, bridge chain-of-record implementation, and value-bearing mainnet launch. |
| 62 | + |
| 63 | +## Gate Delta |
| 64 | + |
| 65 | +### Gate 1: V34 Deployment Roadmap And Spec Opening |
| 66 | + |
| 67 | +Gate 1 opens V34 correctly: |
| 68 | + |
| 69 | +- V34 SPEC, DELTA, NOTES, and PARITY files exist. |
| 70 | +- `BITCODE_SPEC.txt` remains `V33`. |
| 71 | +- README, roadmap, PR template, package docs, demonstration docs, and workflows describe V33 active / V34 draft posture. |
| 72 | +- `check:v34-gate1` validates branch naming, spec family, notes, parity, roadmap truth, workflow posture, deployment-depth vocabulary, and promotion boundaries. |
| 73 | +- The V34 gate list is explicit before deployment-depth implementation begins. |
| 74 | + |
| 75 | +### Gate 2: Host Capability And Environment Lane Catalog |
| 76 | + |
| 77 | +Gate 2 inventories deployable runtime truth. |
| 78 | + |
| 79 | +Closure acceptance: |
| 80 | + |
| 81 | +- website, API, MCP API, ChatGPT App, pipeline workers, observers, broadcasters, proof services, repair jobs, object storage, database projection, and ledger projection are enumerated; |
| 82 | +- local, regtest, signet, staging-testnet, public testnet, mainnet-ready dry run, and value-bearing mainnet lanes are represented; |
| 83 | +- value-bearing mainnet is visible as blocked, not hidden confidence; |
| 84 | +- `.bitcode/v34-deployment-host-capability-catalog.json` and `.bitcode/v34-environment-lane-contracts.json` are source-safe generated artifacts. |
| 85 | + |
| 86 | +### Gate 3: Distributed Execution Runtime Contracts |
| 87 | + |
| 88 | +Gate 3 defines `DistributedExecutionRuntimeReceipt`. |
| 89 | + |
| 90 | +Closure acceptance: |
| 91 | + |
| 92 | +- pipeline runs, PTRR agents, ThricifiedGenerations, tool calls, ledger operations, wallet operations, proof generation, object-storage writes, and repair jobs emit typed receipt shapes; |
| 93 | +- long-running work is not required to finish inside a request/response route handler; |
| 94 | +- receipts contain input roots, output roots, log roots, storage roots, ledger/database roots, status, and repair posture without serializing secrets or protected source. |
| 95 | + |
| 96 | +### Gate 4: Ledger Database Object Storage Deployment Posture |
| 97 | + |
| 98 | +Gate 4 defines durable storage posture. |
| 99 | + |
| 100 | +Closure acceptance: |
| 101 | + |
| 102 | +- ledger-derived state, canonical database projections, object storage, proof artifacts, audit logs, rollback material, backups, retention, encryption posture, and repair commands are specified and tested; |
| 103 | +- source-bearing AssetPack storage remains locked before settlement; |
| 104 | +- database and ledger projection drift has a repair posture. |
| 105 | + |
| 106 | +### Gate 5: Secret Rotation And Credential Boundary Operations |
| 107 | + |
| 108 | +Gate 5 defines credential operations. |
| 109 | + |
| 110 | +Closure acceptance: |
| 111 | + |
| 112 | +- OpenAI, Supabase, Vercel, GitHub, wallet, object storage, webhook, MCP, and ChatGPT App secret families are cataloged without tracked values; |
| 113 | +- rotation commands, cadence, CI masking, leak response, and blast-radius notes exist; |
| 114 | +- generated artifacts and logs prove no secret-shaped values are serialized. |
| 115 | + |
| 116 | +### Gate 6: Migration CI/CD Deployment Approval Gates |
| 117 | + |
| 118 | +Gate 6 hardens release automation. |
| 119 | + |
| 120 | +Closure acceptance: |
| 121 | + |
| 122 | +- schema migration approval, generated type refresh, route scans, build/test gates, generated artifact freshness, Vercel/Supabase lane checks, and promotion commits are fail-closed; |
| 123 | +- deployment approvals carry proof roots and reviewer posture; |
| 124 | +- gate-quality and canon-quality workflows remain greenable and promotion workflows remain version-aware. |
| 125 | + |
| 126 | +### Gate 7: Runtime Observers Broadcasters Repair Jobs |
| 127 | + |
| 128 | +Gate 7 makes background deployment work explicit. |
| 129 | + |
| 130 | +Closure acceptance: |
| 131 | + |
| 132 | +- settlement observers, ledger broadcasters, finality watchers, database projection repair jobs, object-storage repair jobs, generated proof jobs, and queue consumers have host capabilities, lane contracts, receipts, and replay commands; |
| 133 | +- observer/broadcaster drift is repairable and blocks unlock when unsafe. |
| 134 | + |
| 135 | +### Gate 8: Rollback Upgrade Data Repair Playbooks |
| 136 | + |
| 137 | +Gate 8 defines operator playbooks. |
| 138 | + |
| 139 | +Closure acceptance: |
| 140 | + |
| 141 | +- rollback, upgrade, migration rollback, object-storage repair, database repair, ledger projection repair, secret rotation incident response, and generated artifact repair playbooks exist; |
| 142 | +- each playbook names entry condition, operator approval, commands, proof roots, verification, and fail-closed result. |
| 143 | + |
| 144 | +### Gate 9: Local Staging Testnet Deployment Rehearsal |
| 145 | + |
| 146 | +Gate 9 proves deployability before promotion. |
| 147 | + |
| 148 | +Closure acceptance: |
| 149 | + |
| 150 | +- local and staging-testnet rehearsals exercise Terminal, public API, MCP API, ChatGPT App contract surfaces, Reading pipeline execution receipts, settlement/finality simulation, storage posture, repair posture, and source-safe logs; |
| 151 | +- screenshots or logs are source-safe and proof-rooted; |
| 152 | +- value-bearing mainnet remains blocked. |
| 153 | + |
| 154 | +### Gate 10: V34 Promotion Readiness |
| 155 | + |
| 156 | +Gate 10 owns final generated proof, promotion workflow support, source-safe `.bitcode/v34-promotion-readiness-report.json`, and V34 closure. |
| 157 | + |
| 158 | +Closure acceptance: |
| 159 | + |
| 160 | +- V34 promotion checks validate all deployment artifacts, host/lane contracts, runtime receipts, storage posture, secret rotation posture, migration approvals, observer/repair jobs, rehearsal proof, and generated proof appendix support; |
| 161 | +- promotion scripts support V34 command planning, dry-run, generated proof output, and derived promotion commit body generation; |
| 162 | +- promotion rewrites runtime posture to active V34 / draft V35 only after validations pass. |
| 163 | + |
| 164 | +## Completion condition |
| 165 | + |
| 166 | +This delta is complete when Gate 1 is merged into `version/v34`, the roadmap and docs are truthful for V33 active / V34 draft posture, and the gate checker prevents V34 from drifting back into V33 interface-depth wording or hidden deployment assumptions. |
0 commit comments