Per the PRD §5 C7 + O7/O8 (operator additions, 2026-08-19):
Venues/brokers visibility (O7): a brokers service over the existing entry-point registry (discover_brokers()) and BrokerCapabilities: every installed adapter — name, venue id, wired-for-deployment vs optional-dev-venue, session-bound or 24/7, quote currency, asset classes, paper/live endpoints where declared, preview synthesis, supported data feeds — surfaced as keel brokers list (CLI) and a TUI Venues browser under Profile with the selected adapter highlighted and the active deployment's binding shown. Capability display, never key-presence inference (#233-aligned); no secret values ever shown. One service, two front-ends.
Help & glossary (O8): every screen carries a plain-English 'what am I looking at' and every invokable action a 'what will this do' description, written for a newcomer (what a rail IS, what an attestation records, what the promotion gate demands, what the kill switch does, what paper mode means). Definitions live in ONE source (a glossary the TUI help renders and the docs link to); per-screen/per-action help strings land with each menu slice (C2-C5) and are consolidated + audited here. Typed actions' help states explicitly that the prompt cannot be pre-filled.
Acceptance: keel brokers list and the TUI Venues browser show identical information from one service (pinned); every screen/action has help text; glossary has exactly one source with no drifted duplicates.
Per the PRD §5 C7 + O7/O8 (operator additions, 2026-08-19):
Venues/brokers visibility (O7): a
brokersservice over the existing entry-point registry (discover_brokers()) andBrokerCapabilities: every installed adapter — name, venue id, wired-for-deployment vs optional-dev-venue, session-bound or 24/7, quote currency, asset classes, paper/live endpoints where declared, preview synthesis, supported data feeds — surfaced askeel brokers list(CLI) and a TUI Venues browser under Profile with the selected adapter highlighted and the active deployment's binding shown. Capability display, never key-presence inference (#233-aligned); no secret values ever shown. One service, two front-ends.Help & glossary (O8): every screen carries a plain-English 'what am I looking at' and every invokable action a 'what will this do' description, written for a newcomer (what a rail IS, what an attestation records, what the promotion gate demands, what the kill switch does, what paper mode means). Definitions live in ONE source (a glossary the TUI help renders and the docs link to); per-screen/per-action help strings land with each menu slice (C2-C5) and are consolidated + audited here. Typed actions' help states explicitly that the prompt cannot be pre-filled.
Acceptance:
keel brokers listand the TUI Venues browser show identical information from one service (pinned); every screen/action has help text; glossary has exactly one source with no drifted duplicates.