@adbayb/stack 3.5.2 → 3.5.3

package/dist/index.js

@@ -931,7 +931,7 @@ const createWatchCommand = (program) => {
 
 //#endregion
 //#region package.json
-var version = "3.5.2";
+var version = "3.5.3";
 
 //#endregion
 //#region src/index.ts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adbayb/stack",
-  "version": "3.5.2",
+  "version": "3.5.3",
   "description": "My opinionated JavaScript-based toolchain",
   "keywords": [
     "development",

package/skills/skill-audit/SKILL.md

@@ -34,7 +34,7 @@ Never run installs, publishes, or releases while auditing, except installing or
 
 ### 1. Scope
 
-- Confirm the target (skills, `AGENTS.md` files, other agent instruction files, or a diff touching them) and non-goals.
+- Confirm the target (skills, `AGENTS.md` files, other agent instruction files, or a diff touching them) and non-goals; keep the scope bounded but audit everything inside it exhaustively, slice by slice for a broad target.
 - Map the instruction graph: always-loaded files, skill descriptions, `SKILL.md` routes, references, prerequisites, and standalone copies with their guards.
 - Run the repository's instruction checks (skill and template tests) to establish a baseline; record checks that cannot run.
 
@@ -42,6 +42,8 @@ Never run installs, publishes, or releases while auditing, except installing or
 
 Read `references/checklist.md` for the dimension map, evidence, severity, and scoring. Load only the mapped `skill-design` references in scope, apply their rules first, then the audit deltas.
 
+**Exhaustive depth.** A shallow pass is a failed audit. Read every in-scope file in full and run each dimension's evidence prompts against each file. For every Evidence bullet in `references/checklist.md`, record a finding, a "checked, clean" note with the evidence examined, or an inapplicability reason. Report every distinct root cause, including Minors and Unverified gaps (kept out of scoring), then sweep each dimension once more for missed items before reporting. Do not pad: each row needs evidence and an owning rule.
+
 Trace each rule to its owner and every consumer: skills, `AGENTS.md` files, templates, docs, and tests. Walk the checklist counterexamples through the text.
 
 Record each finding as an `Output` table row, grading severity and confidence with `references/checklist.md`. If no rule matches, report a gap and propose a rule for its canonical owner instead of inventing one.
@@ -83,7 +85,7 @@ Present the `Output` section's report before editing. If the request is audit-on
 
 For each finding, name the scoring criterion or criteria it affects. Write each Issue as one sentence: the owning `skill-design` rule, then the contradicting text and the agent decision it changes; cite the rule instead of pasting its prose. Keep each Solution to a fix direction.
 
-Then totals by severity, reviewed and skipped dimensions, unaudited out-of-scope files, verification limits (Supported rows and Unverified gaps), evaluation evidence location and results with the HTML report link or path (or an incomplete status and blocker), and up to 3 highest-leverage fixes. Always include the five criterion scores and **Total score: ?/10** using `references/checklist.md`, even when scoring was not requested or there are no findings; mark incomplete verification provisional. No findings: say so and skip fixes; do not invent work. When fixing, close with what changed per owner, what was left and why, verification results, and the updated score.
+Then totals by severity, a per-dimension coverage line (findings or checked-clean evidence), reviewed and skipped dimensions, unaudited out-of-scope files, verification limits (Supported rows and Unverified gaps), evaluation evidence location and results with the HTML report link or path (or an incomplete status and blocker), and a recommended fix order that highlights the highest-leverage fixes without limiting the findings table. Always include the five criterion scores and **Total score: ?/10** using `references/checklist.md`, even when scoring was not requested or there are no findings; mark incomplete verification provisional. No findings: say so and skip fixes; do not invent work. When fixing, close with what changed per owner, what was left and why, verification results, and the updated score.
 
 ## Example
 
@@ -93,4 +95,4 @@ Request: "Audit and score our skills."
 - Criteria: Consistency 1/2, Ownership 1/2, Actionability 2/2, Proportionality 2/2, Verification 2/2.
 - **Total score: 8/10** (provisional because trigger checks did not run).
 - Evaluation: representative runs passed; prompts, assertions, outputs, and grades saved in the session workspace; trigger accuracy remains unverified.
-- Top fix: delete the restated rule and link the owning reference.
+- Fix order: first delete the restated rule and link the owning reference.

package/skills/skill-audit/references/checklist.md

@@ -2,46 +2,48 @@
 
 Per-dimension evidence prompts and audit deltas, then severity, confidence, and scoring. Each `Rules:` line names the owning `skill-design` reference.
 
+Depth: each dimension is exhaustive within scope. Walk every Evidence item against every in-scope file; clear an item without a finding explicitly, with the evidence examined.
+
 ## A. Anatomy and metadata
 
 Rules: `skill-design` reference `anatomy.md`.
 
-- Evidence: folder and `name` match; frontmatter fields, quoting, and version bounds; section set and order; prerequisite section steps; numbered workflow; `Output` and `Example` sections; glossary placement; reference links and depth; size budgets.
+- Evidence: folder and `name` match (64 chars, lowercase/digits/single hyphens); `description` within 1024 characters and double-quoted; `license`, `metadata.author`, `metadata.repository` set; `metadata.version` semver bumped (patch for wording, minor for added rule or reference, major for removed or renamed rule, workflow, or prerequisite, per the repository rule) per the repository rule for contract changes; `metadata.requires` shape and lowest-sufficient bounds, with every prerequisite declared; unneeded `compatibility`/`allowed-tools`; level-two sections in the shared order and no others; title-case heading and intro covering scope, ownership split, and precedence; `Prerequisite` steps (name, stop-and-ask, install command, approval, no partial work, missing-reference incompatibility); numbered workflow steps each naming the reference to load and when; `Output` and `Example` consistency (the example follows the output template); glossary placement and identical shared expansions; every reference linked from `SKILL.md` with a load condition and kept one level deep; optional `Missing rule?` section for rule-owning skills pointing at non-normative sources (sources never overriding repo rules); `scripts/` and `assets/` use (assets only for files copied into results, response templates kept in `Output`); repository docs kept out of the skill folder; `SKILL.md` and reference line budgets.
 - Deltas: passing repository checks are evidence, not proof of intent; report drift the checks miss. Report a missing guard only when drift occurred or a copy makes it likely.
 
 ## B. Triggers
 
 Rules: `skill-design` reference `writing.md`.
 
-- Evidence: capability plus a "Use when" trigger; real phrasings covered; when-to-use text hidden in the body; overlap with sibling skills; prerequisite named.
+- Evidence: capability followed by "Use when"/"Use whenever" triggers naming tasks, artifacts, and phrasings, including requests that never name the skill and adjacent requests that still need it; leaning toward triggering without capturing trivial one-step requests; when-to-use text hidden in the body; out-of-scope artifacts stated in the body intro; overlap and near misses against sibling skills; closing `Requires` sentence listing every declared prerequisite; description claims matching what the skill does (no hidden network calls, data collection, or approval bypass); trigger-check evidence (about 20 queries, held-out split) for changed descriptions.
 - Deltas: demonstrate a misroute with a concrete request: one that should load the skill but would not, or a near miss that would.
 
 ## C. Ownership and consistency
 
 Rules: `skill-design` reference `writing.md`.
 
-- Evidence: one owner per rule; restated or paraphrased rules in consumers; conflicting precedence or version rules; skills named or referenced without being declared prerequisites; standalone copies with a named source and drift guard.
+- Evidence: one canonical owner per rule across `AGENTS.md`, `SKILL.md`, references, and the audit checklist; restated or paraphrased rules in consumers and non-normative summaries that read as normative; conflicting precedence or version rules; owner-first edits propagated to consumers; skills named or referenced without being declared prerequisites, and scope boundaries stated by artifact rather than by sibling skill; skill split by trigger and workflow, not size, with `<domain>-design`/`<domain>-audit` naming and the audit mapping checks to owning references instead of copying rules; standalone copies with a named source and an automated drift guard (not replaced by links to files the consumer lacks).
 - Deltas: guarded standalone mirrors are not duplicate ownership, and distinct rules with similar wording are not duplication, but an unguarded restatement of an owned rule is, even when the copies agree. Trace each conflict to the agent decision it changes.
 
 ## D. Actionability and proportionality
 
 Rules: `skill-design` reference `writing.md`.
 
-- Evidence: each instruction states when it applies, its scope and prerequisites, and what to do when blocked; workflow steps name the reference to load and when. Check fix authorization against `SKILL.md` workflow step 4; an audit request alone does not authorize edits.
+- Evidence: each instruction states when it applies, its scope and prerequisites, and what to do when blocked or a prerequisite is missing; imperative steps with a one-clause reason instead of all-caps commands; rules generalized from examples rather than one patch per example; output formats as a template plus one example; constraints placed in the step they govern, with cross-step constraints stated once before step 1; workflow steps name the reference to load and when; ambiguous or unmeasurable wording an agent could read two ways; non-skill instruction files (`AGENTS.md`) held to the same ownership and writing rules, with workflow steps for intent capture, rule placement, anatomy, scenario checks, and consumer updates applied proportionately; extension of an existing skill preferred over a new one unless the trigger or workflow is distinct; `Output` skill note items (skill, ownership, files, verification) without repeated change summaries or pasted rule text; application code and `scripts/` internals kept out of scope. Check fix authorization against `SKILL.md` workflow step 4; an audit request alone does not authorize edits.
 - Deltas: walk counterexamples from the instruction's own domain and exceptions (for design rules: a flat input/output script, a data-only transfer object, a closed union switch, a failed lookup versus absence), plus an unavailable prerequisite. A rule that forces speculative work in a counterexample is a finding.
 
 ## E. Progressive disclosure
 
 Rules: `skill-design` reference `writing.md`.
 
-- Evidence: always-loaded text limited to triggers and repository deltas; `SKILL.md` an entry point; references split by concern; budgets met without dropping meaning.
+- Evidence: always-loaded text (`AGENTS.md`, names, descriptions) limited to triggers and repository deltas; `SKILL.md` an entry point (workflow, output, routing) with detail in on-demand references split by concern; repeated deterministic work moved to `scripts/`; budgets met without dropping meaning.
 - Deltas: a budget overrun is a symptom; report its root cause, such as duplication or misplaced detail.
 
 ## F. Verification
 
 Rules: `skill-design` reference `evaluation.md`.
 
-- Evidence: reference targets, prerequisites, and documented commands exist; guards cover anatomy, links, budgets, and mirrors. For skill targets, check the execution evidence and HTML report completion gate in `SKILL.md` workflow steps 3 and 6, including audit-only requests; verify the generated artifact includes every executed evaluation and its grades and the final response links to it, rather than checking instruction text alone. Distinguish executed evaluations from scenario walks and mark unavailable or unrun checks unverified.
+- Evidence: reference targets, prerequisites, and documented commands exist and match repository evidence; evaluation sets stored outside the shipped skill folder and iteration stopped once results match `Output`; consumers of a changed contract updated (dependent skills, `AGENTS.md`, install docs, guards, version metadata); captured intent (what the skill enables, requests that should and should not load it, output, prerequisites); scenario sets (2-3 requests per branch, near misses, blocked paths) with walks and fixes of the instructions rather than the scenarios; comparative or baseline runs where behavior changed, with assertions written before results and transcripts read; guards cover anatomy, links, budgets, and mirrors. For skill targets, check the execution evidence and HTML report completion gate in `SKILL.md` workflow steps 3 and 6, including audit-only requests; verify the generated artifact includes every executed evaluation and its grades and the final response links to it, rather than checking instruction text alone. Distinguish executed evaluations from scenario walks and mark unavailable or unrun checks unverified.
 - Deltas: demand a guard only where drift is costly or already occurred, not for every sentence. Do not demand comparative runs for a wording-only change.
 
 ## Severity

package/skills/software-audit/SKILL.md

@@ -32,7 +32,7 @@ Never install or upgrade dependencies or run releases while auditing, except ins
 
 ### 1. Scope
 
-- Confirm target (files, slice, repo, or PR diff) and non-goals. Do not boil the ocean.
+- Confirm target (files, slice, repo, or PR diff) and non-goals. Keep the scope bounded, but audit everything inside it exhaustively: for a broad target, split it into slices and cover each in turn instead of sampling.
 - For a PR review, audit changed files and direct dependents; report unrelated findings separately.
 - Note the inner style and slice boundaries from the codebase; state assumptions when missing.
 - Run existing tests and the relevant linters/formatters first to establish a baseline; red baselines follow `software-design` reference `testing-refactoring.md`. If project dependencies are missing, stop and ask.
@@ -41,6 +41,8 @@ Never install or upgrade dependencies or run releases while auditing, except ins
 
 Read `references/checklist.md` for the A-G dimension map, evidence, exemptions, and severity. Load only the mapped references in scope, apply their rules first, then the audit deltas.
 
+**Exhaustive depth.** A shallow pass is a failed audit. Read every in-scope file in full, then run each dimension's evidence prompts against each file or module instead of skimming for obvious smells. For every Evidence bullet in `references/checklist.md`, record a finding, an explicit "checked, clean" with the evidence examined, or an inapplicability reason. Report every distinct root cause that meets the rules, including Minors and Unverified investigation gaps (kept out of scoring), rather than only the top few. Before the report, run a second sweep over each dimension for missed items: unused exports, duplicated knowledge, error paths, untested changed contracts, cycles, naming drift, and dependency/config gaps. Do not pad: every row still needs evidence and a rule, and exemptions still apply.
+
 Scan A-G in order for a full audit; for a PR, cover dimensions touched by the change and direct dependents. Mark inapplicable dimensions with a reason.
 
 Trace the changed contract through direct callers, alternate entry points, adapters, exports/configuration, and instruction/template consumers that can affect it. Inspect actual implementations, not only matching names.
@@ -88,7 +90,7 @@ Present the `Output` section's report first. For a PR review, default to the rep
 
 For each finding, name the in-scope scoring dimension or dimensions it affects, using the checklist's letter and title. Write each Issue as one sentence: the violated rule or smell, then the evidence and its consequence; cite the rule instead of pasting its prose or theory. Keep each Solution to a fix direction.
 
-Then total counts by severity, reviewed/skipped dimensions, unaudited out-of-scope files, verification limits (Supported rows and Unverified gaps), and up to 3 highest-leverage fixes. Always include the in-scope criterion scores per `references/checklist.md` and end the report with **Total score: ?/10**, even when scoring was not requested or there are no findings; mark incomplete verification provisional. Before reporting, recalculate the total from the listed criterion scores using the checklist formula and confirm the numerator, denominator, and displayed score agree. No findings: say so and skip fixes; do not invent work. When fixing, close with what was fixed and each fix's blast radius, what was left and why, and verification results, then end with the updated score.
+Then total counts by severity, a per-dimension coverage line (findings count or checked-clean evidence), reviewed/skipped dimensions, unaudited out-of-scope files, verification limits (Supported rows and Unverified gaps), and a recommended fix order that highlights the highest-leverage fixes without limiting the findings table. Always include the in-scope criterion scores per `references/checklist.md` and end the report with **Total score: ?/10**, even when scoring was not requested or there are no findings; mark incomplete verification provisional. Before reporting, recalculate the total from the listed criterion scores using the checklist formula and confirm the numerator, denominator, and displayed score agree. No findings: say so and skip fixes; do not invent work. When fixing, close with what was fixed and each fix's blast radius, what was left and why, and verification results, then end with the updated score.
 
 ## Example
 

package/skills/software-audit/references/checklist.md

@@ -2,53 +2,56 @@
 
 Per-dimension evidence prompts and audit deltas, then severity, confidence, and scoring. Each `Rules:` line names the owning `software-design` reference.
 
+Depth: each dimension is exhaustive within scope. Walk every Evidence item against every in-scope file; an item without a finding must be explicitly cleared with the evidence examined, not silently skipped.
+
 ## A. API surface / blast radius
 
 Rules: `software-design` reference `api-surface.md`.
 
-- Evidence: requirement/consumers per export; parameters/flags/leaked infrastructure/query mutations; invariant ownership and invalid state combinations; atomicity, concurrent updates, value precision, and source/wire/storage compatibility; callers and slices touched.
+- Evidence: YAGNI gate per resource/field/flag/option/export (requirement, add-later cost, removal cost), including unused "future" hooks, duplicate routes, and default-expanded relations; one purpose per unit and CQS (queries that mutate, commands returning more than identity/Result); parameter count (Parameter Object only when inputs are cohesive), boolean traps, observable behavior becoming an accidental contract (Hyrum's Law), `any`/wide inputs; leaked infrastructure types (ORM entities, `Request`/`Response`, SDK DTOs, driver rows/cursors/errors) and hidden mechanisms (ordering, retries, batching, storage); lowest sufficient scope (importers checked, counterpart exported before first consumer, implementations exported instead of contracts); invariant ownership across every entry path and invalid state combinations (flags vs discriminated unions, exhaustiveness, mutable aliases); money/quantity/time-zone units, precision, and rounding; transaction boundary at the use case, partial-failure recovery (outbox/compensation only where the required consistency needs it), unit-of-work ownership in the application layer, transaction held across network calls; read-check-write races and conflict behavior; typed stable errors without stack traces or driver messages; versioning, and source/wire/storage/behavioral compatibility (error shapes, defaults, mixed-version readers/writers); callers and slices touched (blast radius).
 - Deltas: trace each finding to a current consumer or contract; distinguish an internal signature change from an incompatible published contract. Apply reference exceptions; generated code/test doubles exempt.
 
 ## B. Structure
 
 Rules: `software-design` reference `architecture-styles.md`.
 
-- Evidence: inner style and dependency direction; cross-slice/module imports; composition-root wiring; boundary enforcement (linter, package names, or convention).
+- Evidence: slice boundary and inner style stated or inferable, then vertical slicing by capability (no global `controllers/`/`services/`/`models/` sprawl, no `features/` container) and one consistent inner style per module; dependency direction; cross-slice/module imports and deep imports; cross-slice communication via contracts/events only; database-shaped types shared across slices or cross-slice joins; barrel/`index.ts` files containing only re-exports (no imports, declarations, or wiring) and imports through the barrel; sharing threshold and shared-kernel size; composition-root/startup wiring and hosts; hexagonal specifics (ports named for purpose not technology, driver vs driven split, adapters per tech implementing one port, adapters never importing each other, hexagon free of framework/adapter imports, persistence ignorance, clock via param/port, test adapters); clean-architecture specifics (layers bypassed, controller calling repository, controller/presenter mixed, use cases returning view-shaped data, module extraction justified, workspace-name cross-module imports); MVVM viewmodel purity; single `infra/` tree (Périphérique); premature event bus/CQRS/service split; boundary enforcement (linter restricted imports, package `exports`, or convention).
 - Deltas: establish the chosen style before reporting layer bypasses; direct repository calls are valid in flat transaction scripts. Check whether tooling can enforce a claimed boundary; do not invent layers to satisfy the checklist.
 
 ## C. SOLID / GRASP
 
 Rules: `software-design` reference `solid-grasp.md`.
 
-- Evidence: responsibility boundaries/change reasons; extension without stable-file edits; LSP overrides; interface width/unused dependencies; dependency direction/composition root.
+- Evidence: SRP (actor and change reasons per unit); OCP (recurring variant edits to stable files, repeated type switches); LSP (strengthened preconditions, weakened postconditions, no-op/`NotImplemented` overrides); ISP (fat interfaces, unused injected dependencies); DIP (dependency direction, inner-owned ports, composition root, seams via parameters); GRASP (Information Expert/Feature Envy, Creator, thin Controller per use case, Low Coupling/High Cohesion, Protected Variations only at demonstrated volatility (Strategy/Polymorphism for repeated type switches), Pure Fabrication/Indirection without ceremony); composition over inheritance (depth over one level, subclass needing parent internals, Replace Inheritance with Delegation candidates); the four quick checks (one purpose, variant edits, fakeable I/O, used dependencies).
 - Deltas: report an observed change reason, substitution failure, unused dependency, or test obstacle, not a missing pattern. Inheritance and local exhaustive switches alone are not findings.
 
 ## D. Smells / anti-patterns
 
-Rules: `software-design` reference `smells-antipatterns.md`.
+Rules: `software-design` reference `smells-antipatterns.md` and `software-design` reference `patterns.md`.
 
-- Evidence: bloaters, couplers, dispensables, change preventers, architecture anti-patterns in touched code; recurring type-code switches; dead/commented/speculative/duplicated-rule code.
+- Evidence: check each catalog smell by name and record clean or finding. Bloaters (Long Method, Large Class, Primitive Obsession, Long Parameter List, Data Clumps); OO Abusers (Switch Statements/type codes, Refused Bequest, Temporary Field, Alternative Classes with Different Interfaces); Change Preventers (Divergent Change, Shotgun Surgery, Parallel Inheritance Hierarchies); Dispensables (dead/commented-out code, obvious comments, speculative generality, duplicate knowledge, Data Class with invariant behavior elsewhere); Couplers (Feature Envy, Inappropriate Intimacy, Message Chains, Middle Man, Incomplete Library Class); architecture anti-patterns (Leaky Abstraction, God Object, Spaghetti/Lava Flow, Golden Hammer, accidental Vendor Lock-in, Premature distribution).
+- Patterns (`software-design` reference `patterns.md`): for each named pattern present, confirm a present concrete pain justifies it; flag speculative or stacked patterns (Decorator+Proxy+Mediator), Singletons/global mutable instances instead of injection, patterns not removable without touching callers, and GoF implementations where framework-native features suffice. Also flag a missing pattern only when the repeated-pain gate is met (for example Builder for unreadable option bags, Adapter at SDK/driver edges, Decorator/Middleware for orthogonal behavior duplicated across units, Observer/events with mutable payloads instead of immutable past facts).
 - Deltas: group by root cause and establish harm; legitimate data contracts and deliberate duplication are not automatic findings. Separate touched-code remedies from larger cleanups.
 
 ## E. Clean code
 
 Rules: `software-design` reference `clean-code.md`.
 
-- Evidence: naming/verb mapping/banned synonyms; function size/nesting/guards/explanatory variables/named constants; comments/dead code; neutral text/type-checker silencing/absence/public interface/TSDoc.
+- Evidence: laws (KISS cleverness, DRY knowledge ownership, POLA surprises, Gall/YAGNI over-building, Kernighan hard-to-debug code, Conway/unclear ownership, Boy Scout/Broken Windows small decay left in touched code); naming (intent, one verb per meaning, banned synonyms, `All` infix, boolean `is*/has*/can*`, `input`/`output` generics vs domain names, `<Fn>Input`/`<Fn>Output` boundary contracts, `on<Event>` handlers, verb-first functions/noun types, stutter, type prefixes, `Manager`/`Helper`/`Util` identifiers, scope-sized names, consistency with the slice's existing verbs); function size/nesting/guards, single-level abstraction, output args; explanatory variables, encapsulated and positive conditionals, pass-through single-use aliases; named constants for domain policy and arbitrary defaults/limits/timeouts/retry counts (with stated reason); temporal coupling and logical dependencies left implicit (ambient order, hidden initialization); comments (why not what), commented-out code; type-checker silencing (`as any`, `@ts-ignore`, `!`); redundant annotations; top-down file ordering and const use-before-define; error handling convention (Result mapping at adapters, absence vs failed I/O, preserved causes, swallowed errors, error codes mixed with values); silent domain (logging/metrics in entities or use cases); `undefined` vs `null` semantics; neutral text; public interface docs/TSDoc.
 - Deltas: scope naming/style to new or edited code, neutral-text checks to introduced text.
 
 ## F. Tests / cohesion / coupling / errors
 
 Rules: `software-design` reference `cohesion-coupling.md`, `software-design` reference `testing-refactoring.md`, and `software-design` reference `clean-code.md`.
 
-- Evidence: change impact/coupling (cycles, globals, hidden I/O, Demeter, surprise side effects, new third-party dependencies); deterministic tests, adapter contracts, and changed boundary/failure coverage; error convention/boundary mapping/query purity/absence; resource ownership, cancellation, retry/idempotency safety, and bounded workload.
+- Evidence: cohesion (co-located handler/domain/tests/mapping, functional cohesion); sharing threshold (second consumer for a symbol, Rule of Three for a module, premature promotion or lingering duplication); coupling (cycles, globals, hidden I/O, Demeter/Tell-Don't-Ask, surprise side effects, direct call vs port vs event choice, events lacking delivery/duplicate/ordering handling, files changed per change); new third-party dependencies or ones replacing available platform features/existing dependencies (maintenance, security, size, license vs owning the code); testability (pure domain separated from I/O, explicit injection over module mocking, fakes beside ports, no DI framework solely for tests); tests (colocated, behavior through public interface, one behavior per test and scenario naming, `test.each` for overlap, boundaries and failure paths, awaited async/`resolves`/`rejects`, deterministic clocks/randomness/no sleeps, cleanup and mock/global restoration, no implementation-coupled or redundant tests, pyramid balance, adapter contract tests, weakened/deleted tests); refactor hygiene (green baseline, characterization tests, behavior fixes separate, callers updated with blast radius); error convention/boundary mapping/query purity/absence; resource ownership and cleanup on failure/cancellation, unawaited async work, timeouts, retry bounds and stacked retries, idempotency keys claimed atomically, bounded concurrency/queues/payloads, backpressure, unmeasured caches/batching and their invalidation.
 - Deltas: a diff that omits test files alone does not establish a coverage gap. Before reporting one, identify a behavior contract changed by the reviewed diff; an audit-only finding about existing behavior does not make that contract changed. If no changed contract is in scope, do not report or deduct for absent coverage. For a changed contract, inspect the relevant suite to confirm its boundary or failure behavior is untested; if that evidence is unavailable, record an investigation gap rather than a finding or score deduction. Trace success, rejection, timeout/cancellation, duplicate/concurrent execution, and partial-failure paths when relevant; check final state, effect count, cleanup, and reported errors.
 
 ## G. Security
 
 Rules: `software-design` reference `security.md` plus repo security rules.
 
-- Evidence: boundary validation and resource/tenant authorization; untrusted input reaching shell/query syntax, paths, or network destinations; secrets and sensitive data in storage/logs/errors; token/permission scope; dependency pinning/upgrades.
+- Evidence: boundary validation once at the edge with fail-fast actionable errors; authentication and resource/tenant authorization (missing/ambiguous authority denied, no reliance on valid IDs or UI-hidden actions); untrusted input reaching shell commands (non-parameterized exec), query syntax (non-parameterized, non-allowlisted identifiers), paths (canonical containment, symlinks, check/use races, string-prefix checks), URLs (schemes, destinations, and network trust boundary), or output encoding contexts; secrets in code/logs/errors; sensitive personal data minimization and redaction in storage/telemetry/errors; file writes scoped narrowly and destructive operations failing closed on ambiguous scope; token/permission least privilege; lockfile, dependency pinning, and unreviewed upgrades or surprise installs.
 - Deltas: establish input trust and path reachability; redact secret evidence.
 
 ## Severity