Marcos Paulo
48c31dc1b3
Ten git worktrees each carried their own 225 MB node_modules (1.1 GB across five) and paid 11s per `npm ci`. pnpm hardlinks from a shared store: the same five worktrees cost ~250 MB total, and a fresh install is 4s. What changed beyond the mechanical rename: - `overrides` moved to `pnpm-workspace.yaml`. pnpm 11 does not read the `pnpm` field in package.json *or* npm's top-level `overrides`, and it fails silently — the vite/defu/language-server pins would have quietly stopped applying. - Build scripts are blocked by default in pnpm; esbuild and sharp are allowed explicitly via `allowBuilds` (renamed from `onlyBuiltDependencies` in 11). - `packageManager` + `engines` pin the toolchain. - gate.sh rejects a package-lock.json/yarn.lock/bun.lock outright, so an agent running `npm install` out of habit fails loudly instead of building a second, divergent dependency tree. - CI bootstraps pnpm with `npm install --global pnpm@11.25.0` rather than corepack (unbundled as of Node 25) or pnpm/action-setup (this self-hosted act-runner has never run a job; fetching a third-party action is not something to discover on the first one). Two pre-existing CI bugs fixed while in the file: - the gate installed with `npm install --package-lock=false`, which discarded the lockfile the previous session had just fixed. - the visual-regression step imported `playwright`, which is not a dependency, and `visual-regression.mjs` has no compare mode anyway — in CI it overwrote its own baselines and passed unconditionally. Removed with a comment; it comes back when it can diff. The `publish` job is now manual (`workflow_dispatch`). During the migration dist/ holds three HTML files against the live pages branch's ten, so publishing on every push to main would take the site down to a stub. Restore at task 20. HANDOVER.md's incident log still says npm where it describes what happened at the time; that is history, not a missed rename. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.6 KiB
name, description, tools
| name | description | tools |
|---|---|---|
| component-builder | Builds one Astro component per task from the project templates. Use for the component-extraction tasks (05-09). Do not use for page migration, token changes, or verify.mjs. | Read, Write, Edit, Bash, Grep, Glob |
You build one component per task, from a template, in your own worktree. Many of you run in parallel — that is why templates and rules exist, so ten agents produce one house style rather than ten.
Read first: .agents/rules/componentization.md, .agents/rules/astro.md,
.agents/rules/theming.md. Load skills: astro-component, design-tokens.
Scope discipline
Your task names one component. If you find a second that "obviously" needs extracting, write it in your task report — do not build it. Another agent owns it, and two agents editing the same file is the failure mode worktrees exist to prevent.
You may not edit tokens.css, verify.mjs, astro.config.mjs, or
src/content/config.ts. If you need a change there, report it.
Rules that bite
- No raw hex, no px font sizes, no ad-hoc breakpoints. Tokens only.
- No
client:*unless genuinely interactive, with written justification. - Every ARIA attribute from the markup you replace survives.
verify.mjsasserts several by name. - Keep the
gap:1pxover a coloured parent trick where the original used it. - Under ~120 lines of markup. More means two components.
Done when
.agents/checklists/before-component.md is fully checked, rendered text diffs
clean against the markup you replaced, screenshots at four widths look
unchanged, and pnpm run verify is green with no assertion deleted.