[kh0pper]

What this adds

A decision card is an ordinary Bot Board card that carries a question and 2–4 options. A bot asks it over the board MCP server. The owner answers it in the card drawer with one tap, or with "Other…" and a short note. The answer is recorded, and the option can create a follow-up card. That card is always gated, and goes to the bot named on the option or, if that bot isn't enabled, to the Unassigned lane with an owner label.

• board_ask_decision (MCP): validates the question and options.
  • 2–4 options; exactly one recommended, and it must be first; every option needs a consequence.
  • Caps: question ≤300, label ≤120, consequence ≤240, fingerprint ≤200, batch ≤100. snooze_days is an integer 0–90. expires is an ISO date, default today+7. At most 5 open cards per batch.
  • Unknown option keys are rejected.
  • De-dupe, per asker: no new card while the same caller has an open card with the same fingerprint, or while that caller's snoozed answer to it is still in force.
  • It never pushes.
• board_notify_decisions (MCP): one grouped push for the caller's open decision cards in a batch ("N decisions waiting"). A batch is pushed once while its notified cards are still open, and each caller gets at most 3 pushes per UTC day. Overdue cards are expired first. If the operator has turned that notification type off, nothing is claimed and no daily slot is used.
• POST /dashboard/bot-board-api/card/:id/decision {index, other_text?}: the only way to answer. It records the dashboard (human) actor. Answering a second time returns 409 already_decided and never creates a second follow-up. Expired, closed, archived and locked cards return 409 before anything is written.
• Follow-up cards inherit the decision card's tags unchanged (the asker cannot set them), so a consumer that scopes by tag can recognise them.
• Card drawer UI: shows the question, the options in order with the recommended one badged, a consequence line under each, "Other…", and a read-only view once decided or expired. Bot text is inserted as text only. Strings are in en and es.
• board_create_item can now assign a new card to an enabled bot (assigned_bot, cards only). Unknown, disabled and voice bots are refused with 400 bad_bot. A tracker item is refused with 400 bad_field. Assigning starts nothing, and the card is gated by default. Follow-up cards from a decision are always gated.
• servers/gateway/board/bot-lookup.js: one shared "enabled, non-voice bot" check, now also used by POST /card/:id and POST /card/:id/execute.
• Docs: a "Decision cards" section in the Bot Builder guide (en + es).

Security review findings and how they are answered

1. Missing authorization on the push trigger (board_notify_decisions let any board-MCP caller push any batch).
   • Each decision card records who asked it (decision.asked_by, from the resolved, signature-verified board actor).
   • Batches are namespaced by asker: batch_key = <actor key>|<batch>. A caller can only ever find and notify its own cards. Unsigned callers share the key bot:unattributed.
   • A batch is pushed at most once (already_notified).
   • Each caller gets at most 3 decision pushes per UTC day (429 push_limit).
2. Rate-limit race (the count and the insert were separate steps).
   • The cap check and the claim are now one SQLite statement: UPDATE … WHERE … AND (SELECT COUNT(DISTINCT notify_stamp) … today, this caller) < 3 RETURNING id.
   • Pushes are counted from the cards' own stamps, so no schema change was needed.
   • If the push fails, the claim and its stamp are released, which gives the capacity back.
   • Test: 6 parallel notifies by one caller across 6 batches give exactly 3 pushes.
3. Batch hijack / denial (one bot could add a card to another bot's batch and make its notify fail).
   • Closed by the per-asker namespace in (1). Two callers using the same batch name get separate batches, caps and pushes.
   • The whole-branch review found the same problem one level down: fingerprint de-dupe was global, so one caller could pre-empt another's question. Fingerprints are now per asker too (fingerprint_key).
   • Tests: two bots both use batch "x"; two bots both use the same fingerprint.

Known limits (deliberate, noted for follow-up)

• Unsigned bots, all session callers and all human callers each share one namespace and one daily cap.
• A lock can still be taken in the moment between the lock check and the final move to done, because the lock lives in another database. The decision is still recorded, and the call reports locked.
• Concurrent askDecision calls can both get past the fingerprint de-dupe (check-then-create).
• The follow-up link reloads the board onto the new card but does not open its drawer.
• The drawer block is covered by DOM-stub tests only. Before merge: one manual run in a real browser (open a decision card, answer it, answer again from a second tab to see the 409, try Other…, follow the link).

Tests

• New: tests/board-decision-service.test.js, tests/board-bot-lookup.test.js, tests/board-decision-ui.test.js.
• Extended: tests/board-mcp.test.js, tests/board-card-api.test.js.
• Full suite: 10492 tests, 10457 pass / 0 fail / 35 skipped on the final head (cb52ce1); scratch gateway start-up check clean.
• check-public-hygiene: OK. check-port-allocation: OK.

https://claude.ai/code/session_01N9fXzvNy8rCEArj1y5p6fp