@1aboveio/skills 1.0.10 → 1.0.11

package/skills/engineering/ensure-coverage/references/breadth/surface-baseline.md

@@ -2,7 +2,7 @@
 
 > Read when: computing the minimum required-level floor a surface owes. The breadth axis enumerates surfaces; this is the floor each one carries the instant it's discovered. Sibling refs: [coverage-ledger.md](coverage-ledger.md) (the ledger that holds these obligations), [surface-discovery.md](surface-discovery.md) (how surfaces and their `reachability` are found), [inventory-contract.md](inventory-contract.md) (the adapter that emits the taxonomy).
 
-A requirement source (ADR/PRD/spec) is **not** a precondition for a test obligation. Most production gaps are organically-added routes nobody wrote an ADR for; if coverage waited on someone authoring a requirement, the surface would sit silently uncovered. So **every surface in the inventory carries a minimum required-level floor the instant it is discovered**, graded at depth automatically — safe by default. Orphan detection alone is worthless without a *default obligation* attached; it just relocates the judgment call to whoever notices — the session-variance that produced the gaps.
+Use the table as guidance when selecting proof for the agreed scope and material risks, not as a universal obligation for newly discovered surfaces. Existing repository-adopted floors and required checks remain binding unless changed through approval. A requirement document is not needed to recognize a concrete risk. The rules below describe the bundled ledger's mechanical defaults when it is used, not new policy for every feature.
 
 **The baseline keys off an adapter-emitted taxonomy, never inference at grading time** — inference-per-session is how "covered" came to mean different things. The adapter tags each surface deterministically so two agents on the same code compute the same floor.
 
