diff --git a/.github/workflows/bitcode-canon-quality.yml b/.github/workflows/bitcode-canon-quality.yml index f813c6574..9001f8263 100644 --- a/.github/workflows/bitcode-canon-quality.yml +++ b/.github/workflows/bitcode-canon-quality.yml @@ -414,9 +414,15 @@ jobs: node scripts/check-bitcode-canonical-inputs.mjs --current-target V45 node scripts/check-bitcode-canon-posture-drift.mjs --active-canon V45 --draft-target V46 node scripts/check-v45-gate18-promotion-readiness.mjs --promotion-mode --skip-branch-check --skip-package-tests - if [ -f scripts/check-v45-gate19-promotion-addendum.mjs ]; then + if [ ! -f BITCODE_SPEC_V46.md ] && [ -f scripts/check-v45-gate19-promotion-addendum.mjs ]; then node scripts/check-v45-gate19-promotion-addendum.mjs --skip-branch-check --skip-package-tests fi + if [ -f BITCODE_SPEC_V46.md ]; then + node scripts/check-bitcode-spec-family.mjs --version V46 --mode draft --current-target V45 + if [ -f scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs ]; then + node scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs --skip-branch-check + fi + fi else echo "Unexpected BITCODE_SPEC.txt pointer: $POINTER" >&2 exit 1 diff --git a/.github/workflows/bitcode-gate-quality.yml b/.github/workflows/bitcode-gate-quality.yml index 1045478e1..c7a94cfe8 100644 --- a/.github/workflows/bitcode-gate-quality.yml +++ b/.github/workflows/bitcode-gate-quality.yml @@ -543,9 +543,15 @@ jobs: node scripts/check-bitcode-canonical-inputs.mjs --current-target V45 node scripts/check-bitcode-canon-posture-drift.mjs --active-canon V45 --draft-target V46 node scripts/check-v45-gate18-promotion-readiness.mjs --promotion-mode --skip-branch-check --skip-package-tests - if [ -f scripts/check-v45-gate19-promotion-addendum.mjs ]; then + if [ ! -f BITCODE_SPEC_V46.md ] && [ -f scripts/check-v45-gate19-promotion-addendum.mjs ]; then node scripts/check-v45-gate19-promotion-addendum.mjs --skip-branch-check --skip-package-tests fi + if [ -f BITCODE_SPEC_V46.md ]; then + node scripts/check-bitcode-spec-family.mjs --version V46 --mode draft --current-target V45 + if [ -f scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs ]; then + node scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs --skip-branch-check + fi + fi else echo "Unexpected BITCODE_SPEC.txt pointer: $POINTER" >&2 exit 1 @@ -580,9 +586,12 @@ jobs: node scripts/check-v44-gate10-promotion-readiness.mjs --promotion-mode --skip-branch-check else node scripts/check-v45-gate18-promotion-readiness.mjs --promotion-mode --skip-branch-check --skip-package-tests - if [ -f scripts/check-v45-gate19-promotion-addendum.mjs ]; then + if [ ! -f BITCODE_SPEC_V46.md ] && [ -f scripts/check-v45-gate19-promotion-addendum.mjs ]; then node scripts/check-v45-gate19-promotion-addendum.mjs --skip-branch-check --skip-package-tests fi + if [ -f BITCODE_SPEC_V46.md ] && [ -f scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs ]; then + node scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs --skip-branch-check + fi fi if [ "$POINTER" = "V43" ] && [ -f scripts/check-v44-gate1-scaled-economy-roadmap-opening.mjs ]; then node scripts/check-v44-gate1-scaled-economy-roadmap-opening.mjs --skip-branch-check diff --git a/BITCODE_SPEC_V46.md b/BITCODE_SPEC_V46.md new file mode 100644 index 000000000..879cb4a2d --- /dev/null +++ b/BITCODE_SPEC_V46.md @@ -0,0 +1,900 @@ +# Bitcode Spec V46 + +## Status + +- Version: `V46` +- V46 state: draft opening; V46 is the active draft target over promoted V45 canon +- Current canonical/latest target: `V45` +- Draft proof-source commit: not generated +- Prior canonical anchor: `BITCODE_SPEC_V45.md` +- Prior generated proof appendix: `BITCODE_SPEC_V45_PROVEN.md` +- Generated structured artifact inventory: draft `.bitcode/v46-spec-family-report.json` and `.bitcode/v46-canonical-input-report.json`; later V46 gates must add proof, rehearsal, workflow, and promotion artifacts only after their scope is accepted +- Source parity state: V46 source parity is not audited yet; Gate 1 opens the draft-target roadmap only +- Notes companion: `BITCODE_SPEC_V46_NOTES.md` +- Delta companion: `BITCODE_SPEC_V46_DELTA.md` +- Parity companion: `BITCODE_SPEC_V46_PARITY_MATRIX.md` +- Scope: V46 draft system specification for commercial launch comprehension, source-safe public/operator protocol explanation, route/API/MCP/ChatGPT/Conversation interface clarity, and proof-readable market activity over the promoted V45 knowledge commoditization law +- Last fully realized canonical target preserved in source: `V45` + +## Version executive summary + +V46 opens from promoted V45's knowledge commoditization law. Its job is to make +that law commercially legible and interface-consistent without weakening source +safety: a buyer, depositor, operator, API consumer, ChatGPT App user, or future +AI agent must be able to understand what an AssetPack is, what BTD measures and +rights it carries, why BTC finality gates source unlock, what proof roots exist, +and what can be inspected before and after settlement. + +V46 does not replace V45 as active canon until promotion workflow validation. +It is the draft target for external protocol comprehension, public/operator +docs, route copy, interface contract readback, and launch-facing proof +explainability. + +## Canonical Bitcode executive summary + +Bitcode commoditizes technical knowledge by packaging it as AssetPacks. +Depositors form source-safe supply. Readers form measured demand, review Needs, +request Finding Fits, preview source-safe Need-Fit results, settle in BTC, take +BTD rights, and receive entitled repository delivery. Contributor compensation +flows from source-to-shares after final settlement. + +V45 already sharpened the law: AssetPack is the commodity, BTC is settlement +money, BTD is Need-relative weighted scalar knowledge-volume whose settled form +carries rights, and proof-backed readback is the only state advancement +mechanism. V46 makes that law understandable, inspectable, and consistent +across human and machine interfaces. + +## V46 source-of-truth hierarchy + +`BITCODE_SPEC.txt` points to `V45`; V45 is the active promoted Bitcode canon. +`BITCODE_SPEC_V46.md`, `BITCODE_SPEC_V46_DELTA.md`, +`BITCODE_SPEC_V46_NOTES.md`, and `BITCODE_SPEC_V46_PARITY_MATRIX.md` are draft +target material only. They do not authorize implementation behavior until a +gate-specific V46 parity or implementation gate accepts the relevant scope. + +Implementation remains unversioned in source paths. Package, route, component, +test, prompt, script, telemetry, schema, API, and workflow names move in place +as the single current Bitcode system after parity-authorized implementation +gates begin. + +## V46 full-system, re-implementation, and audit rule + +V46 work must be reconstructable from this formal specification family, source +code, generated artifacts, proof roots, workflow receipts, ledger journals, +database projections, storage roots, wallet/provider receipts, repository +delivery receipts, and operator-safe telemetry. + +No V46 surface may disclose protected source, unpaid AssetPack source, raw +prompts, raw model/provider responses, wallet private material, credentials, +private settlement payloads, or private repository access outside entitlement. + +## V46 totality and precision enforcement rule + +V46 must use protocol words precisely. AssetPack is the traded commodity. BTD +is weighted scalar knowledge-volume and, after settlement, a rights-bearing +receipt. BTC is settlement money. Source-to-shares is post-finality contributor +allocation. Preview is not source disclosure. Quote is not payment. Payment +observation is not finality. Database projection is not ledger truth when it +conflicts with ledger, storage, wallet, provider, or delivery readback. + +Every value or state must name whether it is estimate, potential, preview, +quote, observed payment, final settlement, rights transfer, delivery, +contributor allocation, or repair. + +## V46 system goals, non-goals, and design principles + +Goals: + +- Make promoted V45 law externally legible without simplifying away settlement, + rights, proof, source-safety, or compensation boundaries. +- Align public docs, landing copy, README/operator docs, `/packs`, `/read`, + `/deposit`, API/MCP, ChatGPT App, and Bitcode Chat around one protocol + explanation. +- Define source-safe market-activity disclosure: what can be inspected before + settlement, what is hidden until rights transfer, and what proof readback + makes auditable. +- Prepare a parity matrix for launch-facing documentation, route text, + interface schemas, proof explanations, examples, and demonstrations. +- Preserve V45 protocol law unless a later V46 atom explicitly and safely + supersedes it. + +Non-goals: + +- V46 draft work does not expose unpaid source. +- V46 draft work does not admit value-bearing mainnet operation. +- V46 draft work does not authorize behavior outside accepted formal parity, + proof, rehearsal, and promotion evidence. +- V46 draft work does not treat notes, PR bodies, telemetry, or conversations + as implementation authority. + +Design principles: source-safe commodity formation, Need-relative measurement, +BTC finality before rights, proof-backed readback, fail-closed repair, +interface humility, and implementation from formal parity only. + +## V46 system architecture and layer boundaries + +V46 acts through existing Bitcode layers: + +- `/deposit` for source-safe AssetPack supply formation. +- `/read` for Read Request, Need review, Finding Fits, preview, quote, BTC + settlement, BTD rights transfer, and repository delivery. +- `/packs` for searchable master-detail activity, proof roots, repairs, + settlement state, delivery state, and compensation state. +- API/MCP, ChatGPT App, and Bitcode Chat as policy-bound windows into the same + protocol law. +- Package-owned BTD, settlement, source-to-shares, prompt, pipeline, telemetry, + storage, proof, and workflow primitives. +- Ledger, database, object storage, wallet/provider, and repository readback as + protocol evidence boundaries. + +Demonstration code remains self-contained inside `protocol-demonstration/`. + +## V46 canonical domain model + +V46 consolidates these canonical objects and states: + +- AssetPack, deposit AssetPack option, Depository AssetPack, selected Fit set, + Need-Fit AssetPack, source-safe preview, withheld source bundle, quote, + settlement receipt, BTD rights receipt, repository delivery receipt, + source-to-shares allocation, contributor compensation statement, repair case, + proof root, execution receipt, ledger journal, database projection, object + storage root, wallet/provider receipt, and repository delivery receipt. +- AssetPack states: `deposit-option-synthesized`, + `deposit-option-reviewed`, `depository-assetpack-admitted`, + `fit-candidates-recalled`, `fit-set-selected`, + `need-fit-assetpack-synthesized`, `need-fit-assetpack-quoted`, + `settlement-observed`, `btd-settled-rights-transferred`, + `source-unlocked-delivery`, `compensated-and-reconciled`, and + `repair-required`. +- BTD states: `btd-not-applicable`, `btd-potential-measured`, + `need-fit-measurements-admitted`, `measurement-weight-policy-locked`, + `weighted-scalar-volume-computed`, `btd-quantized`, + `measuremint-applied`, `btd-range-assigned`, `btd-quote-bound`, + `btd-rights-pending`, `btd-rights-transferred`, + `btd-source-to-shares-allocated`, and `btd-repair-required`. +- BTC states: `btc-not-quoteable`, `btc-quote-issued`, + `btc-quote-accepted`, `btc-quote-inactive`, `btc-wallet-ready`, + `btc-psbt-prepared`, `btc-psbt-signed`, `btc-broadcast-submitted`, + `btc-payment-observed`, `btc-payment-mismatch-repair-required`, + `btc-finality-confirmed`, `btc-replaced-reorged-or-failed`, + `btc-settlement-finalized`, `btc-contributor-compensation-routable`, + `btc-refund-or-escalation-required`, and `btc-settlement-repair-required`. + +## V46 whole Bitcode operator chain + +The V46 operator chain is: connect source and organization policy, synthesize +deposit AssetPack options, approve source-safe Depository admission, request a +Read, synthesize and review a Need, run Finding Fits, select one or many +Depository AssetPacks above threshold, synthesize a source-bearing but withheld +Need-Fit AssetPack, preview only source-safe measurements and metadata, quote +BTC sats from deterministic BTD scalar-volume and share-to-fee policy, accept +quote, sign through non-custodial wallet flow, observe payment, confirm +Bitcoin finality, transfer BTD rights, unlock source only for the entitled +Reader boundary, deliver to repository, allocate source-to-shares contributor +compensation, reconcile ledger/database/storage, and repair fail-closed drift. + +## V46 consolidated protocol law + +Bitcode is the knowledge commoditization protocol and commercial system for +turning source-derived technical knowledge into source-safe, measurable +AssetPacks whose measurements can be weighted and summed into BTD scalar +knowledge-volume when evaluated against a reviewed Need. That Need-relative BTD +volume drives deterministic BTC quote and settlement, expresses +post-settlement rights, controls source unlock, routes contributor shares, and +is audited through proof roots, ledgerized journals, telemetry, database and +storage synchronization, and generated canon. + +The traded commodity is the AssetPack, not raw source, raw prompts, provider +responses, loose files, screenshots, telemetry logs, private repository access, +or conversational summaries. + +## V46 AssetPack lifecycle law + +Every AssetPack-like object must occupy exactly one lifecycle state at every +protocol boundary. Interfaces, APIs, pipelines, proofs, and operator tools must +not collapse deposit options into settled BTD, previews into source disclosure, +quotes into payment finality, admitted Depository AssetPacks into delivered +Need-Fit AssetPacks, or repair cases into successful purchases. + +Finding Fits recalls many candidates above threshold when available. The +selected Fit set may contain one or many admitted Depository AssetPacks. The +Need-Fit AssetPack is synthesized from the reviewed Need plus selected Fit set +and is a new Need-relative AssetPack, not disclosure of the underlying +Depository source before settlement. + +## V46 BTD scalar-volume law + +BTD is the non-fungible, proof-addressed scalar unit of technical knowledge +volume for a Need-Fit AssetPack. Deposit-time measurements may estimate BTD +potential, but final BTD size is computed only after a reviewed Need, selected +Fit set, synthesized Need-Fit AssetPack, deterministic measurement weights, +dedupe proofs, and source-safe proof roots exist. + +Every final BTD measurement row must be Need-relative, accepted, deduped, +proof-rooted, and tied to the selected Fit set. Measurement weights are +deterministic protocol policy. Scalar volume uses fixed-point or integer +arithmetic. Rights-bearing BTD exists only after BTC settlement finality and +BTD rights transfer. + +## V46 BTC settlement law + +BTC is Bitcode settlement money and payment truth. A BTC quote is a source-safe +procurement offer bound to a reviewed Need, selected Fit set, synthesized +Need-Fit AssetPack, BTD scalar-volume/range, deterministic share-to-fee +policy, wallet authority, network, expiry, and proof roots. + +Prepared, signed, broadcast, and observed states are not final settlement. +Source unlock, rights-bearing BTD transfer, repository delivery, and +contributor compensation require confirmed BTC finality, quote/payment +conservation, ledger/database/storage readback, and repair-free settlement +receipts. + +## V46 interface authority and disclosure law + +All Bitcode interfaces are protocol windows into the same AssetPack, BTD, BTC, +proof, ledger, database, storage, and delivery state. No interface is an +independent source of protocol law. `/deposit` forms source-safe supply; +`/read` procures Need-Fit packs; `/packs` inspects activity and proof readback; +API/MCP exposes machine workflows under equivalent policy; ChatGPT App and +Bitcode Chat guide and summarize; public docs and landing pages explain but do +not represent live transaction truth. + +Disclosure boundaries are `before-settlement`, `after-preview`, `after-quote`, +`after-payment-observation`, `after-finality`, +`after-btd-rights-transfer`, and `after-repository-delivery`. Each boundary +must fail closed to the narrowest source-safe state when evidence is missing or +contradictory. + +## V46 proof readback and operational authority law + +Bitcode state advances only by proof-backed readback. No UI row, conversation +message, streamed telemetry item, route response, external provider event, or +workflow log can alone advance AssetPack lifecycle, BTD rights, BTC settlement, +source unlock, delivery, or contributor compensation. + +Canonical evidence classes are canonical specification and generated proof +appendix, execution/workflow receipt, ledger journal, database projection, +object storage and protected-source roots, telemetry stream, wallet/provider +receipt, and repository delivery receipt. Telemetry is observability only. +Provider observation is not final settlement until reconciled with quote, +wallet authority, and finality policy. + +## V46 gate taxonomy law + +V46 gates are classified as `notes-specification-atom`, +`formal-specification-consolidation`, `specification-parity-matrix`, +`proof-only`, `interface-only`, `implementation`, `rehearsal`, or `promotion`. +Formal consolidation follows accepted notes atoms. The parity matrix follows +formal consolidation. Implementation follows accepted parity gaps. Promotion +alone may advance `BITCODE_SPEC.txt`. + +## V46 canonical subsystem surfaces + +### Depositing and asset supply + +- Current canonical objects and emitted artifacts: deposit AssetPack option, + Depository AssetPack, protected-source storage root, source-safety proof, + admission receipt, policy root, and source-safe earning potential. +- Current algorithms and derivation rules: source is measured into deposit + options, reviewed by depositor authority, admitted only after source-safety + and policy eligibility, then indexed for Finding Fits. +- Current invariants and fail-closed conditions: no final BTD size, reader + ownership, final BTC proceeds, or public source visibility before paid + Need-Fit settlement. +- Current proof obligations: option synthesis root, review decision root, + policy root, admission root, storage projection root, and Depository index + root. +- Current source-bearing implementation basis: protected source remains outside + visible Bitcode surfaces and is represented only by custody roots. +- Current validating commands and parity basis: V46 parity gate must audit + implementation against this formal specification. +- Current accepted boundaries: source-safe depositor supply formation only. + +### Reading and prompt/inference ownership + +- Current canonical objects and emitted artifacts: Read Request, synthesized + Need, reviewed Need, Finding Fits receipt, selected Fit set, source-safe + preview, quote, BTD posture, and delivery receipt. +- Current algorithms and derivation rules: Reading synthesizes a Need from a + request, accepts or resynthesizes it, searches the Depository, synthesizes a + Need-Fit AssetPack, and withholds source until payment and rights transfer. +- Current invariants and fail-closed conditions: preview, quote, and observed + payment are non-final and cannot disclose source. +- Current proof obligations: Read Request root, Need synthesis receipt, review + root, telemetry summary root, selected Fit root, synthesis root, quote root, + rights receipt, and repository delivery receipt. +- Current source-bearing implementation basis: source-bearing pack material may + exist internally only as a withheld bundle root before settlement. +- Current validating commands and parity basis: V46 parity gate must inspect + ReadNeed and ReadFitsFinding source, tests, proof, telemetry, and UI. +- Current accepted boundaries: Reader entitlement starts only after BTC + settlement finality and BTD rights transfer. + +### Fit, recall, ranking, and verification + +- Current canonical objects and emitted artifacts: search query root, search + channel roots, candidate provenance roots, ranking root, threshold root, + selected Fit set root, and verification root. +- Current algorithms and derivation rules: Finding Fits searches broadly over + admitted Depository AssetPacks and selects one or many candidates above + threshold for Need-Fit synthesis. +- Current invariants and fail-closed conditions: candidate source remains + withheld, and provisional BTD contribution is not rights-bearing. +- Current proof obligations: query, search, ranking, threshold, verification, + and selected-fit roots. +- Current source-bearing implementation basis: Fits are represented by + source-safe provenance and protected-source roots before rights transfer. +- Current validating commands and parity basis: parity must audit search, + embeddings, ranking, telemetry, and readback. +- Current accepted boundaries: recall and ranking are source-safe evidence, + not source disclosure. + +### Selection and materialization + +- Current canonical objects and emitted artifacts: Need-Fit AssetPack, + source-bearing withheld bundle, source-safe preview, measurement vector, BTD + posture, quote, source unlock root, and repository delivery receipt. +- Current algorithms and derivation rules: selected Fits plus reviewed Need + synthesize a new Need-relative AssetPack, then materialize delivery only + after settlement and rights. +- Current invariants and fail-closed conditions: no materialized source crosses + to the Reader before entitlement. +- Current proof obligations: synthesis receipt, withheld-source bundle root, + preview boundary root, measurement root, settlement root, rights root, and + delivery root. +- Current source-bearing implementation basis: source-bearing output is held in + protected storage until source unlock. +- Current validating commands and parity basis: parity must audit synthesis, + preview, storage, delivery, and repair paths. +- Current accepted boundaries: source-bearing materialization is delivery + authority, not preview authority. + +### Identity, authorization, and sensitive flow + +- Current canonical objects and emitted artifacts: organization policy, wallet + authority, budget approval, buyer authorization, depositor approval, + no-server-custody proof, and entitlement boundary. +- Current algorithms and derivation rules: policies gate quote acceptance, + wallet readiness, source criticality, deposit approval, delivery, and repair. +- Current invariants and fail-closed conditions: Bitcode never takes custody of + wallet private material and never lets policy bypass settlement law. +- Current proof obligations: wallet authority root, budget root, policy root, + authorization root, and entitlement root. +- Current source-bearing implementation basis: secrets, wallet private + material, and protected source are never serialized into public surfaces. +- Current validating commands and parity basis: parity must audit auth, wallet, + policy, API/MCP, and conversational authorization. +- Current accepted boundaries: authority enables protocol actions but cannot + override proof readback. + +### Disclosure and projection + +- Current canonical objects and emitted artifacts: interface read models, + disclosure boundary labels, redaction receipts, proof roots, repair cases, + and source-safe statements. +- Current algorithms and derivation rules: each surface projects only the data + the actor may see at the current protocol state. +- Current invariants and fail-closed conditions: missing or contradictory + evidence returns to the narrowest source-safe state. +- Current proof obligations: ledger/database readback, storage roots, + entitlement roots, redaction roots, and interface tests. +- Current source-bearing implementation basis: unpaid source, protected source, + raw prompts, raw responses, wallet material, and private payloads remain + withheld. +- Current validating commands and parity basis: parity must audit `/packs`, + `/read`, `/deposit`, API/MCP, ChatGPT App, Bitcode Chat, docs, and landing + surfaces. +- Current accepted boundaries: interfaces guide and inspect; they do not create + settlement, rights, or source truth. + +### Settlement and exact accounting + +- Current canonical objects and emitted artifacts: BTC quote, quote acceptance, + PSBT roots, broadcast receipt, payment observation, finality receipt, BTD + rights receipt, source-to-shares allocation, compensation statement, and + reconciliation root. +- Current algorithms and derivation rules: deterministic BTD scalar-volume and + share-to-fee policy generate sats quote; finality authorizes BTD rights and + delivery; source-to-shares routes contributor compensation after settlement. +- Current invariants and fail-closed conditions: observed payment is not final; + mismatches enter repair, refund, or escalation. +- Current proof obligations: quote root, wallet root, txid/network/amount + observation, finality receipt, conservation root, rights receipt, + compensation root, and reconciliation root. +- Current source-bearing implementation basis: settlement payloads are + source-safe and do not carry wallet private material or unpaid source. +- Current validating commands and parity basis: parity must audit BTD, BTC, + settlement, quote, ledger, database, storage, and compensation code. +- Current accepted boundaries: BTC finality precedes rights, unlock, delivery, + and compensation. + +### Proof contract, witnesses, and replay + +- Current canonical objects and emitted artifacts: specification proof, + execution receipt, workflow receipt, ledger journal, database projection, + object storage root, telemetry event, wallet/provider receipt, repository + delivery receipt, and replay report. +- Current algorithms and derivation rules: state advances only by required + proof root plus readback from the relevant boundary. +- Current invariants and fail-closed conditions: telemetry, UI, conversation, + provider observation, and workflow logs alone do not advance protocol state. +- Current proof obligations: every state advancement must name required + readback and repair behavior. +- Current source-bearing implementation basis: proof artifacts are source-safe + unless they sit behind entitled storage and delivery roots. +- Current validating commands and parity basis: parity must audit generated + proof, workflows, checks, replay, and repair coverage. +- Current accepted boundaries: proof-backed readback is the only authority. + +## V46 proof-family canon + +Every proof family below uses the same detail labels so generated proof and +human inspection remain aligned. + +### Inference-synthesis + +- proofArtifactPath: `.bitcode/v46-inference-synthesis-proof.json`. +- members: ReadNeedComprehension, ReadFitsFinding, deposit option synthesis, + AssetPack synthesis, conversation guidance. +- theoremIds: source-safe inference, typed output, prompt registry closure. +- replayStepIds: synthesize Need, Finding Fits, synthesize AssetPack, redacted + telemetry readback. +- witnessArtifactPaths: execution receipts, telemetry summaries, prompt + registry reports. +- current member closure criteria: every inference is typed, source-safe, and + auditable. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: theorem rows tie prompt, + execution, output type, and redaction. +- current theorem-to-replay grouping: grouped by pipeline and interface. +- minimum artifact/replay binding set: prompt root, execution root, output + root, telemetry root. +- current proof-object fields: proof id, family, member, theorem, input root, + output root, status. +- generated-artifact and test bindings: future parity gate must bind tests. +- fail-closed conditions: missing prompt, untyped output, source leak, or stale + telemetry. + +### Prompt-completeness + +- proofArtifactPath: `.bitcode/v46-prompt-completeness-proof.json`. +- members: prompt parts, prompts, registries, templates, interpolation. +- theoremIds: total prompt catalog, no raw prompt leakage, benchmarkable parts. +- replayStepIds: registry resolution, interpolation, redaction, benchmark run. +- witnessArtifactPaths: prompt inventory and benchmark receipts. +- current member closure criteria: prompt programs are complete and traceable. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem binds a prompt + surface to a typed use. +- current theorem-to-replay grouping: prompt family to inference family. +- minimum artifact/replay binding set: prompt part id, prompt id, registry id, + rendered prompt hash. +- current proof-object fields: prompt ids, interpolation inputs, output type. +- generated-artifact and test bindings: V46 parity determines coverage. +- fail-closed conditions: missing prompt part, unsafe interpolation, raw prompt + exposure, or unbenchmarked critical prompt. + +### Static-code-analysis + +- proofArtifactPath: `.bitcode/v46-static-code-analysis-proof.json`. +- members: packages, routes, scripts, workflows, tests, docs. +- theoremIds: source names align with protocol, no forbidden source exposure, + no versioned source identifiers. +- replayStepIds: lint, typecheck, casing/imports, spec check. +- witnessArtifactPaths: CI logs, local command receipts, diff hygiene. +- current member closure criteria: static checks pass and scope is traced to + formal spec. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem links code surface + to spec law. +- current theorem-to-replay grouping: static commands plus source maps. +- minimum artifact/replay binding set: file path, command, result, spec row. +- current proof-object fields: command, status, artifact root, failures. +- generated-artifact and test bindings: future proof-only gates may harden. +- fail-closed conditions: lint/type failure, import drift, or source-safety + violation. + +### Verification-decisions + +- proofArtifactPath: `.bitcode/v46-verification-decisions-proof.json`. +- members: Need review, Fit thresholding, quote acceptance, payment finality, + rights transfer, delivery. +- theoremIds: explicit decision root, actor authority, no collapsed states. +- replayStepIds: approve Need, select Fits, accept quote, confirm finality. +- witnessArtifactPaths: review receipts, verification roots, policy roots. +- current member closure criteria: decisions are typed, authorized, and + readback-backed. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each decision carries actor, + input, policy, and proof. +- current theorem-to-replay grouping: workflow boundary by state advancement. +- minimum artifact/replay binding set: decision root, actor root, policy root, + readback root. +- current proof-object fields: decision id, actor, state, result, blocker. +- generated-artifact and test bindings: parity must bind route and API tests. +- fail-closed conditions: unauthorized actor, stale decision, missing root, or + evidence conflict. + +### Selection-and-materialization + +- proofArtifactPath: `.bitcode/v46-selection-materialization-proof.json`. +- members: candidate recall, selected Fit set, withheld bundle, source-safe + preview, repository delivery. +- theoremIds: selected Fits above threshold, source withheld, delivery after + rights. +- replayStepIds: search, rank, select, synthesize, unlock, deliver. +- witnessArtifactPaths: selected-fit roots, storage roots, PR receipts. +- current member closure criteria: materialization honors disclosure state. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem binds source custody + to entitlement. +- current theorem-to-replay grouping: Finding Fits and delivery replay. +- minimum artifact/replay binding set: fit root, bundle root, preview root, + delivery root. +- current proof-object fields: candidate ids, bundle hash, preview hash, + delivery id. +- generated-artifact and test bindings: parity must bind storage and delivery. +- fail-closed conditions: no survivor, source overexposure, stale storage, or + delivery mismatch. + +### Authorization-and-sensitive-flow + +- proofArtifactPath: `.bitcode/v46-authorization-sensitive-flow-proof.json`. +- members: organization policy, wallet authority, depositor approval, buyer + entitlement, API/MCP, conversations. +- theoremIds: no secret leakage, no server custody, actor entitlement. +- replayStepIds: policy check, wallet ready, authorization denial, redaction. +- witnessArtifactPaths: policy roots, wallet roots, redaction receipts. +- current member closure criteria: sensitive data stays within its boundary. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem maps actor to + permitted data. +- current theorem-to-replay grouping: human, machine, and conversational + interfaces. +- minimum artifact/replay binding set: actor root, policy root, redaction root, + interface root. +- current proof-object fields: actor, scope, decision, redaction, blocker. +- generated-artifact and test bindings: parity must cover all interfaces. +- fail-closed conditions: secret exposure, wrong actor, missing policy, or + wallet custody drift. + +### Settlement-source-to-shares + +- proofArtifactPath: `.bitcode/v46-settlement-source-to-shares-proof.json`. +- members: BTD scalar-volume, BTC quote, PSBT, finality, rights transfer, + source-to-shares, compensation. +- theoremIds: deterministic quote, finality-before-rights, conservation, + allocation after settlement. +- replayStepIds: compute BTD, quote BTC, observe payment, confirm finality, + allocate shares. +- witnessArtifactPaths: BTD receipts, quote roots, wallet/provider receipts, + ledger journals, compensation statements. +- current member closure criteria: accounting conserves state and value. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem links quote, + payment, rights, and allocation. +- current theorem-to-replay grouping: settlement workflow and repair paths. +- minimum artifact/replay binding set: BTD root, quote root, tx root, + finality root, allocation root. +- current proof-object fields: sats, BTD range, txid, finality, allocation. +- generated-artifact and test bindings: parity must audit settlement packages. +- fail-closed conditions: mismatch, reorg, expired quote, stale readback, or + compensation drift. + +### Disclosure-boundary + +- proofArtifactPath: `.bitcode/v46-disclosure-boundary-proof.json`. +- members: `/deposit`, `/read`, `/packs`, API/MCP, ChatGPT App, Bitcode Chat, + public docs, landing page. +- theoremIds: source-safe before entitlement, non-final labels, boundary + equivalence across interfaces. +- replayStepIds: preview, quote, observation, finality, rights, delivery. +- witnessArtifactPaths: interface tests, redaction roots, read models. +- current member closure criteria: every surface shows only permitted state. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem maps state to + visible fields. +- current theorem-to-replay grouping: interface by actor and state boundary. +- minimum artifact/replay binding set: interface root, actor root, state root, + disclosure root. +- current proof-object fields: actor, boundary, visible fields, redactions. +- generated-artifact and test bindings: parity must bind UI/API proof. +- fail-closed conditions: overexposure, finality confusion, source leak, or + missing entitlement. + +### Proof-contract + +- proofArtifactPath: `.bitcode/v46-proof-contract-proof.json`. +- members: generated spec proof, workflow receipts, ledger journals, database + projections, storage roots, telemetry, provider receipts, repository + receipts. +- theoremIds: proof-backed readback, evidence precedence, repair on conflict. +- replayStepIds: readback join, contradiction, repair, replay. +- witnessArtifactPaths: generated proof appendix, workflow logs, readback + reports, repair receipts. +- current member closure criteria: protocol state advances only with required + readback. +- current member verdict shape: pass, repair-required, or blocked. +- current theorem-by-theorem closure reading: each theorem ties evidence class + to authority and limit. +- current theorem-to-replay grouping: state advancement and repair. +- minimum artifact/replay binding set: proof root, ledger root, database root, + storage root, external receipt when relevant. +- current proof-object fields: evidence class, authority, limit, readback, + conflict policy. +- generated-artifact and test bindings: parity must bind proof and workflow + checks. +- fail-closed conditions: missing, stale, contradictory, or out-of-boundary + evidence. + +## V46 generated canon + +V46 generated canon begins with draft spec-family and canonical-input +validation. Later V46 gates may authorize proof-family, source-safe +end-to-end rehearsal, promotion-readiness, and generated proof appendix +artifacts. Until those gates close, V45 generated proof remains the active +canon evidence. + +### Inherited V19 reproducible-canon artifacts + +V46 inherits V19 reproducible-canon discipline for deterministic replay, +proof-member matrices, theorem evidence, state machines, volatility, negative +mutation, and contract ledger shape. + +### Inherited V20 operator-quality artifacts + +V46 inherits V20 operator-quality artifact posture for accessibility, +operator acceptance, performance budget, projection quality, visual regression, +and quality summary. + +### Exact generated-artifact inventory matrix + +| artifactPath | role | V46 posture | +| --- | --- | --- | +| `.bitcode/v46-spec-family-report.json` | draft spec-family validation report | Gate 1 planned | +| `.bitcode/v46-canonical-input-report.json` | draft canonical input report | Gate 1 planned | +| `.bitcode/v46-inference-synthesis-proof.json` | inference proof-family artifact | future proof gate | +| `.bitcode/v46-prompt-completeness-proof.json` | prompt proof-family artifact | future proof gate | +| `.bitcode/v46-static-code-analysis-proof.json` | static-code proof-family artifact | future proof gate | +| `.bitcode/v46-verification-decisions-proof.json` | verification-decision proof-family artifact | future proof gate | +| `.bitcode/v46-selection-materialization-proof.json` | selection and materialization proof-family artifact | future proof gate | +| `.bitcode/v46-authorization-sensitive-flow-proof.json` | authorization and sensitive-flow proof-family artifact | future proof gate | +| `.bitcode/v46-settlement-source-to-shares-proof.json` | settlement and allocation proof-family artifact | future proof gate | +| `.bitcode/v46-disclosure-boundary-proof.json` | disclosure-boundary proof-family artifact | future proof gate | +| `.bitcode/v46-proof-contract-proof.json` | proof-contract proof-family artifact | future proof gate | +| `.bitcode/v46-source-safe-e2e-rehearsal.json` | source-safe end-to-end rehearsal artifact | future rehearsal gate | +| `.bitcode/v46-promotion-readiness-report.json` | promotion-readiness artifact | future promotion gate | +| `BITCODE_SPEC_V46_PROVEN.md` | generated proof appendix | future promotion gate | + +### V46 specifying generated artifacts + +V46 specifying generated artifacts must include `.bitcode/v46-spec-family-report.json`, +`.bitcode/v46-canonical-input-report.json`, all nine V46 proof-family +artifacts, `.bitcode/v46-source-safe-e2e-rehearsal.json`, +`.bitcode/v46-promotion-readiness-report.json`, and future +`BITCODE_SPEC_V46_PROVEN.md`; each artifact becomes required only when its +own gate closes. + +### Shared generated-artifact fields + +Shared generated-artifact fields include report id, version, generatedAt, +source commit, input roots, artifact roots, pass/fail status, failures, +warnings, source-safe posture, and repair instructions. + +### Artifact-specific generated payload fields + +Artifact-specific generated payload fields include BTD scalar-volume rows, BTC +quote and finality rows, source-to-shares rows, disclosure boundary rows, +interface authority rows, readback evidence rows, and gate taxonomy rows. + +### Artifact confidentiality and disclosability taxonomy + +Artifacts classify fields as public, source-safe actor-scoped, operator-safe, +entitled-source, secret, wallet-private, provider-private, or repair-only. + +### Minimum generated appendix rendered contents + +The minimum generated appendix rendered contents must include aggregate proof +verdict, exact proof-family inventory, exact per-family member inventory, exact +per-family theorem inventory, exact replay-step inventories and theorem +bindings, witness artifact inventories, generated artifact inventories, +scenario and run coverage matrices, proof-source commit, and fail closed when +required evidence is missing, stale, contradictory, or unsafe. + +### Canonical regeneration and fail-closed posture + +Canonical regeneration and fail-closed posture require deterministic outputs, +clean worktree proofs when promotion eventually requires them, and repair +states for missing generated artifacts or stale proof roots. + +## V46 validation canon + +V46 validation proceeds in order: draft spec-family checks, active V45 +promoted-canon checks, canon posture drift checks, small specification atom +checks, formal specification consolidation, parity audit, grouped +implementation tests, proof-only checks, interface proofs, rehearsal, +promotion readiness, and a later promotion workflow. + +Gate 1 validates only active V45 plus draft V46 posture: + +- `node scripts/check-bitcode-spec-family.mjs --version V45 --mode promoted --current-target V45` +- `node scripts/check-bitcode-spec-family.mjs --version V46 --mode draft --current-target V45` +- `node scripts/check-bitcode-canonical-inputs.mjs --current-target V45` +- `node scripts/check-bitcode-canon-posture-drift.mjs --active-canon V45 --draft-target V46` +- `pnpm run check:v46-gate1` + +## V46 promotion canon + +V46 promotion is future work. It will require every accepted parity row to be +closed or explicitly deferred, source-safety to be preserved, implementation +and proof gates to be green, rehearsal receipts to be replayable, and the +promotion workflow to validate before any standalone `BITCODE_SPEC.txt` +pointer change. + +### V46 promotion readiness canon + +V46 promotion readiness is not current in Gate 1. A later gate must generate +`.bitcode/v46-promotion-readiness-report.json`, wire any V46 promotion +workflow, bind all required proof-family and rehearsal artifacts, prove +source-safety exclusions, and show direct-main-push blocking before promotion +can be requested. + +## V46 appendices and canonical supporting material + +V46 supporting material consists of `BITCODE_SPEC_V46.md`, +`BITCODE_SPEC_V46_DELTA.md`, `BITCODE_SPEC_V46_NOTES.md`, +`BITCODE_SPEC_V46_PARITY_MATRIX.md`, future `BITCODE_SPEC_V46_PROVEN.md`, +`BITCODE_SPECIFYING.md`, `BITCODE_SPEC_TEMPLATEGUIDE.md`, V46 checkers, and +future generated `.bitcode` reports. + +## V46 accepted boundaries and reopen conditions + +Accepted boundaries: + +- V45 is active canon and V46 is draft target. +- V46 formal spec is active runtime law only inside the source-safe, + entitlement-bound, proof-backed boundaries it states after a later + promotion. +- No protected source or wallet private material is exposed. +- BTC finality precedes BTD rights, source unlock, delivery, and compensation. +- Proof-backed readback advances state; telemetry observes state. + +Reopen conditions: + +- A formal V46 section contradicts accepted notes law. +- A parity audit finds a protocol impossibility or unsafe implementation gap. +- A proof, ledger, database, storage, wallet, provider, or delivery evidence + class cannot satisfy readback law. +- A product surface requires source disclosure before entitlement. + +## V46 completion condition + +V46 Gate 1 is complete when the V46 draft spec family exists over active V45, +the roadmap names the version focus and tentative gates, the Gate 1 checker is +green, and CI can validate active V45 plus draft V46. The full V46 version is +complete only after later specification, parity, implementation, proof, +interface, rehearsal, and promotion gates close. + +## Appendix A. Canonical type and surface catalog + +Canonical types and surfaces include AssetPack, deposit AssetPack option, +Depository AssetPack, Read Request, Need, selected Fit set, Need-Fit AssetPack, +BTD scalar-volume, BTC quote, settlement receipt, rights receipt, delivery +receipt, compensation statement, repair case, `/deposit`, `/read`, `/packs`, +API/MCP, ChatGPT App, Bitcode Chat, public docs, landing page, proof roots, +ledger journals, database projections, storage roots, wallet/provider receipts, +and repository delivery receipts. + +## Appendix B. Proof family closure catalog + +The V46 proof family closure catalog binds inference, prompts, static code, +decisions, materialization, authorization, settlement, disclosure, and proof +contracts to generated artifacts and replay. + +### Exact proof-family inventory matrix + +| proofFamily | proofArtifactPath | memberIds | theoremIds | replayStepIds | witnessArtifactPaths | Current source basis | +| --- | --- | --- | --- | --- | --- | --- | +| Inference-synthesis | `.bitcode/v46-inference-synthesis-proof.json` | Reading, deposit, conversation | typed inference, source safety | synthesize, search, preview | execution receipts | formal V46 law | +| Prompt-completeness | `.bitcode/v46-prompt-completeness-proof.json` | prompts, registries | total prompt catalog | resolve, interpolate | prompt inventory | formal V46 law | +| Static-code-analysis | `.bitcode/v46-static-code-analysis-proof.json` | packages, routes, workflows | source alignment | lint, typecheck | CI logs | formal V46 law | +| Verification-decisions | `.bitcode/v46-verification-decisions-proof.json` | review, quote, finality | actor authority | approve, select, settle | decision roots | formal V46 law | +| Selection-and-materialization | `.bitcode/v46-selection-materialization-proof.json` | Fits, bundle, preview, delivery | source withheld | search, synthesize, deliver | storage roots | formal V46 law | +| Authorization-and-sensitive-flow | `.bitcode/v46-authorization-sensitive-flow-proof.json` | policy, wallet, entitlement | no secret leakage | authorize, redact | policy roots | formal V46 law | +| Settlement-source-to-shares | `.bitcode/v46-settlement-source-to-shares-proof.json` | BTD, BTC, allocation | finality before rights | quote, observe, allocate | ledger roots | formal V46 law | +| Disclosure-boundary | `.bitcode/v46-disclosure-boundary-proof.json` | interfaces | source-safe boundary | preview, quote, delivery | interface roots | formal V46 law | +| Proof-contract | `.bitcode/v46-proof-contract-proof.json` | evidence classes | proof-backed readback | readback, repair | proof roots | formal V46 law | + +## Appendix C. Generated artifact contract catalog + +Generated artifacts must be deterministic, source-safe by default, explicit +about confidentiality, and fail closed when proof roots or readback evidence +are missing. The draft generated artifacts are `.bitcode/v46-spec-family-report.json`, +`.bitcode/v46-canonical-input-report.json`, all nine V46 proof-family +artifacts, `.bitcode/v46-source-safe-e2e-rehearsal.json`, and +`.bitcode/v46-promotion-readiness-report.json`, and +`BITCODE_SPEC_V46_PROVEN.md`; promotion later refreshes promotion-readiness +proof outputs. + +### Minimum generated appendix rendered contents + +Minimum generated appendix rendered contents are aggregate proof verdict, exact +proof-family inventory, exact per-family member inventory, exact per-family +theorem inventory, exact replay-step inventories and theorem bindings, witness +artifact inventories, generated artifact inventories, scenario and run coverage +matrices, proof-source commit, and fail closed when evidence cannot be trusted. + +### Canonical regeneration and fail-closed posture + +Canonical regeneration and fail-closed posture require deterministic generation, +source-safe output, current proof-source commit, and repair on stale or missing +artifact roots. + +## Appendix D. Validation and checking gate catalog + +Validation commands include `check:v46-gate1`, draft V46 spec-family checks, +active V45 promoted checks, V45/V46 canon posture drift checks, and later +parity, proof, implementation, rehearsal, and promotion commands. + +## Appendix E. Current canonical source map + +The current source map is active V45 canon with V46 draft target posture +prepared. Implementation source remains unversioned and is audited from V45 +until a V46 parity gate authorizes specific implementation work. + +## Appendix F. Subsystem totality and derivability matrix + +Required subsystem coverage includes repo supply and depositing, reading and +measured demand, prompt/inference/evaluator ownership, deposit-to-read fit, +recall and ranking, verification decisions, selection and materialization, +branch artifacts and assetPackEvidence, identity, authority, signing, and +policy, sensitive data and confidentiality flows, projection, disclosure, and +redaction, proof families, members, theorems, witnesses, and replay, +settlement, source-to-shares, journals, and exact accounting, telemetry, +persistence, state, and failure semantics, host/runtime capability truth, +operator experience and pedagogy, validation and test stack, generated +artifacts and canonical promotion. + +## Appendix G. Canonical file-family and promotion contract catalog + +The V46 file family is `BITCODE_SPEC_V46.md`, +`BITCODE_SPEC_V46_DELTA.md`, `BITCODE_SPEC_V46_NOTES.md`, +`BITCODE_SPEC_V46_PARITY_MATRIX.md`, future `BITCODE_SPEC_V46_PROVEN.md`, and +supporting Bitcode specifying files. Promotion may update `BITCODE_SPEC.txt` +only through the promotion gate. + +## Appendix H. Operator surface and quality contract catalog + +Operator surfaces include website routes, ChatGPT App, Bitcode Chat, API/MCP, +public docs, landing page, workflow checks, proof reports, and repair readback. +Quality contracts require accessible, source-safe, performant, replayable, and +operator-legible outputs. + +## Appendix I. Scenario, workflow, and cross-product contract catalog + +Scenario coverage inherits auth-issuer-rollback, privacy-boundary-proof-export, +polyglot-gateway-benchmark-remediation, and auth-many-asset-normalization. +Workflow coverage includes Targeted deposit and Normalization deposit across +patch and context branches and public, buyer, reviewer, and internal +principals. The contract remains Openly writable, Measurably readable, +Provable, and Valuable. + +## Appendix J. Fail-closed contract and error posture matrix + +Fail closed on invalid deposit, prompt contract incompleteness, +parsed-envelope inadmissibility, no-survivor asset pack, authorization denial, +public projection overexposure, settlement conservation drift, stale promoted +status truth, missing proof readback, contradictory evidence, source leak, +wallet custody drift, or delivery mismatch. + +## Appendix K. Source-bearing AssetPack and artifact contract catalog + +Source-bearing AssetPack artifacts include `.bitcode/asset-pack.lock.json`, +`.bitcode/selected-source-material.json`, `.bitcode/verification-report.json`, +`.bitcode/source-to-shares.json`, `.bitcode/projection-policy.json`, +`.bitcode/system-proof-bundle.json`, +`.bitcode/v46-source-safe-e2e-rehearsal.json`, +`.bitcode/v46-promotion-readiness-report.json`, and +`BITCODE_SPEC_V46_PROVEN.md`. V46 requires protected source custody, +source-safe preview, entitlement-based unlock, and repository delivery receipt +before Reader-visible source. diff --git a/BITCODE_SPEC_V46_DELTA.md b/BITCODE_SPEC_V46_DELTA.md new file mode 100644 index 000000000..b434427cc --- /dev/null +++ b/BITCODE_SPEC_V46_DELTA.md @@ -0,0 +1,78 @@ +# Bitcode Spec V46 Delta + +## Status + +- Version: `V46` +- V46 state: draft opening; V46 is the active draft target over promoted V45 canon +- Current canonical/latest target: `V45` +- Prior canonical anchor: `BITCODE_SPEC_V45.md` +- Prior generated proof appendix: `BITCODE_SPEC_V45_PROVEN.md` +- Generated structured artifact inventory: draft `.bitcode/v46-spec-family-report.json` and `.bitcode/v46-canonical-input-report.json`; later V46 gates must authorize proof-family, rehearsal, promotion-readiness, and generated proof appendix artifacts before they become required V46 evidence +- Source parity state: V46 source parity has not been audited; Gate 1 opens the draft-target roadmap and validation boundary only +- Notes companion: `BITCODE_SPEC_V46_NOTES.md` +- Spec companion: `BITCODE_SPEC_V46.md` +- Parity companion: `BITCODE_SPEC_V46_PARITY_MATRIX.md` +- Scope: V46 draft delta for commercial protocol comprehension, public/operator explanation, source-safe interface claims, and proof-readable launch posture over promoted V45 knowledge commoditization law +- Last fully realized canonical target preserved in source: `V45` + +## Why V46 exists + +V45 made Bitcode's knowledge commoditization law explicit: AssetPack is the +commodity, BTD is Need-relative weighted scalar knowledge-volume whose settled +form carries rights, BTC is settlement money, source-to-shares routes +contributor compensation, and proof-backed readback advances state. V46 exists +to make that law commercially legible across public, operator, product, +machine, and conversational surfaces without weakening source-safety or +overstating live value-bearing posture. + +## Accepted V46 decisions + +- V45 remains active canon while V46 is drafted. +- V46 opens as a specification-first version; Gate 1 is roadmap/spec-family + opening only. +- V46 focuses on external protocol comprehension and launch-facing claim + readiness before it authorizes implementation changes. +- Public docs, landing copy, `/packs`, `/read`, `/deposit`, API/MCP, ChatGPT + App, and Bitcode Chat must explain the same protocol law with source-safe + boundaries. +- Investor or pitch material may inform wording, but it is not protocol law + unless reconciled into the formal V46 specification family. +- All V46 work must preserve V45's source-safe preview, BTC finality before + source unlock, BTD rights, proof readback, repair, and value-bearing mainnet + blocks. + +## Explicitly deferred + +- V46 does not replace V45 until a later promotion workflow validates and + advances `BITCODE_SPEC.txt`. +- Gate 1 does not authorize runtime behavior, schema changes, route changes, + settlement behavior, proof-family artifacts, source-safe rehearsal artifacts, + or promotion-readiness artifacts. +- Value-bearing mainnet operation remains deferred. +- Generated V46 proof appendix material remains future work until a proof or + promotion gate makes it current. + +## Accepted Pre-Implementation Sequence + +1. Open the V46 draft family over active V45 and validate draft posture. +2. Specify commercial protocol comprehension atoms in small gates. +3. Consolidate accepted atoms into the formal V46 specification family. +4. Audit implementation parity from the formal V46 family. +5. Group implementation, proof, interface, rehearsal, and documentation work + by accepted parity gaps. +6. Close promotion readiness only after all scoped gates are green. +7. Promote V46 only through the maintained promotion workflow. + +## Gate 1: V46 Commercial Protocol Comprehension Roadmap Opening + +Gate 1 closes when the V46 spec family exists as draft material over active +V45, the roadmap names the V46 focus and tentative gates, the branch/check +contract is present, CI knows how to validate active V45 plus draft V46, and no +V46 file claims promoted authority. + +## Commit-Body Direction + +V46 commit bodies should name the gate class, protocol law or interface claim +being clarified, validation command, source-safety posture, and whether the +change is specification-only, parity-only, proof-only, interface-only, +implementation, rehearsal, or promotion work. diff --git a/BITCODE_SPEC_V46_NOTES.md b/BITCODE_SPEC_V46_NOTES.md new file mode 100644 index 000000000..efedef3d3 --- /dev/null +++ b/BITCODE_SPEC_V46_NOTES.md @@ -0,0 +1,728 @@ +# Bitcode Spec V46 Notes + +## Status + +- Version: `V46` +- Canonical pointer: `BITCODE_SPEC.txt` -> `V45` +- Active canonical anchor: `BITCODE_SPEC_V45.md` +- Active generated proof appendix: `BITCODE_SPEC_V45_PROVEN.md` +- Current canonical/latest target: `V45` +- Prior canonical anchor: `BITCODE_SPEC_V45.md` +- Prior generated proof appendix: `BITCODE_SPEC_V45_PROVEN.md` +- Generated structured artifact inventory: draft `.bitcode/v46-spec-family-report.json` and `.bitcode/v46-canonical-input-report.json`; later V46 gates must authorize proof-family, rehearsal, promotion-readiness, and generated proof appendix artifacts before they become required V46 evidence +- Source parity state: V46 source parity has not been audited; Gate 1 opens the draft-target roadmap and validation boundary only +- V46 state: draft opening; V46 notes record the initial commercial protocol comprehension plan over active V45 canon +- Scope: V46 draft notes for commercial protocol comprehension, public/operator explanation, source-safe interface claims, and proof-readable launch posture over promoted V45 knowledge commoditization law +- Last fully realized canonical target preserved in source: `V45` + +## Notes companion rule + +These notes record the accepted V46 opening atoms. After formal specification +consolidation and promotion, a later workflow may make `BITCODE_SPEC_V46.md` +and its companion family active canon. Until then, V45 remains the active +pointer truth through `BITCODE_SPEC.txt`. + +## Concise current-system reading + +V46 formalizes Bitcode as the world's knowledge commoditization system: +AssetPacks enter and leave the Depository, BTD measures Need-relative scalar +knowledge-volume and settled rights, BTC is payment truth, interfaces remain +source-safe windows, and proof-backed readback advances protocol state. + +## Simplified-spec reading rule + +When V46 work becomes broad, reduce it to the formal law: + +1. AssetPack is the traded commodity, never raw source. +2. BTD is weighted scalar knowledge-volume whose settled form carries rights. +3. BTC settlement finality precedes BTD rights transfer and source unlock. +4. Interfaces may guide and inspect, but proof readback advances state. +5. Implementation begins only after formal specification and parity audit. + +## Notes provenance rule + +These notes are not implementation authority above the active V45 +specification family. They preserve draft notes-level atoms that must later be +consolidated into formal V46 specification text before parity or +implementation gates rely on them. + +## Deferred from V45 + +V45 promotes the scaled engineering economy: `/packs` as portfolio and market +intelligence, `/read` as budgeted BTC procurement of source-bearing +AssetPacks, `/deposit` as supply and earning visibility, and organization +policy over wallet authority, spend limits, source criticality, and approval +thresholds. + +V46 began by discussing Bitcode as the world's knowledge commoditization +system. The discussion audited whether the canonical +protocol fully specifies the commercial experience of depositing and reading +packs, BTC source-of-truth settlement, BTD measuring/mining/minting, rights +transfer, proof/ledger observability, API/MCP access, GitHub delivery, +ChatGPT App surfaces, Bitcode Chat conversation overlays, public docs, +landing-page claims, compute constraints, storage boundaries, and +build/process validation. + +## Candidate V46 workstreams + +- Protocol completeness: audit the V45 canon for AssetPack synthesis, BTD + measuring/mining/minting, BTC settlement, proof roots, ledgerized + journaling, and source-safe disclosure boundaries. +- Product comprehension: refine how `/packs`, `/read`, and `/deposit` explain + the exchange without in-app essays while preserving expandable proof, + telemetry, and economic detail. +- Interface system: align website routes, ChatGPT App, Bitcode Chat + conversation overlay, API/MCP entrypoints, public docs, and landing page as + coherent windows into the same protocol. +- Operational proof: preserve V45 workflow reliability while identifying the + next proof, test, and replay obligations needed for the commercial system. + +## Gate 1: V46 Commercial Protocol Comprehension Roadmap Opening + +Gate 1 records the draft-opening note for the V46 family. It creates the V46 +files, preserves `BITCODE_SPEC.txt -> V45`, names the draft focus, wires a +Gate 1 checker, and prepares CI to validate active V45 plus draft V46. It does +not authorize runtime behavior or generated V46 proof-family artifacts. + +## V46 opening discussion frame + +V46 opened from the premise that specification is the source of protocol truth. +Before the V46 parity matrix and gate plan existed, the first work was a +protocol audit over the promoted V45 canon. The audit classified each framing +as clearly specified, vaguely specified, incorrectly specified, missing, or +already production-grade: + +- Bitcode as the world's knowledge commoditization system. +- AssetPacks as the packaged knowledge commodity entering and leaving the + Depository. +- Depositing as source-safe supply formation and later contributor + compensation. +- Reading as demand formation, Need synthesis, Finding Fits, quote approval, + BTC settlement, BTD rights transfer, and repository delivery. +- `/packs` as the searchable master-detail surface for Bitcode network + activity, proofs, statements, repairs, and economic state. +- BTC as settlement money and source of payment truth. +- BTD as the weighted scalar knowledge-volume unit whose settled form carries + rights, source unlock authority, ownership boundaries, and source-to-shares + allocation context. +- Proof roots, ledgerized journaling, telemetry, database/storage + synchronization, and generated canon as auditability rails. +- Website routes, ChatGPT App, Bitcode Chat conversation overlays, API/MCP, + public docs, and landing page as coherent interface windows into the same + protocol law. + +## V46 known starting observations + +- V45 is strong on source-safe economic labels, route law, proof families, + generated artifacts, organization governance, and scaled rehearsal. +- V45 needed this promotion addendum because canon posture text is protocol law: + a promoted spec cannot contain stale active/draft hierarchy prose. +- V45 states the BTD/BTC/source-to-shares roles clearly, but V46 must decide + whether BTD measuring, mining, minting, scalar knowledge-volume, ownership, + and lifecycle state are specified precisely enough for enterprise and public + protocol comprehension. +- V45 names BTC settlement, quote, observed payment, final settlement, + reconciliation, and repair states, but V46 should audit whether the exact + payment/finality/source-unlock/delivery state machine is complete enough. +- V45 identifies interface surfaces beyond the website only as future alignment + targets; V46 should decide how deeply each interface must be specified before + implementation gates. + +## V46 questions before a parity matrix + +1. What is the smallest complete protocol-law statement for Bitcode as + knowledge commoditization system? +2. What exact state transitions define an AssetPack from potential deposit + option through admitted supply, Finding Fits, paid Need-Fit pack, delivery, + compensation, and repair? +3. What exact state transitions define BTD measuring, mining, minting, scalar + knowledge-volume, ownership transfer, source unlock, and post-settlement + rights? +4. What exact state transitions define BTC quote, payment observation, + confirmation/finality, repair, refund/escalation if any, and contributor + compensation? +5. Which user-visible statements are allowed before settlement, after preview, + after quote, after payment observation, after finality, after rights + transfer, and after repository delivery? +6. Which surfaces are protocol-authoritative in V46: `/packs`, `/read`, + `/deposit`, API/MCP, ChatGPT App, Bitcode Chat, public docs, and landing + page? +7. Which V46 gates should be specification-only, proof-only, interface-only, + implementation, rehearsal, and promotion gates? + +## V46 gate sequencing rule + +V46 proceeds in four ordered movements: + +1. Specification atom gates. Each small protocol specification atom is its own + gate and pull request. Each atom must be correct alone before the next atom + begins, and every atom must be reconciled into the gestalt of Bitcode as the + knowledge commoditization system. +2. Formal specification consolidation gate. After the notes-level + specification atoms are accepted, one gate updates the V46 specification + family from those accepted atoms before implementation auditing begins. +3. Specification parity matrix gate. After the V46 specification family is + updated, one gate audits implementation against the formalized + specification and builds the V46 parity matrix across source code, tests, + proofs, generated artifacts, workflows, documentation, and interface + surfaces. +4. Grouped implementation gates. Only after the parity matrix is accepted do + implementation gates begin, grouped by coherent protocol/product work rather + than by isolated prose atoms. + +This ordering is itself V46 protocol-development law: do not start +implementation work, broad parity claims, or promotion planning while the +specification atoms remain unsettled, while accepted notes have not yet been +consolidated into the V46 specification family, or while implementation parity +has not yet been audited from that formal specification. + +## V46 protocol atom 1: knowledge commoditization system + +Audit classification: V42, V43, and V45 clearly state the commercial path for +depositing and reading technical knowledge, and V43/V45 clearly establish +AssetPacks as the object in and out. The remaining gap is precision of the +one-sentence protocol identity. V46 begins by making that identity exact before +it expands any state machine, interface, pricing, or proof surface. + +Protocol-law statement: + +Bitcode is the knowledge commoditization protocol and commercial system for +turning source-derived technical knowledge into source-safe, measurable +AssetPacks whose measurements can be weighted and summed into BTD scalar +knowledge-volume when evaluated against a reviewed Need. That Need-relative BTD +volume drives deterministic BTC quote/settlement, expresses post-settlement +rights, controls source unlock, routes contributor shares, and is audited +through proof roots, ledgerized journals, telemetry, database/storage +synchronization, and generated canon. + +This means: + +- The traded commodity is the AssetPack, not raw source, raw prompts, provider + responses, loose files, screenshots, telemetry logs, or private repository + access. +- BTC is settlement money and payment truth. +- BTD is the protocol's weighted scalar knowledge-volume unit. Settled BTD is + also rights-bearing: it expresses paid read/use rights, source unlock + authority, ownership boundaries, and source-to-shares allocation context. It + is not merely a read-right, not a deposit option, and not a replacement for + BTC. +- BTD-relevant measurements may exist before a Need: deposit-time measurements + can preview coverage, source criticality, likely utility, BTD potential, and + search posture for the depositor and the Depository. +- Final BTD size can only be calculated against a reviewed Need because the + knowledge volume depends on Need-relative measurement weights, admitted fit + quality, and the selected Need-Fit AssetPack context. +- All admissible Need-Fit measurements are weighted and summed to determine the + scalar BTD knowledge volume and source-to-shares allocation basis for the + settled AssetPack. +- Depositing forms source-safe AssetPack supply; it does not sell or disclose + protected source before paid settlement and rights transfer. +- Reading forms measured demand, synthesizes Needs, finds fitting Depository + supply, previews only source-safe measurements/metadata, and buys full + source-bearing delivery only after BTC settlement and BTD rights transfer. +- Source-to-shares is contributor allocation after paid Need-Fit selection; it + is not an estimated earning range and not a quote. +- `/packs`, `/read`, `/deposit`, API/MCP, ChatGPT App, Bitcode Chat, public + docs, and landing pages may present the system differently, but none may + change the protocol law or disclose source outside the settlement boundary. + +What this atom does not yet decide: + +- the exact AssetPack lifecycle state machine; +- the exact BTD measuring, mining, minting, scalar knowledge-volume, + ownership, and transfer state machine; +- the exact BTC quote, observation, confirmation, finality, repair, refund, or + compensation state machine; +- which non-website interfaces are protocol-authoritative in V46; or +- whether later V46 gates should broaden from technical knowledge toward + all knowledge commodities. + +Acceptance for this atom: later V46 specification may refine terms, but it must +preserve AssetPack as commodity, BTC as settlement money, BTD as weighted scalar +knowledge-volume unit whose settled form carries rights, final BTD size as +Need-relative, source-safety before settlement, repository delivery after rights +proof, and proof/ledger/journal observability as Bitcode's market-infrastructure +rails. + +## V46 protocol atom 2: AssetPack lifecycle state machine + +Audit classification: V43/V45 correctly establish AssetPacks in and +AssetPacks out, but the canon still spreads lifecycle law across `/deposit`, +`/read`, `/packs`, BTD accounting, preview, settlement, and delivery sections. +V46 consolidates the lifecycle into one source-safe state machine before it +specifies BTD calculation and BTC settlement state in later atoms. + +Protocol-law statement: + +Every AssetPack-like object must occupy exactly one lifecycle state at every +protocol boundary, and every transition must state whether the object is source +safe only, source-bearing but withheld, quoteable, settled, deliverable, +compensable, or in repair. No interface, API, pipeline, proof artifact, or +operator tool may collapse lifecycle states to make a deposit option look like +settled BTD, a preview look like source disclosure, a quote look like payment +finality, or an admitted Depository AssetPack look like a delivered Need-Fit +AssetPack. + +The canonical AssetPack lifecycle states are: + +| State | Owner boundary | Source visibility | BTD posture | Required proof | +| --- | --- | --- | --- | --- | +| `deposit-option-synthesized` | Depositor-connected source and deposit pipeline | Source-safe measurements and metadata only; protected source remains outside visible Bitcode surfaces | Deposit-time BTD-relevant measurements may show potential, coverage, likely utility, criticality, and search posture; no final BTD size | option synthesis root, source-safety root, measurement root | +| `deposit-option-reviewed` | Depositor review | Same source-safe view; depositor may approve, reject, or request resynthesis | Still no final BTD size and no minted BTD | review decision root and policy root | +| `depository-assetpack-admitted` | Depository supply | Searchable source-safe metadata, measurements, embeddings, and external protected-source pointer roots only | Admitted supply may carry BTD potential, not final BTD, because no reviewed Need has selected it yet | admission receipt, Depository index root, storage projection root | +| `fit-candidates-recalled` | Reading Finding Fits search | Candidate identity, ranking, measurements, and provenance are source-safe to the Reader; candidate source remains withheld | Candidate BTD contribution is only provisional until selected against the reviewed Need | query root, search-channel roots, ranking root | +| `fit-set-selected` | Reading Finding Fits selection | Selected Fit set provenance is source-safe; protected source remains withheld from the Reader | Need-relative contribution can be measured for quote preparation, but rights-bearing BTD is not minted or transferred | selected-fit root, threshold root, verification root | +| `need-fit-assetpack-synthesized` | AssetPack synthesis pipeline | Source-bearing pack material may exist internally, but Reader-visible output is only a source-safe preview | Need-relative BTD scalar volume may be computed for quote; it is not settled BTD | synthesis root, withheld-source bundle root, preview boundary root | +| `need-fit-assetpack-quoted` | Reading procurement and quote authority | Source-safe measurements, metadata, quality posture, BTD volume/range, BTC quote, expiration, and proof roots only | Quoteable BTD volume exists because a reviewed Need and selected Fit set exist; rights are still unpaid and untransferred | quote root, budget approval root when required, expiry root | +| `settlement-observed` | BTC observation and ledger/database journal | Still source-safe to the Reader until settlement finality and BTD transfer are proven | BTC payment is observed but not final; BTD rights are not yet authoritative | BTC observation root, journal root, reconciliation root | +| `btd-settled-rights-transferred` | BTD and settlement authority | Source unlock is authorized for the paying Reader and still withheld from other parties | Rights-bearing BTD is minted/mined/assigned for the Need-Fit AssetPack according to the later BTD state machine | final settlement root, BTD rights receipt, source-to-shares root | +| `source-unlocked-delivery` | Repository delivery authority | Full source-bearing AssetPack delivery is visible only to the entitled Reader boundary, such as the target repository pull request | BTD rights authorize delivery and future ownership/read/use boundaries | source unlock root, repository delivery receipt, pull request root | +| `compensated-and-reconciled` | Contributor compensation and Packs accounting | `/packs` shows source-safe settlement, delivery, and compensation readback; protected source remains boundary-scoped | Source-to-shares allocation and BTC compensation statements reconcile to settlement truth | compensation statement root, ledger/database/storage reconciliation root | +| `repair-required` | Operator repair | Only source-safe failure class, blocker, repair command, and proof roots are visible | No state may advance until the failed transition is repaired and replayed | repair case root, replay root, operator action root | + +Transition law: + +- A deposit option may transition to `depository-assetpack-admitted` only after + depositor approval, policy eligibility, source-safety verification, and + storage/index projection. +- A Depository AssetPack may transition into Reading only through Finding Fits; + the search may recall many candidates above threshold, and the selected Fit + set may contain one or many admitted Depository AssetPacks. +- The Need-Fit AssetPack is synthesized from the reviewed Need plus the selected + Fit set. It is a new Need-relative AssetPack state, not a disclosure of the + underlying admitted Depository AssetPacks. +- The Reader may review the Need-Fit preview and quote, but may not see source + before BTC settlement finality and BTD rights transfer. +- BTD final scalar knowledge-volume is Need-relative. It may be calculated for + quote only after the reviewed Need, selected Fit set, and synthesized + Need-Fit AssetPack exist; it becomes rights-bearing only after settlement. +- BTC payment observation, BTC finality, BTD rights transfer, source unlock, + repository delivery, source-to-shares compensation, and reconciliation are + distinct states and must not be represented as synonyms. +- Any missing proof root, stale storage projection, failed source-safety check, + failed payment finality, failed rights transfer, failed delivery, or failed + compensation reconciliation moves the object to `repair-required`. + +Acceptance for this atom: later V46 specification may refine field names and +proof root schemas, but it must preserve this lifecycle ordering, exact state +separation, source visibility boundaries, Need-relative BTD calculation +condition, one-to-many Finding Fits input set, BTC settlement-before-source law, +and repair-required fail-closed posture. + +## V46 protocol atom 3: BTD scalar-volume state machine + +Audit classification: V45 names BTD range, rights transfer, BTC settlement, +and source-to-shares accounting, and the BTD package already owns semantic +volume measurement, measureminting, range allocation, mint receipts, read +receipts, rights transfer receipts, and contributor allocation. V46 must make +the protocol meaning explicit: BTD is first the weighted scalar +knowledge-volume of a Need-Fit AssetPack, and only its settled form carries +rights, source unlock, ownership boundaries, and contributor allocation +context. + +Protocol-law statement: + +BTD is the non-fungible, proof-addressed scalar unit of technical knowledge +volume for a Need-Fit AssetPack. Deposit-time measurement may estimate BTD +potential, but final BTD size is only computed after a reviewed Need, selected +Fit set, synthesized Need-Fit AssetPack, deterministic measurement weights, +dedupe proofs, and source-safe proof roots exist. BTC remains the payment +asset. BTD is not money, not a spendable balance, not raw source, not a +fungible exchange token, and not final merely because a deposit was admitted. + +The canonical BTD state machine is: + +| State | Meaning | Required inputs | Output posture | +| --- | --- | --- | --- | +| `btd-not-applicable` | Raw source, a Read Request, or an unreviewed pipeline output is not BTD. | none | no BTD claim | +| `btd-potential-measured` | Deposit or market intelligence has source-safe measurements that may estimate future utility. | deposit option root, source-safety root, measurement roots | potential/range language only; no final BTD size | +| `need-fit-measurements-admitted` | A reviewed Need, selected Fit set, and synthesized Need-Fit AssetPack admit measurement rows. | accepted Need root, selected Fit root, synthesis root, dedupe roots | admissible measurement vector | +| `measurement-weight-policy-locked` | Deterministic measurement weights are bound before scalar volume calculation. | weight policy id/hash, measurement taxonomy root, versioned formula root | no post hoc reweighting | +| `weighted-scalar-volume-computed` | Each admissible measurement contributes `normalizedMeasurementVolume * measurementWeight`, summed with fixed-point arithmetic into BTD scalar knowledge-volume. | admitted measurement vector, weight policy root, dedupe roots, proof roots | Need-relative normalized BTD volume | +| `btd-quantized` | The normalized scalar volume is quantized into protocol BTD cell count or zero-cell tail posture. | normalized BTD volume, quantization root, fixed supply parameters | quoteable BTD token count or zero-cell receipt | +| `measuremint-applied` | The measureminting curve applies cumulative admitted measurement against fixed supply. | prior measuremint state, normalized BTD volume, settlement journal root, access policy hash | measuremint receipt and next measuremint state | +| `btd-range-assigned` | A non-overlapping AssetPack BTD range is assigned when positive cells are minted. | measuremint receipt, supply state, range allocation inputs | source-safe mint receipt; no Reader rights yet | +| `btd-quote-bound` | The BTD volume/range and access policy are bound to a BTC quote for the Reader. | BTD receipt roots, quote root, budget approval root when required | source-safe quote; no payment finality | +| `btd-rights-pending` | BTC payment may be prepared, signed, broadcast, or observed, but finality and rights transfer are incomplete. | payment observation root, quote root, ledger journal root | source remains locked | +| `btd-rights-transferred` | Confirmed BTC settlement authorizes BTD rights transfer to the Reader boundary. | confirmed BTC finality root, rights transfer receipt, ledger projection root | rights-bearing BTD and source unlock authority | +| `btd-source-to-shares-allocated` | Contributor compensation is allocated from the paid Need-Fit settlement. | source-to-shares proof, BTD range slices, BTC payment observation, contributor roots | allocation and compensation readback | +| `btd-repair-required` | Measurement, weight, mint, range, quote, payment, rights, allocation, or reconciliation proof is missing or stale. | repair blocker root | fail-closed repair only | + +Measurement law: + +- Every final BTD measurement row must be Need-relative, accepted, deduped, + proof-rooted, and tied to the selected Fit set that contributed to the + synthesized Need-Fit AssetPack. +- Measurement weights are deterministic protocol policy, not UI preference, + operator discretion, model confidence alone, or depositor-provided pricing. +- Scalar volume calculation uses fixed-point or integer arithmetic. Floating + rounding, hidden post-processing, or undocumented prompt-derived weights are + not protocol-valid. +- Deposit-time measurements may inform depositor review, Depository search, + market intelligence, and BTD potential, but they cannot mint, transfer, + quote final BTD, unlock source, or allocate contributor shares without a + reviewed Need and selected Fit set. +- Positive BTD cells must conserve fixed supply and occupy a contiguous, + non-overlapping AssetPack range. Zero-cell tail receipts remain valid + measuremint evidence but cannot be represented as positive rights-bearing + BTD cells. +- Rights-bearing BTD exists only after BTC settlement finality and BTD rights + transfer. Before that, BTD volume/range is preview or quote state only. +- Source-to-shares uses the settled Need-Fit AssetPack, selected Fit deposits, + BTD range slices, and BTC payment observation to allocate contributor + compensation; it must not be confused with scalar-volume calculation. + +Acceptance for this atom: later V46 specification may refine measurement +taxonomy and formula constants, but it must preserve BTD as Need-relative +weighted scalar knowledge-volume, deposit-time BTD potential as non-final, +deterministic fixed-point measurement weighting, measuremint/range conservation, +zero-cell tail posture, BTC-before-rights law, and source-to-shares as +post-settlement contributor allocation rather than BTD size. + +## V46 protocol atom 4: BTC settlement state machine + +Audit classification: V45 correctly names estimates, quotes, observed payment, +final settlement, contributor allocation, delivery, and repair as distinct +economic labels. The implementation already separates BTC fee quotes, PSBT +handoff, broadcast observation, finality receipts, settlement unlock, +source-to-shares, and compensation statements. V46 must make BTC settlement +law explicit so that a quote, a broadcast transaction, an observed payment, +confirmed finality, BTD rights transfer, source delivery, refund/escalation, +and contributor compensation cannot be collapsed by an interface, pipeline, +or operator. + +Protocol-law statement: + +BTC is Bitcode settlement money and payment truth. A BTC quote is a +source-safe procurement offer bound to a reviewed Need, selected Fit set, +synthesized Need-Fit AssetPack, BTD scalar-volume/range, deterministic +share-to-fee policy, wallet authority, network, expiry, and proof roots. A BTC +payment is not final merely because a transaction is prepared, signed, +broadcast, visible in mempool, or observed by a provider. Source unlock, +rights-bearing BTD transfer, delivery, and contributor compensation require +confirmed BTC finality, quote/payment conservation, ledger/database/storage +readback, and repair-free settlement receipts. + +The canonical BTC settlement state machine is: + +| State | Meaning | Required inputs | Output posture | +| --- | --- | --- | --- | +| `btc-not-quoteable` | No reviewed Need-Fit quote can exist yet. | reviewed Need missing, selected Fit set missing, BTD quote posture missing, wallet authority missing, or policy blocker | no BTC quote claim | +| `btc-quote-issued` | Deterministic sats quote is created for the Reader. | quote root, BTD scalar-volume/range roots, deterministic share-to-fee policy root, network, expiry, budget policy | source-safe offer only; no payment | +| `btc-quote-accepted` | Reader and organization authority accept the quote before expiry. | accepted quote root, buyer authorization root, wallet authority root, budget approval root when required | PSBT preparation admitted | +| `btc-quote-inactive` | Quote is expired, superseded, failed, revoked, or mismatched. | inactive quote root and reason | payment against this quote cannot unlock rights | +| `btc-wallet-ready` | Reader wallet can sign without server custody. | wallet signer session, network match, PSBT signing capability, no-server-custody proof | PSBT handoff may proceed | +| `btc-psbt-prepared` | Settlement transaction is prepared but unsigned. | accepted quote, wallet-ready proof, terminal journal root, PSBT root | no payment observation | +| `btc-psbt-signed` | Reader has signed the transaction. | prepared PSBT root, wallet authorization proof, signed PSBT root | broadcast admitted; no finality | +| `btc-broadcast-submitted` | Signed transaction has been submitted to the Bitcoin network. | signed transaction root, txid, network root, provider observation root | observed payment pending finality | +| `btc-payment-observed` | Debit, credit, txid, amount, payer, payee, and network are observed. | payment observation root, expected sats, observed debit sats, observed credit sats, txid | source remains locked; finality pending | +| `btc-payment-mismatch-repair-required` | Observed payment does not conserve the accepted quote or violates wallet/network policy. | mismatch proof root, repair blocker root | repair, replacement, refund, or escalation only | +| `btc-finality-confirmed` | Bitcoin finality satisfies the configured confirmation/finality policy. | finality receipt, confirmations, txid, block/reorg readback, quote/payment conservation root | settlement can authorize BTD rights transfer | +| `btc-replaced-reorged-or-failed` | Transaction was replaced, reorged out, failed, or became non-final. | replacement, reorg, or failure root | source remains locked; repair or refund/escalation required | +| `btc-settlement-finalized` | Quote, payment, finality, ledger, database, object storage, and source-safe readback agree. | finality root, ledger/database/storage reconciliation root, terminal journal root, settlement unlock root | BTD rights transfer and delivery unlock may proceed | +| `btc-contributor-compensation-routable` | Final settlement is available to source-to-shares allocation and contributor statements. | finalized settlement root, BTD range slices, source-to-shares proof, contributor roots | compensation statements and treasury routes may be issued | +| `btc-refund-or-escalation-required` | A payment or quote cannot be accepted as final settlement, and value movement or operator review is required. | refund/escalation case root, payment evidence, policy reason | no rights, no source unlock, no contributor compensation | +| `btc-settlement-repair-required` | Any quote, wallet, PSBT, broadcast, observation, finality, readback, unlock, or compensation proof is missing or stale. | repair blocker root | fail-closed repair only | + +Settlement law: + +- A quote is not an estimate. It must be denominated in BTC sats, bind the + BTD scalar-volume/range and deterministic share-to-fee policy, name its + network and expiry, and carry a source-safe quote root. +- A quote must be accepted before PSBT preparation. Expired, superseded, + failed, revoked, wrong-network, wrong-wallet, or mismatched quotes cannot + unlock rights even if a payment is later observed. +- Bitcode must never take server custody of wallet private material. The + Reader signs through a wallet session that proves network, capability, + authorization, and no-server-custody posture. +- Prepared, signed, broadcast, and observed states are not final settlement. + They cannot transfer BTD rights, unlock source, deliver a pull request, or + allocate contributor compensation. +- Payment observation must conserve the accepted quote: expected sats, + observed debit sats, observed credit sats, payer, payee, network, txid, and + quote root must reconcile. Drift enters repair, refund, or escalation. +- BTC finality requires the configured confirmation/finality policy and must + fail closed on replacement, reorg, failure, stale provider readback, or + missing ledger/database/object-storage reconciliation. +- Refund or escalation is a repair path, not a successful purchase path. It + does not transfer BTD rights, disclose source, satisfy contributor + compensation, or convert an inactive quote into final settlement. +- Contributor compensation is routable only after final settlement and must be + derived from source-to-shares, BTD range slices, contributor roots, and the + settled BTC payment. Estimated depositor earning ranges remain non-final. +- Product surfaces may show quote, observed payment, finality, repair, + refund/escalation, and compensation states, but they must not expose private + settlement payloads, wallet private material, unpaid AssetPack source, raw + protected source, raw prompts, or raw provider responses. + +Acceptance for this atom: later V46 specification may refine confirmation +thresholds, wallet-provider adapters, refund mechanisms, and compensation +route mechanics, but it must preserve BTC as settlement money, quote as +source-safe deterministic procurement offer, observed payment as non-final, +confirmed finality as prerequisite to BTD rights transfer, source unlock only +after settlement readback, refund/escalation as fail-closed repair, and +contributor compensation as post-finality source-to-shares allocation. + +## V46 protocol-development atom 5: notes-to-spec consolidation before parity + +Audit classification: V46 is intentionally opening through small notes-level +specification atoms because the protocol law must be correct atom by atom +before it is expanded into a full canonical candidate. The missing process +precision was the boundary between notes and implementation parity: accepted +notes are not enough to audit implementations. V46 must first consolidate the +accepted notes into the formal V46 specification family, then audit source +against that formal specification. + +Protocol-development law: + +After the notes-level specification atoms are accepted, V46 must run a formal +specification consolidation gate before any implementation parity matrix gate. +That consolidation gate updates the V46 specification family from the accepted +notes, reconciles terminology across the full document set, preserves the V45 +active canon pointer until promotion, and validates that the V46 formal +specification is internally coherent before implementation auditing begins. +The implementation parity matrix must audit against the formal V46 +specification family, not against loose notes, branch discussion, PR bodies, +or operator memory. + +The required sequence is: + +| Movement | Output | Forbidden shortcut | +| --- | --- | --- | +| `notes-specification-atoms` | Accepted notes-level protocol atoms, each merged through its gate branch | combining unresolved atoms into a broad parity or implementation claim | +| `formal-specification-consolidation` | Updated V46 specification family with accepted atoms reconciled into protocol law | auditing implementation directly from notes or PR discussion | +| `implementation-parity-audit` | V46 parity matrix comparing formal specification to code, tests, proofs, workflows, docs, generated artifacts, and interfaces | claiming parity before the formal specification exists | +| `grouped-implementation-closure` | Grouped implementation gates derived from the accepted parity matrix | implementing speculative behavior before the parity matrix is accepted | + +Consolidation law: + +- The formal specification consolidation gate must update the V46 spec-family + documents before any implementation audit begins. +- The consolidation gate must preserve `BITCODE_SPEC.txt -> V45` while V46 is + still a draft target; promotion remains a later gate. +- The consolidation gate must reconcile accepted notes into one coherent V46 + protocol law, including AssetPack lifecycle, BTD scalar-volume, BTC + settlement, source safety, interface authority, proof roots, and operational + boundaries. +- The parity matrix gate must cite the formal V46 specification family as its + source of truth. It may cite notes only as historical provenance for why the + formal specification changed. +- Implementation gates must be grouped from parity gaps found against the + formal specification, not from isolated notes, UI desire, or ad hoc code + inspection. + +Acceptance for this atom: later V46 sequencing may add more notes atoms or +split formal specification documents further, but it must preserve +notes-specification atoms before formal spec consolidation, formal spec +consolidation before implementation parity auditing, parity auditing before +grouped implementation closure, and V45 as the active canon pointer until V46 +promotion. + +## V46 protocol atom 6: interface authority and disclosure boundaries + +Audit classification: V45 names `/packs`, `/read`, `/deposit`, API/MCP, +ChatGPT App, Bitcode Chat, public docs, and landing pages as interface +surfaces, and it strongly protects source-safe disclosure before settlement. +The remaining protocol gap is exact interface authority: which statements each +surface may make, which actions each surface may initiate, and what may be +shown before settlement, after preview, after quote, after payment observation, +after finality, after BTD rights transfer, and after repository delivery. + +Protocol-law statement: + +All Bitcode interfaces are protocol windows into the same AssetPack, BTD, BTC, +proof, ledger, database, storage, and delivery state. No interface is an +independent source of protocol law. A user-visible statement is valid only when +it is source-safe for that party, names the current protocol state, and can be +traced to the required proof root, ledger/database readback, storage root, +workflow receipt, or generated canonical specification. + +Canonical interface authority is: + +| Surface | Authority | Forbidden claim or action | +| --- | --- | --- | +| `/deposit` | Depositor supply formation: connect source, synthesize deposit AssetPack options, review source-owner measurements, approve or reject Depository admission, and view source-safe earning potential. | claiming final BTD size, reader ownership, final BTC proceeds, or public source visibility before a paid Need-Fit settlement exists | +| `/read` | Reader demand procurement: request a Read, review or resynthesize the Need, request Finding Fits, review source-safe Need-Fit preview, accept quote, pay, and receive entitled repository delivery. | exposing unpaid AssetPack source, treating observed payment as final, bypassing organization/wallet authority, or delivering before BTD rights transfer | +| `/packs` | Searchable master-detail projection of network activity, AssetPack states, quotes, repairs, proof roots, delivery receipts, and compensation statements. | becoming the source of truth without ledger/database/storage readback or showing private source to non-entitled parties | +| API/MCP | Machine interface for the same workflows, read models, proofs, and repair commands exposed under explicit policy and capability boundaries. | returning more data than the corresponding human interface is entitled to see or mutating state without the same proof obligations | +| ChatGPT App | Conversational interface for guided Bitcode actions, summaries, confirmations, and state inspection. | presenting conversational text as final settlement, rights transfer, source unlock, or canonical law without authoritative readback | +| Bitcode Chat | Product conversation overlay for assistance, explanations, workflow navigation, telemetry summarization, and operator-facing repair guidance. | leaking raw prompts, raw provider responses, protected source, wallet private material, or unpaid source-bearing pack content | +| Public docs and landing pages | Explanatory surface for protocol claims, public product positioning, and non-transactional education. | representing live transaction state, buyer entitlement, seller proceeds, or private network facts without a linked authoritative surface | + +Canonical disclosure boundary is: + +| Boundary | User-visible statements allowed | User-visible statements forbidden | +| --- | --- | --- | +| `before-settlement` | source-safe state labels, public protocol explanation, party-owned source to that party, deposit measurements, Need text, candidate counts, proof roots, estimates, and repair blockers | unpaid AssetPack source, raw protected source, secrets, raw prompts, raw provider responses, final rights, final BTD ownership, or final BTC settlement | +| `after-preview` | source-safe Need-Fit measurements, selected Fit set identities when source-safe, rankings, quality/confidence, BTD range or potential, preview proof roots, and why the preview may be worth buying | source-bearing implementation contents, private candidate source, contributor secrets, or assertions that the Reader already owns the AssetPack | +| `after-quote` | deterministic BTC quote, quote expiry, wallet/network, BTD volume/range posture, authorization requirements, quote root, and explicit non-final status | payment-final, rights-transferred, source-unlocked, delivered, or contributor-compensated statements | +| `after-payment-observation` | observed txid, network, amount, payer/payee, quote match or mismatch, mempool/provider evidence, and pending finality/repair posture | treating observation as confirmed finality, unlocking source, transferring BTD rights, or routing contributor compensation | +| `after-finality` | confirmation/finality receipt, finalized payment evidence, settlement readback progress, and remaining rights-transfer or repair requirements | exposing source before settlement readback and BTD rights transfer or claiming delivery before repository delivery receipt | +| `after-btd-rights-transfer` | entitled Reader boundary, source unlock authorization, rights receipt, BTD range ownership, and delivery preparation state | making the source public, granting non-payer access, or claiming contributor compensation before source-to-shares allocation | +| `after-repository-delivery` | delivery PR/commit receipt, entitled repository visibility, delivered AssetPack root, reconciliation state, and source-safe contributor compensation statements | exposing source outside the entitled repository or masking unsettled repair, compensation, or ledger/database mismatch states | + +Interface disclosure law: + +- Every interface must fail closed to the narrowest source-safe state when proof + roots, ledger/database readback, storage roots, wallet authority, or delivery + receipts are missing. +- Human and machine interfaces must use the same entitlement boundary. API/MCP, + ChatGPT App, and Bitcode Chat may not reveal data that `/read`, `/deposit`, + or `/packs` would withhold from the same actor in the same state. +- Public docs and landing pages may explain the protocol and commercial + experience, but they are not transaction state, settlement evidence, source + entitlement, or compensation evidence. +- Conversational interfaces may guide and summarize, but all final claims about + quote, payment, BTD rights, source unlock, delivery, and compensation must be + backed by authoritative state readback. +- Interface copy may be concise and elegant, but it must never collapse preview, + quote, observed payment, finality, rights transfer, delivery, and + compensation into a single "done" state. + +Acceptance for this atom: later V46 formal specification and implementation +work may refine wording and UI shapes, but it must preserve one protocol law +across all surfaces, source-safe user-visible statements before paid +entitlement, explicit non-final language for preview/quote/payment +observation, authoritative readback for final settlement and rights transfer, +and repository delivery visibility only for the entitled Reader boundary. + +## V46 protocol atom 7: proof readback and operational authority + +Audit classification: V45 establishes generated specification proof, +ledgerized journaling, telemetry, database/storage synchronization, workflow +checks, and source-safe repair posture. The remaining gap is evidence +authority: which operational artifacts can advance protocol state, which are +only observability, and what happens when proof, ledger, database, storage, +telemetry, provider, or delivery evidence disagrees. + +Protocol-law statement: + +Bitcode state advances only by proof-backed readback. No UI row, conversation +message, streamed telemetry item, route response, external provider event, or +workflow log can alone advance AssetPack lifecycle, BTD rights, BTC settlement, +source unlock, delivery, or contributor compensation. The advancing artifact +must be paired with the required proof root and read back from the appropriate +ledger, database, storage, wallet, provider, or repository boundary. + +Canonical evidence authority is: + +| Evidence class | Protocol authority | Limit | +| --- | --- | --- | +| canonical specification and generated proof appendix | defines protocol law, required proof families, and promotion-grade validation posture | not a live transaction, wallet, source, or delivery receipt | +| execution/workflow receipt | proves a pipeline, PTRR agent, tool, route, workflow, or validation step ran with typed inputs/outputs and status | not economic finality and not source entitlement unless joined to settlement and rights readback | +| ledger journal | records protocol-economic state transitions, BTD/BTC journals, repair states, and auditable event ordering | cannot override Bitcoin finality, protected storage, or repository delivery evidence | +| database projection | serves queryable application state, interface read models, and reconciliation indexes | cannot be treated as final when it diverges from ledger, storage, wallet, or delivery roots | +| object storage and protected-source roots | prove content custody, source-safe preview objects, source-bearing withheld pack objects, and delivery payload roots | cannot disclose source without entitlement, rights transfer, and delivery authority | +| telemetry stream | makes running phases, agents, tools, prompts, outputs, timings, and errors observable | observability only; telemetry is not settlement, rights transfer, or source unlock | +| wallet/provider receipt | supplies quote, PSBT, broadcast, observation, txid, block/finality, or network evidence | provider observation is not final settlement until reconciled with quote, wallet authority, and finality policy | +| repository delivery receipt | proves pull request, branch, commit, patch, or delivery artifact reached the entitled repository boundary | not public source permission and not contributor compensation by itself | + +Canonical readback requirements are: + +| State advancement | Required readback before advancement | +| --- | --- | +| Depository admission | depositor approval root, source-safety proof, policy eligibility, protected-source storage root, Depository index root, ledger/database projection | +| reviewed Need acceptance | Read Request root, Need synthesis receipt, user review/approval root, database read model, telemetry summary root | +| Finding Fits selection | search receipt, candidate provenance roots, measurement/ranking roots, source-safe Fit set root, depository readback | +| Need-Fit AssetPack synthesis | selected Fit set root, synthesis execution receipt, source-bearing withheld storage root, source-safe preview root, measurement/BTD posture root | +| BTC quote issuance | reviewed Need root, selected Fit set root, Need-Fit AssetPack root, BTD volume/range roots, deterministic quote root, wallet/network policy root | +| BTC payment observation | accepted quote root, wallet authority root, provider observation, txid/network/amount readback, mismatch classification if any | +| BTC settlement finalization | payment observation, configured finality receipt, quote/payment conservation, ledger/database/storage agreement, repair-free settlement receipt | +| BTD rights transfer | finalized settlement root, BTD range/rights receipt, entitled Reader boundary, ledger/database readback | +| source unlock and repository delivery | rights transfer root, protected-source object readback, delivery payload root, repository PR/commit receipt, entitled repository boundary | +| contributor compensation | finalized settlement root, source-to-shares allocation root, contributor roots, compensation statement, ledger/database reconciliation | + +Operational repair law: + +- If any required readback is missing, stale, contradictory, or outside the + allowed actor/network/source boundary, the state must remain in or return to + a source-safe repair state. +- Repair state may expose failure class, blocker, retry command, proof root + identifiers, and operator-safe telemetry, but not unpaid source, secrets, + wallet private material, raw provider payloads, raw prompts, or raw model + responses. +- Computation hosts, sandbox executions, workflow runners, browser proofs, and + API routes may produce receipts, but they do not own protocol truth. They + must write/read through the canonical proof, ledger, database, storage, + wallet, and repository boundaries. +- If evidence classes conflict, Bitcode must prefer the stricter + source-safety and economic-finality posture until reconciliation proves the + correct state. + +Acceptance for this atom: later V46 formal specification and implementation +work may split the readback tables, but it must preserve proof-backed readback +as the only state advancement mechanism, telemetry as observability rather +than authority, Bitcoin finality as payment truth, storage and repository roots +as delivery truth, database projections as reconciled read models, and +fail-closed repair for every evidence mismatch. + +## V46 protocol-development atom 8: gate taxonomy and formal spec readiness + +Audit classification: the opening V46 questions have now been reduced into +accepted notes-level protocol atoms for Bitcode identity, AssetPack lifecycle, +BTD scalar-volume, BTC settlement, notes-to-spec sequencing, interface +authority, disclosure boundaries, proof readback, and operational authority. +The remaining opening question is process taxonomy: which gates are allowed to +change notes, formal specification, parity matrices, proofs, interfaces, +implementations, rehearsals, and promotion state. + +Protocol-development law: + +V46 gates must be classified before the formal specification consolidation +begins. A gate's class defines what it may change, what it must not claim, and +which proof obligations close it. No gate may claim a stronger class than its +accepted artifacts prove. Notes-level atom gates are discussion-to-law +preparation; formal specification gates are draft canon authoring; parity gates +are implementation audit; proof-only gates harden validation; interface-only +gates adjust protocol windows; implementation gates close audited parity gaps; +rehearsal gates prove whole-system behavior; promotion gates alone may advance +`BITCODE_SPEC.txt`. + +The canonical V46 gate taxonomy is: + +| Gate class | Allowed output | Required closure evidence | Forbidden shortcut | +| --- | --- | --- | --- | +| `notes-specification-atom` | one small accepted note atom in `BITCODE_SPEC_V46_NOTES.md` plus its checker | local atom check, prior atom checks, draft-canon posture check, clean diff, PR into `version/v46` | changing source behavior, claiming implementation parity, or updating `BITCODE_SPEC.txt` | +| `formal-specification-consolidation` | V46 specification family documents updated from all accepted notes atoms | spec-family validation, terminology reconciliation, prior notes checks, generated proof posture when applicable | auditing implementation from loose notes or leaving accepted atoms outside the formal spec | +| `specification-parity-matrix` | matrix mapping formal V46 law to code, tests, proofs, workflows, docs, generated artifacts, and interfaces | cited formal V46 specification sections, source-grounded audit, categorized gaps, closure groups | using PR discussion, memory, or notes as primary implementation authority | +| `proof-only` | validators, generated proofs, workflow checks, replay checks, or CI hardening | deterministic command output, CI greenability, no product-state mutation unless specified | silently changing protocol behavior under validation work | +| `interface-only` | source-safe UX/UI, route, API/MCP, ChatGPT App, Bitcode Chat, docs, or landing-page presentation changes | entitlement/disclosure trace to formal spec, accessible UI proof when relevant, read-model tests | making interface copy or telemetry authoritative over protocol readback | +| `implementation` | commercial source code, schemas, APIs, pipelines, storage, ledger, settlement, delivery, or package behavior closing accepted parity gaps | focused tests, integration proof where relevant, source-safety checks, parity row closure | implementing behavior not traced to formal spec and parity matrix | +| `rehearsal` | end-to-end proof run, browser/API/database/ledger/storage replay, staged or local system validation | replayable receipts, logs, screenshots when relevant, ledger/database/storage reconciliation | counting a mocked unit test as whole-system commercial proof | +| `promotion` | formal version promotion PR into `main` and promotion workflow result | complete gate ledger, green promotion workflow, generated proof update, standalone `BITCODE_SPEC.txt` pointer update after validations | promoting while accepted gates, parity gaps, proofs, or required checks remain open | + +Readiness law: + +- The notes-specification atom set for the V46 opening is complete enough to + begin formal specification consolidation after this atom is accepted. +- Formal consolidation must preserve the accepted semantics of all notes atoms: + AssetPack as commodity, Need-relative BTD scalar-volume, BTC settlement + finality, source-safe disclosure boundaries, proof-backed readback, and + fail-closed repair. +- Formal consolidation may reorganize, rename headings, or split sections for + clarity, but it must not weaken or omit accepted atom law without an explicit + new notes-specification atom. +- After consolidation, the parity matrix gate must treat the formal V46 + specification family as the only implementation-audit authority. +- Proof-only and interface-only gates may occur after the parity matrix when + their changes close matrix rows; they are not loopholes for speculative + product behavior. +- Promotion remains prohibited until formal specification, parity, grouped + implementation, proof, interface, rehearsal, and promotion-readiness gates + are accepted according to this taxonomy. + +Acceptance for this atom: later V46 process work may split gate classes or add +stricter closure evidence, but it must preserve class-scoped authority, +formal-specification consolidation as the next movement after accepted notes, +parity auditing from the formal V46 specification, implementation only from +accepted parity gaps, and `BITCODE_SPEC.txt` promotion only through the +promotion gate. + +## Non-goals during V46 opening + +- Do not implement V46 gate behavior before the V46 intent discussion is + completed. +- Do not rename V45 canon surfaces while the active canonical pointer remains + V45. +- Do not weaken Bitcoin, BTD, GitHub, compute, storage, build/process, + proof, or source-safety boundaries to simplify the opening notes. diff --git a/BITCODE_SPEC_V46_PARITY_MATRIX.md b/BITCODE_SPEC_V46_PARITY_MATRIX.md new file mode 100644 index 000000000..b562dc1ca --- /dev/null +++ b/BITCODE_SPEC_V46_PARITY_MATRIX.md @@ -0,0 +1,115 @@ +# Bitcode Spec V46 Parity Matrix + +## Status + +- Version: `V46` +- V46 state: draft opening; V46 parity work is not yet audited and Gate 1 only establishes the draft roadmap and validation boundary +- Current canonical/latest target: `V45` +- Prior canonical anchor: `BITCODE_SPEC_V45.md` +- Prior generated proof appendix: `BITCODE_SPEC_V45_PROVEN.md` +- Generated structured artifact inventory: draft `.bitcode/v46-spec-family-report.json` and `.bitcode/v46-canonical-input-report.json`; later V46 gates must authorize proof-family, rehearsal, promotion-readiness, and generated proof appendix artifacts before they become required V46 evidence +- Source parity state: V46 source parity has not been audited; Gate 1 opens the draft-target roadmap and validation boundary only +- Notes companion: `BITCODE_SPEC_V46_NOTES.md` +- Spec companion: `BITCODE_SPEC_V46.md` +- Delta companion: `BITCODE_SPEC_V46_DELTA.md` +- Scope: V46 draft parity matrix for commercial protocol comprehension, public/operator explanation, source-safe interface claims, and proof-readable launch posture over promoted V45 knowledge commoditization law +- Last fully realized canonical target preserved in source: `V45` + +## Purpose + +This matrix opens V46 parity work. It is intentionally draft-only: it records +the initial audit surface that later V46 gates must turn into source-grounded +implementation, proof, documentation, interface, and rehearsal rows. The +current authority remains V45. + +Draft judgment vocabulary: + +- `draft-required`: V46 must specify and later audit this area. +- `implemented prerequisite`: V45 source already contains material that V46 may + reuse or clarify, but V46 has not yet audited it for closure. +- `accepted boundary`: V45 law remains active and must not be weakened. +- `pending`: V46 has not yet accepted a parity or implementation gate. + +## Audit basis + +Gate 1 audit inputs are `BITCODE_SPEC.txt`, `BITCODE_SPEC_V45.md`, +`BITCODE_SPEC_V45_DELTA.md`, `BITCODE_SPEC_V45_NOTES.md`, +`BITCODE_SPEC_V45_PARITY_MATRIX.md`, `BITCODE_SPEC_V45_PROVEN.md`, +`BITCODE_SPEC_V46.md`, `BITCODE_SPEC_V46_DELTA.md`, +`BITCODE_SPEC_V46_NOTES.md`, this draft parity matrix, `SPECIFICATIONS_ROADMAP.md`, +branch/workflow rules, and the existing product surfaces named by V45: +`/deposit`, `/read`, `/packs`, API/MCP, ChatGPT App, Bitcode Chat, public docs, +landing page, proof roots, ledger/database/storage readback, wallet/provider +receipts, and repository delivery receipts. + +## Source Evidence Map + +Gate 1 does not claim source closure. Later V46 parity gates must inspect the +source files and generated artifacts that implement or explain each row. + +| Evidence area | Current source evidence | Audit reading | +| --- | --- | --- | +| Active canon posture | `BITCODE_SPEC.txt`, `BITCODE_SPEC_V45.md`, `BITCODE_SPEC_V45_PROVEN.md`, spec-family and canon-posture checkers | V45 is active canon; V46 is draft target only. | +| Product routes | `/deposit`, `/read`, `/packs`, and `/exchange` compatibility redirect | V46 must make route claims commercially legible without source leakage or stale Exchange-first framing. | +| Reading and deposit pipelines | Reading, Finding Fits, AssetPack preview, settlement, deposit option, and admission packages named by V45 | V46 may clarify comprehension and claim boundaries, but implementation parity is pending. | +| Interfaces | API/MCP, ChatGPT App, Bitcode Chat, package consumers, public docs, and landing page | V46 must decide which statements are protocol-authoritative and how each surface exposes proof readback. | +| Proof and operations | Generated proof appendices, `.bitcode` artifacts, workflows, ledger/database/storage readback, wallet/provider receipts, repository receipts | V46 must keep proof-backed state advancement clear to non-operator readers. | + +## V46 Implementation Matrix + +| Area | Required V46 result | Current judgment | Source-grounded finding | Closure gate | +| --- | --- | --- | --- | --- | +| Commercial protocol comprehension | Explain Bitcode as knowledge commoditization without reducing BTD to a read-right or AssetPack to raw source | draft-required | V45 law is precise but launch-facing surfaces need a shared claim taxonomy and readback language. | Gate 2 | +| Claim taxonomy | Separate protocol law, product guidance, operator evidence, investor framing, telemetry, preview, quote, settlement, rights, and delivery claims | draft-required | Gate 1 names the need; no taxonomy is source-audited yet. | Gate 2 | +| Public and operator docs | Public docs, landing copy, README/operator docs, and route help stay accurate, source-safe, and non-overclaiming | draft-required | Existing docs inherit V45 law but need V46 claim-boundary audit. | Gate 3 | +| Product route comprehension | `/packs`, `/read`, and `/deposit` expose low-detail default UX with expandable proof and consistent commercial terms | implemented prerequisite | V43-V45 product routes exist; V46 must audit copy, state labels, and proof readback against commercial comprehension. | Gate 4 | +| Machine and conversation interfaces | API/MCP, ChatGPT App, Bitcode Chat, and package consumers expose the same claim boundaries as website routes | draft-required | Prior interface parity exists, but V46 needs launch-facing readback contracts. | Gate 5 | +| Proof readback explanation | Users and operators can understand why proof, ledger, database, storage, wallet/provider, and repository receipts have different authority | draft-required | V45 requires proof-backed state advancement; V46 must make it externally legible. | Gate 6 | +| Local interface rehearsal | A source-safe local rehearsal verifies docs/routes/interfaces explain the protocol without exposing unpaid source | pending | No V46 rehearsal is authorized in Gate 1. | Gate 7 | +| Promotion readiness | V46 can promote only after all accepted comprehension, parity, proof, interface, rehearsal, and source-safety gates close | accepted boundary | V45 remains active canon until a future promotion workflow advances the pointer. | Gate 8 | + +## V46 Implementation Checklist + +| Area | Required V46 result | Current judgment | Source-grounded finding | Closure gate | +| --- | --- | --- | --- | --- | +| Active pointer truth | `BITCODE_SPEC.txt` remains V45 during V46 draft work | accepted boundary | Gate 1 preserves active V45 / draft V46 posture. | Gate 1 | +| Draft files | V46 SPEC, DELTA, NOTES, and PARITY files exist and name draft posture | draft-required | Gate 1 creates and validates the draft family. | Gate 1 | +| CI posture | Gate and canon workflows validate active V45 plus draft V46 when V46 files exist | draft-required | Gate 1 wires the checker into workflows. | Gate 1 | +| Source safety | No V46 explanatory surface may expose protected source, unpaid AssetPack source, raw prompts, raw responses, credentials, or wallet-private material | accepted boundary | V45 source-safety law remains binding. | Gate 2+ | +| Value-bearing mainnet | V46 launch comprehension work must not imply value-bearing mainnet authority | accepted boundary | V45 value-bearing mainnet block remains binding. | Gate 2+ | +| Implementation scope | Runtime work begins only after formal specification and parity gates authorize it | accepted boundary | Gate 1 is roadmap/spec/checking only. | Gate 4+ | + +## Grouped Closure Gates + +The V46 draft-opening plan groups work into eight provisional gates: + +1. Commercial Protocol Comprehension Roadmap Opening. +2. Protocol Comprehension Object Model And Claim Taxonomy. +3. Public Docs, Landing, And Operator Claim Boundaries. +4. `/packs`, `/read`, And `/deposit` Comprehension UX Readback. +5. API/MCP, ChatGPT App, And Bitcode Chat Claim Contracts. +6. Proof Readback And Source-Safe Operator Explanation. +7. Local Interface Comprehension Rehearsal. +8. Promotion Readiness And Canonical Promotion. + +Later V46 gates may split these rows if specification work reveals a safer or +more maintainable closure order. + +## Accepted boundaries + +- V45 is active canon while V46 is draft target. +- Gate 1 does not authorize runtime behavior changes. +- V46 public or product comprehension may simplify language but must not + simplify protocol law. +- AssetPack remains the commodity, BTD remains Need-relative scalar + knowledge-volume and settled rights, BTC remains settlement money, and proof + readback remains state authority. +- Source-safe preview is not source disclosure; quote is not payment; payment + observation is not finality; database projection is not ledger truth when it + conflicts with stronger readback. + +## Completion condition + +V46 Gate 1 is complete when the V46 draft spec family, roadmap, package script, +Gate 1 checker, and CI workflow hooks validate active V45 plus draft V46 and +the gate branch is committed, pushed, and pull-requested into `version/v46`. diff --git a/SPECIFICATIONS_ROADMAP.md b/SPECIFICATIONS_ROADMAP.md index 0a68dee83..65093ae37 100644 --- a/SPECIFICATIONS_ROADMAP.md +++ b/SPECIFICATIONS_ROADMAP.md @@ -4,13 +4,14 @@ - Current active canonical pointer: `BITCODE_SPEC.txt` -> `V45` - Current active canon: `BITCODE_SPEC_V45.md` -- Current draft target: V46 to be opened from active V45 canon. -- Current working gate: V45 Gate 19 Promotion Addendum And Stale Draft Enforcement. -- Next queued work after V45 Gate 19: open V46 Gate 1 from a clean active V45 / draft V46 posture. -- Latest closed gate: V45 Gate 18 Promotion Readiness And Canonical Promotion, which generated `.bitcode/v45-promotion-readiness-report.json`, bound active `BITCODE_SPEC_V45_PROVEN.md`, validated `v45-canon-promotion.yml`, promotion script support, gate/canon workflow active V45 / draft V46 posture, source-safe proof metadata, and V45 workflow promotion. -- V45 Gate 18 closure anchor: promotion readiness closed with a source-safe artifact, proof appendix, V45 promotion workflow, promotion dry-run, gate/canon workflow posture, package exports, tests, docs, and `check:v45-gate18` current and green. -- Current V45 Gate 19 closure target: promoted V45 spec-family addendum that removes stale draft-era active-canon language from `BITCODE_SPEC_V45*`, updates this roadmap to active V45 / draft V46, and extends promoted spec-family validation so future promotions fail on stale active/draft posture outside the source-of-truth section. -- V45 Gate 19 closure anchor: addendum is closed when promoted V45 spec-family checks, canonical-input checks, canon-posture drift checks, promoted-stale-posture tests, generated artifact freshness checks, `check:v45-gate19`, and diff hygiene pass, then the gate branch is committed, pushed, and pull-requested into `main`. +- Current draft target: `BITCODE_SPEC_V46.md` +- Current working gate: V46 Gate 1 Commercial Protocol Comprehension Roadmap Opening. +- Next queued work after V46 Gate 1: V46 Gate 2 Protocol Comprehension Object Model And Claim Taxonomy. +- Latest closed gate: V45 Gate 19 Promotion Addendum And Stale Draft Enforcement, which repaired promoted V45 spec-family posture and added stale promoted/draft posture enforcement. +- V45 Gate 19 closure anchor: promoted V45 spec-family checks, canonical-input checks, canon-posture drift checks, promoted-stale-posture tests, generated artifact freshness checks, `check:v45-gate19`, and diff hygiene passed before merge to `main`. +- V46 Gate 1 closure target: open the V46 draft family over active V45, name commercial protocol comprehension as the V46 focus, list provisional V46 gates, expose `check:v46-gate1`, and wire CI to validate active V45 plus draft V46 without claiming V46 promotion. +- V46 Gate 1 closure anchor: Gate 1 is closed when V46 SPEC, DELTA, NOTES, and PARITY files validate in draft mode, this roadmap lists V46 as active draft target, V45 remains the active pointer, CI runs draft V46 checks when V46 files exist, `check:v46-gate1` passes, and the gate branch is committed, pushed, and pull-requested into `version/v46`. +- V45 Gate 18 closure anchor: promotion readiness closed with a source-safe artifact, `BITCODE_SPEC_V45_PROVEN.md`, V45 promotion workflow, promotion dry-run, gate/canon workflow posture, package exports, tests, docs, and `check:v45-gate18` current and green. - Latest closed version: V43 Route Product Cleanup, which promoted `/packs`, `/read`, and `/deposit`; PackActivity master-detail; five-step Reading route UX; deposit AssetPack option synthesis; deposit criticality/ROI/compensation policy; option admission; product route UX; cross-route rehearsal; and V43 promotion readiness. - Recent V43 canonical promotion anchor: V43 canonical promotion updated `BITCODE_SPEC.txt` to `V43`, generated `BITCODE_SPEC_V43_PROVEN.md`, preserved active V43 / draft V44 runtime posture, and closed route-product cleanup canon. - V44 Gate 1 opening anchor: scaled engineering economy opens over promoted V43 with V44 SPEC, DELTA, NOTES, and PARITY files, `check:v44-gate1`, active V43 / draft V44 posture, and a ten-gate plan for economic domain models, Packs portfolio intelligence, Reading budget/quote governance, Depositor earnings/ROI intelligence, BTD/BTC compensation statements, organization policy/wallet authority, enterprise economic UX, scaled local/staging rehearsal, and promotion readiness. @@ -195,7 +196,7 @@ They are referenced here for specification history only; active implementation w | V43 | `BITCODE_SPEC_V43.md` | promoted historical Bitcode canon | Agentic enterprise deposit-side AssetPack option synthesis and broad UX cleanup after V42 reliable MVP paths: repository-installed Bitcode Agents compare a connected enterprise codebase, the Bitcode Depository, and Reading activity to propose deposit AssetPack options for review; filter out critical IP; estimate positive ROI against development cost and likely demand; let enterprises approve/reject options for Depository admission; split `/terminal` into `/read` and `/deposit`; and rename `/exchange` to `/packs` throughout product routes, code naming, docs, component prefixes, tests, and operator vocabulary. `/packs` becomes the searchable master-detail activity surface for all pack activity, with column sorting/filtering/search over measurements, synthesized AssetPack titles and descriptions, values, activity/transaction type, settlement posture, compensation, proof roots, and repair state. `/deposit` and `/read` become the short core paths into and out of the Depository. Outside public docs, product UX should be self-explanatory through route structure, concise labels, progressive detail, and rich reusable themed components rather than self-referential instructional copy. | | V44 | `BITCODE_SPEC_V44.md` | promoted historical Bitcode canon | Scaled engineering economy and tokenized AssetPack network operation after V43 route cleanup: enterprise AssetPack portfolios, Pack market signals, Reading demand signals, deposit supply opportunities, Reading budget policy, AssetPack quote policy, BTD/BTC/source-to-shares accounting, contributor compensation statements, organization policy, wallet/spend authority, scaled local/staging-testnet rehearsal, and polished economic operation across `/packs`, `/read`, and `/deposit` while keeping value-bearing mainnet blocked until later launch authority. | | V45 | `BITCODE_SPEC_V45.md` | active canon | Knowledge commoditization protocol precision after V44 scaled economics: AssetPack commodity lifecycle, BTD Need-relative scalar knowledge-volume and rights, BTC settlement finality, source-safe interface disclosure, proof-backed readback, operational repair, generated proof-family artifacts, source-safe end-to-end rehearsal, and canonical promotion. | -| V46 | to be opened | planned draft target | Next version to be specified from active V45 after the V45 promotion addendum closes. | +| V46 | `BITCODE_SPEC_V46.md` | active draft target | Commercial protocol comprehension and launch-facing interface claim readiness after V45 knowledge commoditization law: source-safe public/operator explanation, product route comprehension for `/packs`, `/read`, and `/deposit`, API/MCP/ChatGPT App/Bitcode Chat claim contracts, proof-readable market activity, and local interface rehearsal without value-bearing mainnet authority. | ## Current Planning Spine @@ -219,13 +220,15 @@ They are referenced here for specification history only; active implementation w 18. V43 promoted agentic deposit-side and route-product cleanup after the MVP paths became reliable: enterprises get deposit AssetPack options synthesized from connected repositories and Bitcode's observed Depository/Reading demand, then approve or reject source-safe, sub-critical, positive-ROI options for Depository admission; `/terminal` split into `/read` and `/deposit`, and `/exchange` became `/packs`. 19. V44 promoted the scaled engineering economy after product routes became intelligible: enterprise AssetPack portfolios, Pack market intelligence, Reading budgets and quote governance, deposit earning/ROI intelligence, BTD/BTC/source-to-shares compensation statements, organization policy/wallet authority, enterprise economic UX, and scaled local/staging-testnet rehearsal without weakening source-safety or value-bearing mainnet blocks. 20. V45 promoted Bitcode's knowledge commoditization law after V44: AssetPack as commodity, BTD as Need-relative scalar knowledge-volume and settled rights, BTC as settlement money, proof-backed readback as state authority, source-safe interface disclosure, operational repair, generated proof-family artifacts, source-safe rehearsal, and canonical promotion. +21. V46 opens commercial protocol comprehension after V45: the active law remains V45 while V46 drafts how public, operator, product, API/MCP, ChatGPT App, and Bitcode Chat surfaces explain AssetPacks, BTD scalar knowledge-volume and rights, BTC settlement, proof readback, source-safe preview, quotes, finality, delivery, compensation, and repair with launch-safe claims. ## Boundary Rules - Do not treat `_legacy/` ENGI specifications as active implementation authority. - Do use `_legacy/` specifications to understand why current Bitcode concepts exist and what must not regress. - New version work must build on V45 active canon and V27 `$BTD` law unless a future promoted spec explicitly supersedes it. -- V46 is the next draft target to open from active V45 posture after the V45 promotion addendum closes. -- V45 Gate 19 is a promotion addendum only. It repairs promoted specification posture and enforcement, not runtime protocol behavior. +- V46 is the active draft target opened from active V45 posture. +- V46 Gate 1 is a roadmap/spec-family/checking gate only. It does not authorize runtime protocol behavior. +- V45 Gate 19 was a promotion addendum only. It repaired promoted specification posture and enforcement, not runtime protocol behavior. - No implementation route should be versioned by spec number; source should move in place with the active canon. - Future notes files are planning memory only until their version is explicitly opened as the draft-target SPEC family. diff --git a/package.json b/package.json index e5b8cd52d..924659517 100644 --- a/package.json +++ b/package.json @@ -412,6 +412,7 @@ "check:v45-promotion-readiness": "node scripts/generate-v45-promotion-readiness-report.mjs --check", "check:v45-gate18": "node scripts/check-v45-gate18-promotion-readiness.mjs", "check:v45-gate19": "node scripts/check-v45-gate19-promotion-addendum.mjs", + "check:v46-gate1": "node scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs", "generate:v38-inference-surface-inventory": "node scripts/generate-v38-inference-surface-inventory.mjs", "check:v38-inference-surface-inventory": "node scripts/generate-v38-inference-surface-inventory.mjs --check", "check:v38-gate2": "node scripts/check-v38-gate2-inference-surface-inventory.mjs", diff --git a/scripts/check-v45-gate19-promotion-addendum.mjs b/scripts/check-v45-gate19-promotion-addendum.mjs index a0a459276..1f2ade25b 100644 --- a/scripts/check-v45-gate19-promotion-addendum.mjs +++ b/scripts/check-v45-gate19-promotion-addendum.mjs @@ -142,7 +142,7 @@ function main() { ['spec', spec, '`BITCODE_SPEC.txt` points to `V45`; V45 is the active promoted Bitcode canon.'], ['notes', notes, 'Canonical pointer: `BITCODE_SPEC.txt` -> `V45`'], ['roadmap', roadmap, 'Current active canonical pointer: `BITCODE_SPEC.txt` -> `V45`'], - ['roadmap', roadmap, 'Current draft target: V46 to be opened from active V45 canon.'], + ['roadmap', roadmap, 'Current draft target: `BITCODE_SPEC_V46.md`'], ['checker', checker, 'validatePromotedSpecFamilyHasNoStaleDraftPosture'], ['test', test, 'promoted spec-family validation rejects stale draft posture outside source-of-truth prose'], ['package.json', packageJson, '"check:v45-gate19"'], diff --git a/scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs b/scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs new file mode 100644 index 000000000..b98621fb8 --- /dev/null +++ b/scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs @@ -0,0 +1,212 @@ +#!/usr/bin/env node + +import { execFileSync } from 'node:child_process'; +import { existsSync, readFileSync } from 'node:fs'; +import path from 'node:path'; +import { fileURLToPath } from 'node:url'; + +const __filename = fileURLToPath(import.meta.url); +const __dirname = path.dirname(__filename); +const defaultRepoRoot = path.resolve(__dirname, '..'); + +function read(root, relativePath) { + return readFileSync(path.join(root, relativePath), 'utf8'); +} + +function exists(root, relativePath) { + return existsSync(path.join(root, relativePath)); +} + +function git(root, args) { + return execFileSync('git', args, { cwd: root, encoding: 'utf8' }).trim(); +} + +function run(root, command, args) { + return execFileSync(command, args, { cwd: root, encoding: 'utf8', stdio: 'pipe' }).trim(); +} + +function assertCheck(failures, condition, message) { + if (!condition) failures.push(message); +} + +function parseArgs(argv) { + const args = { + repoRoot: defaultRepoRoot, + skipBranchCheck: false, + help: false, + }; + for (let index = 0; index < argv.length; index += 1) { + const arg = argv[index]; + if (arg === '--repo-root') args.repoRoot = path.resolve(argv[++index]); + else if (arg === '--skip-branch-check') args.skipBranchCheck = true; + else if (arg === '--help' || arg === '-h') args.help = true; + else throw new Error(`Unknown argument ${arg}`); + } + return args; +} + +function printHelp() { + process.stdout.write( + [ + 'Usage: node scripts/check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs [--skip-branch-check] [--repo-root ]', + '', + 'Checks the V46 Gate 1 draft-opening posture: active V45 pointer, draft V46 spec family, roadmap scope, package script, and CI workflow hooks.', + ].join('\n'), + ); + process.stdout.write('\n'); +} + +const STALE_PROMOTED_PHRASES = Object.freeze([ + 'canonical promotion complete', + 'Canonical proof-source commit', + 'Current canonical/latest target: `V46`', + 'Canonical pointer: `BITCODE_SPEC.txt` -> `V46`', + 'Active canonical anchor: `BITCODE_SPEC_V46.md`', + 'Active generated proof appendix: `BITCODE_SPEC_V46_PROVEN.md`', + 'V46 is active canon', + 'active V46 / draft V46', + 'promoted V46', + 'active `BITCODE_SPEC_V46_PROVEN.md`', + 'check:v46-gate18', + 'v46-canon-promotion.yml', +]); + +function main() { + const args = parseArgs(process.argv.slice(2)); + if (args.help) { + printHelp(); + return; + } + + const root = args.repoRoot; + const failures = []; + const pointer = read(root, 'BITCODE_SPEC.txt').trim(); + + assertCheck(failures, pointer === 'V45', `BITCODE_SPEC.txt must remain V45 during V46 Gate 1. Observed ${pointer || 'empty'}.`); + + if (!args.skipBranchCheck) { + const branch = git(root, ['branch', '--show-current']); + assertCheck( + failures, + branch === 'version/v46' || /^v46\/gate-1-[a-z0-9][a-z0-9-]*$/u.test(branch), + `V46 Gate 1 work must occur on version/v46 or v46/gate-1-* branches. Observed ${branch || 'detached HEAD'}.`, + ); + } + + const requiredFiles = [ + 'BITCODE_SPEC.txt', + 'BITCODE_SPEC_V45.md', + 'BITCODE_SPEC_V45_PROVEN.md', + 'BITCODE_SPEC_V46.md', + 'BITCODE_SPEC_V46_DELTA.md', + 'BITCODE_SPEC_V46_NOTES.md', + 'BITCODE_SPEC_V46_PARITY_MATRIX.md', + 'SPECIFICATIONS_ROADMAP.md', + 'package.json', + '.github/workflows/bitcode-gate-quality.yml', + '.github/workflows/bitcode-canon-quality.yml', + ]; + for (const relativePath of requiredFiles) { + assertCheck(failures, exists(root, relativePath), `Missing required V46 Gate 1 file: ${relativePath}`); + } + + const specFamilyFiles = [ + 'BITCODE_SPEC_V46.md', + 'BITCODE_SPEC_V46_DELTA.md', + 'BITCODE_SPEC_V46_NOTES.md', + 'BITCODE_SPEC_V46_PARITY_MATRIX.md', + ]; + for (const relativePath of specFamilyFiles) { + const content = read(root, relativePath); + for (const phrase of STALE_PROMOTED_PHRASES) { + assertCheck(failures, !content.includes(phrase), `${relativePath} contains stale promoted V46 posture phrase "${phrase}".`); + } + for (const phrase of [ + 'Version: `V46`', + 'Current canonical/latest target: `V45`', + 'Prior canonical anchor: `BITCODE_SPEC_V45.md`', + 'Prior generated proof appendix: `BITCODE_SPEC_V45_PROVEN.md`', + 'Source parity state:', + 'Last fully realized canonical target preserved in source: `V45`', + ]) { + assertCheck(failures, content.includes(phrase), `${relativePath} must include "${phrase}".`); + } + } + + const spec = read(root, 'BITCODE_SPEC_V46.md'); + const delta = read(root, 'BITCODE_SPEC_V46_DELTA.md'); + const notes = read(root, 'BITCODE_SPEC_V46_NOTES.md'); + const parity = read(root, 'BITCODE_SPEC_V46_PARITY_MATRIX.md'); + const roadmap = read(root, 'SPECIFICATIONS_ROADMAP.md'); + const packageJson = read(root, 'package.json'); + const gateWorkflow = read(root, '.github/workflows/bitcode-gate-quality.yml'); + const canonWorkflow = read(root, '.github/workflows/bitcode-canon-quality.yml'); + + for (const [label, content, phrase] of [ + ['spec', spec, '`BITCODE_SPEC.txt` points to `V45`; V45 is the active promoted Bitcode canon.'], + ['spec', spec, 'V46 does not replace V45 as active canon until promotion workflow validation.'], + ['delta', delta, 'Gate 1: V46 Commercial Protocol Comprehension Roadmap Opening'], + ['notes', notes, 'Gate 1: V46 Commercial Protocol Comprehension Roadmap Opening'], + ['parity', parity, 'V46 Gate 1 is complete when the V46 draft spec family'], + ['roadmap', roadmap, 'Current draft target: `BITCODE_SPEC_V46.md`'], + ['roadmap', roadmap, 'Current working gate: V46 Gate 1 Commercial Protocol Comprehension Roadmap Opening.'], + ['roadmap', roadmap, '| V46 | `BITCODE_SPEC_V46.md` | active draft target |'], + ['package.json', packageJson, '"check:v46-gate1"'], + ['gate workflow', gateWorkflow, 'check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs'], + ['canon workflow', canonWorkflow, 'check-v46-gate1-commercial-protocol-comprehension-roadmap.mjs'], + ]) { + assertCheck(failures, content.includes(phrase), `${label} must include "${phrase}".`); + } + + for (const phrase of [ + 'commercial protocol comprehension', + 'source-safe public/operator explanation', + '/packs', + '/read', + '/deposit', + 'API/MCP', + 'ChatGPT App', + 'Bitcode Chat', + 'proof-readable', + 'value-bearing mainnet', + ]) { + assertCheck( + failures, + spec.includes(phrase) || delta.includes(phrase) || notes.includes(phrase) || parity.includes(phrase) || roadmap.includes(phrase), + `V46 Gate 1 opening must name ${phrase}.`, + ); + } + + const commandChecks = [ + ['node', ['scripts/check-bitcode-spec-family.mjs', '--version', 'V45', '--mode', 'promoted', '--current-target', 'V45']], + ['node', ['scripts/check-bitcode-spec-family.mjs', '--version', 'V46', '--mode', 'draft', '--current-target', 'V45']], + ['node', ['scripts/check-bitcode-canonical-inputs.mjs', '--current-target', 'V45']], + ['node', ['scripts/check-bitcode-canon-posture-drift.mjs', '--active-canon', 'V45', '--draft-target', 'V46']], + ]; + + for (const [command, commandArgs] of commandChecks) { + try { + run(root, command, commandArgs); + } catch (error) { + failures.push(`Command failed: ${command} ${commandArgs.join(' ')}`); + if (error && typeof error === 'object' && 'stdout' in error) { + const stdout = String(error.stdout || '').trim(); + if (stdout) failures.push(stdout); + } + if (error && typeof error === 'object' && 'stderr' in error) { + const stderr = String(error.stderr || '').trim(); + if (stderr) failures.push(stderr); + } + } + } + + if (failures.length > 0) { + process.stderr.write(['V46 Gate 1 roadmap opening check failed:', ...failures.map((failure) => `- ${failure}`)].join('\n')); + process.stderr.write('\n'); + process.exit(1); + } + + process.stdout.write('V46 Gate 1 roadmap opening check passed.\n'); +} + +main();