Files
ai-for-dummies/.agents/context/verification.md
T
Marcos Paulo aae4d42229 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>
2026-09-05 01:18:27 +00:00

2.6 KiB

Context: the verification contract

scripts/verify.mjs is 13 KB, 42 throw new Error sites, 16 checkpoints. It reads 26 source files and asserts that specific string tokens appear in them — data-phase="plan", renderTree, .change-lens, styles.css?v=20260904-vote-widget, and so on.

Why this matters more than it looks

These assertions are the only thing standing between this site and silent content loss during a large refactor. They are also all going to break, because they assert against files that will stop existing.

The failure mode to guard against: an agent runs npm run verify, sees red, and "fixes" it by deleting the assertion. The suite goes green and the site loses a section. Deleting an assertion is a change that requires review, the same as deleting a feature.

How the contract must evolve

Three kinds of assertion, three different fates:

Kind Example Fate
Content presence 'data-phase="plan"' in full-guide/index.html Re-point at built output (dist/) — the token should survive rendering. If it does not, the component dropped content.
Implementation detail 'const phases', 'renderTree' in app.js Obsolete. Replace with an assertion about behaviour or output, never delete outright.
Cache-busting version 'app.js?v=20260904-vote-widget' Obsolete — Astro hashes assets. Replace with "the built HTML references a hashed asset".

Rule: the assertion count must not fall. Every removed token is replaced by one that pins the same user-visible fact against the new architecture. The verification engineer owns this and is the only role allowed to reduce coverage, with a written reason per removal.

The stronger check to add

Token-matching is brittle. During the migration, add a rendered-output diff: snapshot the current site's DOM text content per route, then assert the Astro build produces the same text. That catches dropped paragraphs the way token matching cannot.

# before migrating a page, from the vanilla site:
node .agents/scripts/snapshot-route.mjs /models/ > .agents/snapshots/models.txt
# after: same script against dist/, diff must be empty (or reviewed)

See ../skills/verify-contract/SKILL.md.

Also in the suite

scripts/audit-ui.mjs asserts every page has a viewport meta and no external <script>/<link>. Keep it and extend it: it currently misses external URLs inside CSS (@font-face src, @import, url()), which is exactly how the broken Google Fonts request in styles.css:1 got in.