@@ -27,9 +27,9 @@ Baseline only **entry surfaces** (`route`, `api`). **Internal surfaces** (`table
 | permission | — | `integration` | resolves an auth test |
 | integration (external) | — | fake adapter + contract | — |
 
-Every **live browser route is `browser-journey` at minimum** — `class` changes only *what the journey additionally proves*, not *whether* you drive the page. A genuinely static/content page (marketing, docs) is downgraded via the **`static` exclusion category** to a `render-health` floor — a cheap reachability guarantee, never weakening the floor for real app pages. (`smoke` is accepted as an alias for this level; it is not the curated `smoke` gate, which is a cross-flow liveness check, not a per-route level.) **`render-health` is a browser-level check, not an API ping**: a real browser must load the rendered page and confirm it renders without error (externals may be faked). An HTTP-200 / API-level test does **not** satisfy it. The other exclusion categories (`seed`/`deprecated`/`internal`) drop to manifest-only. `render-health` is the one level a present-but-shallow test can satisfy, precisely because it is definitionally shallow. (Same "page loads/renders" concept as e2e-test's Tier-1 and the `presentation:render-health` spine.)
+In the ledger, every **live browser route is `browser-journey` at minimum** — `class` changes only *what the journey additionally proves*, not *whether* you drive the page. A genuinely static/content page (marketing, docs) is downgraded via the **`static` exclusion category** to a `render-health` floor — a cheap reachability guarantee, never weakening the floor for real app pages. (`smoke` is accepted as an alias for this level; it is not the curated `smoke` gate, which is a cross-flow liveness check, not a per-route level.) **`render-health` is a browser-level check, not an API ping**: a real browser must load the rendered page and confirm it renders without error (externals may be faked). An HTTP-200 / API-level test does **not** satisfy it. The other exclusion categories (`seed`/`deprecated`/`internal`) drop to manifest-only. `render-health` is the one level a present-but-shallow test can satisfy, precisely because it is definitionally shallow. (Same "page loads/renders" concept as e2e-test's Tier-1 and the `presentation:render-health` spine.)
 
-Every live browser route *also* auto-carries the **Presentation floor** on top of the functional floor above — see [../presentation/axis.md](../presentation/axis.md).
+In the ledger, every live browser route *also* auto-carries the **Presentation floor** on top of the functional floor above — see [../presentation/axis.md](../presentation/axis.md).
 
 ## Exclusion is gated, not honored on a reason
 
@@ -41,4 +41,4 @@ An exclusion downgrades a surface to manifest-only — the exact move that re-op
 
 ## The feature card is a deviation record, not a precondition
 
-Because the baseline auto-applies, a surface with no requirement is **not blocked on authoring a file** — it is already graded at its floor. A curated `…coverage.yml` (the "feature card") is required only to **deviate**: raise above baseline, mark `sensitive`, exclude, attest (`verified`), or attach `owner`/`purpose`/`userVisibleContract` ownership. Pure happy-path baseline surfaces need no card. Requirement *ownership* (traceability) is a `warn`; the baseline *test obligation* is the hard gate.
+When using the ledger, because its baseline auto-applies, a surface with no requirement is **not blocked on authoring a file** — it is already graded at its floor. A curated `…coverage.yml` (the "feature card") is required only to **deviate**: raise above baseline, mark `sensitive`, exclude, attest (`verified`), or attach `owner`/`purpose`/`userVisibleContract` ownership. Pure happy-path baseline surfaces need no card. Requirement *ownership* (traceability) is a `warn`; the baseline *test obligation* is the hard gate.

package/skills/engineering/ensure-coverage/references/breadth/surface-discovery.md

@@ -4,13 +4,13 @@
 >
 > **Guard-chain vs navigational reachability.** This protocol determines **guard-chain** reachability — "can the URL load past middleware/auth." That is *different* from `presentation:reachability` ([../presentation/axis.md](../presentation/axis.md)), which is **navigational** — "can a user *click* their way here from an entry point." A route can be guard-reachable yet navigation-orphaned. Both matter; they are different checks.
 
-Use this inline protocol for E2E audits even if `e2e-test` is unavailable. Route discovery is not complete after listing route files; verify whether each route can actually be reached through layouts, middleware, redirects, guards, rewrites, and route groups. For Next.js App Router and similar file-based routers:
+Use this protocol within the agreed audit scope, even if `e2e-test` is unavailable. Enumerate the whole repository only for an explicitly requested broad audit. For scoped work, inspect relevant routes and their reachability as needed; the following describes comprehensive discovery for Next.js App Router and similar file-based routers:
 
 1. Enumerate all `page.*` and `route.*` files, including route groups, dynamic segments, parallel/intercepting routes, and exported HTTP methods for `route.*`. Tag each by kind — **browser route** (`page.*`) or **API route** (`route.*`) — because they carry different depth obligations and proof types ([../depth/grading.md](../depth/grading.md)). Never let one stand in for the other.
 2. For each page route, walk the layout chain root → route group → segment; inspect `layout.*`, `middleware.*`, redirects, `notFound`, auth/session checks, role/tenant guards, feature flags, rewrites.
 3. Classify reachability as `Reachable`, `Redirected`, `Guarded`, `Blocked`, or `Unknown`, with the guard/layout/middleware evidence.
-4. For each `Reachable` page, inventory its user-actionable mutations (forms, submit buttons, write actions) and the backend endpoint each targets. Record one **journey obligation** per mutation (operator completes form → backend accepts → state changes), separate from the page merely rendering. A write form with no journey test is uncovered, even when the route renders.
+4. For relevant `Reachable` pages, identify user-actionable mutations and their backend targets. Distinguish rendering from submission and durable-state evidence; select proof based on agreed criteria and material risks, not an automatic journey obligation per mutation.
 5. Cross-reference discovered routes against PRD/spec claims, route manifests, navigation links, product journeys, and the golden-path candidate list. Discovery may suggest golden-path candidates, but the golden-path contract is curated: a route is not release-blocking merely for being a mutation route or containing an auth/payment-looking word.
-6. Flag routes that are unreachable, misplaced, stale, missing from the manifest, absent from code, or contradicting design docs — and reachable pages whose mutation forms have no journey coverage.
+6. Report relevant concrete gaps and unavailable evidence. Treat missing journey coverage according to agreed criteria and existing required floors, not as an automatic feature blocker.
 
 Do not classify a route as covered, missing, or part of a valid journey solely because a `page.*`/`route.*` file exists — a route file is only a declared route until its guard chain and journey validity are checked.

package/skills/engineering/ensure-coverage/references/depth/characterization.md

@@ -1,68 +1,7 @@
-# Depth: Characterization — pin existing behavior before you change it
+# Characterization and fails-first evidence
 
-> Read when: a change **modifies existing behavior** (edits/deletes lines in a non-test source file) rather than adding a brand-new surface. Sibling: [grading.md](grading.md) (how each obligation is graded), [mock-policy.md](mock-policy.md) (the boundary). New-surface work is TDD red→green; *this* is the obligation for touching code that already runs in production.
+When changing existing behavior, consider whether a relevant existing test already protects the behavior that should stay unchanged. Reuse it if sufficient. Add a characterization test when the risk of unintended change warrants it; it captures actual behavior at an observable boundary, including quirks. Do not require a new test or pre-change run for every source edit, or introduce a seam solely to satisfy a blanket rule.
 
-Michael Feathers' rule: *"Characterization tests document the actual behavior of the code, not the intended behavior."* The common agent failure mode: it refactors or "fixes" a function, the existing tests stay green (they never covered the changed path), and an **observable behavior silently shifts**. A green suite after the change proves nothing if no test pinned the behavior *before* it.
+For a bug fix, a test that fails before the fix and passes afterward can show that the fix addresses the defect. Use it when practical and useful or when repository policy requires it; otherwise explain the proof and any limitation. A feature test should make meaningful assertions about the agreed outcome, not just a mock call or a fixture that bypasses the real behavior. Inspect it before claiming coverage; a broken-tree run is not automatically required.
 
-So a modification carries a depth obligation a fresh feature does not: **before you change existing behavior, write a test that captures what the code does today, and make it pass against the unchanged tree.** That test becomes a boundary the change cannot silently cross — the seam ([below](#seams-where-to-pin)) at which you alter behavior deliberately.
-
-## The obligation: when it is owed
-
-A change owes a characterization test when **all** hold:
-
-- It **edits or removes** existing lines of a non-test **source** file (a pure addition into a new file, or appended-only code, is new behavior → TDD path).
-- The touched code has **observable behavior** — return value, durable-state effect, emitted event, HTTP contract, rendered output. (Internal-only renames with no behavioral surface don't.)
-- The surface is **non-trivial** — anything carrying a Surface Baseline floor, or logic a user/caller depends on.
-
-When owed, the test must: **(1) capture actual, not intended, behavior** including quirks/bugs (if current behavior is wrong, characterize it *then* fix it in a separate declared step); **(2) pass on the pre-change tree** (GREEN on `HEAD~`/base before your edit — capture as evidence); **(3) still pass after the change**, unless the change is a declared intended behavior change.
-
-## When it is waived
-
-Mark the waiver explicitly in the PR's evidence, never silently:
-
-- **Already pinned** — an existing behavior test covers the exact changed path and still passes unchanged. Cite it (`file:line`); that test *is* the characterization.
-- **Declared intended behavior change** — deliberately alters observable behavior per an AC/bug brief. The obligation inverts: update/author the test to assert the **new** behavior, and the diff must show the old assertion changing to the new (a behavior change with no test delta is the suspicious case). Cite the AC.
-- **Trivial / generated / non-behavioral** — formatting, comments, type-only edits, generated code with no behavior delta.
-
-## The `@characterizes` convention
-
-Tag a characterization test so the gate can resolve it, parallel to `@covers`:
-
-```js
-// @characterizes <surface-id>   // pins prior behavior of a surface being modified
-// @covers <surface-id>          // (a characterization test usually also @covers it)
-// @level <level>
-```
-
-`@characterizes` is the signal that *this* test exists to hold a modification's behavior boundary. A modifying diff with no `@characterizes` test and no declared waiver is the gap this obligation names.
-
-## Grading
-
-Characterization is a **depth** concern, graded with the [shared vocabulary](grading.md):
-
-- A modifying diff whose changed behavior is pinned by a passing characterization test (or cited pre-existing behavior test) → that surface can reach `Covered` on the normal evidence rules.
-- A modifying diff with **no** characterization test and **no** declared intended-change → `Partial` at best; the reviewer raises the `modifies-existing-behavior` lead (below). Not a hard `Missing` (existing tests may incidentally cover it) — a **lead to adjudicate**, because whether a characterization test is *needed and adequate* is judgment.
-
-## Detection (mechanical) → adjudication (judgment)
-
-The decidable half is mechanical: any non-test source file with **removed/changed** lines emits a `modifies-existing-behavior` **lead** ("look here and verify," never an auto-finding). The reviewer checks for a `@characterizes` test (or a declared change) and adjudicates, citing `file:line`. The reviewer resolves it with a locator, not prose. The split matches the GATE-vs-LEAD line everywhere in this skill: detecting *that behavior changed* is mechanical; deciding *whether the pinning test is adequate* is semantic.
-
-## Seams: where to pin
-
-A characterization test is writable only where you can observe behavior without rewriting the thing you're about to change — a **seam** (*"a place where you can alter behavior without editing the code in that place"*). Pin at the nearest observable seam: the public function's return/throw, the endpoint's HTTP contract, the rendered page's output, the emitted event. If there's no seam, that itself is the finding — introduce one first (extract the call, expose the boundary), pin, *then* change. Do not skip characterization because "it's hard to test as written"; hard-to-pin is the legacy-code smell the obligation exists to surface.
-
-## Fails-first: bug-fix AND feature-AC — prove the test fails when the behavior is broken
-
-The shared property: **a test is evidence for a behavior only if it would go red were that behavior broken.** A green test that passes with *and* without the behavior it claims is **vacuous coverage** — it locks in nothing. Two cases:
-
-**Bug-fix sibling.** A bug fix changes behavior that's *already wrong*, so it owes the inverse of characterization: at least one test demonstrated to **fail on the unfixed code and pass on the fixed code** (RED→GREEN, run in that order), tagged `// @fails-without-fix <surface>`. Reverting the fix must turn the test red. Waive only with a cited reason the failure can't be reproduced in-suite (a tracked `Unverified` manual check, not a silent skip).
-
-**Feature-AC sibling.** The same test applies to a *new feature's* AC, where it's most-missed: a green test cited for an AC clears it only if it would go red were the AC's behavior removed — it exercises the AC's real code path, not a proxy. Recurring vacuous forms:
-- a fixture that **early-returns before the code runs** (a 0-step workflow "proving" a multi-step reset that never executes);
-- a `.fill()`/`setValue` that sets state in one shot and so **masks a re-render/defocus bug** a character-by-character `pressSequentially` would expose;
-- an assertion **pinned to a stand-in value the real producer never emits**;
-- asserting **the mock was called** rather than that the outcome happened.
-
-**Grading the two outcomes** (they differ from [grading.md](grading.md)'s `Unverified`): can't-yet-confirm it would go red → `Unverified` (a warning unless `unverifiedBlocks: true`); confirm it would **still pass** with the behavior gone → `Missing`/`Over-mocked` (a proven-vacuous test is *worse* than unchecked).
-
-The two **decidable** vacuous forms (a swallowed assertion, a fixed timeout) are gated by `lint-tests`; the semantic "would it have been red?" property is verified at review and by running the test against the broken tree. Named incident: the login regression (#237), where a green sweep asserted nothing the bug could trip.
+If an existing adopted gate requires annotations, a pre-change run, or other evidence, follow it unless an approved change alters the gate. Grade evidence honestly using [grading](grading.md).

package/skills/engineering/ensure-coverage/references/depth/grading.md

@@ -2,11 +2,9 @@
 
 > Read when: grading whether a test actually proves the behavior against real state. Sibling: [mock-policy.md](mock-policy.md) (the boundary principle this grading enforces). Depth grades each `Aligned` row — and each `Orphan surface` carrying a [Surface Baseline Contract](../breadth/surface-baseline.md) floor — by inspecting its actual tests.
 
-The canonical depth failure is **internal interception counted as behavior**: a Playwright `route.fulfill`/`page.route(` faking your own endpoint's response, or any substitute standing in for an internal seam. It makes a surface *look* covered while proving only proxy wiring — the boundary violation the [Mocking Stance](mock-policy.md) forbids. Classify it `Over-mocked`, never `Covered`.
+A depth failure occurs when a substitute bypasses the behavior a test claims to prove. For example, a Playwright interception of an endpoint cannot prove that endpoint's real behavior. Grade that claim `Over-mocked`, not `Covered`; a focused UI test may still prove its own scope. See the [mock policy](mock-policy.md).
 
-**Separate browser routes from API routes; prove each with its own evidence kind.** Prove an API route (`route.*`) by hitting the endpoint and asserting the HTTP contract, auth, and durable state. Prove a browser route (`page.*`) by driving the rendered page: what it displays, what the user can do, and what happens when they do. Never grade a browser route `Covered` because its backing endpoints are covered (the `/settings/connectors` miss) — a green API test under a page is necessary but never sufficient.
-
-**For any write form, require one test that fills the rendered UI and asserts the mutation end to end** — operator fills the actual form and submits → backend accepts → durable state changes. Keep the render-health watcher attached **through** the submit (compose with `presentation:render-health`, [../presentation/axis.md](../presentation/axis.md)), so an uncaught error / `console.error` / first-party 5xx fired *during* the write fails the test even when the durable-state assertion would pass — the "mutate-health" gap. Do not accept seam tests in its place: a schema endpoint returning fields, a validator rejecting bad input, and an API forwarding a hand-built payload all pass while the rendered form silently drops a backend-required field. This is acute for the **split-contract form**, whose fields come from one source (schema endpoint, config descriptor, generated form spec) and validation from another (the backend contract); only a rendered-form submission proves the form emits a payload the backend accepts.
+Distinguish what API and browser evidence actually proves. An API test alone does not prove a rendered form works; a UI test that fakes the backend does not prove durable state. Select the proof needed for the agreed outcome and material risk, reusing existing evidence where sufficient. A rendered end-to-end submission can expose split-contract form failures, but is not an automatic new obligation for every form. Existing adopted floors and required checks remain binding.
 
 ## Evidence Hierarchy
 
@@ -25,11 +23,11 @@ Classify coverage as `Covered` only after inspecting the relevant test file/case
 
 A self-declared `@level` is a claim the validator must try to **refute**, and can never alone reach `Covered`. The three terminal states are marked below.
 
-- `Covered` (green, terminal): inspected test code validates the AC at the right level with meaningful assertions and acceptable mock/fake use, **and** the test has been read and marked `verified: true`. A self-declared `@level` alone never reaches it.
-- `Partial`: some behavior is tested, but edge cases, failures, permissions, state, or evidence are incomplete.
+- `Covered` (green, terminal): inspected test code validates the agreed AC at the appropriate level with meaningful assertions and acceptable mock/fake use. A self-declared `@level` alone never reaches it. The ledger additionally requires its `verified: true` attestation.
+- `Partial`: some agreed behavior or material-risk proof is incomplete. An untested hypothetical state alone is not an automatic blocker.
 - `Missing`: no meaningful test maps to the AC.
 - `Wrong Level`: test exists but is too shallow for the risk — e.g. unit-only for stateful workflow, API contract, auth, money movement, concurrency, or event behavior.
-- `Over-mocked` (red, terminal): mocks bypass the behavior the AC must prove — a behavior/journey test that intercepts first-party traffic (`page.route`, `route.fulfill`, MSW, first-party fixtures), or a `mutation` journey that never resolves a real durable-state path. Proves only proxy wiring.
+- `Over-mocked` (red, terminal): substitutes bypass the behavior the agreed AC must prove. For example, an intercepted endpoint cannot prove its real durable-state path; the test may still prove a narrower UI behavior.
 - `Unverified` (yellow, terminal): the level is satisfied statically (or claimed by docs/reports/CI) but nobody has read the test yet. It is a **warning** by default; it blocks only when the user sets `unverifiedBlocks: true`. Marking `verified: true` after reading the test promotes it to `Covered`; no evidence is required unless the user asks for it. The residual variance is over *quality of an existing test*, not *whether a surface exists*.
 - `Excluded`: a human marked the surface out of scope with category + reason and the adapter signals permit it; surfaced in the exclusion census.
 - `BLOCKED`: required source, code, tests, route discovery, environment, or product decision is unavailable.

package/skills/engineering/ensure-coverage/references/depth/mock-policy.md

@@ -4,11 +4,7 @@
 
 ## Mocking Stance
 
-Default to real. The governing principle is **real internals, faked externals, nothing in between**:
-
-- A test substitute is permitted **only at a trust boundary you do not own**: third-party HTTP APIs, payment/KYC providers, email/SMS, the clock, randomness.
-- Everything **inside** your own system runs for real: database, repositories, service layer, internal endpoints, event bus. A substitute for an internal seam is a design smell or coverage gap, not a testing choice.
-- The rule is **two-sided**: don't mock inward, don't reach outward — externals must be replaced by a fake/stub adapter so tests stay deterministic and never call a live third party in CI. "Be pure by calling the real provider" is the opposite failure, also rejected.
+Choose substitutes based on what the test must prove and the material risk. Unit tests may isolate internal collaborators, but a substitute cannot prove the behavior it replaces. Use real boundaries where needed to prove security, tenancy, money, or durable-state behavior, subject to existing repository policy. Fake external providers when necessary for safe, deterministic tests; follow the repository's rules for live services.
 
 The problem we reject is **mock-only coverage of behavior that must be proven against real state** — not the presence of mocks. Fakes/stubs that keep failure-path and edge tests fast and deterministic are good and expected.
 
@@ -43,15 +39,13 @@ These are **internal** and are therefore never covered by substitutes alone:
 
 Prefer integration tests with real app/service code, real DB or test containers with migrations, queue/pub-sub emulators where practical, fake external provider adapters, and assertions on final durable state, emitted events, and externally visible outcomes.
 
-## Mechanized gate: `mock-internal-seam` (zero-tolerance)
+## Optional scan: `mock-internal-seam`
 
-The decidable core of the stance is a hard gate, because over-mock is the failure mode that shipped a production incident behind green tests. The trick that makes it decidable is the **externals-allowlist inversion**: internal seams are unbounded, but the set of things that may legitimately be faked is small and known. So a mock whose target resolves to first-party code is a defect; anything on the declared externals allowlist, a bare npm package, or the stdlib is exempt.
+The following describes the scanner's strict mechanics, not a universal ban on internal test doubles. Run it when requested or required by the repository; a whole-tree scan belongs to an explicitly requested broad audit. Assess hits against the behavior and risk rather than counting them as automatic feature blockers. Existing required gates remain binding.
 
-- **Default-on, no waiver, no grandfathering.** Config only declares topology; it cannot turn the gate off. A believed false positive is fixed by declaring the truth in `coverage.config.json`, never by waiving.
-- **Both lanes.** Diff-scoped for new seams, whole-tree for inherited ones; a tree with existing over-mock stays red until it is removed.
-- **Three resolutions, and "keep it" is not one:** replace with a real-boundary test, fake only the external behind it, or **delete** the test. Over-mock is worse than no test: an untested route is an honest gap, an over-mocked one is dishonest green. Deletion reverts the surface to its honest breadth status (`Missing` or `Excluded`).
-- **In audit mode, run it whole-tree from this skill against the target repo** and count every hit as an `Over-mocked` row and a no-ship contributor. A missing `coverage.config.json` means "run on defaults", not "not applicable"; the scripts' absence from the audited repo means nothing.
+The scanner uses an **externals-allowlist inversion**: it flags mocks resolving to first-party code and exempts declared externals, bare npm packages, and the standard library. Its default configuration is strict; a flag does not itself establish that a test is inadequate. Where an adopted required gate fails, report the failure and seek the appropriate approved resolution rather than bypassing it. Do not delete a useful test merely to silence an optional scan.
+- **When run**, a missing `coverage.config.json` uses defaults. The scripts live in this skill, not the audited repo. A hit is a lead; determine whether the test actually bypasses the behavior it claims to prove.
 
-What stays a review lead: whether a real-boundary sibling exists, shallow assertions, semantically wrong fakes. The gate proves the decidable shell; the reviewer judges the rest. The ledger also reports an over-mock *rate* as a trend signal; the merge bar stays "count is zero".
+Whether a real-boundary sibling exists, assertions are shallow, or fakes are wrong requires judgment. The scanner detects patterns, not their full meaning. The ledger's over-mock rate is a trend signal; do not invent a zero-count merge bar.
 
 CLI, rules, and the `coverage.config.json` topology keys: [`scripts/README.md`](../../scripts/README.md).

package/skills/engineering/ensure-coverage/references/enforcement/ci-contract.md

@@ -2,7 +2,7 @@
 
 > Read when: the user asks what this skill should require, wire, or audit in CI.
 
-Curated golden-path smoke is the **only CI gate supported by this skill**. The coverage ledger, inventory freshness, presentation sweep, broad E2E suite, test lint, over-mock scan, design parity, and quarantine expiry remain local or review-time evidence. Do not propose, require, wire, or audit them as CI gates.
+When asked to propose a CI gate, this skill supports curated golden-path smoke. Do not propose, require, wire, or audit additional gates without an explicit request. Existing repository-required checks, including checks outside this menu, remain binding; do not bypass or remove them.
 
 ## What smoke proves
 

package/skills/engineering/ensure-coverage/references/presentation/axis.md

@@ -2,7 +2,7 @@
 
 > Read when: working any `presentation:*` invariant. Sibling: `e2e-test/references/presentation-sweep.md` (the runner and the result shape it emits). This skill *grades* the axis; the `e2e-test` sweep *runs* it.
 
-The **Presentation** axis (third axis) rides the [Surface Baseline Contract](../breadth/surface-baseline.md) machinery as a per-route floor. Every live browser route auto-carries a presentation obligation *on top of* its `browser-journey` floor, checked at the viewport floor `[375, 1280]` (default theme, seeded data).
+Consider presentation evidence when it matters to the agreed outcome or material risks. The following describes the bundled ledger and sweep's per-route mechanics, not a new universal requirement or an automatic presentation campaign. Existing repository-adopted floors and required checks remain binding unless changed through approval. In the ledger, every live browser route carries a presentation floor at `[375, 1280]` (default theme, seeded data).
 
 > **This skill grades the axis; it does not run it.** The tokens below are *graded* by the Coverage Ledger (does a qualifying real-render test exist, is it non-intercepting, is it attested). The *instruments* that open a browser and observe these invariants live in the **`e2e-test` skill's presentation sweep**. ensure-coverage owns the **obligation**; the runner and the per-`(route, level)` result shape the ledger consumes are documented with the runner (`e2e-test/references/presentation-sweep.md`). This mirrors how breadth delegates surface discovery to an inventory adapter ([../breadth/inventory-contract.md](../breadth/inventory-contract.md)).
 
@@ -14,7 +14,7 @@ Invariants, **spine first**:
 - **`presentation:reachability`** — a user can get to the page and tell its controls are actionable: every manifest route is reachable by crawling the rendered nav (no **navigational orphan**), interactive controls show a visible focus indicator and meet the ≥44px target floor. Negative form: a modal traps focus (no click-through / focus escape); a privilege-gated route is not navigationally reachable for the wrong role.
 - **`presentation:temporal`** — the layout holds still as things inject. **Split by who renders the shift** — *first-party* (lazy images, async data, our dynamic fields) is a **hermetic gate** (real render, no network; before/after geometry gated on a stable condition, never a fixed sleep, or a `PerformanceObserver` CLS score). *Third-party* (Stripe/Adyen payfields) runs against the provider **sandbox iframe** in a **non-blocking PR lane**: a failure posts a visible annotation and the surface stays `Unverified` until the test is read and marked `verified: true`. Top-page CLS is **structurally blind to cross-origin iframes** (WICG excludes descendant frames), so this is a before/after geometry assertion gated on a provider-ready signal, not CLS. The mobile **dynamic-viewport (`dvh`/`100vh`) cell** is gated via Playwright emulation with a tuned tolerance (staging fallback if flake is unmanageable).
 
-"Graded" means the ledger marks a route's floor `Missing` / `Over-mocked` / `Unverified` / `Covered` from the tests that exist — it cannot itself detect a runtime crash, which is why the sweep is a **separate evidence run**, not a side effect of the functional E2E suite. It is not a CI gate; curated golden-path smoke is the sole CI gate ([CI contract](../enforcement/ci-contract.md)).
+"Graded" means the ledger marks a route's floor `Missing` / `Over-mocked` / `Unverified` / `Covered` from the tests that exist — it cannot itself detect a runtime crash, which is why the sweep is a **separate evidence run**, not a side effect of the functional E2E suite. It is not a new CI gate; existing repository-required checks remain binding ([CI contract](../enforcement/ci-contract.md)).
 
 The floor runs at the screen viewport floor (`[375, 1280]`). The **`media=print` cell is warn-only by default** — a broken print stylesheet is logged in the census, not a blocking gate (lower-frequency, harder to assert deterministically). A surface may escalate it to a gate when print output is a real product surface (e.g. an invoice).
 
@@ -37,7 +37,7 @@ A cell-qualified level grades exactly like its base (real render, exact-match, D
 
 A presentation level is **exact-match** and proven only against a **real rendered page**:
 
-- A functional `browser-journey` does **not** satisfy a presentation level — a journey clicks the DOM; it never asserts no-overflow or perceivability. Each is required separately; one presentation level does not satisfy another.
+- In the ledger, a functional `browser-journey` does not automatically satisfy a separate presentation level. For scoped proof, a single test can demonstrate multiple outcomes if its assertions actually cover them.
 - A DOM-only / JSDOM assertion of a presentation level grades **`Over-mocked`** — the axis's proxy-wiring (it can't see what a human sees). The proving test must drive a real browser.
 - Like any obligation, a statically-satisfied presentation level lands at `Unverified` until the test is read and marked `verified: true`.
 
@@ -51,7 +51,7 @@ Every level above is **self-referential**: render-health asks whether the page r
 
 That gap is not theoretical. A baseline captured from a wrong implementation is green forever — in the incident below it would have locked in a card plane the design did not have and a flattened type scale, and reported success. Drift detection cannot substitute for fidelity, because it takes the implementation as its own authority.
 
-**When it is owed.** A unit whose source cites a design artifact — a prototype branch/path, a mockup, a design doc that fixes layout — carries `presentation:fidelity` on the surfaces that artifact covers. A unit with no cited design source does not; this is not an auto-floor and inventing one for a CRUD tweak is ceremony.
+**When it is relevant.** Compare the implementation with a cited design where the agreed outcome calls for fidelity. Use the parity workflow when requested or required by the repository; citing a design alone does not automatically mandate a campaign.
 
 **The rule that makes it fidelity.** Every expected value is read off the **source**, with it rendered, and cites the source line it came from. A value copied off the page you built is a baseline wearing a fidelity label.
 
@@ -59,6 +59,6 @@ That gap is not theoretical. A baseline captured from a wrong implementation is
 
 **No rewriting the target to match the page.** The cheapest way to green this gate is to edit `expected` instead of fixing the page. Because the source is pinned, a changed `expected` under an unmoved `source.sha` is mechanically detectable and blocks; a genuine mis-read is declared with `rebase: <reason>`. The reviewer treats an undeclared rewrite as a blocker, exactly as it does a silent re-baseline.
 
-**The render is not optional.** A property list catches what someone thought to list. Before the terminal review, render source and deliverable at the floor viewports side by side in the PR.
+When the parity workflow is agreed or required, rendering source and deliverable side by side can reveal differences that a property list misses.
 
-Two hard rules, from the named incident (fmm-express #521, 2026-08-06: a cited prototype was summarized once into four bullets, nothing downstream re-read or rendered it, and the criteria doc listed visual baselines under non-goals, so a green suite shipped a page that took four rounds of correction): a presentation-only unit **may not** list visual or parity evidence as a non-goal, and a cited design source is **consumed, not summarized**.
+The fmm-express #521 incident shows why a presentation-focused change may need direct comparison with its design source. Agree that proof before implementation; do not impose the full parity workflow on unrelated features.

package/skills/engineering/ensure-coverage/references/process/audit-mode.md

@@ -1,27 +1,11 @@
 # Audit Mode (process)
 
-> Read when: auditing whether existing code/tests cover a requirement, PR, issue, feature, or bugfix. Audit current sufficiency against the behavior-first criteria; do not only generate ideal future criteria. Coverage classifications used here are defined in [../depth/grading.md](../depth/grading.md).
+Audit the agreed feature scope against its observable criteria and material risks. A whole-repo census is only for an explicitly requested broad audit. Existing required checks and adopted floors remain binding.
 
-Audit steps:
+1. Establish the source, scope, criteria, and required repository checks. Identify product or architecture questions for their owners.
+2. Inspect relevant behavior and existing tests; map evidence to the agreed criteria. A prior report is a lead, not proof of test content. Reuse sufficient proof rather than requiring redundant layers.
+3. Grade honestly using [grading](../depth/grading.md). Describe concrete material gaps and any unavailable evidence. A hypothetical untested state alone is not a feature blocker.
+4. Report what was verified, failed or unavailable, distinguishing required fixes and decisions from speculative follow-ups. A newly discovered concrete defect may need a fix; do not silently add criteria after implementation starts.
+5. Audit CI wiring only when asked. A missing optional coverage gate is not a finding. Required repository checks still apply.
 
-1. Derive ACs from the source before inspecting implementation details.
-2. Identify public interfaces, workflows, state transitions, side effects, code paths, and existing tests.
-3. For E2E audit, run the [Route Discovery & Reachability Protocol](../breadth/surface-discovery.md) before judging coverage.
-4. Identify critical journeys with actor/role, start state, trigger, major steps, expected end state, route reachability, and observable side effects.
-5. Map each AC and journey to existing tests only after inspecting the actual test files/cases/assertions; prior docs, PR summaries, or agent reports are leads, not proof.
-6. Reject coverage that only validates private functions, implementation structure, or shallow route render-health checks for business journeys.
-7. Create follow-up items for every gap with required test level, setup/input, assertions, and mock/fake policy.
-8. Reach a production-readiness verdict — an explicit ship / no-ship call, the specific scenarios a real user would hit in the first week, and the evidence that would raise confidence — and **put it at the TOP of the deliverable** (the reader's first question is "what's the call?"; the census and detail justify it below). Do not let mapped ACs alone earn a ship call. Separate **blocking decisions** (product/scope choices that change the verdict and need a human answer) from **follow-up actions** (work to schedule) — see the output template; don't dump both into one vague "open questions" list.
-9. **Do not audit CI wiring** unless the user asks. A repo without coverage gates in CI is not a finding. When the user does ask, run `ci-audit.mjs` against the repo's CI config and report curated golden-path smoke as present / warn-only / absent. Do not turn the other audit checks into CI findings; they contribute directly to the coverage verdict.
-10. **Run the over-mock scan whole-tree** (`lint-tests.mjs --rules mock-internal-seam`, no `--diff`) from this skill against the target repo. Every hit is an `Over-mocked` census row and a no-ship contributor; **count them in the verdict**. A missing `coverage.config.json` means "run on defaults", not "not applicable"; a non-conventional topology earns a "declare topology" follow-up, never a downgrade of the finding ([../depth/mock-policy.md](../depth/mock-policy.md)).
-11. If code, tests, or route discovery cannot be inspected or run, mark the assessment `BLOCKED` and state the missing access or command failure. "The lint script isn't in the audited repo" is not `BLOCKED`: the scripts are part of this skill ([../../scripts/README.md](../../scripts/README.md)).
-
-The coverage classifications (`Covered` / `Partial` / `Missing` / `Wrong Level` / `Over-mocked` / `Unverified` / `Excluded` / `BLOCKED`) are defined in [../depth/grading.md](../depth/grading.md). Use that vocabulary, not a vague "covered."
-
-## Completeness: enumerate every surface, not just the salient gaps
-
-**Gap-finding must be exhaustive, not a highlight reel.** An audit that lists "the top 3 problems" silently leaves the long tail uncovered — where the un-ACed orphan hides. Completeness comes from **closed-world enumeration**:
-
-1. **Start from the full surface inventory** (every route, API, write form, table, event, job — from [surface discovery](../breadth/surface-discovery.md) / the generated inventory), not the list of things you happened to notice.
-2. **Emit a complete surface census**: one row per inventoried surface with its status. `gaps = inventory − {surfaces at Covered}`, so every surface is accounted for *by construction*. The census is the deliverable's backbone (the **Surface Census** table in [output-template.md](output-template.md)); the prose highlights the worst rows, but the table proves nothing was skipped.
-3. **Every non-`Covered`/non-`Excluded` row is a gap** with its own follow-up item. If the inventory cannot be fully enumerated (no adapter, partial access), say so and mark the unenumerated portion `BLOCKED`; do not silently scope to what was easy to see.
+For an explicitly requested broad audit, define its boundaries and use [discovery](../breadth/surface-discovery.md) or a census when useful. Report incomplete access or inventory rather than claiming completeness. The optional whole-tree over-mock scan produces leads to assess in context, not automatic feature no-ship findings; an existing required gate retains its own result.

package/skills/engineering/ensure-coverage/references/process/output-template.md

@@ -1,139 +1,24 @@
-# Output Template, Writing Rules & Validation (process)
+# Output Template, Writing Rules & Validation
 
-> Read when: producing the criteria/audit document (create mode), or running the final self-check before saving.
-
-## Lead with the verdict
-
-An **audit deliverable opens with the verdict**, not buries it under tables. Put a one-line `## Verdict: Ship / No-ship` (with the one-sentence reason) as the **first section**, before the Surface Census and the detailed assessment, which then *justify* it below. (Create-mode criteria docs lead with Source/Scope — there's no verdict yet.)
-
-**A no-ship is a number, not a vibe.** The verdict carries the counts that make it no-ship: uncovered surfaces, orphan surfaces, ledger warnings, skipped tests, over-mock findings. If a finding has a count, the count goes in the summary; "it doesn't block CI yet" is never a license to omit it.
-
-## Writing Rules
-
-- Make each AC independently testable.
-- Prefer observable outcomes over internal implementation details.
-- Include negative cases and misuse paths, not only happy paths.
-- For async/pub-sub/orchestrator systems, require correlation IDs and final durable state assertions.
-- For idempotent APIs, require duplicate request tests and concurrent request tests when money/state transitions are involved.
-- For security-sensitive flows, require authorization tests for cross-tenant/cross-merchant access.
-- For provider integrations, use fake adapters in integration tests and real providers only in staging smoke tests.
-- Avoid vague criteria like “works correctly,” “fast,” or “secure”; replace them with measurable expectations.
-
-## Output Template
-
-Use this structure unless the user asks for another format:
+Use the issue or conversation by default. Create a document only when requested or required by the repository. Adapt this optional structure to the agreed scope rather than filling every section for routine work.
 
 ```markdown
-# Test Criteria: <feature/task name>
-
-## Source
-- Input: <PRD/design document/spec/bug brief/GitHub issue/code audit source name or link>
-- Version/date: <if available>
-- Author/owner: <if available>
-
-## Scope
-- In scope: <behaviors covered>
-- Out of scope: <behaviors intentionally excluded>
-- Assumptions: <behavior inferred from issue/context/sibling flows because source is incomplete>
-- Blockers: <product/access/env decisions that prevent precise criteria>
-- Design source: <the prototype ref:path / mockup / layout-fixing doc this unit is built from, pinned at a commit — or `none`>
-
-> **"Out of scope" excludes behaviors, never the axis the unit is about.** A unit that cites a **Design source** owes `presentation:fidelity` ([../presentation/axis.md](../presentation/axis.md)); listing that evidence as a non-goal declares the point of the work out of scope (named incident: fmm-express #521). A unit with no design source simply says `none`.
-
-## Acceptance Criteria
-- AC1: <actor/system does ... under condition ... with expected observable result>
-- AC2: <...>
-
-## Critical User/System Journeys
-- J1: <actor/role starts from ... does ... and reaches ... with expected side effects>
-- J2: <...>
-
-## Test Matrix
-| Scenario | AC/Journey | Test Level | Mock/Fake Policy | Setup/Input | Assertions | Proving Test |
-|---|---|---|---|---|---|---|
-| Happy path | AC1 / J1 | Integration/API | Real DB + fake external provider | ... | ... | test name |
-| Invalid input | AC2 | Unit + API | Mock provider only to assert it is not called | ... | ... | test name |
-
-## Mock And Integration Policy
-- Mock acceptable: <pure decision logic, provider failures, asserting side effect is not called>
-- Integration required: <DB transactions, idempotency, concurrency, event/outbox, auth/tenant isolation, schema compatibility>
-- External dependency strategy: <fake provider adapter, emulator, test container, staging smoke test>
-- Mock-only exceptions: <AC/scenario + justification + reviewer approval; mocking a first-party internal seam is never an approvable exception — [../depth/mock-policy.md](../depth/mock-policy.md)>
-
-## Required Automated Tests
-- Unit: <specific logic and edge cases>
-- Integration: <DB/broker/provider fakes/state transitions>
-- Contract/API: <request/response/schema guarantees>
-- API E2E: <endpoint behavior with state/side-effect assertions, if needed>
-- UI E2E: <page route render-health/functional browser behavior, if needed>
-- Journey E2E: <cross-page/core business flow with real APIs where practical, if needed>
-
-## Coverage Mapping
-| Requirement/Journey | ACs | Test Case/File | Status |
-|---|---|---|---|
-| <REQ-1 / J1> | AC1, AC2 | <path::test_name> | Required |
-
-## Surface Census (Audit Mode Only — every surface, not just the gaps)
-One row per inventoried surface so completeness is provable by construction: gaps = every row not `Covered`/`Excluded`. If the inventory can't be fully enumerated, say so and mark the rest `BLOCKED` — do not quietly scope to what was easy to see.
-| Surface | kind/class | Required level | Status | Proving test (or — ) |
-|---|---|---|---|---|
-| /settings/team | route/mutation | browser-journey + presentation | Over-mocked | e2e/team.spec.ts (intercepts own API) |
-| /settings/team/members | route/mutation | browser-journey + presentation | Missing | — (orphan, no test) |
-| /api/team/invite | api/mutation | api + integration | Partial | tests/api/invite.test.ts |
-| ... (every remaining surface) | ... | ... | ... | ... |
-
-## Existing Coverage Assessment (Audit Mode Only)
-- Production-readiness verdict: <Ship / No-ship>, with the specific user scenarios likely to generate bug reports in the first week and the evidence that would raise confidence. **State the driving counts** (uncovered/orphan surfaces, ledger warnings, skips, over-mock findings) — a no-ship names its numbers, including advisory-scan counts; it does not hide them behind "partial."
-- Current coverage status: <Covered / Partial / Missing / Wrong Level / Over-mocked / Unverified / BLOCKED>
-- Existing tests reviewed: <actual paths/test names/cases/assertions inspected; do not list docs-only claims as reviewed tests>
-- Code paths reviewed: <paths/modules>
-- Route/endpoint discovery: <method/command/source used, discovered count, manifest count, missing/stale/uncovered entries>
-- Route reachability: <Reachable / Redirected / Guarded / Blocked / Unknown per relevant route, with layout/middleware/guard evidence>
-- E2E journeys identified: <journey list or Not applicable>
-- E2E journey coverage: <journey -> API/UI/Journey E2E evidence/status>
-- Prior coverage docs/reports checked: <None or list; state which claims were verified against test code>
-- Coverage gaps: <missing scenarios, weak assertions, over-mocking, wrong level, uncovered journeys, unverified claims, or None>
-- Follow-up test criteria items: <specific tests to add/update, with AC/journey mapping>
-
-## Test Skipping
-- Skipped tests: <None or list with allowed category, evidence/blocker link, and replacement verification>
-
-## Behavior-First Validation
-- ACs describe externally observable behavior, not private functions.
-- Test matrix scenarios validate outcomes, durable state, contracts, side effects, permissions, and failure behavior.
-- Unit tests are scoped to public behavior, pure decision logic, or stable public contracts.
-- Mock-only coverage does not bypass the core behavior under test.
-- Existing coverage claims were verified against actual test code, not trusted from prior docs/reports.
-- Route discovery and reachability analysis were performed before E2E audit, if applicable.
-- Production-readiness verdict is stated as an explicit ship/no-ship call with named first-week bug-report scenarios, not a vibe.
-- Status: PASS / FAIL / BLOCKED
-- Required revisions before approval: <None or list>
-
-## Reviewer Checklist
-- Obligation impact stated: which obligations/surfaces this change touches, their `requirementRefs`, and the test that proves each.
-- No `Orphan surface` introduced: every changed/new surface is referenced by at least one requirement and has a Coverage Ledger row.
-- Every changed/new page with a write form has a mutation-form journey test that fills the real UI and asserts the backend accepts the submission; split-contract forms (fields and validator from different sources) are not signed off on seam tests alone.
-- Every AC maps to an automated test or approved exception.
-- Tests assert behavior/state, not implementation details only.
-- No tests skipped/weakened to make CI pass; every (inherited) skip has an allowed category, evidence/blocker link, and replacement verification.
-- Substitutes appear only at external trust boundaries; no internal seam (DB, service layer, internal endpoint, event bus) is mocked. Fakes/stubs keep failure-path/edge cases fast and deterministic and never call a live third party in CI; mocks/fakes don't bypass the core behavior.
-- Mock-only coverage is rejected for stateful workflow, money movement, auth, idempotency, concurrency, event/outbox, or orchestrator recovery unless explicitly approved; money movement, auth, and idempotency can never be mock-only even with approval. Mocking a first-party internal seam is never approvable ([the mock policy](../depth/mock-policy.md)).
-- Failure, retry, duplicate, permission, and concurrency cases are covered where relevant.
-- Each proving test ran green (exit 0). No logs, screenshots, traces, or read-backs attached on top.
-
-## Blocking Decisions (need a human answer to finalize the criteria)
-Each entry is a product/scope decision you could NOT make yourself — phrase it so the reader knows exactly what to decide and why it matters. These are distinct from follow-up actions (which are just work to schedule); a blocking decision changes the criteria/verdict depending on the answer.
-- Decision: <the choice to make> · Why it blocks: <which AC/scope/verdict is undetermined until this is answered> · If A → <consequence for the criteria/tests> · If B → <consequence>. Default if no answer: <the assumption you'll proceed on, marked `Assumption`>.
+## Outcome and scope
+- Source, agreed behavior, material risks, assumptions, and out-of-scope work.
+- Product or architecture decisions needing their owners, if any.
+
+## Agreed acceptance criteria and proof
+- Observable criteria agreed before implementation.
+- Existing tests or checks that suffice; focused additional proof if needed.
+- Required repository checks and applicable security or data-integrity protections.
+
+## Assessment (when auditing)
+- Evidence inspected and execution results; what each proves and does not prove.
+- Coverage grades for the agreed scope, with concrete gaps and unavailable evidence.
+- Required fixes or decisions, separate from speculative follow-ups.
+- What was verified and what was not.
 ```
 
-## Behavior-First Validation (the gate before saving)
-
-After drafting, validate and revise before saving. Mark `BLOCKED` only when the source lacks enough information/access to define observable behavior. Reject criteria or audit claims that rely on:
+Use a surface census only for an explicitly requested broad audit; state its boundaries and any incomplete inventory. Do not invent a ship/no-ship verdict where the evidence or an owner decision is missing. If a verdict is requested, explain its concrete basis; do not make an untested hypothetical state an automatic blocker. A newly found concrete defect may require a fix without silently changing the agreed criteria.
 
-- ACs phrased as calls to specific internal functions, or test matrices organized around implementation modules instead of user/system scenarios.
-- Mock-heavy plans that never exercise state changes, API contracts, permissions, events, or side effects; or substitutes standing in for internal seams (DB, service layer, internal endpoints, event bus) instead of external trust boundaries.
-- Requirement coverage mapped only to private-method/unit tests when integration, contract, or E2E is required.
-- Coverage classified `Covered` from prior docs/PR summaries/audit reports/issue comments/CI/agent claims without inspecting actual test code/assertions.
-- E2E audits that skipped deterministic route/endpoint discovery or reachability analysis.
-- Audits driven only test-outward (mock census, existing-test mapping) without requirement-inward reconciliation, so `Orphan surface` gaps stay invisible.
-- Reachable pages with write forms treated as covered by route/API/validator tests, without a mutation-form journey that fills the rendered UI and asserts the backend accepts the submission (split-contract form gap).
+Prefer observable behavior to implementation-shaped assertions. Choose relevant failure, authorization, tenant-isolation, money, or durable-state cases based on material risk and existing policy. Preserve required repository checks and adopted floors. For design work, compare against the agreed design where needed; a cited source does not automatically require a separate presentation campaign. Inspect tests before saying they prove a behavior, and do not claim that an unavailable or failed check passed.

package/skills/engineering/ensure-coverage/references/process/test-strategy.md

@@ -4,15 +4,15 @@
 
 ## Test Level Selection
 
-Classify each AC before writing the matrix:
+Choose sufficient proof for each agreed AC and material risk, reusing existing evidence. The examples below are options, not automatic extra layers; existing required checks and adopted floors remain binding:
 
 - Logic AC: unit test is acceptable for pure decision logic or stable public contracts.
-- Boundary AC: contract/API test is required for request/response, validation, schema, compatibility, and error contracts.
-- Stateful workflow AC: integration test is required for DB writes, transactions, state transitions, idempotency, and recovery.
-- Async/pub-sub/orchestrator AC: integration test is required with real state store plus broker emulator or fake event adapter; assert final durable state and emitted events.
+- Boundary AC: consider a contract/API test for request/response, validation, schema, compatibility, and error contracts.
+- Stateful workflow AC: consider an integration test for DB writes, transactions, state transitions, idempotency, and recovery.
+- Async/pub-sub/orchestrator AC: consider an integration test with real state store plus broker emulator or fake event adapter; assert final durable state and emitted events.
 - Critical money/security AC: integration, API E2E, or Journey E2E is required; mock-only coverage is never acceptable here, even with approval.
-- Browser/UI AC: UI E2E is required for page behavior, navigation, user-visible errors, forms, and role-dependent visibility.
-- Cross-page/core business journey: Journey E2E is required with real APIs where practical; do not mock internal endpoints unless explicitly approved.
+- Browser/UI AC: consider UI E2E for page behavior, navigation, user-visible errors, forms, and role-dependent visibility.
+- Cross-page/core business journey: consider Journey E2E with real APIs where practical; do not mock internal endpoints unless explicitly approved.
 
 ## E2E Coverage Rules
 
@@ -31,12 +31,7 @@ Smoke is not a separate browser-test level. A browser smoke path is a **curated
 
 You can use the generated surface inventory to suggest candidates (mutation routes, auth/payments-looking routes, health endpoints), but do not let code discovery decide the golden-path manifest. Product/release judgment must promote candidates into `golden-paths.json` and write concrete observables.
 
-For audit mode:
-
-- Run deterministic route/endpoint discovery before coverage judgment.
-- Include discovery method, discovered count, manifest count, missing/stale/uncovered entries, and changed-route coverage status.
-- Build the user journey inventory before mapping tests; route render-health tests do not prove a business journey unless they exercise the full flow and assert final outcomes.
-- Decompose every reachable dashboard/settings page into its mutation-form journeys (e.g. "operator creates a GitHub connector account"). For each, require UI/Journey E2E proof that the form renders every backend-required field and that submitting it produces a payload the backend accepts plus the expected durable state change. Reject backend-validator, schema-source, and API-forwarding tests as a substitute — they are proxy wiring for a split-contract form.
+For audit mode, inspect the routes and journeys relevant to the agreed scope. A render-health test does not by itself prove a business journey; a backend test alone does not prove a form submits correctly. Use broader discovery only for an explicitly requested broad audit, and do not require a separate browser journey for every form by default.
 
 ## Test Skipping Policy (no-skip)
 

package/skills/engineering/ensure-coverage/scripts/README.md

@@ -1,8 +1,9 @@
 # ensure-coverage scripts
 
-The mechanized half of the skill: each script decides one thing the doctrine in
-[`../SKILL.md`](../SKILL.md) says must be proven. This file is the CLI reference. The
-*what* lives in `SKILL.md` and `references/`; the *why* of each rule is cited there.
+This is the CLI reference for optional coverage tools. `SKILL.md` and `references/`
+define when a tool is relevant; the checks below describe its unchanged mechanics,
+not new acceptance conditions. Run a tool when requested or required by the repository.
+Preserve adopted gates, but do not turn an optional scan into a feature blocker.
 
 **Resolution.** Every script is under this skill's own directory, not the target
 repo. Set `SKILL_DIR` to the directory you read `SKILL.md` from and run
@@ -45,7 +46,14 @@ Static test-lint gate engine. Deterministic, near-zero false positives, blocks o
 | `no-swallowed-assertion` | an assertion whose rejection is eaten by a chained `.catch(...)` |
 | `mock-internal-seam` | a `vi.mock` / `jest.mock` / `vitest.mock` whose target is first-party code |
 
-`mock-internal-seam` is default-on and zero-tolerance: no `@mock-ok` waiver, no grandfathering. In audit mode run it **whole-tree** (`--rules mock-internal-seam`, no `--diff`) and count every hit in the verdict. A believed false positive is fixed by declaring the repo's topology, never by waiving:
+The scanner mechanically treats `mock-internal-seam` as default-on and zero-tolerance:
+`@mock-ok` and inherited code do not suppress its exit status. Whole-tree scanning
+belongs to an explicitly requested broad audit or an existing repo requirement;
+a scoped task uses scoped checks when needed. Assess optional hits against the
+behavior claimed; the classifier alone cannot determine test adequacy. Do not
+require remediation merely because an optional scan flags a useful isolated unit
+test. An adopted required gate remains binding. Correct topology declarations
+when the scanner misclassifies an external boundary:
 
 ```json
 // coverage.config.json at the repo root — declares what counts as first-party

package/skills/engineering/golden-path/SKILL.md

@@ -3,7 +3,7 @@ name: golden-path
 description: "Golden-path E2E: the short list of user journeys whose failure blocks a release, kept in a repo as one contract (golden-paths.json) with a generated GOLDEN_PATHS.md and a generated GitHub Actions workflow, and run against a local build or a deployed URL for an ALIVE/DEAD verdict. Use to set golden paths up in a repo ('init golden paths', 'add golden-path CI'), to migrate an older smoke.manifest.json or a hand-built smoke setup ('audit', 'migrate smoke'), to add, change, or remove a golden path, to ask 'is the build alive?' or run them before a PR or release, or when a change touches a flow listed in GOLDEN_PATHS.md. NOT for writing the Playwright specs themselves (e2e-test), deciding what a change must prove (ensure-coverage), or general workflow YAML (github-actions)."
 dependencies:
   - e2e-test
-release-version: 0.44.1
+release-version: 0.45.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Golden path