Update the audit-docs prompt

.claude/rules/code-style.md

@@ -12,15 +12,15 @@ These rules mirror [`.github/copilot-instructions.md`](../../.github/copilot-ins
 
 - **Tabs, not spaces** for indentation (ESLint errors otherwise).
 - Semicolons required; single quotes (including JSX); `printWidth` 120; trailing commas everywhere.
-- Imports are sorted automatically by `@trivago/prettier-plugin-sort-imports` — don't hand-order them.
+- Imports are sorted automatically by `@trivago/prettier-plugin-sort-imports` - don't hand-order them.
 - Prefix intentionally-unused variables/args with `_` (e.g. `_event`) so ESLint ignores them.
 
 ## Imports
 
 - **Always use path aliases, never relative paths.** Aliases are defined in [`tsconfig.json`](../../tsconfig.json) and mirrored in [`jest.config.js`](../../jest.config.js):
   `@/`, `@components/`, `@configs/`, `@constants/`, `@data/`, `@helpers/`, `@images/`, `@layouts/`, `@styles/`, `@util/`.
-- Example: `import Avatar from '@components/banner/Avatar';` — not `'../banner/Avatar'`.
-- Import Node built-in modules with the **bare specifier** (`import { readFileSync } from 'fs'`), never the `node:` prefix (`'node:fs'`). Matches the existing convention — e.g. `require('util')` in [`jest/setup.ts`](../../jest/setup.ts).
+- Example: `import Avatar from '@components/banner/Avatar';` - not `'../banner/Avatar'`.
+- Import Node built-in modules with the **bare specifier** (`import { readFileSync } from 'fs'`), never the `node:` prefix (`'node:fs'`). Matches the existing convention - e.g. `require('util')` in [`jest/setup.ts`](../../jest/setup.ts).
 
 ## Components & styling
 
@@ -31,4 +31,4 @@ These rules mirror [`.github/copilot-instructions.md`](../../.github/copilot-ins
 ## TypeScript
 
 - Strict mode is on; types must be explicit (no implicit `any`).
-- Do **not** "fix" an existing `any` by swapping it to `unknown` or adding an `eslint-disable` — replace it with a specific concrete type, and respect an `any` that is intentional.
+- Do **not** "fix" an existing `any` by swapping it to `unknown` or adding an `eslint-disable` - replace it with a specific concrete type, and respect an `any` that is intentional.

.claude/rules/docs-authoring.md

@@ -11,21 +11,24 @@ When creating or editing any markdown file, follow the discipline below. These a
 ## Accuracy
 
 - **Zero hallucination.** Document only what the code provably does. Read the implementation; don't infer behaviour from a name, type, comment, file location, or familiar pattern.
-- **Prove it.** Before writing any technical claim, know the exact file (and ideally lines) that prove it. If you can't, don't write it. Silence beats speculation — no "appears to", "should", "will", or planned/intended behaviour.
+- **Prove it.** Before writing any technical claim, know the exact file (and ideally lines) that prove it. If you can't, don't write it. Silence beats speculation: no "appears to", "should", "will", or planned/intended behaviour.
 - Fix existing statements that contradict the code.
 
 ## Style
 
+- **No em-dashes or en-dashes.** Never write `—` (em-dash) or `–` (en-dash); replace each with a comma, parenthesis, colon, separate sentence, or a spaced hyphen `-`. The hyphen `-` is fine wherever it is grammatically correct, including the ` - ` separator between a label and a brief description in lists. When you edit a markdown file, replace its existing em-dashes and en-dashes too.
+- **Canadian English (strong preference)** for prose you write or change: colour, behaviour, favour, centre, defence, and `-ize`/`-ization` (standardize, organization). See the [Canadian spelling guide](https://our-languages.canada.ca/en/blogue-blog/canadian-spelling-eng). Don't retroactively convert existing prose, and never change code identifiers, config/JSON keys, quoted code, file/package names, or CSS properties (`background_color`, `themeColor`).
 - **No subjective adjectives** in new prose (important, critical, robust, seamless, powerful, efficient, etc.). State facts.
 - High-density, low-volume: explain *why* and *how the system uses it*, not line-by-line narration. Bullets for lists/steps, paragraphs only for intros/complex architecture.
-- Document configuration by its **external-facing name** (env var, config key, CLI flag), never the internal variable name.
+- Document a tunable value by the **name a consumer changes it by** (env var, config key, CLI flag, or a named member of a centralized constants/config module that other code reads), judging by role, not location. Don't document an ephemeral local variable as the config surface.
+- **Acronyms** in prose you write or edit use capitals (ID, URL) and are expanded on first use per doc ("Deoxyribonucleic acid (DNA)"). Keep exact casing for brand/tool/package names (npm, iOS), domain terms (snRNA), and direct code references (an `id` field).
 - No placeholders, TODOs, or empty "add details here" sections.
 
 ## Links & code
 
 - Every file reference is a **clickable markdown link to a file**, never a bare filename and never a link to a directory. Link to a file inside the directory (e.g. its `index.md`/`README.md`) instead.
 - Use relative links (GitHub-compatible) and verify the path resolves from the doc's own location.
-- Don't paste full definitions/class bodies — link to the file. Inline snippets only for a short usage example, a critical config line, or logic that text can't convey (3–10 lines max).
+- Don't paste full definitions/class bodies; link to the file. Inline snippets only for a short usage example, a critical config line, or logic that text can't convey (3-10 lines max).
 
 ## Mermaid
 

.claude/skills/audit-docs/SKILL.md

@@ -7,20 +7,23 @@ description: Audit and update the project's documentation so it matches the curr
 
 This skill is the Claude Code counterpart to the Copilot prompt [`.github/prompts/audit-docs.prompt.md`](../../../.github/prompts/audit-docs.prompt.md), which is the canonical, fuller spec. **Read that prompt and apply it.** The hard rules also live in [`.claude/rules/docs-authoring.md`](../../rules/docs-authoring.md) and load automatically when editing Markdown. This file is the operating procedure.
 
+**Scope: documentation only.** Change docs, comments, and docstrings, never executable code or behaviour; if you notice a code problem (a stale variable, dead code, a bug), note it for a human instead of fixing it. The only exception is when the task explicitly asks for code changes.
+
 ## Phases (run in order)
 
-1. **PR sync** — If there are uncommitted changes or an active PR, treat that diff as the source of truth. Identify what the code changes actually do (read the implementation) and update `docs/` to reflect only those changes. Report whether docs changed or were already accurate.
-2. **General audit** — Audit the whole [`docs/`](../../../docs/index.md) tree against the current code. Correct statements that contradict the code; add docs only for exported/public APIs or genuinely complex logic that lacks them; remove bloat and redundant narration. Prefer correcting over deleting (delete only if a file describes a removed feature or is unsalvageably wrong). New directories need an `index.md`.
-3. **In-code docs** — Scan Markdown outside `docs/`, plus JSDoc/docstrings/module headers and inline comments, for the files you touched. Fix or remove inaccurate/stale content; don't add narration that restates obvious code.
+1. **PR sync** - If there are uncommitted changes or an active PR, treat that diff as the source of truth. Identify what the code changes actually do (read the implementation) and update `docs/` to reflect only those changes. Report whether docs changed or were already accurate.
+2. **General audit** - Audit the whole [`docs/`](../../../docs/index.md) tree against the current code. Correct statements that contradict the code; add docs only for exported/public APIs or genuinely complex logic that lacks them; remove bloat and redundant narration. Prefer correcting over deleting (delete only if a file describes a removed feature or is unsalvageably wrong). New directories need an `index.md`.
+3. **In-code docs** - Scan Markdown outside `docs/`, plus JSDoc/docstrings/module headers and inline comments, for the files you touched. Fix or remove inaccurate/stale content; don't add narration that restates obvious code.
 
 ## Hard rules (quick reference)
 
 Full detail in [`.claude/rules/docs-authoring.md`](../../rules/docs-authoring.md):
 
-- **Zero hallucination / prove it.** Document only what the code provably does — read it, don't infer from names, types, comments, or structure. If you can't point to the proof, don't write it. No "appears to" / "should" / planned behaviour.
+- **Documentation only.** Change docs/comments/docstrings, never executable code or behaviour (note code problems for a human instead), unless the task explicitly asks for code changes.
+- **Zero hallucination / prove it.** Document only what the code provably does: read it, don't infer from names, types, comments, or structure. If you can't point to the proof, don't write it. No "appears to" / "should" / planned behaviour.
 - **Objective tone.** No subjective adjectives (important, critical, robust, …). Fix existing claims that contradict the code.
-- **Links.** Every file reference is a clickable relative markdown link to a *file* (never a bare name, never a directory — link its `index.md`/`README.md`). Verify the path resolves.
-- **Snippets.** Link to files instead of pasting definitions; inline only 3–10 lines for a usage example or critical config line.
+- **Links.** Every file reference is a clickable relative markdown link to a *file* (never a bare name, never a directory; link its `index.md`/`README.md`). Verify the path resolves.
+- **Snippets.** Link to files instead of pasting definitions; inline only 3-10 lines for a usage example or critical config line.
 - **Mermaid.** Every diagram includes `accTitle` and `accDescr`; valid syntax; reflects real code; choose the fitting diagram type.
 - **No placeholders or TODOs.**
 

.github/copilot-instructions.md

@@ -98,7 +98,7 @@ NETWORK.SLOW_DOWNLINK_THRESHOLD; // Network performance checks
 ### Linting & Formatting
 
 - **Indentation**: Tabs (not spaces) - enforced by ESLint
-- **Line length**: No hard limit, use Prettier
+- **Line length**: Prettier wraps at `printWidth` 120 (`.prettierrc`)
 - **Import sorting**: Handled by `@trivago/prettier-plugin-sort-imports`
 - **Unused vars**: Prefix with `_` to ignore (e.g., `_unusedParam`)
 
@@ -138,12 +138,16 @@ export const metadata: Metadata = {
 
 ### Security Headers
 
-CSP and security headers configured in `next.config.js` headers() function. Includes:
+Security headers configured in `next.config.js` headers() function. The `/` route includes:
 
 - X-Content-Type-Options: nosniff
+- X-XSS-Protection: 1; mode=block
 - X-Frame-Options: DENY
 - Strict-Transport-Security (HSTS)
-- Content Security Policy for service workers
+- Referrer-Policy: same-origin
+- Permissions-Policy
+
+The `/sw.js` route sets Content-Type, Cache-Control, and Service-Worker-Allowed headers.
 
 ## Special Features
 
@@ -158,7 +162,7 @@ CSP and security headers configured in `next.config.js` headers() function. Incl
 
 ### Service Worker
 
-- Lives in `public/sw.js` and served via `src/app/sw.js/`
+- Lives in `public/sw.js` and served by Next.js from the public directory at `/sw.js`
 - Registration in `src/components/ServiceWorkerRegister.tsx`
 - Used for PWA offline support