pramaan-functions · Story-3047 · EPIC-3034

One Vani command vocabulary, now available to the app

The Channels settings page can now ask the app API which commands Vani supports. The endpoint reads the same registry that renders /help, so the app cannot advertise a command the broker does not know.

The contract

GET /app/channels/commands

{
  "commands": [
    {
      "name": "matters",
      "description": "I'll show you the matters you can work on",
      "available": true
    }
  ]
}

Availability is data, not a filter: a future registered command can stay visible with available: false. The current five registered commands are implemented, so they are all available. Unbuilt /hearings, /team, /record, and /filings remain outside the registry as the Story requires.

One source, three consumers

COMMANDS
  ├── /help reply
  ├── GET /app/channels/commands
  └── Meta sync (Story-3039)

Registry construction rejects command names over 32 characters and descriptions over 256 characters, matching Meta's limits before any consumer serialises the data. The HTTP boundary validates the same limits again through its response DTO.

Boundaries kept intact

• No agent run or model call: this is a deterministic in-memory read.
• No tenant data or RLS read: every counsel receives the same vocabulary.
• No manual span: normal HTTP auto-instrumentation covers this route.
• The lowercase mira machine key is untouched.

Proof

• The registry tests pin Meta limits and preservation of unavailable rows.
• The route test performs a full response DTO round-trip against the shared registry.
• The OpenAPI contract test pins the route, operation id, errors, fields, and limits.
• Both committed OpenAPI snapshots are regenerated for consumer codegen.