You are building me a "chief of staff" orchestrator: one always-on service that
posts a morning brief to Slack (sprint tickets, open PRs with a 0-10 approve
verdict, watched repos, comments I still owe), lets me approve a PR from a
button, and runs long headless coding jobs on a dev machine I already own.

Ground rules, non-negotiable:
- Scripted first. Deterministic code owns control flow. The model is called only
  at fixed transform points: one-line "takes" as JSON, and a per-PR verdict from
  the diff. If the model fails, titles stand in and nothing else changes.
- Nothing mutates without my tap. Every write (approve, transition, push) is a
  PENDING row that a button in Slack claims with a compare-and-set update. The
  button value carries only that row's id. Only my Slack user id may approve.
- Tokens stay where they already are. The orchestrator holds its own Slack and
  model API keys and nothing else. Every git, Jira and Claude Code call runs as
  a small script on the dev machine over SSH, and only text comes back.
- One Slack channel. Use Block Kit for every message. Respect the limits: ack a button
  within 3 seconds and repaint the card in place, 50 blocks per message, 3000
  characters per section, 75 per button label.
- When something is down the brief loses detail but never posts wrong data: an outbox table for Slack, circuit
  breakers per dependency, alerts only on a transition, a deadman ping after
  each brief.
- Log every command and result with duration and outcome. Tests on the server
  side for every state transition.

Before writing any code, interview me. Ask ONE question at a time, wait for the
answer, and keep a running summary. Questions:
1. Which machine already has working `gh`, Bitbucket or Jira credentials and
   Claude Code logged in? How do you reach it (Tailscale, LAN, SSH key)? What
   is its login shell?
2. For each project: the forge (GitHub org or Bitbucket workspace), the Jira
   project key, and which repos matter. One project is fine.
3. Slack: workspace, whether you can create an app with Socket Mode, and the
   channel it should own. Your Slack user id.
4. When should the brief land, in which timezone, on which days? Should PR
   scoring run before it?
5. What counts as "needs my review": requested reviews only, or every open PR
   in the watched repos?
6. What must never happen without a tap? List the actions. Anything you'd let
   run unattended?
7. Do you need long-running coding jobs on that machine (yes/no)? If yes, how
   long may one run before it is killed?
8. Stack preference for the server. Default if none: Java 21, Spring Boot,
   SQLite in WAL mode, one small VPS.
9. Which of my answers above are you unsure about? For those, take the boring
   default and note it in a DECISIONS.md.

Then produce, in this order, stopping for my review after each:
M1  Skeleton: config per project, SSH executor that wraps every command in a
    login shell, SQLite schema, execution log, Slack outbox and poster, health
    endpoint. A first brief with raw text.
M2  Sweeps and the brief: sprint tickets with a one-line take, PRs with author,
    review state and CI, watched repos, unresolved comments on my PRs. Block Kit
    cards sorted by what I do next. Compact fallback when 50 blocks would
    overflow.
M3  Approvals: prepared_actions table, Approve button per card, two-step
    repaint (button becomes "approving" at once, then the outcome), 24 hour TTL
    for PR approvals, operator gating, ephemeral refusal for anyone else.
M4  Verdicts: a box script that scores each PR diff 0-10 with a one-line
    reason using the local coding agent, results stored on the box as JSON
    lines, dropped after 24 hours, shown on the card as advisory text only.
M5  Runs (only if I said yes in 7): detached tmux, exit file written atomically,
    resume decided on the box by a marker file, poller with a hard timeout,
    exit triage into timeout, killed, auth, provider and task failure.

For every milestone list what you built, what you skipped, and how I test it
from Slack on my phone. Never invent a repo, ticket, person or credential. If
a step needs access I don't have, say so and stop.