mandrel 1.57.0

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

@@ -0,0 +1,191 @@
+---
+description: Audit test coverage gaps, flaky tests, missing assertions, and test-pyramid balance; recommend a remediation batch.
+---
+
+# 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 active Epic 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 (Epic mode)
+
+When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+following block is populated with the Epic's 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.
+
+```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)
+
+This lens runs along one of two execution paths. Both emit the **identical**
+report contract (Step 3); downstream consumers (`/epic-deliver` Phase 4
+epic-audit, `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
+  available, the saved project workflow
+  `.claude/workflows/audit-quality.workflow.js` fans the dimensions below
+  out as parallel read-only subagents, runs an **adversarial cross-check**
+  stage (an independent agent reviews each dimension's findings and drops
+  false positives before they enter the report), then synthesises the Step 3
+  report. The orchestrator derives its per-dimension prompts from *this*
+  markdown at run time — the lens stays the single source of truth; the
+  script does not fork a second copy of the spec.
+- **Sequential (single-pass) path.** When dynamic workflows are unavailable,
+  follow Steps 1–3 below turn-by-turn exactly as before. This is the default
+  fallback and changes nothing about the existing behaviour.
+
+**Strategy selection** is computed by
+[`lib/dynamic-workflow/capability.js`](../scripts/lib/dynamic-workflow/capability.js)
+(`selectAuditStrategy`). The orchestrated path is chosen only when the runtime
+is Claude Code, `disableWorkflows` is not set (settings.json **or**
+`CLAUDE_CODE_DISABLE_WORKFLOWS`), and the Claude Code version meets the
+research-preview floor (`>= 2.1.154`). Any other runtime, a disabled setting,
+or an older version degrades gracefully to the sequential path.
+
+> **Capability degradation, not a contract shim.** This dual path is **not**
+> covered by the No-Shim / hard-cutover rule in
+> [`git-conventions.md`](../rules/git-conventions.md). That rule forbids
+> running two shapes of the *same contract* side by side. Here there is **one**
+> report contract; only the *execution strategy* is selected from a runtime
+> capability — the same pattern the protocol already endorses for live-docs
+> fallback in [`instructions.md` §1.C/§1.D](../instructions.md). The full
+> capability-degradation rationale lives in the
+> [`capability.js`](../scripts/lib/dynamic-workflow/capability.js) module
+> docstring; the orchestrated-run evidence and per-lens cost/precision gate
+> verdicts live in [`docs/roadmap.md`](../../docs/roadmap.md) (Part 3 —
+> Dynamic-Workflow Orchestration).
+
+**Forcing a path (for testing).** Set `MANDREL_AUDIT_STRATEGY=sequential` to
+verify the fallback path with the feature notionally disabled, or
+`MANDREL_AUDIT_STRATEGY=orchestrated` to pin the dynamic path. To exercise the
+real disable signals instead, set `CLAUDE_CODE_DISABLE_WORKFLOWS=1` (env) or
+`disableWorkflows: true` in `.claude/settings.json` and re-run the lens — both
+degrade to the sequential path.
+
+> **Read-only on both paths.** The lens is read-only (see Constraint). The
+> orchestrated subagents run in `acceptEdits` and inherit the session tool
+> allowlist, but the workflow script grants the analysis agents only
+> read/search tools (`Read`, `Grep`, `Glob`) — no write/edit/shell-mutation
+> tools. The single write in an orchestrated run is the final report artifact.
+
+## Step 0 - Project Context
+
+1.  Read the active Epic and its child tickets to identify the current milestone
+    and target features.
+2.  Identify the target codebase paths for the audit.
+
+## 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:
+
+- Test configuration files (e.g., `jest.config.js`, `vitest.config.ts`,
+  `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.
+- Mocking and stubbing setups (e.g., `__mocks__/`, `setupTests.js`, MSW
+  handlers).
+- CI/CD workflow files to understand how and when tests are executed.
+
+## Step 2: Analysis Dimensions
+
+Evaluate the gathered context against the following test quality dimensions:
+
+1. **Coverage vs. Confidence:** Identify areas with missing tests (unit,
+   integration, or E2E) or tests that assert trivial things while missing core
+   business logic.
+2. **Test Fragility & Flakiness:** Spot patterns that lead to flaky tests, such
+   as reliance on hardcoded timeouts (`sleep`), improper handling of
+   asynchronous code, or shared mutable state between tests.
+3. **Mocking & Stubbing Strategy:** Identify over-mocked tests that test
+   implementation details rather than behavior, or missing mocks that cause
+   tests to inadvertently hit external networks/APIs.
+4. **Test Data Management:** Look for hardcoded test data, lack of proper
+   setup/teardown (`beforeEach`/`afterEach`), or test pollution.
+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.
+   Verify that the implementation found in the codebase correctly matches the
+   architectural requirements and highlight any inconsistencies or gaps.
+
+## Step 3: Output Requirements
+
+Generate and save a highly structured Markdown audit report to
+`{{auditOutputDir}}/audit-quality-results.md`, using the exact template below.
+
+```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          |
+| ------------------- | -------------------------------- | -------------- |
+| Unit Testing        | [Healthy / Needs Work / Missing] | [Brief reason] |
+| 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:]
+
+### [Short Title of the Issue]
+
+- **Category:** [Flakiness | Coverage | Performance | Mocking | Test Plans]
+- **Impact:** [High | Medium | Low]
+- **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]
+- **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. This is strictly a read-only analysis. Output the report and stop.

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

