ci-authoringlisted

# CI authoring Pipeline work has a bad feedback loop: the only real test is a push, each push costs minutes, and every failed attempt is visible to everyone. So validate as much as possible locally, and change one thing per push. ## Before writing Read the existing pipelines end to end. A repo's CI usually encodes constraints nobody wrote down — a job that must run on a specific runner, an ordering that exists because of a licence server, a cache key shaped around a quirk. Changing it without reading it reintroduces problems that were already solved. Establish the baseline: current wall-clock time per job, and which job is actually the bottleneck. Optimising a two-minute job while a nine-minute one runs beside it is effort spent on nothing. ## The shape of a good pipeline **Fail fast, cheapest first.** Lint and typecheck before tests before build before e2e. A syntax error should cost thirty seconds, not nine minutes. **Filter to the changed set** on pull requests, full run on the default branch. Take the changed-set command from `docs/agent/repo-map.md`; where the repo has no such tooling, the fallback ladder in the map's **Workspace** section applies. Filtering requires correct fetch depth — most CI checkouts default to a shallow clone, and comparing against a base the runner never fetched silently yields either everything or nothing. **Cache what is expensive and keyed correctly.** The dependency store keyed on the lockfile hash; the build cache keyed on whatever t