02 / Operator ModesAuxillaries

Configure Auxillaries for wallet, externals, profile, and interfaces

Auxillaries explain the commercially important configuration layer around Terminal: Wallet, Externals, Profile, and Interfaces.

Use this page to understand what each auxillary pane changes and why Terminal may stay fail-closed until wallet, repository, or profile posture is complete.

After reading

You can identify each auxillary pane and understand which Terminal capability it unlocks.

Auxillaries

01

Auxillaries are the wallet, externals, profile, and interface layer

Auxillaries hold the context that changes how Terminal can operate: signed Bitcoin wallet identity, connected repositories, optional profile metadata, interface defaults, and BTD preferences.

The auxillary shell should feel adjacent to Terminal, not detached from it. Opening Auxillaries changes readiness and configuration while the selected Terminal activity remains recoverable.

Why this matters

Configuration is commercially important only when users can understand which operational capability it unlocks or blocks.

  • Wallet owns the first identity step: a Bitcoin wallet proof that can back a Supabase session.
  • Leather support uses its documented Bitcoin provider methods: getAddresses, signMessage, signPsbt, sendTransfer, and open.
  • Leather Taproot p2tr is preferred for Bitcode auth when present; Native SegWit p2wpkh remains the payment-address read.
  • Externals owns GitHub and future source-provider bindings after wallet identity exists.
  • Profile owns optional email, display identity, account role, and organization metadata.
  • Interfaces owns default behavior and visual/product posture.
  • Wallet also owns BTD balances, range posture, and share-specific settings.

Readiness

02

Wallet, Externals, Profile, and Interfaces are readiness surfaces

Wallet identity, repository scope, profile roles, interface defaults, and $BTD controls determine which writes can move from review to signed or connected execution.

A user may still learn or draft in launch mode, but production execution must keep blockers clear before deposit, branch, settlement, delivery, or connected-interface writes proceed.

Why this matters

This lets Bitcode ship a strong Terminal experience with mocked data while preserving the production direction toward real connectivity.

  1. 01Connect and sign with a Bitcoin wallet first.
  2. 02For Leather, unlock the extension, use its testnet lane, approve the Bitcode message signature, and expect Bitcode to keep auth and payment addresses distinct.
  3. 03Install the GitHub App or connect a source provider second.
  4. 04Add optional email/contact settings only after wallet and source readiness are clear.
  5. 05Set profile identity, organization, and role posture only after required wallet and repository prerequisites are visible.
  6. 06Choose interface defaults for Terminal and connected surfaces.
  7. 07Review BTD and wallet-adjacent controls before settlement.

Externals

03

Third-party connections are source-bearing ingress, not hidden account settings

Externals owns GitHub and future provider bindings because repository scope becomes source-bearing input for Read measurement, AssetPack synthesis, proof follow-through, and settlement readiness.

A healthy connection read tells the user whether the provider is pending, connected, reconnect-required, or available only from stored inventory. It also explains that wallet identity stays in Wallet, while repository attachment and provider scope stay in Externals.

Why this matters

New users read to understand why a missing GitHub or wallet connection blocks live writes without blocking learning-mode Terminal review.

  • GitHub scope defines which repositories Bitcode can read for source supply.
  • Stored inventory can support reread, but live write admission fails closed until the provider is restored.
  • Bitcoin wallet posture plus GitHub scope are the minimum live prerequisites before settlement or signed delivery.

Interfaces

04

Interface defaults shape how Terminal, conversations, and proofs open

Interfaces owns Terminal detail density, non-ledgerized instruction posture, conversation return behavior, proof read mode, instruction tone, and execution bias.

These are not cosmetic preferences. They change how much detail Terminal opens with, how conversations re-enter the product, and whether proof readers see visual, mixed, or raw evidence first. Ledgerized Reading keeps protocol-owned model configuration.

Why this matters

Configuration becomes teachable when every preference says what operational consequence it has.

  • Exchange detail density controls how much selected activity detail opens by default.
  • Conversation launch controls whether chat appears as overlay, focused work, or continuity-preserving mode.
  • Proof mode controls whether evidence opens visually, mixed with structured payloads, or raw first.

Disclosure limits

05

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.

Interface preview

Learn with the same UI grammar used in Terminal

These embedded specimens reuse the Terminal card and explainer pattern so docs readers become familiar with the real product surfaces before they operate against them.

Auxillary shell

Wallet, Externals, Profile, Interfaces

The auxillary rail is configuration with product consequences: each pane changes readiness or defaults for Terminal.

Wallet

Bitcoin identity + BTD posture

Externals

Repository + providers

Profile

Email + roles