@@ -0,0 +1,156 @@
+---
+description: Audit dependency CVEs, input-validation gaps, secrets handling, and auth boundaries; emit a structured High/Medium/Low findings report.
+---
+
+# Security & Vulnerability Audit
+
+## Role
+
+Cybersecurity Architect & Penetration Tester
+
+## 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 (Epic mode)
+
+When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+following block is populated with the Epic's 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.
+
+```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)
+
+This lens runs along one of two execution paths. Both emit the **identical**
+report contract (Step 3); downstream consumers (`/epic-deliver` Phase 4
+epic-audit, `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
+  available, the saved project workflow
+  `.claude/workflows/audit-security.workflow.js` fans the dimensions below
+  out as parallel read-only subagents, runs an **adversarial cross-check**
+  stage (an independent agent reviews each dimension's findings and drops
+  false positives before they enter the report), then synthesises the Step 3
+  report. The orchestrator derives its per-dimension prompts from *this*
+  markdown at run time — the lens stays the single source of truth; the
+  script does not fork a second copy of the spec.
+- **Sequential (single-pass) path.** When dynamic workflows are unavailable,
+  follow Steps 1–3 below turn-by-turn exactly as before. This is the default
+  fallback and changes nothing about the existing behaviour.
+
+**Strategy selection** is computed by
+[`lib/dynamic-workflow/capability.js`](../scripts/lib/dynamic-workflow/capability.js)
+(`selectAuditStrategy`). The orchestrated path is chosen only when the runtime
+is Claude Code, `disableWorkflows` is not set (settings.json **or**
+`CLAUDE_CODE_DISABLE_WORKFLOWS`), and the Claude Code version meets the
+research-preview floor (`>= 2.1.154`). Any other runtime, a disabled setting,
+or an older version degrades gracefully to the sequential path.
+
+> **Capability degradation, not a contract shim.** This dual path is **not**
+> covered by the No-Shim / hard-cutover rule in
+> [`git-conventions.md`](../rules/git-conventions.md). That rule forbids
+> running two shapes of the *same contract* side by side. Here there is **one**
+> report contract; only the *execution strategy* is selected from a runtime
+> capability — the same pattern the protocol already endorses for live-docs
+> fallback in [`instructions.md` §1.C/§1.D](../instructions.md). The full
+> capability-degradation rationale lives in the
+> [`capability.js`](../scripts/lib/dynamic-workflow/capability.js) module
+> docstring; the orchestrated-run evidence and per-lens cost/precision gate
+> verdicts live in [`docs/roadmap.md`](../../docs/roadmap.md) (Part 3 —
+> Dynamic-Workflow Orchestration).
+
+**Forcing a path (for testing).** Set `MANDREL_AUDIT_STRATEGY=sequential` to
+verify the fallback path with the feature notionally disabled, or
+`MANDREL_AUDIT_STRATEGY=orchestrated` to pin the dynamic path. To exercise the
+real disable signals instead, set `CLAUDE_CODE_DISABLE_WORKFLOWS=1` (env) or
+`disableWorkflows: true` in `.claude/settings.json` and re-run the lens — both
+degrade to the sequential path.
+
+> **Read-only on both paths.** The lens is read-only (see Constraint). The
+> orchestrated subagents run in `acceptEdits` and inherit the session tool
+> allowlist, but the workflow script grants the analysis agents only
+> read/search tools (`Read`, `Grep`, `Glob`) — no write/edit/shell-mutation
+> tools. The single write in an orchestrated run is the final report artifact.
+
+## Step 1: Vulnerability Surface Analysis
+
+> 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`.
+
+Scan the codebase for:
+
+- **Input Validation:** Check where user input enters the system (API endpoints,
+  forms). Is it sanitized/validated?
+- **Injection Risks:** Search for raw SQL queries, `dangerouslySetInnerHTML`,
+  `eval()`, or command execution logic.
+- **Authentication/Authorization:** Review how sessions/tokens are handled. Are
+  there missing checks on sensitive routes?
+- **Dependency Security:** Check `package.json` for known-vulnerable versions of
+  libraries.
+- **Secret Management:** Scan for `.env` files in git, hardcoded keys, or
+  exposed credentials.
+
+## Step 2: Evaluation Dimensions
+
+1. **Injection:** SQL, NoSQL, OS Command, and Cross-Site Scripting (XSS).
+2. **Broken Access Control:** Can a user access data they don't own?
+3. **Cryptographic Failures:** Is sensitive data (passwords, PII) hashed or
+   encrypted using modern standards?
+4. **Security Misconfiguration:** Are there default passwords, verbose error
+   messages in production, or insecure headers?
+5. **Vulnerable Components:** Are outdated libraries introducing risks?
+
+## Step 3: Output Requirements
+
+Generate and save a highly structured Markdown audit report to
+`{{auditOutputDir}}/audit-security-results.md`, using the exact template below.
+
+```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:]
+
+### [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]
+- **Current State:** [Technical explanation of the flaw and its location]
+- **Recommendation & Rationale:** [Step-by-step fix and defensive hardening
+  strategy]
+- **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.

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

