Handoffs, a work list, docs for agents

Set up "week two" for running coding agents unattended in this repository:
handoffs that survive a cleared context, a keep-going rule, agent docs that
stay true to the code, and a reviewed close. 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 it runs on events: session start, after a context clear or
      compaction, and turn end (can a turn-end hook refuse the stop?);
   b. how a hook's output reaches the agent's context;
   c. where it reports context size, whether a hook can read it, and the
      token count at which it compacts automatically;
   d. the instructions file it loads at session start, and its scopes.
   If week one's rules file exists, name it; this week adds to it. If
   not, create one under the name the harness loads (from d).

2. This repo. Find any existing handoff, notes or work-list file; any
   docs folder written for agents; existing git hooks and git tags; how
   specs or design notes are kept; the ticket tracker, if one is named.
   Name the file 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 lane name for the handoff file; where the work list should live;
   which directories hold runtime code (the docs gate watches only
   those); who may run an audit. If nobody answers, continue on stated
   assumptions and mark each one ASSUMED in the final report.

4. The cards. For each card, choose the strongest layer available here,
   in this order unless the card names its own: git hook or CI check;
   your harness's hooks or permission settings; the rules file. Name the
   layer and the file, and propose the change as a diff.
   Card 1: state outlives the context window. A handoff file with a
           CURRENT section above an end marker, at most about 6,000
           characters, holding only what is true now plus a working set
           (path:line-range and the conclusion reached); history in an
           archive file, newest first. Both files stay out of git: they
           are this lane's state. Strongest here: a session-start hook
           that prints CURRENT after start, clear and compaction. Then a
           nudge with stale, wrap and urgent bands below the real
           compaction point: measure that point if you can (the size at
           which a past compaction fired); otherwise take the documented
           one, mark it ASSUMED, and leave a wide margin. If no hook can
           read context size, say how the nudge would get it, or that it
           can't.
   Card 2: finishing a task isn't a stop. A keep-going rule in the rules
           file (the only stops: a blocker that needs a person, or the
           context budget) and an ordered work list in a tracked file.
           Strongest here: a turn-end hook that refuses a turn ending on
           work it announced but didn't start. It matches wording, not
           intent; list the phrasings it lets through.
   Card 3: agent docs stay true. A docs/architecture/ folder with a
           README contract (three tiers: always loaded, read on demand,
           never documented; terse; mostly why and gotchas; one owning
           doc per concept). Strongest here: a pre-push hook that refuses
           a push to the shared branch carrying runtime changes past a
           docs tag; other branches push freely. Create the tag once now
           as the baseline; after that only the close step moves it. If
           the repo has no runtime code yet, don't invent a directory:
           leave the gate's path list empty and say so.
   Card 4: nobody closes their own work unreviewed. Rules file only; say
           so in the report. A spec lifecycle (scope, start, audit by a
           fresh agent given the spec and commit range with verdict ship,
           fix first or review, close that reconciles docs, archives the
           spec, moves the docs tag, and transitions the ticket last), and
           a five-line spec header: status, ticket, depends, blocks,
           author. With no tracker, the work list stands in for it.

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. Create the docs tag on that commit. Run
   each hook you wrote once by hand with the input it would get (a
   session-start event, a sample final message, the refs a push would
   see); never push to trigger it. Show each output. For anything outside
   the repo (harness settings in your home directory, hooks registered
   there, tracker changes), write the exact steps for me instead.

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