mandrel 2.0.0 → 2.2.0

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

@@ -0,0 +1,375 @@
+# Security and Hardening — Reference (on-demand)
+
+**Read this when** a task engages one of the sections below and the Policy
+Capsule in [`SKILL.md`](SKILL.md) does not settle it on its own. The capsule
+is the contract; this file is the reference material behind it. Nothing here
+relaxes a capsule MUST, and nothing here is required reading merely because
+the skill is active.
+
+## When to Use
+
+- Building anything that accepts user input
+- Implementing authentication or authorization
+- Storing or transmitting sensitive data
+- Integrating with external APIs or services
+- Adding file uploads, webhooks, or callbacks
+- Handling payment or PII data
+
+## Security Surfacing, Not Runtime Pause
+
+Some changes are not unsafe by themselves but expand the security surface
+enough that the change must be **explicitly documented** in the PR
+description and on the originating ticket so a reviewer can sign off in
+band. Documenting them is the gate — they do **not** pause execution:
+
+- Adding new authentication flows or changing auth logic
+- Storing new categories of sensitive data (PII, payment info)
+- Adding new external service integrations
+- Changing CORS configuration
+- Adding file upload handlers
+- Modifying rate limiting or throttling
+- Granting elevated permissions or roles
+
+For each item that applies, call it out under a "Security surface" section
+in the PR body and on the parent ticket, label the change `risk::high`,
+and link the relevant `security-baseline.md` MUST. Reviewers gate the
+merge; the agent keeps moving.
+
+`agent::blocked` remains the **only** runtime pause label. Use it for
+unrecoverable blockers (missing prerequisite, ambiguous spec a sub-agent
+cannot resolve), not for "this change is sensitive." Sensitive changes
+ship through the documentation path above.
+
+## OWASP Top 10 Prevention Patterns
+
+The patterns below show **how** to satisfy the MUSTs in
+[`security-baseline.md`](../../../rules/security-baseline.md). The MUSTs
+themselves (parameterize queries, hash passwords, encode output, verify
+ownership, set headers, restrict CORS, exclude sensitive fields) are listed
+in the rule.
+
+### 1. Injection (SQL, NoSQL, OS Command)
+
+See [security-baseline § Output & Rendering](../../../rules/security-baseline.md#output--rendering).
+
+```typescript
+// BAD: SQL injection via string concatenation
+const query = `SELECT * FROM users WHERE id = '${userId}'`;
+
+// GOOD: Parameterized query
+const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
+
+// GOOD: ORM with parameterized input
+const user = await prisma.user.findUnique({ where: { id: userId } });
+```
+
+### 2. Broken Authentication
+
+See [security-baseline § Authentication](../../../rules/security-baseline.md#authentication).
+
+```typescript
+import { hash, compare } from 'bcrypt';
+
+const SALT_ROUNDS = 12;
+const hashedPassword = await hash(plaintext, SALT_ROUNDS);
+const isValid = await compare(plaintext, hashedPassword);
+
+// Session management
+app.use(
+  session({
+    secret: process.env.SESSION_SECRET, // From environment, not code
+    resave: false,
+    saveUninitialized: false,
+    cookie: {
+      httpOnly: true,
+      secure: true,
+      sameSite: 'lax',
+      maxAge: 24 * 60 * 60 * 1000,
+    },
+  }),
+);
+```
+
+### 3. Cross-Site Scripting (XSS)
+
+See [security-baseline § Output & Rendering](../../../rules/security-baseline.md#output--rendering).
+
+```typescript
+// BAD: Rendering user input as HTML
+element.innerHTML = userInput;
+
+// GOOD: Use framework auto-escaping (React does this by default)
+return <div>{userInput}</div>;
+
+// If you MUST render HTML, sanitize first
+import DOMPurify from 'dompurify';
+const clean = DOMPurify.sanitize(userInput);
+```
+
+### 4. Broken Access Control
+
+See [security-baseline § Authorization](../../../rules/security-baseline.md#authorization).
+
+```typescript
+app.patch('/api/tasks/:id', authenticate, async (req, res) => {
+  const task = await taskService.findById(req.params.id);
+
+  if (task.ownerId !== req.user.id) {
+    return res.status(403).json({
+      error: {
+        code: 'FORBIDDEN',
+        message: 'Not authorized to modify this task',
+      },
+    });
+  }
+
+  const updated = await taskService.update(req.params.id, req.body);
+  return res.json(updated);
+});
+```
+
+### 5. Security Misconfiguration
+
+See [security-baseline § Transport & Headers](../../../rules/security-baseline.md#transport--headers).
+
+```typescript
+import helmet from 'helmet';
+app.use(helmet());
+
+app.use(
+  helmet.contentSecurityPolicy({
+    directives: {
+      defaultSrc: ["'self'"],
+      scriptSrc: ["'self'"],
+      styleSrc: ["'self'", "'unsafe-inline'"],
+      imgSrc: ["'self'", 'data:', 'https:'],
+      connectSrc: ["'self'"],
+    },
+  }),
+);
+
+app.use(
+  cors({
+    origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:3000',
+    credentials: true,
+  }),
+);
+```
+
+### 6. Sensitive Data Exposure
+
+See [security-baseline § Output & Rendering](../../../rules/security-baseline.md#output--rendering)
+and [§ Secrets Management](../../../rules/security-baseline.md#secrets-management).
+
+```typescript
+function sanitizeUser(user: UserRecord): PublicUser {
+  const { passwordHash, resetToken, ...publicFields } = user;
+  return publicFields;
+}
+
+const API_KEY = process.env.STRIPE_API_KEY;
+if (!API_KEY) throw new Error('STRIPE_API_KEY not configured');
+```
+
+## Input Validation Patterns
+
+See [security-baseline § Input Validation](../../../rules/security-baseline.md#input-validation).
+
+### Schema Validation at Boundaries
+
+```typescript
+import { z } from 'zod';
+
+const CreateTaskSchema = z.object({
+  title: z.string().min(1).max(200).trim(),
+  description: z.string().max(2000).optional(),
+  priority: z.enum(['low', 'medium', 'high']).default('medium'),
+  dueDate: z.string().datetime().optional(),
+});
+
+app.post('/api/tasks', async (req, res) => {
+  const result = CreateTaskSchema.safeParse(req.body);
+  if (!result.success) {
+    return res.status(422).json({
+      error: {
+        code: 'VALIDATION_ERROR',
+        message: 'Invalid input',
+        details: result.error.flatten(),
+      },
+    });
+  }
+  const task = await taskService.create(result.data);
+  return res.status(201).json(task);
+});
+```
+
+### File Upload Safety
+
+```typescript
+const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];
+const MAX_SIZE = 5 * 1024 * 1024; // 5MB
+
+function validateUpload(file: UploadedFile) {
+  if (!ALLOWED_TYPES.includes(file.mimetype)) {
+    throw new ValidationError('File type not allowed');
+  }
+  if (file.size > MAX_SIZE) {
+    throw new ValidationError('File too large (max 5MB)');
+  }
+  // Don't trust the file extension — check magic bytes if critical
+}
+```
+
+## Triaging npm audit Results
+
+The MUST is in [security-baseline § Dependency Hygiene](../../../rules/security-baseline.md#dependency-hygiene).
+This decision tree shows how to prioritize:
+
+```text
+npm audit reports a vulnerability
+├── Severity: critical or high
+│   ├── Is the vulnerable code reachable in your app?
+│   │   ├── YES --> Fix immediately (update, patch, or replace the dependency)
+│   │   └── NO (dev-only dep, unused code path) --> Fix soon, but not a blocker
+│   └── Is a fix available?
+│       ├── YES --> Update to the patched version
+│       └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date
+├── Severity: moderate
+│   ├── Reachable in production? --> Fix in the next release cycle
+│   └── Dev-only? --> Fix when convenient, track in backlog
+└── Severity: low
+    └── Track and fix during regular dependency updates
+```
+
+**Key questions:**
+
+- Is the vulnerable function actually called in your code path?
+- Is the dependency a runtime dependency or dev-only?
+- Is the vulnerability exploitable given your deployment context (e.g., a
+  server-side vulnerability in a client-only app)?
+
+When you defer a fix, document the reason and set a review date.
+
+## Rate Limiting
+
+```typescript
+import rateLimit from 'express-rate-limit';
+
+// General API rate limit
+app.use(
+  '/api/',
+  rateLimit({
+    windowMs: 15 * 60 * 1000,
+    max: 100,
+    standardHeaders: true,
+    legacyHeaders: false,
+  }),
+);
+
+// Stricter limit for auth endpoints (the rule MUSTs rate-limiting on auth)
+app.use(
+  '/api/auth/',
+  rateLimit({
+    windowMs: 15 * 60 * 1000,
+    max: 10,
+  }),
+);
+```
+
+## Secrets Management Layout
+
+See [security-baseline § Secrets Management](../../../rules/security-baseline.md#secrets-management).
+
+```text
+.env files:
+  ├── .env.example  → Committed (template with placeholder values)
+  ├── .env          → NOT committed (contains real secrets)
+  └── .env.local    → NOT committed (local overrides)
+
+.gitignore must include:
+  .env
+  .env.local
+  .env.*.local
+  *.pem
+  *.key
+```
+
+**Always check before committing:**
+
+```bash
+# Check for accidentally staged secrets
+git diff --cached | grep -i "password\|secret\|api_key\|token"
+```
+
+## Security Review Checklist
+
+Use this when reviewing your own change before requesting human review. Each
+item maps to a section in
+[`security-baseline.md`](../../../rules/security-baseline.md).
+
+```markdown
+### Authentication
+
+- [ ] Passwords hashed with bcrypt/scrypt/argon2 (salt rounds ≥ 12)
+- [ ] Session tokens are httpOnly, secure, sameSite
+- [ ] Login has rate limiting
+- [ ] Password reset tokens expire
+
+### Authorization
+
+- [ ] Every endpoint checks user permissions
+- [ ] Users can only access their own resources
+- [ ] Admin actions require admin role verification
+
+### Input
+
+- [ ] All user input validated at the boundary
+- [ ] SQL queries are parameterized
+- [ ] HTML output is encoded/escaped
+
+### Data
+
+- [ ] No secrets in code or version control
+- [ ] Sensitive fields excluded from API responses
+- [ ] PII encrypted at rest (if applicable)
+
+### Infrastructure
+
+- [ ] Security headers configured (CSP, HSTS, etc.)
+- [ ] CORS restricted to known origins
+- [ ] Dependencies audited for vulnerabilities
+- [ ] Error messages don't expose internals
+```
+
+## Common Rationalizations
+
+| Rationalization                                     | Reality                                                                         |
+| --------------------------------------------------- | ------------------------------------------------------------------------------- |
+| "This is an internal tool, security doesn't matter" | Internal tools get compromised. Attackers target the weakest link.              |
+| "We'll add security later"                          | Security retrofitting is 10x harder than building it in. Add it now.            |
+| "No one would try to exploit this"                  | Automated scanners will find it. Security by obscurity is not security.         |
+| "The framework handles security"                    | Frameworks provide tools, not guarantees. You still need to use them correctly. |
+| "It's just a prototype"                             | Prototypes become production. Security habits from day one.                     |
+
+## Red Flags
+
+- User input passed directly to database queries, shell commands, or HTML
+  rendering
+- Secrets in source code or commit history
+- API endpoints without authentication or authorization checks
+- Missing CORS configuration or wildcard (`*`) origins
+- No rate limiting on authentication endpoints
+- Stack traces or internal errors exposed to users
+- Dependencies with known critical vulnerabilities
+
+## Verification
+
+After implementing security-relevant code, confirm against the rule:
+
+- [ ] `npm audit` shows no critical or high vulnerabilities
+- [ ] No secrets in source code or git history
+- [ ] All user input validated at system boundaries
+- [ ] Authentication and authorization checked on every protected endpoint
+- [ ] Security headers present in response (check with browser DevTools)
+- [ ] Error responses don't expose internal details
+- [ ] Rate limiting active on auth endpoints

package/.agents/skills/skills.index.json

@@ -1,17 +1,7 @@
 {
-  "generatedAt": "2026-07-14T21:42:10.296Z",
+  "generatedAt": "2026-07-16T20:44:41.281Z",
   "generator": "generate-skills-index.js@1",
   "skills": [
-    {
-      "name": "analyze-execution",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/analyze-execution/SKILL.md",
-      "description": "Aggregate per-Story or per-plan-run execution signals into a structured perf-summary or perf-report and upsert it onto the corresponding GitHub ticket. Use after a Story closes (Story mode) or during run closeout (plan-run mode). Reads NDJSON via `lib/signals/read` and writes a single structured comment.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": ["Read", "Bash"],
-      "vendor": null
-    },
     {
       "name": "api-and-interface-design",
       "tier": "core",
@@ -118,7 +108,7 @@
       "category": "core",
       "path": ".agents/skills/core/scope-triage/SKILL.md",
       "description": "Optional split-advisory for `/plan`. Under v2 there is no epic|story routing verdict — `/plan` always authors Stories. Use this skill only when judging whether a draft should stay one Story or legitimately split (near-zero overlap or an architectural seam).",
-      "policyCapsuleBullets": 1,
+      "policyCapsuleBullets": 5,
       "allowedTools": null,
       "vendor": null
     },

package/.agents/skills/stack/qa/playwright-bdd/SKILL.md

@@ -122,9 +122,8 @@ authoring.
   expression across jobs — tag-sharding makes flake triage non-deterministic.
 - Run `bddgen` once per job before `playwright test`; cache the generated
   directory only if the cache key includes every `.feature` and step file.
-- Publish the Cucumber HTML/JSON report as the evidence artifact consumed by the
-  `epic-testing` helper, alongside the Playwright HTML report and any trace
-  zips.
+- Publish the Cucumber HTML/JSON report as the evidence artifact, alongside
+  the Playwright HTML report and any trace zips.
 - Quarantine `@flaky` scenarios with a dedicated job that does not gate the
   merge queue; do not silently retry flakes in the main suite.
 
@@ -185,4 +184,3 @@ those outcomes.
 - Scenario authoring rules: `.agents/rules/gherkin-standards.md`.
 - Browser-level conventions: `.agents/skills/stack/qa/playwright/SKILL.md`.
 - Operator entry point: `.agents/workflows/qa-run.md`.
-- Evidence handoff: `.agents/workflows/helpers/epic-testing.md`.

package/.agents/skills/stack/qa/qa-explore-driving/SKILL.md

@@ -91,7 +91,7 @@ source, route definitions, and rendered markup rather than a running browser.
 
 The agent-driven Capture phase is **strictly read-only**. This invariant is
 inviolable per [`security-baseline.md`](../../../../rules/security-baseline.md)
-and the Epic's security considerations — it is not a soft preference.
+and the Story's security considerations — it is not a soft preference.
 
 - **No source edits.** The agent does not modify application code, config, or
   tests while driving. Exploration observes; it never repairs.

package/.agents/skills/stack/qa/qa-harness/SKILL.md

@@ -192,9 +192,7 @@ Bundle findings **by likely root cause** into proposed follow-up tickets with
 `Depends-on` / `Blocks` relationships, then present the draft for operator
 approval. The harness **MUST NOT** create tickets autonomously — it stops at a
 draft. The operator-approval gate is the safety boundary against spurious
-filing. When the run was triggered from an Epic-testing context, hand the
-**approved** findings to the Epic-testing helper for attachment to the Epic's
-QA evidence ticket.
+filing.
 
 ## 6. Sign-In & Contract Discipline
 

package/.agents/workflows/audit-architecture.md

@@ -19,8 +19,7 @@ existing external APIs or business logic.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/deliver` Phase 4
-epic-audit, `audit-to-stories`) are agnostic to which path produced it.
+report contract (Step 3); downstream consumers (`audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
   [dynamic workflows](https://code.claude.com/docs/en/workflows) are
@@ -218,7 +217,7 @@ Evaluate the gathered context against the following clean code dimensions:
    gates, baseline kinds, close-validation steps, dependencies, or
    harness subsystems under this dimension.
 
-   **Scope-mode behavior.** When this lens is invoked in Epic mode (the
+   **Scope-mode behavior.** When this lens is invoked in Story scope (the
    `{{changedFiles}}` block above is populated with a file list), the
    maturity assessment for this dimension is a repo-wide property that
    cannot be represented by a small changeset. In that case, render the
@@ -269,7 +268,7 @@ architectural pain points and areas for simplification.]
 ## Architecture Guardrail Coverage
 
 [Codebase-wide mode: complete this section using the maturity rubric in
-Step 2. Epic-mode / scoped run: set `Current Maturity` to
+Step 2. Story-scoped run: set `Current Maturity` to
 `Not Assessed — scoped run` and leave the remaining fields empty or
 marked `n/a`.]
 

package/.agents/workflows/audit-clean-code.md

@@ -39,8 +39,7 @@ before this section existed.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/deliver` Phase 4
-epic-audit, `audit-to-stories`) are agnostic to which path produced it.
+report contract (Step 3); downstream consumers (`audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
   [dynamic workflows](https://code.claude.com/docs/en/workflows) are
@@ -102,8 +101,9 @@ Analyze the repository with a focus on:
   cyclomatic complexity > 8 (`delivery.quality.codingGuardrails.cyclomaticFlag`)
   is **flag in review** (annotate or split); > 12
   (`codingGuardrails.cyclomaticMustFix`) is **must-fix** before the work merges.
-  A per-file MI drop > 1.5pt (`codingGuardrails.miDropMustRefactor`) requires a
-  refactor in the same Story rather than a baseline bump.
+  A per-file MI drop beyond the configured
+  `delivery.quality.gates.maintainability.tolerance` (default 0.5pt) requires
+  a refactor in the same Story rather than a baseline bump.
 - **Duplication:** Find "copy-paste" logic that should be abstracted into
   reusable utilities or hooks.
 - **Component Health:** In UI code, look for "component bloat" (files > 300

package/.agents/workflows/audit-documentation.md

@@ -16,7 +16,7 @@ renamed, scripts move, described workflows change shape, and
 version/topology claims go stale. The deterministic gates
 (`check-doc-links.js`, `check-lifecycle-doc-drift.js`,
 `validate-docs-freshness.js`) catch broken links, drift against generators,
-and Epic-scoped freshness — they cannot tell whether the prose still
+and per-delivery freshness — they cannot tell whether the prose still
 describes how the code actually behaves. That semantic verification is this
 lens's job.
 
@@ -71,8 +71,7 @@ before this section existed.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/deliver` Phase 4
-epic-audit, `audit-to-stories`) are agnostic to which path produced it.
+report contract (Step 3); downstream consumers (`audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
   [dynamic workflows](https://code.claude.com/docs/en/workflows) are
@@ -279,8 +278,8 @@ match the code), the deterministic-gate verdicts, and primary drift themes.]
 ## Periodic full-scope sweep
 
 Context Economy findings accrete slowly — a doc that is lean today grows a
-bloated tail over many Epics, and no single change-set-scoped `/deliver`
-Phase 4 run sees the whole picture. Run this lens **full-scope** on a
+bloated tail over many deliveries, and no single change-set-scoped `/deliver`
+run sees the whole picture. Run this lens **full-scope** on a
 recurring cadence so the drift is caught before it compounds:
 
 - **Scheduled invocation** — `/schedule` running `/audit-documentation`

package/.agents/workflows/audit-lighthouse.md

@@ -5,6 +5,14 @@ command: false
 
 # Lighthouse Audit & Analysis
 
+## Applicability
+
+**Web targets only.** Registered with `target: "web"` in
+[`audit-rules.json`](../schemas/audit-rules.json): the selector skips this lens
+on a project with no web surface, since there is no page to launch Lighthouse
+against. See the `target` key's schema description for how applicability is
+probed from the consumer's checkout.
+
 ## Role
 
 Senior Web Performance & Quality Engineer. You operate Lighthouse end-to-end:

package/.agents/workflows/audit-navigability.md

@@ -8,6 +8,16 @@ description: >-
 
 # Navigability Audit
 
+## Applicability
+
+**Web targets only.** Registered with `target: "web"` in
+[`audit-rules.json`](../schemas/audit-rules.json). This is consistent with the
+lens's own no-op contract below rather than an additional constraint: the
+web-surface probe's first signal _is_ configured `routeGlobs`, so a consumer
+that has configured this lens's route-tree SSOT always clears the gate. The
+gate only bites where the lens had no route data to read anyway — it converts a
+silent no-op run into no run at all.
+
 ## Role
 
 Information-Architecture Reviewer & Frontend Navigation Auditor

package/.agents/workflows/audit-performance.md

@@ -1,5 +1,5 @@
 ---
-description: Audit hot paths, algorithmic complexity, and I/O bottlenecks in the tooling surface (`epic-close`, dispatcher, gates); propose remediations.
+description: Audit hot paths, algorithmic complexity, and I/O bottlenecks in the tooling surface (`single-story-close`, dispatcher, gates); propose remediations.
 ---
 
 # Performance & Bottleneck Audit
@@ -38,8 +38,7 @@ before this section existed.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/deliver` Phase 4
-epic-audit, `audit-to-stories`) are agnostic to which path produced it.
+report contract (Step 3); downstream consumers (`audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
   [dynamic workflows](https://code.claude.com/docs/en/workflows) are

package/.agents/workflows/audit-quality.md

@@ -15,7 +15,7 @@ infrastructure, test coverage, and overall quality assurance practices. Your
 goal is to identify testing gaps, flaky tests, inefficient mocking strategies,
 and opportunities to improve test execution speed and reliability without making
 any immediate changes. Additionally, you must evaluate the implemented tests
-against the active Epic and the current codebase to ensure all quality
+against the Story under audit and the current codebase to ensure all quality
 requirements are met and correctly documented.
 
 **Note on Testing Responsibilities**: When evaluating test maturity, note the
@@ -48,8 +48,7 @@ before this section existed.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/deliver` Phase 4
-epic-audit, `audit-to-stories`) are agnostic to which path produced it.
+report contract (Step 3); downstream consumers (`audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
   [dynamic workflows](https://code.claude.com/docs/en/workflows) are
@@ -101,8 +100,8 @@ degrade to the sequential path.
 
 ## Step 0 - Project Context
 
-1.  Read the active Epic and its child tickets to identify the current milestone
-    and target features.
+1.  Read the Story under audit — its `## Goal`, inline `acceptance[]` /
+    `verify[]`, and folded `## Spec` — to identify the target features.
 2.  Identify the target codebase paths for the audit.
 
 ## Step 1: Context Gathering (Read-Only Scan)
@@ -116,8 +115,8 @@ files. Pay special attention to:
   `playwright.config.ts`, `cypress.json`).
 - Test directories and files (e.g., `__tests__/`, `spec/`, `e2e/`, `*.test.ts`,
   `*.spec.js`).
-- The active Epic and its child tickets to map out expected features versus
-  implemented tests.
+- The Story's `acceptance[]` / `verify[]` arrays, to map expected behaviour
+  versus implemented tests.
 - Mocking and stubbing setups (e.g., `__mocks__/`, `setupTests.js`, MSW
   handlers).
 - CI/CD workflow files to understand how and when tests are executed.
@@ -140,8 +139,8 @@ Evaluate the gathered context against the following test quality dimensions:
 5. **Performance & Execution:** Find bottlenecks in the test suite, such as
    unnecessary serial execution, heavy setup running too frequently, or
    opportunities for parallelization.
-6. **Requirement Alignment:** Cross-reference the features outlined in the
-   active Epic to ensure they have corresponding and complete test coverage.
+6. **Requirement Alignment:** Cross-reference the Story's `acceptance[]`
+   criteria to ensure they have corresponding and complete test coverage.
    Verify that the implementation found in the codebase correctly matches the
    architectural requirements and highlight any inconsistencies or gaps.
 

package/.agents/workflows/audit-security.md

@@ -39,8 +39,7 @@ before this section existed.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/deliver` Phase 4
-epic-audit, `audit-to-stories`) are agnostic to which path produced it.
+report contract (Step 3); downstream consumers (`audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
   [dynamic workflows](https://code.claude.com/docs/en/workflows) are

package/.agents/workflows/audit-seo.md

@@ -4,6 +4,16 @@ description: Audit SEO fundamentals and Generative Engine Optimization signals (
 
 # SEO & Generative Engine Optimization Audit
 
+## Applicability
+
+**Web targets only.** This lens is registered with `target: "web"` in
+[`audit-rules.json`](../schemas/audit-rules.json), so the selector skips it
+entirely on a project with no web surface — however well its keyword triggers
+match the ticket prose. Applicability is derived from the consumer's own
+checkout (configured navigability `routeGlobs`, a declared web-framework
+dependency, or a tracked `.html` / `.css` / `.jsx` / `.tsx` source file), not
+from an `.agentrc` key, and the probe fails open when indeterminate.
+
 ## Role
 
 Senior Technical SEO and Generative Engine Optimization (GEO) Specialist. You

package/.agents/workflows/audit-ux-ui.md

@@ -4,6 +4,13 @@ description: Audit UX/UI consistency and design system adherence
 
 # UX/UI & Design System Audit
 
+## Applicability
+
+**Web targets only.** Registered with `target: "web"` in
+[`audit-rules.json`](../schemas/audit-rules.json): the selector skips this lens
+on a project with no rendered frontend. See the `target` key's schema
+description for how applicability is probed from the consumer's checkout.
+
 ## Role
 
 Lead Product Designer & Frontend Architect