02 / Operator ModesConfiguration
Read launch-mode, environment, and feature configuration clearly
Configuration docs explain feature flags, environment modes, disabled controls, optional preferences, and fail-closed readiness so launch-mode Terminal remains honest.
Use this page when a control is visible but disabled, when an interface is mocked or boundary-only, or when a setting has a settlement or delivery consequence.
After reading
You can tell the difference between disabled launch controls, mocked Terminal state, review-only posture, and live-ready configuration.
Environment mode, feature flags, and boundary state explain what is live
Production, staging, development, and mock postures must stay explicit. Feature flags can keep launch-mode controls visible but disabled until the connected implementation is ready.
A disabled control should still teach what it will do. That keeps users oriented and avoids implying that missing connectivity is accidental breakage.
Why this matters
This is especially important while Terminal is active and advancing from mocked state toward commercial readiness.
- Disabled controls remain visible with clear tooltip copy.
- Terminal is active; Exchange and Auxillaries can remain gated by launch flags.
- Boundary truth should be readable before any proof or settlement trust decision.
Configuration should be rich but consequence-oriented
Auxillary configuration includes repository connections, interface defaults, profile identity, wallet posture, organization roles, $BTD settings, and future connected-interface options.
Each preference should explain the operational consequence: what it changes in Terminal, Exchange, settlement, delivery, or proof visibility.
Why this matters
Configuration is not a settings dump; it is the user-facing control plane around Source Shares.
Every blocked configuration path should fail closed
Wallet verification drift, missing repository scope, stale connection state, projection overexposure, or unadmitted interface writes should block the risky action while preserving safe reads and learning.
The product can still show mocked or review-only state, but it must be honest about what cannot yet transact or deliver.
Why this matters
Fail-closed behavior makes launch-mode UX useful without weakening the production standard.
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.