Marcos Paulo
aae4d42229
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>
74 lines
4.9 KiB
Markdown
74 lines
4.9 KiB
Markdown
# 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.
|