Files

T

Marcos Paulo 48c31dc1b3 build: migrate from npm to pnpm

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>

2026-09-05 04:29:42 +00:00

4.7 KiB

Raw Blame History

AGENTS.md

Entry point for any AI agent or new engineer working in this repository. Read this file, then follow the links you need. Full map: .agents/ORCHESTRATOR.md.

What is this project?

"AI For Dummies" — a bilingual (EN/PT-BR) presentation and workshop about working with coding agents: model routing, subagents, git worktrees, skills, rules, and verification. It is published as a static site on a self-hosted Gitea Pages Server, and it doubles as its own teaching artifact: the hands-on labs are dependency-free HTML/CSS/JS that workshop attendees point an agent at.

Current stack: hand-written HTML + CSS + ES modules, no build step, no dependencies
Target stack: Astro (see plans/astro-refactor/) — migration in progress
Languages: English and Brazilian Portuguese, toggled client-side
Companion service: vote-service/ (Go + Kubernetes) — separate lifecycle, see its own README

Essential commands

pnpm run verify     # content + interaction contracts (scripts/verify.mjs) — the gate
node scripts/audit-ui.mjs          # responsive / no-external-dependency audit
node scripts/build-skill-review.mjs # regenerate skill-reviews/improved/ from catalog.js
pnpm run serve      # python3 -m http.server 4173

pnpm run verify is not a formality. It is a set of ~42 string-token assertions that pin the site's real content and interactions. A refactor that "passes" by deleting assertions has failed. See .agents/context/verification.md.

Publishing

main is the source of truth. The pages branch is what the Gitea Pages Server actually serves, and its tree must end up identical to main's. The full procedure — including why merge --ff-only does not work here — is in docs/operations-guide.md.

Adding a build step changes this contract. Read .agents/context/publishing.md before doing so.

Never touch

hands-on/starter/ and hands-on/rules/ — lab fixtures. The exercise is that they are dependency-free vanilla HTML/CSS/JS an attendee can hand to an agent. Componentizing them destroys the lesson. They ship as static assets.
submitted-skills/ — other people's submitted work, reproduced verbatim
skill-reviews/improved/ — generated; edit skills-review/catalog.js instead
vote-service/ — separate deploy lifecycle; do not fold into the site build
dist/, node_modules/ — build output, never committed
pnpm-lock.yaml — committed, but never hand-edited. Change it only as a side effect of pnpm install. Every worktree spins up with pnpm install --frozen-lockfile, which fails outright without it.
This project is pnpm-only (packageManager in package.json pins the version). Never run npm install or bun install here — the gate rejects a package-lock.json, yarn.lock, or bun.lock outright. pnpm settings live in pnpm-workspace.yaml, not in a pnpm field in package.json; pnpm 11 ignores that field silently.

Rules

Binding. Read the one that covers what you are about to do.

Rule	When
`astro.md`	any `.astro` file
`theming.md`	any colour, font, or spacing value
`componentization.md`	creating or splitting a component
`animation.md`	any motion, transition, or transform
`accessibility.md`	any interactive element
`content-i18n.md`	any user-visible string
`code-style.md`	always
`git-worktrees.md`	starting or finishing a task

The one thing to understand first

This site's styling is not a design system today. Three near-duplicate palettes have drifted apart (--ink exists as #172f42, #122534, and #173044), and the @font-face rule in styles.css:1 is malformed, so the intended Manrope/DM Mono typography has never actually rendered. "Maintain the same styles" therefore needs a deliberate decision, not a copy-paste. Read .agents/context/design-system.md before touching any CSS.

4.7 KiB Raw Blame History