mandrel 2.39.0 → 2.41.0

package/.agents/skills/core/browser-testing-with-devtools/reference.md

@@ -3,8 +3,8 @@
 **Read this when** a task engages one of the sections below and the Policy
 Capsule in [`SKILL.md`](SKILL.md) does not settle it on its own. The capsule
 is the contract; this file is the reference material behind it. The
-untrusted-data and JS-execution security constraints live in the capsule and
-are not repeated here; generic DevTools tool tables and symptom-by-symptom
+untrusted-content and JS-execution constraints live in the capsule and the
+security baseline it cites; generic DevTools tool tables and symptom-by-symptom
 workflow ladders are omitted as frontier-known.
 
 ## Setting Up Chrome DevTools MCP
@@ -17,7 +17,7 @@ Code settings):
   "mcpServers": {
     "chrome-devtools": {
       "command": "npx",
-      "args": ["@anthropic/chrome-devtools-mcp@latest"]
+      "args": ["chrome-devtools-mcp@latest"]
     }
   }
 }
@@ -28,47 +28,8 @@ network monitor, performance traces, computed styles, the accessibility tree,
 and read-only JavaScript execution — the runtime evidence that static code
 analysis cannot provide.
 
-## Writing Test Plans for Complex UI Bugs
+## The clean-console standard
 
-For a complex UI issue, write a structured test plan the agent can follow in
-the browser — each step names its expected result and the console/network
-checks that confirm it:
-
-```markdown
-## Test Plan: Task completion animation bug
-
-### Setup
-
-1. Navigate to http://localhost:3000/tasks
-2. Ensure at least 3 tasks exist
-
-### Steps
-
-1. Click the checkbox on the first task
-   - Expected: strikethrough animation, task moves to "completed" section
-   - Check: console has no errors
-   - Check: network shows PATCH /api/tasks/:id with { status: "completed" }
-
-2. Click undo within 3 seconds
-   - Expected: task returns to the active list with reverse animation
-   - Check: network shows PATCH /api/tasks/:id with { status: "pending" }
-
-### Verification
-
-- [ ] All steps completed without console errors
-- [ ] Network requests are correct and not duplicated
-- [ ] Visual state matches expected behavior
-- [ ] Accessibility: task status changes are announced to screen readers
-```
-
-## Screenshot-Based Verification
-
-Use screenshots for visual regression checks: take a "before" screenshot, make
-the code change, reload, take an "after" screenshot, and compare. This is
-especially valuable for CSS changes, responsive layouts at different viewports,
-loading/empty/error states, and transitions.
-
-**Clean-console standard.** A production-quality page has **zero** console
-errors and warnings. If the console is not clean after a browser-touching
-change, fix the warnings before shipping — warnings become errors, and a clean
-console catches bugs early.
+A production-quality page has **zero** console errors and warnings. If the
+console is not clean after a browser-touching change, fix the warnings before
+shipping — warnings become errors, and a clean console catches bugs early.

package/.agents/skills/core/code-review-and-quality/SKILL.md

@@ -14,13 +14,8 @@ description:
 
 - Every change gets reviewed before merge — no exceptions, including agent-authored code.
 - Apply the **five-axis review** to every change: **Correctness, Readability & Simplicity, Architecture, Security, Performance**.
-- Approval standard: approve when the change **definitely improves overall code health**, even if it isn't perfect. Don't block on stylistic preferences that match project conventions.
-- Verify the spec/task requirements are met, edge cases (null, empty, boundary) and error paths are handled, and the tests are actually testing the right things — not just that they pass.
-- Reject "clever" code in favour of the boring, obvious solution. Abstractions MUST earn their complexity (no generalizing before the third use case).
 - Flag dead code artifacts (`_unused` vars, backwards-compat shims, `// removed` comments) and require their removal before merge.
 - Defer to `.agents/rules/security-baseline.md` and the `security-and-hardening` skill for security review; explicit checks include input validation, no hardcoded secrets, parameterized queries, encoded output, authn+authz, and treating external data as untrusted.
