[Ermag]

Stacked on #51 (which is on #49): it uses #49's per-connection tokens as the record of where each agent is connected. Retarget to main once those merge.

Before: Nothing told you which database Rowbit is guarding. The review page only listed changes, and the CLI had no overview. To find out which setups exist, what each one points at and which projects are connected, you had to read files in ~/.rowbit.

After:

• rowbit status: lists every setup on the machine (those in ~/.rowbit and the demo), or with --dir just that one. For each it shows:
  • the database: name, host, port, user and TLS, never the password;
  • the review page address, whether it's running, and how many changes are held;
  • each agent's rules in brief;
  • where each agent is connected ("Claude Code in ~/projects/app", last used …).
    It reads files only, so it works when the database is down.

  demo  ~/rowbit-demo
        database: shop on 127.0.0.1:33070 as rowbit, no TLS
        review page: http://127.0.0.1:8080/, running, nothing held
        agent coding-agent: 2 rules, else holds
          Claude Code in ~/projects/app (last used 2026-11-07T14:02:11Z)
  

• Review page: the header says "Guarding shop on 127.0.0.1:33070 as rowbit" and links to a new Setup view. That view shows the database, Rowbit's folder, the review page and MCP addresses, sign-in, notification targets, the number held and the version. It also lists each agent with its rules and connections, including when each was made and last used. It is served by /api/setup, behind sign-in. No passwords are shown.
• Engine: a new rowbit_engine::overview builds the database summary (from the URL, without its password) and the agent summaries. The CLI and the web share it.
• Smaller fix: inside the demo's folder, commands now read the database URL from the demo's marker, so rowbit serve there no longer needs ROWBIT_DATABASE_URL exported.
• Docs: a spec section "What Rowbit is connected to", plus a quickstart note pointing to rowbit status, the Setup view and connecting more projects.

How:

• Unit tests check that the database summary carries no password and that agent summaries list rules and connections.
• The web test checks that /api/setup needs sign-in and lists the agents.
• The CLI integration test checks that rowbit status shows the database without the password, the review page state and the connection label.
• Checked by hand: ran rowbit serve on a copy of a v0.2.2 demo, signed in, and looked at the header and the Setup view.

Review fixes (v0.2.3 review):

• Read-only status: rowbit status opens each rowbit.db read-only (new Store::open_read_only). A state file it can't read is reported as an error, never as "not connected". It says "a Rowbit answers there" only when the Rowbit sign-in page answers at that address. (Store changes and a hash-chained audit log in SQLite #7)

• What reviewers see: the spec (setup.md and server.md) now says everyone who can review sees the Setup view, and lists what that includes. I kept the content, since a reviewer should know which database a change writes to. (Take a proposed change from statement to policy decision #8)

• Connection ids: status and the Setup view show each connection's id and the command that signs it out. The view now keys rows by id, which fixes the duplicate-label nit.

• Tests cover the new behaviour

• docs/spec/ is updated if this changes the change lifecycle or rowbit.yml