docs: add .agents workspace and the Astro refactor plan

Adds the agent-facing workspace and a 20-task plan for migrating the site
to Astro. Nothing here implements the refactor; these are briefs, rules and
templates that the task agents read.

- .agents/ holds context, rules, checklists, skills, specialist agents,
  component/page/config templates and gate scripts. It is vendor-neutral so
  MiniMax, Gemini and Codex can all read it; CLAUDE.md just points at
  AGENTS.md.
- .husky/ plus .lintstagedrc.json wire the three gate tiers. gate.sh locks on
  the shared git-common-dir so parallel worktrees serialise, and guards the
  assertion count in scripts/verify.mjs against a coverage drop.
- plans/astro-refactor/ carries the phase graph, per-task briefs and the
  model-routing recommendation.

These files must be tracked before fanning out: a worktree only checks out
tracked files, so an untracked plan is invisible to every agent working in one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

plans/astro-refactor/MODEL-ROUTING.md

@@ -0,0 +1,73 @@
+# Which model runs which task
+
+You have **MiniMax-M3** (primary), **Gemini**, and **Codex**. They are not
+interchangeable here, and the split is not about which is "smartest" — it is
+about which failure mode each task punishes.
+
+**Honest caveat up front:** I have not benchmarked these three on this
+repository. The routing below is reasoned from task shape and each model's
+known strengths. Validate it cheaply on **task 07** (small, self-contained,
+easy to judge) before fanning out across ten worktrees.
+
+## Short answer
+
+**Run the refactor on MiniMax-M3.** It is your primary, the work is mostly
+bounded mechanical migration with a hard verification gate, and that is exactly
+the shape M3 handles well at low cost. Reach for the other two at three specific
+points where M3 is the wrong tool.
+
+## Routing table
+
+| Task | Model | Why this one |
+| --- | --- | --- |
+| 01 scaffold + gates | **Codex** | Config-heavy, many interacting tools (Astro + husky + lint-staged + CI), and success is binary — it builds and hooks fire, or not. Codex's long autonomous run-until-green loop suits it, and getting the foundation wrong is expensive later. |
+| 02 design tokens | **Gemini** | Needs the whole CSS corpus in one context (8 stylesheets, ~90 KB) plus **visual judgement on screenshots**. Gemini's long context and multimodal comparison are the differentiator; the others would work file-by-file and miss cross-file drift. |
+| 03 verification net | **Codex** | Writing test tooling with a tight feedback loop. Precision about what an assertion pins matters more than speed. |
+| 04 content schema | **MiniMax-M3** | Small, well-specified, one file. |
+| 05–06 content migration | **MiniMax-M3** | High-volume mechanical string moves with a `diff` as the oracle. Cheap, parallel, verifiable. Exactly M3's sweet spot. |
+| 07 primitives | **MiniMax-M3** | Small components from templates. Use this task to calibrate the whole routing decision. |
+| 08–11 component blocks | **MiniMax-M3 ×4 parallel** | Four bounded tasks, one template each, checklist-gated. Cost per task matters because there are many. |
+| 12–14, 17 pages | **MiniMax-M3** | Bounded, snapshot-diff verified. |
+| 15 full guide | **Codex** | The hard one: 50 KB `app.js`, 12 render functions, tab state, bilingual swap. Long sustained reasoning over interacting pieces; the task most likely to need many iterations against a failing check. |
+| 16 review desk | **Codex** | Same shape and worse — search, filtering, file fetching, six query params, markdown rendering, client-side diff. Highest defect risk in the plan. |
+| 18 motion | **Gemini** | Judging whether motion looks right is perceptual. Feed it before/after captures. |
+| 19 contract re-point | **Codex** | 42 assertions to translate without losing coverage. Meticulous, mechanical, verifiable. |
+| 20 cutover | **you, with M3 assisting** | Touches production publishing. A human should be watching. |
+| review of every task | **Gemini** | Fresh eyes, whole-diff-in-context, and it did not write the code. Never review with the model that wrote it. |
+
+## The reasoning in one line each
+
+- **MiniMax-M3** — cheapest per task and strong at bounded, tool-driven edits.
+  Use it for volume: 13 of the 20 tasks. Its weakness is long multi-file
+  reasoning where the spec is vague; every task above that it owns has a
+  template and a mechanical oracle.
+- **Codex** — best at "keep iterating until the check passes" over a
+  complicated existing codebase. Use it where the loop is long and the answer is
+  not obvious: scaffold, the two hard pages, verification.
+- **Gemini** — biggest context and genuinely useful multimodal comparison. Use
+  it where the input is *everything at once* or where the judgement is
+  **visual**: token consolidation, motion, screenshot diffing, and code review.
+
+## Cross-checking rule
+
+Whatever writes a task must not review it. Pair them: M3 writes → Gemini
+reviews; Codex writes → Gemini reviews; Gemini writes → Codex reviews. The
+`reviewer` agent definition is model-agnostic on purpose.
+
+## Swap the routing if you see this
+
+| Symptom | Move the task to |
+| --- | --- |
+| M3 spends more than ~3 iterations failing the same gate | Codex |
+| M3 edits files outside its task scope | Codex, and tighten the brief |
+| Codex "fixes" a red suite by deleting assertions | anything — but re-read `context/verification.md` to it first; `gate.sh` blocks the merge either way |
+| Gemini gives confident visual sign-off with no screenshots attached | require the artifacts; do not accept prose |
+| A task needs more than two models' worth of hand-holding | the task is too big — split it |
+
+## Cost shape
+
+Tasks 05–14 are ~two-thirds of the work and are all M3-eligible. Running those
+on Codex would work and cost several times more for no measurable quality gain,
+because the checklist and `gate.sh` — not the model — are what guarantee those
+outputs. Spend the expensive models where there is no mechanical oracle: 15, 16,
+and the visual judgement calls.