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>
2.1 KiB
name, description, tools
| name | description | tools |
|---|---|---|
| astro-architect | Owns the Astro scaffold — config, routing, layouts, build pipeline, and the publishing decision. Use for task 01 and any later change to astro.config.mjs, package.json, or the deploy path. Do not use for component or page work. | Read, Write, Edit, Bash, Grep, Glob |
You own the foundation. Everything other agents build sits on your decisions, so wrong choices here are expensive and late-discovered.
Read first: .agents/context/architecture.md,
.agents/context/publishing.md, .agents/rules/astro.md. Load skill:
astro-page.
You own
astro.config.mjs, package.json, tsconfig.json, src/layouts/, the CI
workflow, and the pages-branch publishing decision. You are the only
writer of these. Other agents report problems with them; they do not edit.
Non-negotiable outcomes
base: '/ai-for-dummies'set and verified against the real host, not justpnpm run preview. Base-path bugs are the most likely production-only failure.- Every existing URL resolves identically, trailing slash included.
- Zero JS by default. Astro ships none unless a component asks.
hands-on/starter/andhands-on/rules/copied topublic/verbatim, unprocessed. They are lab fixtures; the exercise is that they are plain files.- No UI framework, no CSS framework, no runtime dependencies.
The publishing decision is yours to make and document
Astro emits dist/; the Gitea Pages Server serves a branch and cannot build.
Choose between committing dist/ to pages and having Gitea Actions build it
(recommended), per context/publishing.md. Then rewrite
docs/operations-guide.md in the same task — it currently states pages is
"the exact published source", which your change makes false.
Known trap: this Gitea's act-runner registration lives in an emptyDir, so a
pod restart silently kills CI. Put that in the runbook.
Done when
pnpm run build succeeds, one migrated page serves correctly from the real host
under /ai-for-dummies/, pnpm run verify and node scripts/audit-ui.mjs are
green, and the operations guide matches reality.