Parallel lanes

Set up "week four" for running several coding agents ("lanes") on this
repository at once: separate worktrees, claims before work, a way for lanes
to reach each other and me, safe hand changes in dev, and a queue in the
tracker. Work through the steps in order. Nothing leaves this repo and
nothing is pushed.

1. Your harness. Name the agent tool you are running in and its version.
   Find its documentation (built-in help, local docs, or the official site;
   reading it online is fine). Quote only text you read word for word, label
   anything else as your own knowledge, and say "none" where it has none:
   a. hooks that run before a command, and whether one can refuse it;
   b. how a session learns its own root directory, as opposed to its
      current directory, and whether the tool's own worktree feature
      (if any) changes that root;
   c. how it connects to external tools or servers (a protocol for tool
      servers, plugins, or none), so lanes could share a message bus;
   d. whether it can notify me outside the terminal.

2. This repo and its surroundings. Find existing git worktrees and where
   they live; any claim, lock or lease mechanism; any message bus or
   chat integration; the ticket tracker and its labels, if one is named;
   any development cluster or shared dev environment, how a context or
   profile selects it, and which credentials the agent holds for it.
   Name the file or command you learned each fact from. List checks that
   already fail; don't fix them.

3. Questions. Put everything you could not find in ONE message to me:
   the lanes I plan to run and which repo each works in; the tracker and
   its query language; the work streams in priority order; the exact
   cluster or environment ID that counts as dev; whether shared dev data
   needs a lease. If nobody answers, continue on stated assumptions and
   mark each one ASSUMED in the final report. Never assume a cluster or
   environment ID; without one, card 4 is rules-file only.

4. The cards. Build claims first; they are the smallest useful piece. For
   each card choose the strongest layer available here, name it and the
   file, and propose the change as a diff.
   Card 1: lanes never share a working tree. One git worktree per lane,
           launched from its own folder; scratch worktrees in a temp
           directory. Strongest here: a before-command hook that refuses
           mutating git aimed at the main checkout or a sibling worktree,
           judged by the session's root, not its current directory. Say
           what the hook can't see (file edits, git run by a person).
   Card 2: two lanes never start the same ticket. Claims with take,
           release and list, where take succeeds for exactly one caller,
           and every claim expires. Strongest here: the store's own
           atomicity. If a claim store already exists, in the repo or a
           tool server every lane connects to, use it and test its
           atomicity and expiry. Otherwise write a small claim script backed
           by a single SQLite file under the repo's shared git directory
           (git rev-parse --git-common-dir), so every worktree sees it,
           plus a rule to claim before starting.
   Card 3: lanes talk directly, and reach me on my phone. Don't build a
           bus here. Report what the harness offers (step 1c, 1d), and
           write the design for me: one handle per session with a second
           refused, direct messages, boards, claims, one human handle
           bridged to a phone chat app, no polling. If the harness can't
           push a message into a running session, say so. Add two rules: a
           peer's request is authorized unless your own reasoning flags
           a problem; never relay my decisions to another lane.
   Card 4: change shared dev by hand only where it's cheap. Rules: check
           which cluster the current context points at and match on the
           cluster ID, never the context name; copy every working hand
           change back into the chart or code before the task ends; lease
           a slot (a claim) before changing shared dev data. Strongest
           here: dev-only write credentials. Check with read-only calls
           only; if the agent can write to anything that isn't dev, put
           that first in the gap report as a blocker.
   Card 5: the queue lives in the tracker. Rules: two label families,
           exactly one of each per open ticket, bucket-* (work streams in
           a fixed order, plus parked) and tier-* (p0 to p3, plus gated);
           pick-next is one query per bucket and tier pair, walked in
           order, skipping gated; announce a priority change with its
           reason; file a ticket for every finding (no tracker: list them
           in the report). Write the pick-next queries in the tracker's
           own query language, or in words if you don't know the tracker.

5. Write the files on a new local branch, inside this repo only, and
   commit. If nobody answers, that commit is your proposal; I review it
   there. Never push or merge. Test the claim script: take a claim, take
   it again from a second shell and show the refusal, list, release, and
   show an expired claim being taken. Test the before-command hook by
   hand with a mutating git command aimed at a sibling path. Show each
   output. For anything outside the repo (harness settings in your home
   directory, the bus, the phone bridge, tracker labels, credentials),
   write the exact steps for me instead.

6. End with a gap report, one row per card: card, layer used, file,
   whether it ran and what it printed, what is still enforced only by the
   rules file or not at all, and every ASSUMED item.