Run the ticket skills through T3 Code, with a review council before pre-mr-review

Agents now start pre-mr-review on the work account themselves, through a Klaude
delegate, and continue from its verdict. A council of models on my own accounts
replaces the single reviewer before it, and adding a seat is one table row.

Proof comes from T3's browser, with mp4 recordings, and capture-proof stays as
the fallback. Ticket pages carry their own data, so index.html renders alone in
T3's file viewer, and worktree threads share the main checkout's docs.

A PreToolUse hook sends subagents in T3 threads to delegate_task. Blocker, proof,
review and MR summary rules come from ideas in t3dotgg/tstack.

user/agents/skills/ticket/SITE.md

@@ -15,17 +15,19 @@ sees. It is a personal working file, exempt from the prose bar like the rest of
   tickets/<TICKET-KEY>/          # same shape, for a ticket with no epic, and no index
 ```
 
-Each `index.html` carries the renderer from `templates/site/` inline, rewritten on every
-write, and loads only its own data file beside it. That is what lets T3 Code's file viewer
-show it: an HTML file there can load files from its own folder and below, nothing above.
+Each `index.html` carries the renderer from `templates/site/` and its own data inline, rewritten
+on every write, so it renders alone with no server and no other file. That is what T3 Code's
+file viewer needs: it sandboxes the page, with no `fetch` or `localStorage`, and serves files
+only from the page's own folder and below. The `.data.js` beside it is the store `ticket-page`
+reads and writes. An open page polls it to stay live, and shows its last write if it cannot.
+Screenshots and attachments stay as relative files under the ticket folder.
 
 ## In T3 Code
 
 Gib follows the work in a T3 Code thread, so the page and the plan come to him there.
 
 - **The live page.** `ticket-page open <KEY>` refreshes the page and prints its absolute path.
-  Link that path in your reply, and it opens in T3's file viewer beside the thread, still
-  reloading as you write. Outside T3 (no `T3CODE_THREAD_ID`) it also opens the browser.
+  Link that path in your reply, and it opens in T3's file viewer beside the thread. Outside T3 (no `T3CODE_THREAD_ID`) it also opens the browser.
   Never start an http server for the page.
 - **Inline snapshots.** `ticket-page view <KEY> <view>` prints a self-contained page styled
   with T3's theme. Pass its output, verbatim, to `html_preview`, check the screenshot, then
@@ -36,7 +38,7 @@ Gib follows the work in a T3 Code thread, so the page and the plan come to him t
 | Moment | View |
 |---|---|
 | Plan ready for approval (Phase 1, last step) | `plan`, then `mocks --mock <id>` once per artboard |
-| Hand-off for pre-mr-review, and on resume | `progress` |
+| Starting pre-mr-review, final hand-off, and on resume | `progress` |
 
 - One artboard per render, so each can be expanded full screen on its own and options sit
   one after another for comparison. `view` refuses a page over html_render's 512 KB and
@@ -68,8 +70,8 @@ the repo.
 | Starting a step | `step <KEY> <n> running` |
 | A step's commit exists | `step <KEY> <n> done --commit <sha>`, one `--commit` per commit |
 | A criterion is met | `criterion <KEY> <ID> done --evidence "<what shows it>"` |
-| Proof captured, or dropped from `proof/` | `proof <KEY> --file proof/<name> --proves AC1,AC3 --caption "<test case>" [--mock <id>]`, `proof <KEY> --test "<name>" ...`, `unproof <KEY> <file>` |
-| Reviewer finding, and its resolution | `finding <KEY> add "<text>" --severity CONFIRMED --where <file:line>`, then `finding <KEY> F1 fixed --commit <sha>` or `rejected --reason "<why>"` |
+| Proof captured (image, mp4, or text), or dropped from `proof/` | `proof <KEY> --file proof/<name> --proves AC1,AC3 --caption "<test case>" [--mock <id>]`, `proof <KEY> --test "<name>" ...`, `unproof <KEY> <file>` |
+| Council finding, and its resolution | `finding <KEY> add "[should] <text> (<seats>)" --severity CONFIRMED --where <file:line>`, then `finding <KEY> F1 fixed --commit <sha>` or `rejected --reason "<why>"` |
 | pre-mr-review audit read | `verdict <KEY> <verdict text> --recommendation <R> --head <sha>` |
 | A Jira field PUT and verified | `jira <KEY> "<field name>"` |
 | `mr.md` written | `mr <KEY>` |
@@ -163,7 +165,7 @@ The rest of the index is yours to seed and keep true.
 ## Reading it as an agent
 
 `ticket-page md <KEY>` prints the ticket and the plan as markdown. Use it when you resume a
-ticket, and hand it to the fresh reviewer as the ticket and plan in its reading order.
+ticket, and write it to a scratch file for the council and the audit, which read it there.
 
 ## Tickets from before the page