|
| 1 | +# Bitcode Spec V29 Delta |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +- Version: `V29` |
| 6 | +- V29 state: draft target opened; this delta records V29's planned Terminal-depth changes over promoted V28 |
| 7 | +- Current canonical/latest target: `V28` |
| 8 | +- Prior canonical anchor: `BITCODE_SPEC_V28.md` |
| 9 | +- Prior generated proof appendix: `BITCODE_SPEC_V28_PROVEN.md` |
| 10 | +- Generated structured artifact inventory: draft `.bitcode/v29-spec-family-report.json`, draft `.bitcode/v29-canonical-input-report.json`, future `.bitcode/v29-canon-posture-drift-report.json`, and no `BITCODE_SPEC_V29_PROVEN.md` until promotion |
| 11 | +- Source parity state: V29 delta truth is opened in documentation and gate-quality scripts; product implementation begins only through V29 gate branches |
| 12 | +- State: draft target delta opened |
| 13 | +- Active canonical pointer during draft opening: `BITCODE_SPEC.txt` -> `V28` |
| 14 | +- Scope: V29 delta for deeper Terminal transaction operation after V28 commercial Reading, AssetPack, settlement, delivery, and promotion closure |
| 15 | +- Spec companion: `BITCODE_SPEC_V29.md` |
| 16 | +- Notes companion: `BITCODE_SPEC_V29_NOTES.md` |
| 17 | +- Parity companion: `BITCODE_SPEC_V29_PARITY_MATRIX.md` |
| 18 | +- Generated proof appendix: none until V29 promotion |
| 19 | + |
| 20 | +## Why V29 exists |
| 21 | + |
| 22 | +V28 canonically promoted the first commercial Bitcode Protocol and Terminal MVP: |
| 23 | + |
| 24 | +- Depositing creates source-bound depository evidence. |
| 25 | +- Read Request to Read-Need comprehension is formalized. |
| 26 | +- Finding Fits searches the depository and synthesizes source-safe AssetPack previews. |
| 27 | +- Settlement, read-license/right transfer, and PR delivery are specified and implemented at MVP depth. |
| 28 | +- Gate, branch, commit, CI, and promotion governance are formalized. |
| 29 | + |
| 30 | +V29 exists because the Terminal now needs enterprise operational depth. |
| 31 | +The product must not merely complete the happy path; it must make every transaction state navigable, recoverable, provable, and comprehensible. |
| 32 | + |
| 33 | +## Accepted V29 decisions |
| 34 | + |
| 35 | +- V28 remains active canon during V29 drafting. |
| 36 | +- V29 owns deeper Terminal workflows and transaction operation. |
| 37 | +- V29 gate branches are opened from `version/v29` and merged back only when their gate acceptance criteria are closed. |
| 38 | +- V29 preserves the V28 five-step Reading UX: request Read, review synthesized Need, request Finding Fits, review source-safe AssetPack preview, buy/settle. |
| 39 | +- V29 deepens wallet, signer-session, BTC fee, PSBT, broadcast, replacement, reorg, blocked-readiness, and failure recovery in Terminal. |
| 40 | +- V29 deepens AssetPack range detail, owner-read, licensed-read, denied-state, source-safe preview, paid unlock, and access-policy review. |
| 41 | +- V29 deepens Terminal journal diffing, ledger/database/metaphysical separation, reconciliation repair, and proof-root surfacing. |
| 42 | +- V29 deepens organization holdings, roles, read-license usage, and registry-derived permission decisions. |
| 43 | +- V29 continues formalizing demonstration-origin commercial internals into packages and narrow APIs without importing `protocol-demonstration/` runtime code. |
| 44 | +- V29 workflows and scripts must be retargeted to active V28 and draft V29. |
| 45 | + |
| 46 | +## Explicitly deferred |
| 47 | + |
| 48 | +- Exchange product/market depth remains beyond V29. |
| 49 | +- Website Conversations product depth remains beyond V29. |
| 50 | +- New `$BTD` supply law remains out of scope. |
| 51 | +- Value-bearing mainnet launch remains separately approval-gated. |
| 52 | +- Full provider-family completion remains out of scope unless a Terminal transaction gate requires a narrow hook. |
| 53 | +- V30 remains the home for Protocol/BTD hardening discovered during V28/V29 when the hardening is not required to complete Terminal transaction depth. |
| 54 | +- V31+ scopes remain future unless explicitly reopened by a later spec. |
| 55 | + |
| 56 | +## Pre-Implementation Sequence |
| 57 | + |
| 58 | +1. Open `version/v29` from promoted `main`. |
| 59 | +2. Open `v29/gate-1-objectives-and-gating` from `version/v29`. |
| 60 | +3. Create the V29 SPEC, DELTA, NOTES, and PARITY family while preserving `BITCODE_SPEC.txt -> V28`. |
| 61 | +4. Retarget gate-quality and canon-quality workflow posture checks from V27/V28 to V28/V29. |
| 62 | +5. Add a V29 Gate 1 checker and package script. |
| 63 | +6. Define V29 gates, acceptance criteria, and carryforward parity rows. |
| 64 | +7. Validate spec family, canonical inputs, canon posture, workflows, and diff hygiene. |
| 65 | +8. Push the gate branch and open a pull request to `version/v29`. |
| 66 | + |
| 67 | +## Commit-Body Direction |
| 68 | + |
| 69 | +V29 gate commit bodies should describe the closed gate, the spec-family changes, the implementation surfaces, the validation commands, and any accepted boundaries. |
| 70 | +The eventual V29 promotion commit body must name the Terminal transaction-depth surfaces, list all closed V29 gates, cite generated proof artifacts, state that `BITCODE_SPEC.txt` advances from `V28` to `V29`, and explicitly defer Exchange/Conversations/value-bearing-mainnet work. |
| 71 | + |
| 72 | +## Gate Delta |
| 73 | + |
| 74 | +### Gate 1: V29 Objectives And Gating |
| 75 | + |
| 76 | +Gate 1 opens V29 correctly: |
| 77 | + |
| 78 | +- V29 SPEC, DELTA, NOTES, and PARITY files exist. |
| 79 | +- `BITCODE_SPEC.txt` remains `V28`. |
| 80 | +- README and workflows describe V28 active / V29 draft posture. |
| 81 | +- `check:v29-gate1` validates branch naming, spec family, notes, parity, workflow posture, and promotion boundaries. |
| 82 | +- The V29 gate list is explicit before product implementation begins. |
| 83 | + |
| 84 | +### Gate 2: Terminal Transaction Read Models And Navigation |
| 85 | + |
| 86 | +Gate 2 owns URL-addressable transaction state, Terminal state machine, detail panes, execution-to-transaction read models, low-detail defaults, expandable detail, and no raw-JSON dependency for ordinary operators. |
| 87 | + |
| 88 | +### Gate 3: Wallet Signer Session And BTC Fee Operations |
| 89 | + |
| 90 | +Gate 3 owns wallet connection depth, signer-session recovery, BTC fee quote lifecycle, PSBT handoff, broadcast/finality/replacement/reorg/failure states, blocked-readiness receipts, and no server-custody posture. |
| 91 | + |
| 92 | +### Gate 4: Reading Transaction Recovery And Pipeline Observability |
| 93 | + |
| 94 | +Gate 4 owns deep Terminal visibility over `ReadNeedComprehensionSynthesis` and `ReadFitsFindingSynthesis`, including execution, phase, PTRR agent, PTRR step, ThricifiedGeneration, prompt, tool, output, and typed parse telemetry. |
| 95 | + |
| 96 | +### Gate 5: AssetPack Disclosure Rights And Preview Depth |
| 97 | + |
| 98 | +Gate 5 owns AssetPack range detail, owner-read/licensed-read/denied-state flows, source-safe preview, disclosure policy review, paid unlock state, and protected-source leakage tests. |
| 99 | + |
| 100 | +### Gate 6: Settlement Reconciliation And Repair |
| 101 | + |
| 102 | +Gate 6 owns ledger/database/metaphysical separation, journal diffing, reconciliation repair actions, proof-root surfacing, settlement conservation drift handling, and delivery recovery. |
| 103 | + |
| 104 | +### Gate 7: Organization Permissions And Interface Authority |
| 105 | + |
| 106 | +Gate 7 owns organization holdings, roles, read-license usage, registry-derived permission decisions, MCP/ChatGPT action authority alignment, and Terminal permission explainers. |
| 107 | + |
| 108 | +### Gate 8: Demonstration-Origin Commercial Formalization |
| 109 | + |
| 110 | +Gate 8 owns cleanup of freshly ported demonstration-origin internals into package-native APIs, no demonstration runtime imports, durable package tests, and updated internal/public documentation. |
| 111 | + |
| 112 | +### Gate 9: Terminal UX Quality And Browser Proof |
| 113 | + |
| 114 | +Gate 9 owns accessibility, responsive layout, copy/prose clarity, empty/loading/blocked/failed states, Playwright coverage, and visual/browser verification for the complete Terminal transaction cockpit. |
| 115 | + |
| 116 | +### Gate 10: Local And Staging Promotion Readiness |
| 117 | + |
| 118 | +Gate 10 owns non-mocked local validation, staging-testnet readback, generated proof artifacts, V29 promotion workflow support, promotion dry-run, and final version branch readiness. |
0 commit comments