01 / Exchange And TerminalWrite guide
Terminal actions: what writes and what should read back
Every Terminal write should have an expected read result. This guide lists the operator actions and the state they should make visible.
Use this as the practical manual for Terminal operation. It follows the same model as the exhaustive tooltips: write deliberately, then verify the resulting read surface before moving deeper.
After reading
You can identify the write, the expected read, and the proof signal for each major Terminal action.
Controls, flow guide, and working posture
Scenario, projection, branch mode, guide progress, and closure controls stay in one shared control surface.
This card is where the working flow becomes resumable. You should be able to see the current posture, reopen the guide, and continue without reconstructing context.
Why this matters
Controls are not generic preferences. Scenario, projection, branch mode, and guide state decide what Bitcode will measure, materialize, and prove.
- Guide progress is resumable instead of one-shot
- Scenario, projection, and branch mode remain explicit
- Closure control stays adjacent to the active working posture
Search and select supply
Deposit-side supply should be searchable, reviewable, and selectable without turning transactions into an infrastructure note.
Use this surface to bind the current auth session, narrow the inventory, and keep only the supply you want in the active deposit draft before moving into Depositing, fit, and closure.
Why this matters
Supply search is the first filter on what source can become share-bearing intelligence.
- Keeps searchable supply inside the Bitcode Terminal
- Makes selected inventory explicit before Depositing drafting
- Preserves continuity into the deposit draft instead of forcing context rebuilds
Depositing flow and submission
Depositing should read like a resumable working draft built from selected supply, not like infrastructure plumbing.
Use this surface to bind selected supply, add issuer and provenance overrides where needed, and submit Depositing while keeping the rest of the working chain coherent.
Why this matters
Deposit provenance is what prevents useful source from becoming anonymous or unauditable.
- Treats Depositing as a resumable working draft
- Keeps selected supply and issuer continuity visible
- Feeds directly into fit, proof, and settlement follow-through
Run and review closure follow-through
Closure work should stay adjacent to the active Bitcode activity detail so verification, branch execution, settlement, and ledger follow-through are one continuous operation.
This surface is where you run closure, refresh the current state, and reopen the exact follow-through path without rebuilding context.
Why this matters
Closure is where reviewable Read, verification, branch materialization, proof, and settlement become one consequence chain.
- Keeps closure controls near the active activity
- Makes refresh and reset explicit instead of hidden
- Preserves continuity into Read review, verification, branch, settlement, and ledger reads
Public docs expose guidance and proof posture, not protected source
Public Bitcode docs derive from the active Protocol, package-owned catalogs, route contracts, and source-safe generated artifacts. They can explain usage, measurements, event ids, proof roots, docs links, runbook links, redaction posture, testnet rollout readiness, fee boundaries, and settlement posture.
They must not reveal protected source payloads, raw protected prompts, secret values, provider tokens, wallet private material, or unpaid AssetPack source. Source-bearing AssetPack contents cross to the reader only after settlement and rights transfer.
Why this matters
This keeps the public product understandable while preserving the boundary that makes Source Shares economically and operationally safe.
- Allowed: usage guidance, route links, state labels, source-safe measurements, proof roots, dashboard/runbook ids, redacted incident posture, testnet rollout readiness, LocalStagingTelemetryDocumentationRehearsal evidence, and fee/right boundaries.
- Interface docs may surface event ids, proof roots, docs links, runbook links, and redaction posture from TelemetryDocumentationInterfaceIntegration without revealing source-bearing payloads.
- Local and staging-testnet rehearsal docs may surface documentation discovery, telemetry event emission, dashboard/runbook lookup, docs QA, incident drill, source-safe proof-root review, and blocked value-bearing mainnet posture.
- Blocked: secrets, provider tokens, wallet private material, raw protected prompts, protected source payloads, and unpaid AssetPack source.
- Docs QA fails closed when public docs, internal docs, route docs, interface docs, generated artifacts, proof posture, or workflow checks drift.
- Deferred boundaries stay explicit: V35 documents Exchange and Conversations usage while deeper product depth remains future-canon work.