@@ -0,0 +1,118 @@
+---
+description: Audit SEO fundamentals and Generative Engine Optimization signals (meta, structured data, crawlability); only relevant for web targets.
+---
+
+# SEO & Generative Engine Optimization Audit
+
+## Role
+
+Senior Technical SEO and Generative Engine Optimization (GEO) Specialist. You
+are an expert in semantic HTML, JSON-LD Schema markup, Core Web Vitals, and
+optimizing content structure for both traditional search engines (Google, Bing)
+and Large Language Models (ChatGPT, Perplexity, Gemini).
+
+## Context & Objective
+
+You are performing a comprehensive, read-only SEO and GEO audit of this
+codebase. Your goal is to surface structural, semantic, and content-level
+improvements that will increase discoverability in both traditional search
+indexes and AI-powered answer engines — without making any immediate changes.
+
+## Scope (Epic mode)
+
+When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+following block is populated with the Epic's 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.
+
+```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.
+
+## 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 codebase. Pay special attention
+to:
+
+- Page `<head>` elements: `<title>`, `<meta name="description">`, canonical
+  tags, Open Graph, and Twitter Card tags.
+- Semantic HTML structure: heading hierarchy (`h1`–`h6`), landmark elements
+  (`<main>`, `<nav>`, `<article>`, `<section>`), and `<img alt>` attributes.
+- Structured data: JSON-LD blocks and Schema.org types in use.
+- Internal linking patterns and URL structure.
+- Content layout: answer-friendly formatting (FAQs, numbered steps, definition
+  lists) vs. dense prose.
+
+## Step 2: Analysis Dimensions
+
+Evaluate the gathered context against the following dimensions:
+
+1. **Traditional SEO:** Meta tags, semantic structure, accessibility, internal
+   linking logic, and keyword placement.
+2. **AIO & GEO (Answer Engine Optimization):** Entity clarity, concise answer
+   formatting, structured data (Schema.org), and token efficiency for LLM
+   retrieval.
+3. **Core Web Vitals:** CLS, LCP, and INP risk factors visible from the codebase
+   (e.g., unsized images, render-blocking resources, large layout shifts).
+4. **Crawlability:** `robots.txt`, `sitemap.xml`, and any `noindex` directives
+   that may unintentionally block pages.
+
+## Step 3: Output Requirements
+
+Generate and save a highly structured Markdown audit report to
+`{{auditOutputDir}}/audit-seo-results.md`, using the exact template below.
+
+```markdown
+# SEO & GEO Audit Report
+
+## Executive Summary
+
+[A high-level view of the site's current optimization health, highlighting the
+primary gaps and the most impactful opportunities.]
+
+## Detailed Audit Table
+
+| Issue               | Impact           | Category   | Suggested Fix |
+| ------------------- | ---------------- | ---------- | ------------- |
+| [Issue description] | High / Med / Low | SEO or GEO | [Brief fix]   |
+
+## GEO-Specific Recommendations
+
+[Specific advice on how to make this codebase more readable for AI models —
+e.g., adding specific Schema types, flattening nested DOM structures, or
+reformatting key content as FAQ blocks.]
+
+## Detailed Findings
+
+[For any issue requiring deeper explanation, use the following strict
+structure:]
+
+### [Short Title of the Issue]
+
+- **Category:** [SEO | GEO | Core Web Vitals | Crawlability]
+- **Impact:** [High | Medium | Low]
+- **Current State:** [What exists in the codebase and why it's suboptimal]
+- **Recommendation & Rationale:** [The specific fix and how it improves
+  discoverability or LLM retrieval]
+- **Agent Prompt:**
+  `[A copy-pasteable, highly specific prompt to execute this fix independently]`
+```
+
+---
+
+## Constraint
+
+Do NOT rewrite or modify any files. Do NOT implement the changes. Focus strictly
+on analyzing the code. Output the report and stop.

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

@@ -0,0 +1,139 @@
+---
+description: "Audit production-readiness for a release candidate: SLOs, observability, runbooks, error budgets, and rollback paths."
+---
+
+# Production Release Candidate Audit
+
+## Role
+
+Senior Site Reliability Engineer (SRE) & Lead Developer
+
+## Context & Objective
+
+You are conducting a rigorous, read-only final code audit for a production
+release candidate. Your goal is to surface critical risks across configuration
+integrity, security, observability, and code quality — providing a prioritized,
+actionable report that can be handed off for remediation before deployment.
+
+## Scope (Epic mode)
+
+When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+following block is populated with the Epic's 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.
+
+```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.
+
+## 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. Pay special attention
+to:
+
+- Application configuration files (e.g., `site.config.ts`, `.env.example`,
+  `wrangler.toml`, `app.config.ts`).
+- Source files for hardcoded values (strings resembling secrets, IDs, or
+  environment-specific data).
+- Error handling patterns across services, API routes, and background jobs.
+- `package.json` for unused, deprecated, or overly heavy dependencies.
+- Any debugging artifacts likely introduced during development.
+
+## Step 2: Analysis Dimensions
+
+Evaluate the gathered context against the following production-readiness
+criteria:
+
+### 1. Configuration Architecture
+
+- **Config Integrity:** Audit the application config to ensure it defines a
+  clear schema for all variable/environment-specific data.
+- **Hardcoding Scan:** Scan components, utils, and services for any hardcoded
+  values that should come from config or environment variables (e.g., API URLs,
+  feature flags, region/locale data, identifiers).
+- **Fallback Logic:** Verify how the app behaves if a required config value is
+  missing — does it fail gracefully or crash silently?
+
+### 2. Security & Secrets Management
+
+- **Secret Leaks:** Check for hardcoded API keys, tokens, or credentials
+  committed to source. Ensure all secrets use environment variables.
+- **Input Sanitization:** Identify potential XSS or injection vectors,
+  particularly where user input or URL parameters are reflected in the DOM or
+  database.
+- **Dependency Risks:** Flag obviously deprecated, unmaintained, or unused heavy
+  dependencies in `package.json`.
+
+### 3. Error Handling & Observability
+
+- **Console Hygiene:** Identify debugging artifacts (`console.log`, `debugger`,
+  commented-out test code) that must be removed before release.
+- **Error Swallowing:** Flag empty `catch` blocks or places where errors are
+  silently ignored rather than logged or re-thrown.
+- **Boundary Handling:** Ensure the app handles unexpected or invalid inputs
+  (e.g., bad URL params, missing DB records) with appropriate error responses.
+
+### 4. Code Quality & Performance
+
+- **Dead Code:** Identify unused variables, imports, functions, or unreachable
+  code blocks.
+- **Complexity:** Highlight logic with high cyclomatic complexity (deeply nested
+  `if/else`, massive switch statements) that violates DRY principles.
+- **Asset Loading:** Flag synchronous heavy operations or unoptimized asset
+  loading patterns that could hurt Core Web Vitals or API response times.
+
+## Step 3: Output Requirements
+
+Generate and save a highly structured Markdown audit report to
+`{{auditOutputDir}}/audit-sre-results.md`, using the exact template below.
+
+```markdown
+# Production Release Candidate Audit
+
+## Executive Summary
+
+[A brief overview of the release candidate's health. Highlight the most critical
+risks that must be resolved before deployment.]
+
+## Findings
+
+[Group findings by the categories below. Use this structure for each item:]
+
+### [Short Title of the Issue]
+
+- **Category:** [Configuration | Security | Observability | Code Quality]
+- **Severity:** [High | Medium | Low]
+- **Location:** [`path/to/file.ts` or relevant area]
+- **Current State:** [What exists and why it's a risk]
+- **Recommendation:** [The specific fix and rationale]
+- **Agent Prompt:**
+  `[A copy-pasteable, highly specific prompt to execute this fix independently]`
+
+## Release Readiness Checklist
+
+| Category                | Status                     |
+| ----------------------- | -------------------------- |
+| Configuration Integrity | ✅ Clear / ⚠️ Issues Found |
+| Security & Secrets      | ✅ Clear / ⚠️ Issues Found |
+| Error Handling          | ✅ Clear / ⚠️ Issues Found |
+| Code Quality            | ✅ Clear / ⚠️ Issues Found |
+```
+
+---
+
+## Constraint
+
+Do NOT generate code fixes, edit files, or create branches. This is strictly a
+read-only analysis. Output the report and stop.