01 / Exchange And TerminalTerminal map
Orient inside the Bitcode Terminal
Understand the Terminal as one focused Deposit/Read operator surface with recent activity results, support rails, and exact proof follow-through.
Use this page when you read to know where to read, where to write, and when to open deeper modes such as Conversations or Auxillaries.
After reading
You can open Terminal and identify the read window, write posture, repository supply, support rail, and deeper modes.
Bitcode Terminal operator model
01Bitcode Terminal experience map
The Bitcode Terminal is the primary operator surface for Deposit, Read, closure, and recent activity results, while Exchange owns the market-wide master-detail view.
Use this map to keep the main Bitcode Terminal working surface stable: Deposit, Read, recent activity, and selected results stay primary, while conversations and Auxillaries remain deliberate mode changes instead of parallel destinations, and every one of those reads stays grounded in Bitcode Exchange state and Bitcode Protocol canon.
Why this matters
The Terminal keeps the product understandable by making the activity ledger primary and treating deeper modes as deliberate follow-through.
- Keeps the ledger and selected activity central
- Treats conversations and Auxillaries as deliberate follow-through modes
- Keeps Deposit and Read legible as the two primary actions
Read window
The main Bitcode Terminal read window is recent activity plus the selected Terminal result, not the Exchange master-detail table.
Exchange owns the market-wide master-detail loop. Terminal keeps a focused read/write loop for recent Deposit, Read, proof, and closure results; deeper proof, conversation, and auxillary surfaces should remain deliberate follow-through rather than parallel primaries.
Why this matters
The read window is where users learn whether a Bitcode action actually changed state.
Write posture
Deposit, read, and transactional follow-through are the active write posture of the Bitcode Terminal.
This is where click-based and chat-based write paths meet. Conversations can draft, but the ledger-facing write posture still belongs to deposit, read, deposit, branch, and closure so writes land in Bitcode Exchange and remain auditable against Bitcode Protocol canon.
Why this matters
Writes must stay bounded because Bitcode has proof, wallet, repository, and disclosure consequences.
Read here, open deeper modes when needed
The right rail should keep mode changes obvious without competing with the recent activity result window.
Use the rail to open conversations or Auxillaries deliberately, while recent activity and the selected result remain the primary Terminal read surface.
Why this matters
Mode changes are useful only when the reader never loses the active Exchange activity context.
- Keeps deeper drafting deliberate
- Avoids splitting attention away from recent activity results
- Preserves orientation when switching modes
Repository supply connection
Repository connection and selection make searchable supply explicit before Depositing, fit, and closure read the rest of the chain.
This is where you set the boundary for deposit-side supply. It should read as a clean source selection surface, not as infrastructure plumbing.
Why this matters
Repository scope is the deposit-side boundary; every deposit and downstream proof depends on it staying explicit.
- Anchors deposit-side supply to one repository boundary
- Keeps provider posture visible
- Supports continuing straight into Deposit and Read
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.