mandrel 2.7.0 → 2.9.0

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

@@ -4,59 +4,35 @@ description: Audit performance by measuring first — profile hot paths, I/O, me
 
 # Performance & Bottleneck Audit
 
-## Role
-
-Performance Engineer & Systems Architect
-
-## Context & Objective
-
-Find where a system is slow, wasteful, or unsafe under concurrency — and prove
-it with numbers, not opinions. This lens has three standing commitments that
-separate it from a prose read-through:
-
-1. **Measure before you judge.** A performance claim that is not backed by a
-   profile, a timing, or a byte count is a hypothesis, not a finding. Step 0
-   times the repo's own suite and entry points and produces the evidence every
-   finding must cite.
-2. **Adapt to the repo profile.** A CLI/tooling repo has no bundle and no Core
-   Web Vitals; a frontend app does. Step 1 detects the target profile and
-   activates only the dimensions that apply, declaring the rest inapplicable
-   rather than fabricating findings for a surface that does not exist.
-3. **Interleaving correctness is a performance concern.** The most expensive
-   defects this repo has shipped were not slow loops — they were races
-   (check-then-act on a lease, non-atomic checkout mutation under concurrent
-   close, shared-cache poisoning). Step 2 treats interleaving & partial-failure
-   correctness as a first-class dimension, statically and repo-observably.
-
-## Scope (Story / plan-run mode)
-
-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
-before this section existed.
+You are a Performance Engineer & Systems Architect finding where a system is
+slow, wasteful, or unsafe under concurrency — and proving it with numbers, not
+opinions. Three standing commitments separate this lens from a prose
+read-through: **measure before you judge** (a claim with no profile/timing/byte
+count is a hypothesis, not a finding); **adapt to the repo profile** (activate
+only the dimensions that apply, declaring the rest inapplicable); and
+**interleaving correctness is a performance concern** (races have been the most
+expensive defects this repo shipped). The shared lens machinery — read-only
+constraint, scope interpretation, report envelope + finding-block skeleton,
+severity scale, self-cross-check, and execution strategy — lives in
+[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
+`{{auditOutputDir}}/audit-performance-results.md`. Extra finding field:
+**Evidence:** [a Step 0 repro command (or quoted code path) + a `measured` or
+`estimated` tag]. The report adds a **Low-Hanging Fruit** section.
+
+## Scope
+
+Interpret this lens's change-set fence per the core's Scope interpretation:
 
 ```text
 {{changedFiles}}
 ```
 
-- If the block above contains a newline-delimited list of file paths,
-  restrict your analysis to those files (and their direct dependencies
-  when the lens explicitly calls for cross-file reasoning).
-- If the block above renders as the literal string `{{changedFiles}}`
-  (i.e. no substitution was supplied), ignore this section entirely and
-  proceed with the full codebase-wide scan defined in the remaining
-  steps.
+## Execution strategy
 
-## Execution strategy (dual-path)
-
-This lens runs along one of two execution paths (orchestrated dynamic-workflow
-or sequential single-pass). Both emit the **identical** Step 4 report contract;
-downstream consumers (`audit-to-stories`) are agnostic to which path produced
-it. See [`helpers/audit-dual-path.md`](helpers/audit-dual-path.md) for strategy
-selection, the forcing flags, and the read-only guarantee — read `audit-<lens>`
-there as this lens's name.
+This is a **heavyweight lens**: dispatch it as a single `subagent_type: auditor`
+call, or fan its resource dimensions out per-dimension across parallel `auditor`
+subagents (parallel-tooling Rule 3) and merge under the self-cross-check.
+Sequential inline execution is the fallback (see the core's Execution strategy).
 
 > **Measurement is non-mutating, not forbidden.** This lens is read-only with
 > respect to source, but it MUST be allowed to *run* measurements. The
@@ -64,11 +40,11 @@ there as this lens's name.
 > **non-mutating command allowlist** (profilers, timers, bundle-stat and
 > file-size probes — never a command that writes source, installs, or mutates
 > git/labels). See the allowlist in
-> [`.claude/workflows/audit-performance.workflow.js`](../../.claude/workflows/audit-performance.workflow.js).
+> [`../../.claude/workflows/audit-performance.workflow.js`](../../.claude/workflows/audit-performance.workflow.js).
 
 ## Step 0: Measure before you judge (mandatory)
 
-Produce evidence first; every finding in Step 4 carries an **Evidence** field
+Produce evidence first; every finding in the report carries an **Evidence** field
 that cites a repro command and tags itself `measured` or `estimated`. Run the
 measurements that apply to the repo (Step 1 tells you which), preferring the
 repo's own scripts over invented ones.
@@ -180,9 +156,8 @@ dimension (per Step 1) against measured evidence from Step 0.
 
 ## Step 3: Severity rubric (performance-anchored)
 
-Grade every finding on the shared
-[`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md),
-anchored to performance/correctness cost rather than gut feel:
+Grade every finding on the shared severity scale, anchored to
+performance/correctness cost rather than gut feel:
 
 - Grade **Critical** for a guaranteed data-loss or corruption path under normal
   concurrency (e.g. a lost-update TOCTOU on persisted state), or a hang/outage
@@ -198,67 +173,26 @@ anchored to performance/correctness cost rather than gut feel:
 Latency thresholds, when a user-facing route is in scope, follow the CWV bands
 in the payload/bundle dimension (LCP ≤2.5s good / ≤4.0s needs-improvement).
 
-## Step 4: Output Requirements
-
-Generate and save a highly structured Markdown audit report to
-`{{auditOutputDir}}/audit-performance-results.md`, using the exact template
-below.
-
-```markdown
-# Performance Audit Report
+## Constraint (lens-specific carve-out)
 
-## Executive Summary
+This lens is read-only **with respect to source**: it does not edit, create, or
+delete application code, dependencies, or configuration. It **does** run
+non-mutating measurements (Step 0) and writes exactly two artifacts — the report
+and `perf-baseline.json`.
 
-[Overview of performance posture vs the Step 0 measurements. State the repo
-profile detected (Step 1) and which dimensions were inapplicable. State the
-baseline trend verdict (first-run / improved / unchanged / regressed) and the
-`perf-baseline.json` path. Close with the self-cross-check `kept k / dropped d`
-line.]
+The **interleaving** dimension leans on the self-cross-check hardest: drop every
+claimed race that lacks a concrete losing interleaving over a repo-observable
+shared-state path.
 
-## Detailed Findings
+## Report additions
 
-[For every bottleneck or correctness defect identified, use the following
-strict structure. Lead each title with the primary file it lives in:]
+Beyond the shared skeleton (Executive Summary + Detailed Findings from the
+core), this lens's report carries its own title and a Low-Hanging Fruit section:
 
-### `path/to/primary-file.ext` — [Short title of the finding]
-
-- **Dimension:** [CPU & algorithmic | I/O | Memory & leaks | Payload & bundle | Interleaving & partial-failure]
-- **Impact:** [Critical | High | Medium | Low]
-- **Location:** `path/to/primary-file.ext:line`
-- **Evidence:** [A repro command from Step 0 (or a quoted code path) and a
-  `measured` or `estimated` tag — e.g. "`measured`: `hyperfine 'npm test'` →
-  regressed 8.1s → 11.4s (+40%) vs perf-baseline.json"]
-- **Current State:** [Technical explanation of where and why the bottleneck or
-  race occurs]
-- **Recommendation & Rationale:** [Specific optimization/fix tactic and the
-  expected gain or the interleaving it closes]
-- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. a benchmark below the target threshold, a re-run of this lens showing the baseline no longer regressed, or a test exercising the losing interleaving]
-- **Agent Prompt:**
-  `[A copy-pasteable, highly specific prompt to execute this fix independently]`
+```markdown
+# Performance Audit Report
 
 ## Low-Hanging Fruit
 
 - [List 3 quick changes that provide immediate performance gains.]
 ```
-
-## Constraint
-
-This is a **read-only** audit **with respect to source**: it does not edit,
-create, or delete application code, dependencies, or configuration. It **does**
-run non-mutating measurements (Step 0) and writes exactly two artifacts — the
-report and `perf-baseline.json`. Note: this lens supersedes the retired
-`audit-lighthouse` lens by folding its measured Core-Web-Vitals material (the
-per-route score baseline and median-of-3 protocol) into the web branch of the
-payload/bundle dimension.
-
-## Self-cross-check (mandatory — filter false positives before you finalize)
-
-Before you write the report artifact from the previous step, run the shared
-adversarial self-cross-check over your Detailed Findings — see
-[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
-per-finding evidence bar, the exclusion list, and the final re-open-and-drop
-pass whose `kept <k> / dropped <d>` counts you record in the Executive
-Summary, so the sequential single-pass path filters unverified findings just as
-the orchestrated path's adversarial reviewer does. The **interleaving**
-dimension leans on this pass hardest: drop every claimed race that lacks a
-concrete losing interleaving over a repo-observable shared-state path.

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

@@ -4,41 +4,32 @@ description: Audit logs, telemetry, and persistence paths for PII leakage and re
 
 # Privacy and PII Data Audit
 
-## Role
+You are a Data Privacy Officer & Security Engineer finding accidental logging,
+insecure storage, or unnecessary collection of PII, and checking GDPR/CCPA
+compliance. The shared lens machinery — read-only constraint, scope
+interpretation, report envelope + finding-block skeleton, severity scale,
+self-cross-check, and execution strategy — lives in
+[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
+`{{auditOutputDir}}/audit-privacy-results.md`. This lens labels the severity
+axis **Impact** and uses dimension values `Leaky Log | Insecure Storage | Data
+Over-collection`; its report adds a **Privacy Scorecard** section (Data
+Encryption / Logging Safety / Minimization: Pass/Fail/Partial).
 
-Data Privacy Officer & Security Engineer
+## Scope
 
-## Context & Objective
-
-You are conducting a privacy audit to identify potential mishandling of
-Personally Identifiable Information (PII) and ensure compliance with data
-protection standards (GDPR, CCPA). Your goal is to find accidental logging,
-insecure storage, or unnecessary collection of sensitive data.
-
-## Scope (Story / plan-run mode)
-
-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
-before this section existed.
+Interpret this lens's change-set fence per the core's Scope interpretation:
 
 ```text
 {{changedFiles}}
 ```
 
-- If the block above contains a newline-delimited list of file paths,
-  restrict your analysis to those files (and their direct dependencies
-  when the lens explicitly calls for cross-file reasoning).
-- If the block above renders as the literal string `{{changedFiles}}`
-  (i.e. no substitution was supplied), ignore this section entirely and
-  proceed with the full codebase-wide scan defined in the remaining
-  steps.
+## Execution strategy
 
-## Step 1: Sink-First Detection
+Run this lens as a single `subagent_type: auditor` dispatch returning the report
+path + Executive Summary; sequential inline execution is the fallback (see the
+core's Execution strategy).
 
-> Apply [`helpers/parallel-tooling.md`](helpers/parallel-tooling.md) when batching the scan below — independent reads belong in one turn, long shells run via `run_in_background` + `Monitor`.
+## Step 1: Sink-First Detection
 
 A PII leak is a **source → sink** flow: sensitive data reaching an egress point.
 Enumerate the **sinks** first, then trace which ones receive PII. Report only
@@ -86,57 +77,3 @@ Evaluate the codebase against these privacy pillars:
    in plain text?
 5. **Consent & Retention:** Check for logic related to data deletion (Right to
    be Forgotten) and consent management.
-
-## Step 3: Output Requirements
-
-Generate and save a highly structured Markdown audit report to
-`{{auditOutputDir}}/audit-privacy-results.md`, using the exact template below.
-
-> Grade every finding's severity on the shared
-> [`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md).
-
-```markdown
-# Privacy & PII Audit Report
-
-## Executive Summary
-
-[Overview of the privacy posture and critical risks identified.]
-
-## Privacy Scorecard
-
-- **Data Encryption:** [Pass/Fail/Partial]
-- **Logging Safety:** [Pass/Fail/Partial]
-- **Minimization:** [Pass/Fail/Partial]
-
-## Detailed Findings
-
-[For every gap identified, use the following strict structure. Lead each title
-with the primary file the finding lives in:]
-
-### `path/to/primary-file.ext` — [Short title of the issue]
-
-- **Dimension:** [Leaky Log | Insecure Storage | Data Over-collection]
-- **Impact:** [Critical | High | Medium | Low]
-- **Location:** `path/to/primary-file.ext:line`
-- **Current State:** [The specific file/line/module and why it is problematic]
-- **Recommendation & Rationale:** [How to remediate and why it's necessary for
-  compliance]
-- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. a grep for the leaky log that now returns empty, or a re-run of this lens]
-- **Agent Prompt:**
-  `[A copy-pasteable, highly specific prompt to execute this remediation independently]`
-```
-
-## Constraint
-
-This is a **read-only** audit. Do not modify any code. Focus on identifying
-risks and providing clear remediation steps.
-
-## Self-cross-check (mandatory — filter false positives before you finalize)
-
-Before you write the report artifact from the previous step, run the shared
-adversarial self-cross-check over your Detailed Findings — see
-[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
-per-finding evidence bar, the exclusion list, and the final re-open-and-drop
-pass whose `kept <k> / dropped <d>` counts you record in the Executive
-Summary, so the sequential single-pass path filters unverified findings just as
-the orchestrated path's adversarial reviewer does.

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

@@ -4,55 +4,31 @@ description: Audit test coverage gaps, flaky tests, missing assertions, and test
 
 # Testing & Quality Assurance Audit
 
-## Role
-
-Principal SDET (Software Development Engineer in Test) & Quality Architect
-
-## Context & Objective
-
-You are performing a comprehensive, read-only audit of this repository's testing
-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 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
-established standard: Software Engineers (SWEs) must provide comprehensive unit
-and integration test coverage alongside their feature implementations. The QA
-Engineering function focuses on End-to-End (E2E) testing, complex system
-integrations, and test environment stability.
-
-## Scope (Story / plan-run mode)
-
-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
-before this section existed.
+You are a Principal SDET & Quality Architect auditing the repository's testing
+infrastructure, coverage, flaky tests, mocking strategy, and test-pyramid
+balance — and, in Story-scoped mode, evaluating the implemented tests against
+the Story under audit. The shared lens machinery — read-only constraint, scope
+interpretation, report envelope + finding-block skeleton, severity scale,
+self-cross-check, and execution strategy — lives in
+[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
+`{{auditOutputDir}}/audit-quality-results.md`. Each finding carries a
+**Category:** (`Flakiness | Coverage | Performance | Mocking | Test Plans`); the
+report adds a **Test Strategy Assessment** table (Unit / Integration / E2E /
+Test Plans: Healthy / Needs Work / Missing).
+
+## Scope
+
+Interpret this lens's change-set fence per the core's Scope interpretation:
 
 ```text
 {{changedFiles}}
 ```
 
-- If the block above contains a newline-delimited list of file paths,
-  restrict your analysis to those files (and their direct dependencies
-  when the lens explicitly calls for cross-file reasoning).
-- If the block above renders as the literal string `{{changedFiles}}`
-  (i.e. no substitution was supplied), ignore this section entirely and
-  proceed with the full codebase-wide scan defined in the remaining
-  steps.
+## Execution strategy
 
-## Execution strategy (dual-path)
-
-This lens runs along one of two execution paths (orchestrated dynamic-workflow
-or sequential single-pass). Both emit the **identical** Step 3 report contract;
-downstream consumers (`audit-to-stories`) are agnostic to which path produced
-it. See [`helpers/audit-dual-path.md`](helpers/audit-dual-path.md) for strategy
-selection, the forcing flags, and the read-only guarantee — read `audit-<lens>`
-there as this lens's name.
+Run this lens as a single `subagent_type: auditor` dispatch returning the report
+path + Executive Summary; sequential inline execution is the fallback (see the
+core's Execution strategy).
 
 ## Step 0 - Mode split + tool-first artifact read (mandatory)
 
@@ -60,13 +36,13 @@ there as this lens's name.
 do not share a Step 0 — a codebase-wide run must not try to read a Story it was
 never given.
 
-- **Story-scoped mode** (the `## Scope` block above is populated with a change
-  set): read the Story under audit — its `## Goal`, inline `acceptance[]` /
+- **Story-scoped mode** (the change-set fence is populated with a change set):
+  read the Story under audit — its `## Goal`, inline `acceptance[]` /
   `verify[]`, and folded `## Spec` — to identify the target features, and scope
   the audit to the change set and its direct dependencies.
-- **Codebase-wide mode** (the `## Scope` block renders the literal
-  `{{changedFiles}}` token): there is **no Story** — do not look for one. Audit
-  the whole test surface, ranked (below).
+- **Codebase-wide mode** (the fence renders the literal `{{changedFiles}}`
+  token): there is **no Story** — do not look for one. Audit the whole test
+  surface, ranked (below).
 
 **Read the committed test-quality artifacts as evidence** (both modes). This
 lens grounds every coverage/quality claim in the metrics the delivery gates
@@ -96,8 +72,6 @@ the Constraint) — it is not "running the suite".
 
 ## Step 1: Context Gathering (Read-Only Scan)
 
-> Apply [`helpers/parallel-tooling.md`](helpers/parallel-tooling.md) when batching the scan below — independent reads belong in one turn, long shells run via `run_in_background` + `Monitor`.
-
 Before generating the report, silently scan the workspace for testing-related
 files. Pay special attention to:
 
@@ -134,22 +108,23 @@ Evaluate the gathered context against the following test quality dimensions:
    Verify that the implementation found in the codebase correctly matches the
    architectural requirements and highlight any inconsistencies or gaps.
 
-## Step 3: Output Requirements
+## Constraint (lens-specific carve-out)
+
+Do NOT **run** the test suite (do not invoke `npm test`, a coverage run, or a
+mutation run — those mutate state and cost minutes). Reading the **committed**
+coverage / CRAP / mutation artifacts under `baselines/` is explicitly permitted
+and required (Step 0): citing an already-computed metric is read-only analysis,
+not a suite run.
 
-Generate and save a highly structured Markdown audit report to
-`{{auditOutputDir}}/audit-quality-results.md`, using the exact template below.
+## Report additions
 
-> Grade every finding's severity on the shared
-> [`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md).
+Beyond the shared skeleton (Executive Summary + Detailed Findings from the
+core), this lens's report carries its own title and a Test Strategy Assessment
+table:
 
 ```markdown
 # Testing & Quality Assurance Audit
 
-## Executive Summary
-
-[Provide a brief overview of the current test suite health, highlighting the
-primary vulnerabilities, coverage gaps, and areas causing developer friction.]
-
 ## Test Strategy Assessment
 
 | Layer               | Status                           | Notes          |
@@ -158,43 +133,4 @@ primary vulnerabilities, coverage gaps, and areas causing developer friction.]
 | Integration Testing | [Healthy / Needs Work / Missing] | [Brief reason] |
 | E2E Testing         | [Healthy / Needs Work / Missing] | [Brief reason] |
 | Test Plans          | [Healthy / Needs Work / Missing] | [Brief reason] |
-
-## Detailed Findings
-
-[For every gap identified, use the following strict structure. Lead each title
-with the primary file the finding lives in:]
-
-### `path/to/primary-file.ext` — [Short title of the issue]
-
-- **Category:** [Flakiness | Coverage | Performance | Mocking | Test Plans]
-- **Impact:** [Critical | High | Medium | Low]
-- **Location:** `path/to/primary-file.ext:line`
-- **Current State:** [How the tests are currently written and why it's
-  problematic]
-- **Recommendation & Rationale:** [The specific testing pattern or refactor
-  strategy to fix the issue]
-- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. the new test failing before / passing after the fix, a coverage re-check, or a re-run of this lens]
-- **Agent Prompt:**
-  `[A copy-pasteable, highly specific prompt to execute this fix independently]`
 ```
-
----
-
-## Constraint
-
-Do NOT execute any code modifications, edit files, create branches, or **run**
-the test suite (do not invoke `npm test`, a coverage run, or a mutation run —
-those mutate state and cost minutes). Reading the **committed** coverage / CRAP
-/ mutation artifacts under `baselines/` is explicitly permitted and required
-(Step 0): citing an already-computed metric is read-only analysis, not a suite
-run. Output the report and stop.
-
-## Self-cross-check (mandatory — filter false positives before you finalize)
-
-Before you write the report artifact from the previous step, run the shared
-adversarial self-cross-check over your Detailed Findings — see
-[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
-per-finding evidence bar, the exclusion list, and the final re-open-and-drop
-pass whose `kept <k> / dropped <d>` counts you record in the Executive
-Summary, so the sequential single-pass path filters unverified findings just as
-the orchestrated path's adversarial reviewer does.

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

@@ -5,45 +5,30 @@ command: false
 
 # Security & Vulnerability Audit
 
-## Role
+You are a Cybersecurity Architect & Penetration Tester conducting a
+comprehensive security review (OWASP Top 10, insecure configs, attack vectors).
+The shared lens machinery — read-only constraint, scope interpretation, report
+envelope + finding-block skeleton, severity scale, self-cross-check, and
+execution strategy — lives in
+[`helpers/audit-lens-core.md`](helpers/audit-lens-core.md). Write the report to
+`{{auditOutputDir}}/audit-security-results.md`. Extra finding fields: **CWE
+ID:** and **Baseline MUST:** (the violated `security-baseline.md` MUST). The
+report adds a **Defensive Recommendations** section (3–5 headers/configs/
+libraries to harden the app).
 
-Cybersecurity Architect & Penetration Tester
+## Scope
 
-## Context & Objective
-
-Conduct a comprehensive security review of the codebase. Your goal is to
-identify common vulnerabilities (OWASP Top 10), insecure configurations, and
-potential attack vectors.
-
-## Scope (Story / plan-run mode)
-
-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
-before this section existed.
+Interpret this lens's change-set fence per the core's Scope interpretation:
 
 ```text
 {{changedFiles}}
 ```
 
-- If the block above contains a newline-delimited list of file paths,
-  restrict your analysis to those files (and their direct dependencies
-  when the lens explicitly calls for cross-file reasoning).
-- If the block above renders as the literal string `{{changedFiles}}`
-  (i.e. no substitution was supplied), ignore this section entirely and
-  proceed with the full codebase-wide scan defined in the remaining
-  steps.
-
-## Execution strategy (dual-path)
+## Execution strategy
 
-This lens runs along one of two execution paths (orchestrated dynamic-workflow
-or sequential single-pass). Both emit the **identical** Step 3 report contract;
-downstream consumers (`audit-to-stories`) are agnostic to which path produced
-it. See [`helpers/audit-dual-path.md`](helpers/audit-dual-path.md) for strategy
-selection, the forcing flags, and the read-only guarantee — read `audit-<lens>`
-there as this lens's name.
+Run this lens as a single `subagent_type: auditor` dispatch returning the report
+path + Executive Summary; sequential inline execution is the fallback (see the
+core's Execution strategy).
 
 ## Rubric — `rules/security-baseline.md` is the contract
 
@@ -59,8 +44,6 @@ baseline is silent — is out of scope for this lens.
 
 ## Step 1: Detection Battery (Tool-First, Read-Only)
 
-> Apply [`helpers/parallel-tooling.md`](helpers/parallel-tooling.md) when batching the scan below — independent reads belong in one turn, long shells run via `run_in_background` + `Monitor`.
-
 Ground every finding in tool output, not vibes. Run the ladder below; each rung
 is **presence-gated** — when a scanner is absent, fall through to the next rung
 and note the missing tool as a `Security Misconfiguration` finding (recommend
@@ -122,58 +105,17 @@ CWE where one applies):
 5. **Vulnerable Components:** Are outdated libraries introducing risks? —
    _Dependency Hygiene_.
 
-## Step 3: Output Requirements
-
-Generate and save a highly structured Markdown audit report to
-`{{auditOutputDir}}/audit-security-results.md`, using the exact template below.
+## Report additions
 
-> Grade every finding's severity on the shared
-> [`Critical | High | Medium | Low` scale](helpers/audit-severity-scale.md).
+Beyond the shared skeleton (Executive Summary + Detailed Findings from the
+core), this lens's report carries its own title and a Defensive Recommendations
+section, and each finding adds the CWE ID / Baseline MUST fields:
 
 ```markdown
 # Security Audit Report
 
-## Executive Summary
-
-[Overview of the risk profile (Critical/High/Medium/Low) and overarching
-security posture.]
-
-## Detailed Findings
-
-[For every vulnerability identified, use the following strict structure. Lead
-each title with the primary file the vulnerability lives in:]
-
-### `path/to/primary-file.ext` — [Short title of the vulnerability]
-
-- **Dimension:** [e.g., Injection | Broken Access Control]
-- **Severity:** [Critical | High | Medium | Low]
-- **CWE ID:** [e.g., CWE-89 for SQL Injection]
-- **Baseline MUST:** [the violated `security-baseline.md` MUST — e.g. "Secrets Management: fallback secrets MUST NOT be committed"]
-- **Location:** `path/to/primary-file.ext:line`
-- **Current State:** [Technical explanation of the flaw and its location]
-- **Recommendation & Rationale:** [Step-by-step fix and defensive hardening
-  strategy]
-- **Acceptance signal:** [the command or observable that proves this finding is remediated — e.g. the exploit no longer reproducing, an added regression test, or a re-run of this lens]
-- **Agent Prompt:**
-  `[A copy-pasteable, highly specific prompt to execute this remediation independently]`
-
 ## Defensive Recommendations
 
 - [List 3-5 security headers, configurations, or libraries to implement to
   harden the app.]
 ```
-
-## Constraint
-
-This is a **read-only** audit. Your priority is accuracy and clear impact
-assessment. Do not attempt to exploit the system or modify code.
-
-## Self-cross-check (mandatory — filter false positives before you finalize)
-
-Before you write the report artifact from the previous step, run the shared
-adversarial self-cross-check over your Detailed Findings — see
-[`helpers/audit-self-check.md`](helpers/audit-self-check.md). It defines the
-per-finding evidence bar, the exclusion list, and the final re-open-and-drop
-pass whose `kept <k> / dropped <d>` counts you record in the Executive
-Summary, so the sequential single-pass path filters unverified findings just as
-the orchestrated path's adversarial reviewer does.