Loomworks — command and settings discoverability — scoping note — v0.1

Document: loomworks-command-settings-discoverability-scoping-note-v0_1 Version: v0.1 Status: scoping note — queued. Captures the need and early shape; full scoping (the actual settings/command catalog) is a fresh chat after the add-side rework phases land. Date: 2026-06-27 Origin: Operator: there is no way for an Operator to get a list of available commands or settings/preferences. You can change a setting by command (e.g. lists.page_size) only if you already know it exists — there's no discovery.

The need

The Operator can change settings and issue commands by voice or text, but there is no way to discover what's available. You have to already know a command/setting exists to use it. The Operator wants a way to ask "what can I change?" / "show settings" and get the available commands and settings, with their current values.

Seed fit — no conflict, actually aligned

The seed's "only show what's available" rule fits this directly: a discoverability surface shows what you can do. Making available commands visible is the seed's instinct (don't make the Operator guess). No conflict; this is the seed's direction made concrete.

Early shapes (to settle at full scoping)

1. A spoken/typed command — "what can I say?" / "show settings" → the Companion lists available commands and settings with current values. Voice-first fit.
2. A Settings/Preferences surface — a panel listing each setting, its current value, and how to change it.
3. Both — the command surfaces the list conversationally; the panel is the persistent reference.

Early lean: both, command-first. Voice-first product, so "what settings can I change?" answered in the Companion is the natural primary; a panel is the persistent reference layer behind it. Settle at full scoping.

What full scoping needs (the open questions)

• The actual catalog. What settings/commands exist today? (Grounding found lists.page_size via KNOWN_SETTINGS in person_settings.py, _LABEL_TO_KEY in tune_setting.py, and the frontend applySettingChange.) Is the set fixed or growing? Is there a single source of truth to enumerate from?
• Settings vs. commands. Settings (tunable values like page size) and commands (actions like "remove parking", "open rendering") are different kinds — does discoverability cover both, or settings first?
• Current values. Showing a setting should show its current value (and default), not just its name.
• Plain-terms discipline. The list must read in plain English (methodology nouns in plain terms), not codebase keys (lists.page_size → "how many items load at a time").
• Source of truth. Ideally the list is generated from the real catalog (so it can't drift from what actually works) rather than hand-maintained — same instinct as the API-documentation-from-code direction already queued.

Sequencing

Queued. Do NOT fold into the add-side rework (unrelated — that's the capture flow; this is discoverability). Scope as its own piece after the add-side phases (4-5) land. May relate to the queued API-documentation effort (both are "describe what the system offers from a single source of truth") — worth checking if they share a catalog mechanism.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — command and settings discoverability — scoping note — v0.1 — 2026-06-27 No way to discover available commands/settings today. Seed-aligned ("only show what's available"). Early lean: both a spoken "show settings" command and a Preferences panel, command-first, plain-terms, generated from the real catalog. Queued — full scoping after the add-side phases.