# Weir Agent Map This file is the short entry point for coding agents. Keep detailed rules in linked docs so this stays readable. ## Repository Boundaries - Do not use old duplicate checkouts or copied source trees. - Treat `main` as protected. Use short-lived branches and pull requests. - Never revert user changes unless the user explicitly asks for that exact revert. ## Start Here - Project overview: [`README.md`](README.md) - Architecture map: [`ARCHITECTURE.md`](ARCHITECTURE.md) - Local development: [`docs/local-development.md`](docs/local-development.md) - Documentation index: [`docs/README.md`](docs/README.md) - Repository scripts and which language each uses: [`scripts/README.md`](scripts/README.md) - Agent operating model: [`docs/agent-harness.md`](docs/agent-harness.md) - Issue triage: [`docs/triage.md`](docs/triage.md) - Release governance: [`docs/release-governance.md`](docs/release-governance.md) - CI and release standard (shared with Deluno as an identical separate copy): [`docs/ci-standard.md`](docs/ci-standard.md) ## High-Risk Invariants - Media mutation safety lives in [`docs/file-lifecycle-contract.md`](docs/file-lifecycle-contract.md). - Windows installer and upgrade behavior must follow [`docs/release.md`](docs/release.md) and [`docs/smoke-checklists.md`](docs/smoke-checklists.md). - Secrets and credential rotation rules live in [`docs/security-hardening.md`](docs/security-hardening.md). - Operator-facing messages should follow [`docs/operator-messaging-standard.md`](docs/operator-messaging-standard.md). ## Validation Defaults - Server: `dotnet build apps/server/Weir.slnx -warnaserror` and `dotnet test apps/server/Weir.slnx`. - Frontend: from `apps/web`, run `npm run lint`, `npm run build` and `npm run test`. - Tray (Windows): `dotnet build apps/tray/Weir.Tray.slnx` and `dotnet test apps/tray/Weir.Tray.slnx`. - Contract suite (judges a running server over HTTP): `dotnet test apps/server/tests/Weir.Contract.Tests --filter "Area="` per area, listed in `areas.json`; see [`Weir.Contract.Tests/README.md`](apps/server/tests/Weir.Contract.Tests/README.md). The server test run above leaves it and E2E out (`--filter "Category!=Stress&Category!=Contract&Category!=E2E"` is what CI uses). - E2E (Playwright for .NET): `WEIR_E2E=1 dotnet test apps/server/tests/Weir.E2E.Tests`, after `npm run build` in `apps/web` and the browser install in [`Weir.E2E.Tests/README.md`](apps/server/tests/Weir.E2E.Tests/README.md). The packaged live audit is `apps/server/tools/Weir.LiveAudit`. - Weir has no Python: `node scripts/check-no-python.mjs` fails if a `.py` file is tracked. Tooling is Node, PowerShell or .NET. - Packaging smoke checks are documented in [`CONTRIBUTING.md`](CONTRIBUTING.md). - Docs map validation: `node scripts/check-agent-docs.mjs`. - Coverage: CI holds line and branch coverage per project to the floors in [`docs/coverage/floors.json`](docs/coverage/floors.json); a pull request that adds tests raises the floors it earned, and a floor only goes down in a pull request of its own ([`docs/coverage/README.md`](docs/coverage/README.md)). Locally: `npm run test:coverage` in `apps/web`. - Coverage register: `node scripts/check-coverage-register.mjs --base origin/main`. Every route, job kind, setting, event type, web route, screen control and tray menu item needs a row in [`docs/testing/coverage-register.json`](docs/testing/coverage-register.json), and every row names the tests that prove it or the open coverage issue that will. Update the register in the same pull request as the code. The gaps may only go down from the register on the branch you target; no gap count or totals live in the files, so parallel pull requests do not conflict (a rise needs a reasoned `gapIncrease` entry). The rules and the proof types are in [`docs/testing/COVERAGE.md`](docs/testing/COVERAGE.md). ## Working Style - How an issue is worked (owner rule, 7 Nov 2026): raise it; fix it; have the fix peer-reviewed by a higher-capability model (a round table of reviewers when it is risky or contested) before it merges; prove it live on a CI build installed on the rig; close it. Nothing per issue waits on mutation testing or any other multi-hour run. - Mutation testing gates nothing. It runs weekly on a schedule (`mutation.yml`, Sunday 11:17 UTC), and can also be started by hand. Each weekly run is the finding run: every surviving mutant or floor drop is raised as an issue and fixed during the week, and the next run checks the fixes. The loop continues until a full mutation run passes with no new issues. - Encode recurring lessons in docs, scripts, tests, or CI instead of relying on chat memory. - Prefer small PRs with focused validation. - No user-facing issue closes without live proof on the rig, and every tag, release candidates included, needs a passing scenario-suite record before it is made, on its exact commit or on an earlier one with the same shipped files and the same version (a change only to tests, scripts, docs or CI keeps a pass; no waivers): [`docs/release-governance.md`](docs/release-governance.md), [`docs/release.md`](docs/release.md). - If a task exposes missing tooling or missing repository knowledge, add that capability as part of the fix or open a backlog issue.