mandrel 1.94.0 → 2.1.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-13T15:00:10.171Z",
+  "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-Epic 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 as part of `/deliver` Phase 6 (Epic 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",
@@ -72,46 +62,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "epic-plan-consolidate",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/epic-plan-consolidate/SKILL.md",
-      "description": "Run a holistic, pre-persist consolidation pass over the draft Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/plan`, after `epic-plan-decompose-author` writes `temp/epic-<Epic_ID>/tickets.json` and before `plan-persist.js` validates and persists it. Reconciles the draft against the Tech Spec \"Delivery Slicing\" ceiling via scope-preserving operations only.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": ["Read", "Write", "Bash"],
-      "vendor": null
-    },
-    {
-      "name": "epic-plan-decompose-author",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/epic-plan-decompose-author/SKILL.md",
-      "description": "Author the Story ticket JSON for an Epic from the decomposer authoring context emitted by `plan-context.js --epic <Epic_ID>`. Use during Phase 8 of `/plan` when the host LLM needs to write the ticket array before `plan-persist.js` validates and persists it.",
-      "policyCapsuleBullets": 15,
-      "allowedTools": ["Read", "Write", "Bash"],
-      "vendor": null
-    },
-    {
-      "name": "epic-plan-premortem",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/epic-plan-premortem/SKILL.md",
-      "description": "Run a fresh-context, code-reading pre-mortem critic over the draft Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/plan`, after `epic-plan-decompose-author` / `epic-plan-consolidate` write `temp/epic-<Epic_ID>/tickets.json` and before `plan-persist.js` validates and persists it. Reads the sectioned Epic body AND the cited code surfaces, then emits predicted-rework findings before any GitHub write.",
-      "policyCapsuleBullets": 7,
-      "allowedTools": ["Read", "Write", "Bash", "Grep"],
-      "vendor": null
-    },
-    {
-      "name": "epic-plan-spec-author",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/epic-plan-spec-author/SKILL.md",
-      "description": "Author the Tech Spec, Acceptance Table markdown, and risk-verdict JSON for an Epic from the planner authoring context emitted by `plan-context.js --epic <Epic_ID>`. Use during Phase 7 of `/plan` when the host LLM needs to write the three artifacts before `plan-persist.js` folds them into the Epic body's managed sections.",
-      "policyCapsuleBullets": 14,
-      "allowedTools": ["Read", "Write", "Bash"],
-      "vendor": null
-    },
     {
       "name": "gates-and-baselines",
       "tier": "core",
@@ -157,8 +107,8 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/scope-triage/SKILL.md",
-      "description": "Judge whether a piece of planned work is epic-sized or story-sized before the planning ceremony is paid for. Emits one of three verdicts — `epic` | `story` | `borderline` — over any planning artifact (a one-pager, an Epic body, or a Story draft). Use from `/plan` Phase 1.5 and any other planning gate that needs the canonical story-vs-epic rubric.",
-      "policyCapsuleBullets": 1,
+      "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": 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/starter-agentrc.json

@@ -13,10 +13,5 @@
     "repo": "[REPO]",
     "operatorHandle": "@[USERNAME]",
     "projectNumber": null
-  },
-  "delivery": {
-    "ci": {
-      "skipForStoryPushes": true
-    }
   }
 }

package/.agents/templates/agent-protocol.md

@@ -5,14 +5,14 @@ Version: {{PROTOCOL_VERSION}}
 You are an AI coding assistant. This protocol governs your execution of the
 current work unit. You must follow these rules strictly.
 
-> **Hierarchy shape.** Mandrel uses a **2-tier hierarchy**
-> (Epic → Story). The work unit is the `type::story` issue
-> itself, with acceptance criteria and verification inlined on the
-> Story body. There is no per-Task sub-loop; the agent authors commit
+> **Hierarchy shape.** Mandrel uses a **Story-only** model. The work unit
+> is the `type::story` issue itself, with acceptance criteria and
+> verification inlined on the Story body and the folded Tech Spec in
+> `## Spec`. There is no per-Task sub-loop; the agent authors commit
 > subjects directly per `.agents/rules/git-conventions.md` and
-> references the parent Story via `(refs #<storyId>)`. Branch naming
-> (`{{BRANCH_NAME}}` from `{{EPIC_BRANCH}}`), the Epic-branch
-> integration target, and the close protocol are as documented below.
+> references the Story via `(refs #<storyId>)`. Branch naming
+> (`{{BRANCH_NAME}}` from `{{EPIC_BRANCH}}` / base), the PR target
+> (`main`), and the close protocol are as documented below.
 
 ## 1. Pre-Flight Verification
 
@@ -50,9 +50,8 @@ When your implementation is complete and verified:
    `{{TEST_CMD}}`) here. The close script's lint/test/format/maintainability
    chain is the authoritative gate, run at Story closure (`story-close.js`).
    Exception: you may run them interactively while iterating on a fix.
-3. The Story branch is auto-merged into the Epic branch by
-   `helpers/epic-deliver-story` (via `story-close.js`) — do **not** merge
-   manually.
+3. The Story branch is opened as a PR to `main` by `helpers/deliver-story`
+   (via `single-story-close.js`) — do **not** merge manually.
 
 ## 6. Definition of Done
 

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
@@ -70,10 +69,10 @@ degrade to the sequential path.
 > read/search tools (`Read`, `Grep`, `Glob`) — no write/edit/shell-mutation
 > tools. The single write in an orchestrated run is the final report artifact.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have
@@ -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

@@ -15,10 +15,10 @@ quality. Your objective is to identify "code smells," technical debt, and
 violations of clean code principles (SOLID, DRY, KISS) that hinder long-term
 velocity.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have
@@ -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-dependencies.md

@@ -14,10 +14,10 @@ Manage the lifecycle of project dependencies. Your goal is to identify outdated,
 vulnerable, or bloated packages and suggest a safe upgrade path that maintains
 system stability.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

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

@@ -15,10 +15,10 @@ infrastructure, developer experience (DX) tooling, and CI/CD pipelines. Your
 goal is to identify inefficiencies, security risks, and areas for modernization
 without making any immediate changes.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have