-- Review performance on the hot path only, and measure before optimizing; explicit checks include no N+1 queries, no unbounded fetches, no blocking sync work, no obviously oversized bundles.
-- Disallow scope creep in a PR: drive-by cleanups, adjacent refactors, and "while I'm here" edits should be split into a separate change.
 - Bug-fix reviews cover **both** the fix and the regression test; a fix without a failing-then-passing test is not approvable.
 - **Refactoring is post-green and behaviour-preserving.** Run the refactor pass only when the suite is already green and gates pass; inputs, outputs, side effects, error semantics, and ordering MUST be identical before and after, and existing tests MUST keep passing **without modification** (if a test had to change, behaviour changed — revert).
 - **Lower CRAP by lowering complexity, and remove duplication at the root.** Target the highest-CRAP well-covered functions and the largest verbatim duplications by measurement (`check-baselines.js`), not by smell; extract one well-named helper rather than leaving near-copies. CRAP must not rise and maintainability must not fall on any touched file, and no gate, floor, or threshold may be retuned to make the pass "succeed".

package/.agents/skills/core/documentation-and-adrs/SKILL.md

@@ -14,11 +14,8 @@ description:
 - Write an ADR for any decision that would be expensive to reverse (framework choice, data model, auth strategy, API architecture, hosting platform).
 - Mandrel ships **two first-class decisions-log layouts** — pick one at onboarding (see [Decisions-log layouts](reference.md#decisions-log-layouts)): the **single-file dated-entry** `docs/decisions.md` (default; best for small projects) or the **index + `docs/decisions/` directory** (MADR-style, one file per ADR; best once the log outgrows a single file). Either way, the canonical ADR sections are **Status, Date, Deciders, Context, Decision, (Alternatives Considered), Consequences**.
 - Mark an ADR's status as `Accepted`, `Superseded by ADR-XXX`, `Deprecated`, or `Reverted (<date>)` — a reverted decision was **undone** rather than replaced, so unlike a superseded one it has no successor to point at. Never silently delete an ADR — supersede it.
-- Do **not** document obvious code; do **not** restate what the code already says. Stale or redundant docs are worse than no docs.
-- Comments explain **non-obvious intent** (the why). If a comment describes what the code does, refactor the code instead.
 - Keep user-facing docs (README, API docs, changelog) updated as part of the change — out-of-date docs are bugs.
 - Pair every public API change with a changelog entry that links the relevant Story and any superseding ADR.
-- When you find yourself explaining the same thing repeatedly in chat, write it down — the explanation belongs in the project docs or an ADR.
 
 ## Long-form reference — read on demand
 

package/.agents/skills/core/gates-and-baselines/SKILL.md

@@ -2,9 +2,10 @@
 name: gates-and-baselines
 description:
   Governs quality gates and the unified-baseline snapshots. Use when authoring
-  a baseline refresh commit (CRAP, maintainability, dead-exports, lighthouse),
-  when setting up or modifying CI quality gates, or when introducing a new gate
-  that asserts on pre-existing state without turning the integration branch red.
+  a baseline refresh commit (coverage, CRAP, maintainability, duplication,
+  dead-exports), when setting up or modifying CI quality gates, or when
+  introducing a new gate that asserts on pre-existing state without turning the
+  base branch red.
 allowed_tools:
   - Read
   - Write
@@ -15,141 +16,13 @@ allowed_tools:
 
 ## Policy Capsule
 
-- **No gate may be skipped.** Failing lint means fix lint, not disable the rule; a failing test means fix the code, not `.skip` or delete the test. Gates are ordered shift-left so cheap checks fail first, and CI failure output is fed back verbatim with the directive to reproduce and fix locally before re-pushing.
+- **No gate may be skipped.** Failing lint means fix lint; a failing test means fix the code, not `.skip` or delete the test. Feed CI failure output back verbatim and reproduce locally before re-pushing.
 - **Introducing a gate that asserts on pre-existing state** (doc-drift, lint-vocabulary, dependency-cycle, missing-coverage) MUST land green at merge: either advisory-first (report-only until the backlog is burned down) or with the populated baseline committed in the same change that turns the gate on. Never wire a gate into `requiredChecks` that lands red on latent findings nobody authored.
 - **Refresh a baseline only when the change is deliberate** — a rename/move, an operator-approved complexity bump, a signed-off perf delta, an intentional API-surface change. Never refresh to paper over an unintentional regression; fix the regression instead.
-- **Pick the refresh that matches why you are refreshing** — the two are different scopes, and the wrong one silently no-ops. `npm run <kind>:update` is **diff-scoped**: it re-scores only files changed in `origin/main..HEAD` and preserves every other row verbatim. That is what you want after changing code. `npm run <kind>:reanchor` is the same script with `--full-scope`: it re-scores every file in every target dir. That is what you want when the baseline is **stale** — a scorer-version bump, a coverage-shape change, accumulated drift — because a diff-scoped run would leave the stale rows exactly as they were and the staleness finding would re-fire. Kinds with both scopes: `coverage`, `crap`, `maintainability`, `duplication`. Dead-exports has a producer but no scope axis — knip scores the whole graph, so `npm run dead-exports:update` (both passes, via `.agents/scripts/update-dead-exports-baseline.js`) is the only sanctioned way to write `baselines/dead-exports.json` / `baselines/dead-exports-production.json`; never hand-edit those files. Lighthouse still has no producer — edit `baselines/lighthouse.json` directly. Run any of them on the **Story branch**, not on `main`.
+- **Pick the refresh that matches why you are refreshing** — the wrong scope silently no-ops. `npm run <kind>:update` is **diff-scoped**: it re-scores only files changed in `origin/main..HEAD` and preserves every other row verbatim; that is what you want after changing code. `npm run <kind>:reanchor` is the same script with `--full-scope` and re-scores every file in every target dir; that is what you want when the baseline is **stale** (a scorer-version bump, a coverage-shape change, accumulated drift), because a diff-scoped run would leave the stale rows exactly as they were.
+- Kinds carrying both scopes: `coverage`, `crap`, `maintainability`, `duplication`. Dead-exports has no scope axis — knip scores the whole graph, so `npm run dead-exports:update` (both passes) is the only sanctioned way to write `baselines/dead-exports.json` / `baselines/dead-exports-production.json`; never hand-edit them. Run any refresh on the **Story branch**, never on `main`.
 - Verify the refresh diff is scoped to the relevant `baselines/<kind>.json` (plus cosmetic `package-lock.json` churn only). If unrelated files appear, STOP — the refresh is contaminated. Stage baseline files **explicitly** (`git add baselines/<kind>.json`); never `git add -A` in a refresh commit.
-- Commit-subject contract: a **Conventional-Commits** subject `chore(baselines): refresh <kind> snapshot for <reason>` — never an ad-hoc leading token like `baseline-refresh:` (commitlint and the planner validator reject it). The body is **mandatory** and non-empty: what changed, why the new floor is correct, and the Story that triggered it.
-- Add the machine-readable trailer `baseline-refresh: true` (git-trailer `Key: value` style) and `Story: #<storyId>` to the body whenever observability classification matters. Never pass `--no-verify`; the `commit-msg` hook (commitlint) MUST run and pass.
+- Commit-subject contract: the **Conventional-Commits** subject `chore(baselines): refresh <kind> snapshot for <reason>` — never an ad-hoc leading token like `baseline-refresh:` (commitlint and the planner validator reject it). The body is **mandatory** and non-empty: what changed, why the new floor is correct, and the Story that triggered it.
+- Add the machine-readable trailer `baseline-refresh: true` (git-trailer `Key: value` style) and `Story: #<storyId>` to that body. Never pass `--no-verify`; the `commit-msg` hook (commitlint) MUST run and pass.
 - After the refresh lands, re-run `node .agents/scripts/check-baselines.js` to confirm the gate passes against the new snapshot; if it still fails, a sibling kind drifted — refresh that kind too.
-- Keep credentials in GitHub Secrets (or platform equivalent) even for CI-only test databases; treat the security audit (`npm audit` or equivalent) as gating for critical/high vulnerabilities reachable in production code.
-
-## The Quality Gate Pipeline
-
-Automate quality gates so no change reaches production without passing tests,
-lint, type checking, and build. **Shift left** — a bug caught in linting costs
-minutes; the same bug caught in production costs hours — and prefer many small,
-frequent releases over big-bang merges (a deploy of 3 changes is debuggable, one
-of 30 is not).
-
-```text
-lint → typecheck → unit tests → build → integration → E2E (optional)
-     → security audit → bundle-size
-```
-
-**No gate can be skipped.** If lint fails, fix lint. If a test fails, fix the
-code. When CI fails, feed the specific error back into the agent loop with the
-directive to verify locally before re-pushing.
-
-### Introducing a gate on pre-existing state
-
-A new gate that asserts on latent state (doc-drift, lint-vocabulary,
-dependency-cycle, missing-test-coverage) lands red because of findings nobody
-authored, and every downstream PR is blocked until someone hotfixes the
-integration branch. Before wiring such a gate into `requiredChecks`, land it in
-a shape that is green at merge — **advisory-first** (report-only until the
-backlog is burned down) or by **committing the populated baseline in the same
-change** that turns the gate on.
-
-## Baseline Refresh
-
-The close-validation chain enforces unified baseline snapshots
-(`baselines/crap.json`, `baselines/maintainability.json`,
-`baselines/dead-exports.json`, `baselines/lighthouse.json`). A refresh is **not**
-a regression entry — it tells the ratchet that the new baseline key is
-intentional, so the gate compares future runs against the refreshed snapshot
-rather than the prior one.
-
-**When to refresh:** a file rename/move detached an MI/CRAP key; a method rename
-inside a file produced a phantom new + phantom deleted key (escomplex keys CRAP
-rows on `<file>::<methodName>`); an operator-approved complexity bump or perf
-delta needs to be enshrined as the new floor; a dead-export gate flagged a
-signed-off API-surface change. If the underlying change is an **unintentional**
-regression, do not refresh — remediate first.
-
-### Commit-subject contract (authoritative)
-
-```text
-chore(baselines): refresh <kind> snapshot for <reason>
-
-<non-empty body explaining the refresh — what changed, why the new
-baseline is the correct floor, and any operator sign-off reference>
-
-baseline-refresh: true
-Story: #<storyId>
-```
-
-The `commit-msg` hook (`commitlint`) rejects any subject whose leading token is
-not one of `feat|fix|chore|refactor|perf|docs|style|test|build|ci|revert`, and
-`--no-verify` is forbidden by
-[`.agents/rules/git-conventions.md`](../../../rules/git-conventions.md), so the
-subject MUST conform. `release-please` consumes the subject on `main`;
-`chore(baselines):` keeps the refresh out of the user-facing changelog (correct —
-it is internal hygiene) while staying machine-parseable. The
-`baseline-refresh: true` **body trailer** is the canonical machine-readable
-marker — subject-level leading tokens are not, and must not be, used for this
-purpose. (Its only reader, `baseline-refresh-rate.js`, went with the
-execution-analysis surface in Story #4545; the trailer convention stands on its
-own as the parseable marker for any future reader.)
-
-### Procedure
-
-| Kind            | After a code change (diff-scoped)  | Stale baseline (full re-anchor)      |
-| --------------- | ---------------------------------- | ------------------------------------ |
-| CRAP            | `npm run crap:update`              | `npm run crap:reanchor`              |
-| Maintainability | `npm run maintainability:update`   | `npm run maintainability:reanchor`   |
-| Coverage        | `npm run coverage:update`          | `npm run coverage:reanchor`          |
-| Duplication     | `npm run duplication:update`       | `npm run duplication:reanchor`       |
-| Dead-exports    | `npm run dead-exports:update` (regenerates both passes; never hand-edit the JSON) | same — no scope flag applies |
-| Lighthouse      | edit `baselines/lighthouse.json`   | same — no scope flag applies         |
-
-1. **Run the matching command for your reason** — left column after a code
-   change, right column for a stale baseline — on the Story branch (HEAD must
-   already be the Story branch, not `main`).
-2. **Verify the diff is scoped** to the relevant `baselines/<kind>.json` (and
-   possibly cosmetic `package-lock.json` churn). Unrelated files → STOP, the
-   refresh is contaminated. Judge contamination by **which files** changed, not
-   how many rows moved inside the baseline: a `:reanchor` legitimately rewrites
-   most of its own file, so say in the commit body that the breadth is a
-   re-anchor and not a mass regression.
-3. **Author the commit.** Stage the baseline file(s) explicitly, then commit with
-   the Conventional-Commits subject + body trailer above:
-
-   ```bash
-   git add baselines/<kind>.json
-   git commit -m "$(cat <<'EOF'
-   chore(baselines): refresh <kind> snapshot for <reason>
-
-   <body: what changed, why the new floor is correct, linking the Story.>
-
-   baseline-refresh: true
-   Story: #<storyId>
-   EOF
-   )"
-   ```
-
-   Do NOT pass `--no-verify`.
-4. **Re-run the gate** — `node .agents/scripts/check-baselines.js`. If it still
-   fails, a sibling kind drifted; repeat from step 1 for that kind.
-
-## Red Flags
-
-- CI failures ignored or silenced; tests disabled in CI to make the pipeline pass.
-- A new required gate merged red on pre-existing findings, blocking every
-  downstream PR.
-- A legacy ad-hoc leading token (`baseline-refresh:`) as the commit subject type.
-- An empty-body refresh — unreviewable, hides the operator decision.
-- A refresh commit whose diff touches unrelated files (contaminated refresh).
-- Refreshing to paper over an unintentional regression.
-- Secrets stored in code or CI config instead of a secrets manager.
-
-## Verification
-
-- [ ] Every quality gate is present (lint, types, tests, build, audit) and
-      failures block merge (branch protection configured).
-- [ ] Any newly introduced gate is green at merge (advisory-first or
-      baseline-in-same-change).
-- [ ] A baseline refresh uses the Conventional-Commits subject + non-empty body
-      + `baseline-refresh: true` trailer, staged explicitly, no `--no-verify`.
-- [ ] `check-baselines.js` passes against the refreshed snapshot.
+- Open a [`reference.md`](reference.md) section only when the task engages it: the baseline roster, the per-kind refresh table, and the step-by-step procedure live there.

package/.agents/skills/core/gates-and-baselines/reference.md

@@ -0,0 +1,103 @@
+# Gates and Baselines — Reference (on-demand)
+
+**Read this when** a refresh is actually in front of you and the Policy Capsule
+in [`SKILL.md`](SKILL.md) does not settle it. The capsule is the contract; this
+file is the roster, the per-kind command table, and the procedure.
+
+## The baseline roster
+
+`baselines/` holds one snapshot per gate kind. What is present here is what
+`check-baselines.js` and its siblings enforce:
+
+| Baseline | Enforced by |
+| --- | --- |
+| `coverage.json` | `npm run coverage:check` |
+| `crap.json` | `npm run crap:check` |
+| `maintainability.json` | `npm run maintainability:check` |
+| `duplication.json` | `npm run duplication:check` |
+| `dead-exports.json`, `dead-exports-production.json` | `check-dead-exports.js` |
+| `arch-cycles.json` | `npm run check:arch` |
+| `cyclomatic.json` | `npm run check:cyclomatic` |
+| `context-budget.json` | `npm run check:context-budget` |
+| `workflow-citations.json` | `npm run check:workflow-citations` |
+| `agents-loc.csv` | `npm run baseline:agents-loc` |
+
+A refresh is **not** a regression entry — it tells the ratchet that the new
+baseline key is intentional, so the gate compares future runs against the
+refreshed snapshot rather than the prior one.
+
+**When to refresh:** a file rename/move detached an MI/CRAP key; a method
+rename inside a file produced a phantom new + phantom deleted key (escomplex
+keys CRAP rows on `<file>::<methodName>`); an operator-approved complexity bump
+or perf delta needs to be enshrined as the new floor; a dead-export gate
+flagged a signed-off API-surface change. If the underlying change is an
+**unintentional** regression, do not refresh — remediate first.
+
+## Per-kind refresh commands
+
+| Kind            | After a code change (diff-scoped)  | Stale baseline (full re-anchor)      |
+| --------------- | ---------------------------------- | ------------------------------------ |
+| CRAP            | `npm run crap:update`              | `npm run crap:reanchor`              |
+| Maintainability | `npm run maintainability:update`   | `npm run maintainability:reanchor`   |
+| Coverage        | `npm run coverage:update`          | `npm run coverage:reanchor`          |
+| Duplication     | `npm run duplication:update`       | `npm run duplication:reanchor`       |
+| Dead-exports    | `npm run dead-exports:update` (regenerates both passes; never hand-edit the JSON) | same — no scope flag applies |
+| Cyclomatic      | `npm run cyclomatic:update`        | same — no scope flag applies         |
+| Context budget  | `node .agents/scripts/check-context-budget.js --update` | same — no scope flag applies |
+
+## Procedure
+
+1. **Run the matching command for your reason** — left column after a code
+   change, right column for a stale baseline — on the Story branch (HEAD must
+   already be the Story branch, not `main`).
+2. **Verify the diff is scoped** to the relevant `baselines/<kind>.json` (and
+   possibly cosmetic `package-lock.json` churn). Unrelated files → STOP, the
+   refresh is contaminated. Judge contamination by **which files** changed, not
+   how many rows moved inside the baseline: a `:reanchor` legitimately rewrites
+   most of its own file, so say in the commit body that the breadth is a
+   re-anchor and not a mass regression.
+3. **Author the commit.** Stage the baseline file(s) explicitly, then commit
+   with the Conventional-Commits subject the capsule pins, plus the body and
+   trailers:
+
+   ```bash
+   git add baselines/<kind>.json
+   git commit -m "$(cat <<'EOF'
+   <the refresh subject the Policy Capsule pins>
+
+   <body: what changed, why the new floor is correct, linking the Story.>
+
+   baseline-refresh: true
+   Story: #<storyId>
+   EOF
+   )"
+   ```
+
+   Do NOT pass `--no-verify`.
+4. **Re-run the gate** — `node .agents/scripts/check-baselines.js`. If it still
+   fails, a sibling kind drifted; repeat from step 1 for that kind.
+
+The `baseline-refresh: true` body trailer — not a subject-level token — is the
+canonical machine-readable marker for a refresh commit; the decision and its
+history are recorded in
+[`docs/decisions.md` ADR 20260906-5160b](../../../../docs/decisions.md).
+
+## Red Flags
+
+- CI failures ignored or silenced; tests disabled in CI to make the pipeline
+  pass.
+- A new required gate merged red on pre-existing findings, blocking every
+  downstream PR.
+- A legacy ad-hoc leading token (`baseline-refresh:`) as the commit subject
+  type.
+- An empty-body refresh — unreviewable, hides the operator decision.
+- A refresh commit whose diff touches unrelated files (contaminated refresh).
+- Refreshing to paper over an unintentional regression.
+
+## Verification
+
+- [ ] Any newly introduced gate is green at merge (advisory-first or
+      baseline-in-same-change).
+- [ ] A baseline refresh uses the pinned subject + non-empty body +
+      `baseline-refresh: true` trailer, staged explicitly, no `--no-verify`.
+- [ ] `check-baselines.js` passes against the refreshed snapshot.

package/.agents/skills/core/idea-refinement/SKILL.md

@@ -34,15 +34,6 @@ separate Epic Clarity Gate path in v2 — N=1 Story authoring with a folded
 You are an ideation partner. Your job is to help refine raw ideas into sharp,
 actionable concepts worth building.
 
-### Philosophy
-
-- Simplicity is the ultimate sophistication. Push toward the simplest version
-  that still solves the real problem.
-- Start with the user experience, work backwards to technology.
-- Say no to 1,000 things. Focus beats breadth.
-- Challenge every assumption. "How it's usually done" is not a reason.
-- Show people the future — don't just give them better horses.
-
 ### Process
 
 When the user invokes this skill with an idea (`$ARGUMENTS`), guide them through
@@ -93,9 +84,8 @@ before anything lands in the Phase 3 one-pager.
    vitamin), feasibility branches (cost, hardest part, build vs. buy,
    sequencing), differentiation branches (why switch), and hidden assumptions
    (what you're betting is true, what could kill this, what you're ignoring and
-   why that's okay for now). Read `refinement-criteria.md` in this skill
-   directory for the full evaluation rubric. If the list is empty after
-   enumeration, take the off-ramp.
+   why that's okay for now). If the list is empty after enumeration, take the
+   off-ramp.
 
 3. **Interrogate sequentially.** For each branch, in priority order
    (highest-leverage / most blocking first):
@@ -177,9 +167,3 @@ saying no to good ideas. Make the trade-offs explicit.
 
 Ask the user if they'd like to save this to `docs/ideas/[idea-name].md` (or a
 location of their choosing). Only save if they confirm.
-
-### Tone
-
-Direct, thoughtful, slightly provocative. You're a sharp thinking partner, not a
-facilitator reading from a script. Channel the energy of "that's interesting,
-but what if…" — always pushing one step further without being exhausting.

package/.agents/skills/core/security-and-hardening/SKILL.md

@@ -4,8 +4,8 @@ description:
   Hardens code against vulnerabilities. Use when handling user input,
   authentication, data storage, or external integrations. The non-negotiable
   security MUSTs live in `.agents/rules/security-baseline.md`; this skill shows
-  how to apply them with process guidance, an audit-triage tree, and a review
-  checklist.
+  how to apply them, with the project's surfacing and validation-response
+  process.
 ---
 
 # Security and Hardening
@@ -35,5 +35,3 @@ task engages it.
 
 - [Security Surfacing, Not Runtime Pause](reference.md#security-surfacing-not-runtime-pause)
 - [Validation-Error Responses](reference.md#validation-error-responses)
-- [Triaging npm audit Results](reference.md#triaging-npm-audit-results)
-- [Security Review Checklist](reference.md#security-review-checklist)

package/.agents/skills/core/security-and-hardening/reference.md

@@ -45,73 +45,3 @@ and [§ Response Envelope](../../../rules/api-conventions.md#response-envelope).
 Do not hand-roll a divergent status (e.g. 422) or envelope shape in
 security-relevant handlers — cite the rule and reuse its shape, keeping the
 security skill and the api skill in agreement.
-
-## Triaging npm audit Results
-
-The MUST is in [security-baseline § Dependency Hygiene](../../../rules/security-baseline.md#dependency-hygiene).
-This decision tree shows how to prioritize:
-
-```text
-npm audit reports a vulnerability
-├── Severity: critical or high
-│   ├── Is the vulnerable code reachable in your app?
-│   │   ├── YES --> Fix immediately (update, patch, or replace the dependency)
-│   │   └── NO (dev-only dep, unused code path) --> Fix soon, but not a blocker
-│   └── Is a fix available?
-│       ├── YES --> Update to the patched version
-│       └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date
-├── Severity: moderate
-│   ├── Reachable in production? --> Fix in the next release cycle
-│   └── Dev-only? --> Fix when convenient, track in backlog
-└── Severity: low
-    └── Track and fix during regular dependency updates
-```
-
-**Key questions:**
-
-- Is the vulnerable function actually called in your code path?
-- Is the dependency a runtime dependency or dev-only?
-- Is the vulnerability exploitable given your deployment context (e.g., a
-  server-side vulnerability in a client-only app)?
-
-When you defer a fix, document the reason and set a review date.
-
-## Security Review Checklist
-
-Use this when reviewing your own change before requesting human review. Each
-item maps to a section in
-[`security-baseline.md`](../../../rules/security-baseline.md).
-
-```markdown
-### Authentication
-
-- [ ] Passwords hashed with bcrypt/scrypt/argon2 (salt rounds ≥ 12)
-- [ ] Session tokens are httpOnly, secure, sameSite
-- [ ] Login has rate limiting
-- [ ] Password reset tokens expire
-
-### Authorization
-
-- [ ] Every endpoint checks user permissions
-- [ ] Users can only access their own resources
-- [ ] Admin actions require admin role verification
-
-### Input
-
-- [ ] All user input validated at the boundary
-- [ ] SQL queries are parameterized
-- [ ] HTML output is encoded/escaped
-
-### Data
-
-- [ ] No secrets in code or version control
-- [ ] Sensitive fields excluded from API responses
-- [ ] PII encrypted at rest (if applicable)
-
-### Infrastructure
-
-- [ ] Security headers configured (CSP, HSTS, etc.)
-- [ ] CORS restricted to known origins
-- [ ] Dependencies audited for vulnerabilities
-- [ ] Error messages don't expose internals
-```