@joshski/dust 0.1.93 → 0.1.95

package/dist/audits.js

@@ -62,6 +62,94 @@ function dedent(strings, ...values) {
 `).trim();
 }
 
+// lib/audits/checks-audit.ts
+function checksAuditTemplate() {
+  return dedent`
+    # Checks Audit
+
+    Analyze the project's technology ecosystem and suggest appropriate checks for \`.dust/config/settings.json\`.
+
+    ## Scope
+
+    This audit examines the project structure to identify:
+
+    1. **Tech stack detection** - Identify languages, frameworks, and tools based on config files
+    2. **Existing checks review** - Read \`.dust/config/settings.json\` to understand current coverage
+    3. **CI configuration analysis** - Parse CI configs to find checks that run in CI but not locally
+    4. **Gap identification** - Compare configured checks against what's appropriate for the detected stack
+
+    ## Check Categories to Evaluate
+
+    For each detected ecosystem, consider these categories:
+
+    ### JavaScript/TypeScript
+    - Linting (ESLint, oxlint, Biome)
+    - Formatting (Prettier, oxfmt, Biome)
+    - Type checking (tsc)
+    - Build verification
+    - Unit tests (Vitest, Jest)
+    - Unused code detection (Knip)
+
+    ### Python
+    - Linting (Ruff, Pylint, Flake8)
+    - Formatting (Ruff, Black)
+    - Type checking (mypy, pyright)
+    - Unit tests (pytest)
+
+    ### Go
+    - Linting (golangci-lint)
+    - Formatting (gofmt)
+    - Build verification
+    - Unit tests
+    - Vetting (go vet)
+
+    ### Rust
+    - Linting (Clippy)
+    - Formatting (rustfmt)
+    - Build verification
+    - Unit tests
+
+    ## Analysis Steps
+
+    1. List all config files in the repository root to detect tech stack
+    2. Read \`.dust/config/settings.json\` to identify configured checks
+    3. Search for CI configuration files and parse them for check commands
+    4. For each missing check category, create an idea file proposing it
+    5. If CI has checks not in dust config, note the discrepancy
+
+    ## Output
+
+    Create separate idea files for each missing check category. Each idea should include:
+    - The detected stack indicators
+    - The suggested check command
+    - Alternative tool options
+    - Configuration snippet for settings.json
+
+    When multiple ecosystems are detected, create separate ideas for each ecosystem's checks.
+
+    ## Principles
+
+    - [Batteries Included](../principles/batteries-included.md) - Dust should provide everything required for an agent to be productive
+    - [Easy Adoption](../principles/easy-adoption.md) - Help users configure checks without deep research into each tool
+    - [Stop the Line](../principles/stop-the-line.md) - Comprehensive checks catch problems at source
+    - [Lint Everything](../principles/lint-everything.md) - Static analysis should cover as much as possible
+    - [Comprehensive Test Coverage](../principles/comprehensive-test-coverage.md) - Tests are critical for agent confidence
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Identified all tech stack indicators in the project
+    - [ ] Reviewed existing checks in settings.json
+    - [ ] Parsed CI configuration files for check commands
+    - [ ] Created ideas for each missing check category
+    - [ ] For multi-ecosystem projects, created separate ideas per ecosystem
+    - [ ] Each idea includes suggested command and alternatives
+  `;
+}
+
 // lib/audits/stock-audits.ts
 var ideasHint = "Review existing ideas in `./.dust/ideas/` to understand what has been proposed or considered historically, then create new idea files in `./.dust/ideas/` for any issues you identify, avoiding duplication.";
 function dataAccessReview() {
@@ -113,13 +201,13 @@ function dataAccessReview() {
 
     ## Definition of Done
 
-    - [ ] Searched for N+1 query patterns (loops with data access)
-    - [ ] Reviewed database schemas for missing indexes (if applicable)
-    - [ ] Identified over-fetching or under-fetching patterns
-    - [ ] Found repeated lookups that could be cached
-    - [ ] Checked for sequential operations that could be batched
-    - [ ] Verified connection/resource cleanup is handled properly
-    - [ ] Proposed ideas for any data access improvements identified
+    - Searched for N+1 query patterns (loops with data access)
+    - Reviewed database schemas for missing indexes (if applicable)
+    - Identified over-fetching or under-fetching patterns
+    - Found repeated lookups that could be cached
+    - Checked for sequential operations that could be batched
+    - Verified connection/resource cleanup is handled properly
+    - Proposed ideas for any data access improvements identified
   `;
 }
 function coverageExclusions() {
@@ -153,11 +241,11 @@ function coverageExclusions() {
 
     ## Definition of Done
 
-    - [ ] Identified all coverage exclusions in the project
-    - [ ] Documented the reason each exclusion exists
-    - [ ] Evaluated whether each exclusion is still necessary
-    - [ ] Identified exclusions that could be removed through decoupling
-    - [ ] Proposed ideas for refactoring where feasible
+    - Identified all coverage exclusions in the project
+    - Documented the reason each exclusion exists
+    - Evaluated whether each exclusion is still necessary
+    - Identified exclusions that could be removed through decoupling
+    - Proposed ideas for refactoring where feasible
   `;
 }
 function componentReuse() {
@@ -189,11 +277,11 @@ function componentReuse() {
 
     ## Definition of Done
 
-    - [ ] Searched for repeated patterns across the codebase
-    - [ ] Identified copy-pasted or near-duplicate code
-    - [ ] Evaluated each case for whether extraction would be beneficial
-    - [ ] Considered whether similar code serves different purposes that may evolve independently
-    - [ ] Proposed ideas only for extractions where duplication is truly about the same concept
+    - Searched for repeated patterns across the codebase
+    - Identified copy-pasted or near-duplicate code
+    - Evaluated each case for whether extraction would be beneficial
+    - Considered whether similar code serves different purposes that may evolve independently
+    - Proposed ideas only for extractions where duplication is truly about the same concept
   `;
 }
 function agentDeveloperExperience() {
@@ -224,11 +312,182 @@ function agentDeveloperExperience() {
 
     ## Definition of Done
 
-    - [ ] Reviewed file sizes and organization for context window fit
-    - [ ] Verified test coverage is sufficient for agent verification
-    - [ ] Measured feedback loop speed (time from change to check result)
-    - [ ] Confirmed debugging tools and structured logging are in place
-    - [ ] Proposed ideas for any improvements identified
+    - Reviewed file sizes and organization for context window fit
+    - Verified test coverage is sufficient for agent verification
+    - Measured feedback loop speed (time from change to check result)
+    - Confirmed debugging tools and structured logging are in place
+    - Proposed ideas for any improvements identified
+  `;
+}
+function agentInstructionQuality() {
+  return dedent`
+    # Agent Instruction Quality
+
+    Review agent instruction files (AGENTS.md, CLAUDE.md) for clarity and completeness.
+
+    ${ideasHint}
+
+    ## Context
+
+    Agent instruction files directly impact agent effectiveness. Poor instructions lead to wasted context, confusion, and suboptimal decisions. This audit focuses on the instruction artifacts themselves.
+
+    ## Scope
+
+    Focus on these areas:
+
+    1. **Contradictory instructions** - Find conflicting guidance across instruction files
+    2. **Stale references** - Identify instructions that reference removed code or features
+    3. **Missing context** - Detect areas where agents frequently need information not provided
+    4. **Verbose instructions** - Flag overly long sections that waste context window space
+    5. **Linter-replaceable rules** - Identify instructions that could be enforced by linter rules instead
+
+    ## Analysis Steps
+
+    ### 1. Locate Instruction Files
+
+    Search for agent instruction files:
+    - \`CLAUDE.md\` (Claude Code instructions)
+    - \`AGENTS.md\` (general agent instructions)
+    - \`.cursorrules\` (Cursor rules)
+    - \`copilot-instructions.md\` (GitHub Copilot instructions)
+    - Any other agent-specific configuration files
+
+    ### 2. Check for Contradictory Instructions
+
+    For each instruction file:
+    1. Extract all directives, rules, and guidance statements
+    2. Compare against directives in other instruction files
+    3. Flag cases where:
+       - One file says "always do X" and another says "never do X"
+       - Instructions give conflicting guidance for the same scenario
+       - Priority or ordering conflicts exist
+
+    Example finding:
+    \`\`\`markdown
+    ### Contradiction: Commit message format
+    - **CLAUDE.md:45** says "Use conventional commits (feat:, fix:, etc.)"
+    - **AGENTS.md:23** says "Use imperative mood without prefixes"
+    - **Impact**: Agents may produce inconsistent commit messages
+    - **Suggestion**: Align both files on a single commit message convention
+    \`\`\`
+
+    ### 3. Detect Stale References
+
+    For each instruction file:
+    1. Extract references to files, functions, directories, or features
+    2. Verify each reference exists in the codebase
+    3. Flag references to:
+       - Deleted or renamed files/directories
+       - Removed functions, classes, or APIs
+       - Deprecated features or workflows
+       - Outdated tool names or commands
+
+    Example finding:
+    \`\`\`markdown
+    ### Stale reference: src/legacy/parser.ts
+    - **Location**: CLAUDE.md:78
+    - **Instruction**: "Use the parser from src/legacy/parser.ts for..."
+    - **Reality**: src/legacy/ directory was removed in commit abc123
+    - **Impact**: Agents will fail to follow this instruction
+    - **Suggestion**: Update to reference the new parser location
+    \`\`\`
+
+    ### 4. Identify Missing Context
+
+    Review instruction files for gaps:
+    1. Check if common agent tasks are covered (setup, testing, deployment)
+    2. Look for areas where instructions assume knowledge not documented
+    3. Identify patterns where agents might need guidance but none exists
+    4. Consider what questions a new agent would have that aren't answered
+
+    Signals of missing context:
+    - Instructions reference concepts without explanation
+    - Workflows have steps that require undocumented knowledge
+    - Common failure modes have no troubleshooting guidance
+
+    Example finding:
+    \`\`\`markdown
+    ### Missing context: Environment setup
+    - **Gap**: No instructions for required environment variables
+    - **Impact**: Agents may fail setup or produce incorrect configuration
+    - **Suggestion**: Add section documenting required env vars and their purpose
+    \`\`\`
+
+    ### 5. Flag Verbose Sections
+
+    Analyze instruction file sections for efficiency:
+    1. Measure section lengths (line count, word count)
+    2. Flag sections over 50 lines that could be condensed
+    3. Identify redundant explanations or excessive examples
+    4. Look for sections that repeat information found elsewhere
+
+    Verbosity signals:
+    - Multiple examples where one would suffice
+    - Lengthy explanations of concepts that could be linked
+    - Repeated disclaimers or caveats
+    - Inline documentation that duplicates code comments
+
+    Example finding:
+    \`\`\`markdown
+    ### Verbose: Testing guidelines
+    - **Location**: CLAUDE.md:120-220 (100 lines)
+    - **Issue**: Includes 15 code examples; 3 would suffice
+    - **Context cost**: ~2000 tokens that could be reclaimed
+    - **Suggestion**: Condense to key patterns, link to test files for examples
+    \`\`\`
+
+    ### 6. Find Linter-Replaceable Rules
+
+    Identify instructions that describe rules enforceable by static analysis:
+    1. Search for instructions about code formatting (spacing, quotes, semicolons)
+    2. Look for naming convention rules (camelCase, PascalCase, etc.)
+    3. Find import ordering or organization requirements
+    4. Identify type annotation requirements
+
+    For each candidate:
+    - Verify whether an ESLint, Biome, or similar rule exists
+    - Check if the rule is already configured in the project
+    - If not configured, recommend adding the linter rule
+
+    Example finding:
+    \`\`\`markdown
+    ### Linter-replaceable: Import ordering
+    - **Location**: CLAUDE.md:34
+    - **Instruction**: "Always order imports: external, then internal, then relative"
+    - **Linter rule**: \`import/order\` or \`@ianvs/prettier-plugin-sort-imports\`
+    - **Current state**: Not configured in .eslintrc
+    - **Suggestion**: Add linter rule to enforce automatically
+    \`\`\`
+
+    ## Output
+
+    For each issue found, document:
+    - **Location** - File path and section/line number
+    - **Type** - One of: contradictory, stale, missing, verbose, linter-replaceable
+    - **Impact** - How this affects agent effectiveness
+    - **Suggested improvement** - Specific fix or action
+
+    ## Principles
+
+    - [Agent Autonomy](../principles/agent-autonomy.md) - Clear instructions enable autonomous work
+    - [Context Window Efficiency](../principles/context-window-efficiency.md) - Concise instructions leave room for reasoning
+    - [Actionable Errors](../principles/actionable-errors.md) - Instructions should guide agents toward correct actions
+    - [Lint Everything](../principles/lint-everything.md) - Prefer static analysis over runtime guidance where possible
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Located all agent instruction files in the repository
+    - [ ] Reviewed for contradictory instructions across files
+    - [ ] Checked all file/code references for staleness
+    - [ ] Identified gaps where context is missing
+    - [ ] Flagged verbose sections that waste context window space
+    - [ ] Found instructions that could be replaced by linter rules
+    - [ ] Documented each issue with location, type, impact, and suggestion
+    - [ ] Created ideas for substantial instruction improvements
   `;
 }
 function deadCode() {
@@ -259,13 +518,132 @@ function deadCode() {
 
     ## Definition of Done
 
-    - [ ] Ran static analysis tools to find unused exports
-    - [ ] Identified files with no incoming imports
-    - [ ] Listed unused dependencies
-    - [ ] Reviewed commented-out code blocks
-    - [ ] Created list of code safe to remove
-    - [ ] Verified removal won't break dynamic imports or reflection
-    - [ ] Proposed ideas for any dead code worth removing
+    - Ran static analysis tools to find unused exports
+    - Identified files with no incoming imports
+    - Listed unused dependencies
+    - Reviewed commented-out code blocks
+    - Created list of code safe to remove
+    - Verified removal won't break dynamic imports or reflection
+    - Proposed ideas for any dead code worth removing
+  `;
+}
+function documentationDrift() {
+  return dedent`
+    # Documentation Drift
+
+    Review code documentation for accuracy against current implementation.
+
+    ${ideasHint}
+
+    ## Context
+
+    Code-level documentation (JSDoc, README sections, inline comments) can drift from reality over time. Outdated docs mislead agents who may trust incorrect parameter descriptions, wrong return types, or stale code examples. This audit complements the facts-verification audit by focusing on code-level documentation rather than \`.dust/facts/\`.
+
+    ## Scope
+
+    Focus on these areas:
+
+    1. **JSDoc descriptions** - Check if function descriptions match actual behavior
+    2. **Parameter documentation** - Identify docs for removed or renamed parameters
+    3. **Return type documentation** - Find return type docs that contradict actual types
+    4. **README code examples** - Verify that code examples compile and run
+    5. **Inline comments** - Review comments describing code that has changed
+
+    ## Analysis Steps
+
+    ### 1. JSDoc Description Accuracy
+
+    For key functions with JSDoc comments:
+    1. Read the JSDoc \`@description\` or opening sentence
+    2. Read the function implementation
+    3. Flag cases where the description doesn't match what the function actually does
+    4. Common drift patterns: descriptions that mention removed features, describe old algorithms, or omit new behavior
+
+    ### 2. Parameter Documentation
+
+    For functions with \`@param\` documentation:
+    1. List all documented parameters
+    2. List all actual function parameters
+    3. Flag documented parameters that don't exist in the function signature
+    4. Flag actual parameters missing from documentation (if the function has any \`@param\` docs)
+
+    ### 3. Return Type Documentation
+
+    For functions with \`@returns\` or \`@return\` documentation:
+    1. Read the documented return type and description
+    2. Check the actual return type (TypeScript type or inferred from implementation)
+    3. Flag mismatches between documented and actual return types
+    4. Flag return descriptions that don't match actual return behavior
+
+    ### 4. README Code Examples
+
+    For code blocks in README.md and other documentation:
+    1. Extract code examples that appear to be runnable (not pseudocode)
+    2. Check if imports/requires reference files or modules that exist
+    3. Check if function calls use correct signatures
+    4. Flag examples that reference renamed or removed APIs
+
+    ### 5. Inline Comment Review
+
+    For inline comments that describe specific code behavior:
+    1. Read the comment
+    2. Read the adjacent code
+    3. Flag comments where the described behavior doesn't match the implementation
+    4. Common patterns: "TODO" comments for work that's done, "HACK" comments for code that's been cleaned up
+
+    ## Output
+
+    For each drift found, document:
+
+    - **Location** - File path and line number
+    - **What the documentation claims** - Quote or summarize the documentation
+    - **What the code actually does** - Describe the actual behavior
+    - **Suggested fix** - One of:
+      - \`update\` - Update the documentation to match the code
+      - \`remove\` - Remove stale documentation entirely
+      - \`add\` - Add missing documentation (only if partial docs exist)
+
+    Example findings:
+
+    \`\`\`markdown
+    ### lib/parser.ts:42 - JSDoc description drift
+
+    - **Documentation claims**: "Parses the input string and returns an AST with source locations"
+    - **Code actually does**: Returns an AST without source locations (that feature was removed)
+    - **Fix**: update - Remove "with source locations" from the description
+
+    ### README.md:156 - Stale code example
+
+    - **Documentation claims**: \`import { parseFile } from './lib/parser'\`
+    - **Code actually does**: \`parseFile\` was renamed to \`parse\`
+    - **Fix**: update - Change import to \`import { parse } from './lib/parser'\`
+
+    ### lib/utils.ts:89 - Outdated inline comment
+
+    - **Documentation claims**: "// HACK: workaround for Node 14 bug"
+    - **Code actually does**: Clean implementation with no workaround; min Node version is now 18
+    - **Fix**: remove - Delete the obsolete comment
+    \`\`\`
+
+    ## Principles
+
+    - [Agent Autonomy](../principles/agent-autonomy.md) - Accurate documentation enables agents to work without trial and error
+    - [Context Window Efficiency](../principles/context-window-efficiency.md) - Incorrect docs waste context on misleading information
+    - [Maintainable Codebase](../principles/maintainable-codebase.md) - Up-to-date documentation reduces maintenance burden
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Reviewed JSDoc descriptions for accuracy against function behavior
+    - [ ] Checked parameter documentation for removed or renamed parameters
+    - [ ] Verified return type documentation matches actual return types
+    - [ ] Tested README code examples for correctness (imports, function signatures)
+    - [ ] Reviewed inline comments for outdated descriptions
+    - [ ] Documented each drift finding with location, claim, reality, and suggested fix
+    - [ ] Created ideas for any substantial documentation updates needed
   `;
 }
 function factsVerification() {
@@ -295,12 +673,155 @@ function factsVerification() {
 
     ## Definition of Done
 
-    - [ ] Read each fact file in \`.dust/facts/\`
-    - [ ] Verified each fact against current codebase
-    - [ ] Identified outdated or inaccurate facts
-    - [ ] Listed missing facts that would help agents
-    - [ ] Updated or removed stale facts
-    - [ ] Proposed ideas for any facts improvements needed
+    - Read each fact file in \`.dust/facts/\`
+    - Verified each fact against current codebase
+    - Identified outdated or inaccurate facts
+    - Listed missing facts that would help agents
+    - Updated or removed stale facts
+    - Proposed ideas for any facts improvements needed
+  `;
+}
+function feedbackLoopSpeed() {
+  return dedent`
+    # Feedback Loop Speed
+
+    Measure and report on check/test execution times to identify bottlenecks.
+
+    ${ideasHint}
+
+    ## Context
+
+    The [Fast Feedback Loops](../principles/fast-feedback-loops.md) principle emphasizes that the primary feedback loop—write code, run checks, see results—should be as fast as possible. Agents especially benefit because they operate in tight loops of change-and-verify; slow feedback wastes tokens and context window space on waiting rather than working.
+
+    This audit focuses specifically on measuring the development feedback loop speed to help identify which checks consume the most time.
+
+    ## Scope
+
+    Measure timing data for each component of the feedback loop:
+
+    1. **\`dust check\` total time** - Aggregate time for all checks
+    2. **Per-check breakdown** - Time spent on each individual check configured in \`dust check\`
+    3. **Test suite execution time** - Total time and identification of slowest individual tests
+    4. **Type checking duration** - Time spent on TypeScript/type checking
+    5. **Linting duration** - Time spent on lint checks
+    6. **Build time** - Time to compile/bundle if applicable
+
+    ## Analysis Steps
+
+    ### 1. Measure \`dust check\` Timing
+
+    Run \`dust check\` and capture timing for each check:
+
+    \`\`\`bash
+    time bin/dust check
+    \`\`\`
+
+    Alternatively, if the output shows timing per check, extract those values.
+
+    ### 2. Measure Test Suite Timing
+
+    Depending on the test framework:
+
+    - **Vitest**: Run \`npx vitest run --reporter=verbose\` to see per-test timing
+    - **Jest**: Run \`jest --verbose\` or \`jest --json\` for timing data
+    - **Bun test**: Run \`bun test --verbose\` and parse output
+    - **Other frameworks**: Use the framework's timing/verbose output option
+
+    Identify the slowest individual tests by duration.
+
+    ### 3. Measure Type Checking Duration
+
+    \`\`\`bash
+    time npx tsc --noEmit
+    \`\`\`
+
+    ### 4. Measure Linting Duration
+
+    \`\`\`bash
+    time npx eslint .
+    # or
+    time npx oxlint .
+    \`\`\`
+
+    ### 5. Measure Build Time (if applicable)
+
+    \`\`\`bash
+    time npm run build
+    # or
+    time bun run build
+    \`\`\`
+
+    ### 6. Calculate Time Distribution
+
+    For each check, calculate:
+    - Absolute duration (seconds)
+    - Percentage of total \`dust check\` time
+    - Flag checks consuming >30% of total time as dominant
+
+    ## Output
+
+    Report timing data in a structured format:
+
+    ### Summary
+
+    | Check | Duration | % of Total |
+    |-------|----------|------------|
+    | lint | 2.1s | 12% |
+    | typecheck | 4.5s | 26% |
+    | tests | 8.3s | 48% |
+    | build | 2.4s | 14% |
+    | **Total** | **17.3s** | **100%** |
+
+    ### Dominant Checks
+
+    Flag any check that consumes a disproportionate amount of time (>30% of total):
+
+    - **tests** (48% of total) - Consider investigating slow tests
+    - See the \`slow-tests\` audit for detailed test timing analysis
+
+    ### Slowest Individual Tests
+
+    List the top 5 slowest tests:
+
+    | Test | Duration |
+    |------|----------|
+    | "integration: full workflow" | 3.2s |
+    | "parses large file" | 1.8s |
+    | ... | ... |
+
+    ## Interpretation Guidelines
+
+    This audit reports raw timing data without prescribing specific thresholds. Different projects have different acceptable speeds depending on:
+
+    - Codebase size
+    - Team workflow (local vs CI-heavy)
+    - Test strategy (unit-heavy vs integration-heavy)
+
+    Use the data to:
+    - Identify which checks to optimize first
+    - Track feedback loop speed over time
+    - Make informed decisions about parallelization or caching
+
+    ## Principles
+
+    - [Fast Feedback Loops](../principles/fast-feedback-loops.md) - Directly measures feedback loop speed
+    - [Fast Feedback](../principles/fast-feedback.md) - Identifies bottlenecks in feedback delivery
+    - [Agent Autonomy](../principles/agent-autonomy.md) - Faster feedback means agents can iterate more within context limits
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Measured total \`dust check\` execution time
+    - [ ] Measured time for each individual check (lint, typecheck, tests, build, etc.)
+    - [ ] Identified test suite total execution time
+    - [ ] Identified slowest individual tests (top 5)
+    - [ ] Calculated percentage of total time for each check
+    - [ ] Flagged dominant checks (>30% of total time)
+    - [ ] Documented findings in summary table format
+    - [ ] Created ideas for any feedback loop speed improvements identified
   `;
 }
 function ideasFromCommits() {
@@ -330,11 +851,11 @@ function ideasFromCommits() {
 
     ## Definition of Done
 
-    - [ ] Reviewed commits from the last 20 commits
-    - [ ] Identified patterns or shortcuts worth addressing
-    - [ ] Listed TODO comments added in recent commits
-    - [ ] Noted areas where changes could be generalized
-    - [ ] Proposed follow-up ideas for any issues identified
+    - Reviewed commits from the last 20 commits
+    - Identified patterns or shortcuts worth addressing
+    - Listed TODO comments added in recent commits
+    - Noted areas where changes could be generalized
+    - Proposed follow-up ideas for any issues identified
   `;
 }
 function ideasFromPrinciples() {
@@ -364,10 +885,10 @@ function ideasFromPrinciples() {
 
     ## Definition of Done
 
-    - [ ] Read each principle file in \`.dust/principles/\`
-    - [ ] Analyzed codebase for alignment with each principle
-    - [ ] Listed gaps between current state and principle intent
-    - [ ] Proposed new ideas for unmet or underserved principles
+    - Read each principle file in \`.dust/principles/\`
+    - Analyzed codebase for alignment with each principle
+    - Listed gaps between current state and principle intent
+    - Proposed new ideas for unmet or underserved principles
   `;
 }
 function refactoringOpportunities() {
@@ -413,11 +934,11 @@ function refactoringOpportunities() {
 
     ## Definition of Done
 
-    - [ ] Identified high-churn files (modified in 3+ commits since last audit)
-    - [ ] Flagged files exceeding 300 lines that grew significantly
-    - [ ] Noted commits with concerning message patterns
-    - [ ] Provided specific refactoring suggestions for each opportunity
-    - [ ] Created ideas for any substantial refactoring work identified
+    - Identified high-churn files (modified in 3+ commits since last audit)
+    - Flagged files exceeding 300 lines that grew significantly
+    - Noted commits with concerning message patterns
+    - Provided specific refactoring suggestions for each opportunity
+    - Created ideas for any substantial refactoring work identified
   `;
 }
 function performanceReview() {
@@ -448,11 +969,11 @@ function performanceReview() {
 
     ## Definition of Done
 
-    - [ ] Measured startup time for common commands
-    - [ ] Profiled memory usage during typical operations
-    - [ ] Identified slow commands or operations
-    - [ ] Listed optimization opportunities by impact
-    - [ ] Proposed ideas for any performance improvements identified
+    - Measured startup time for common commands
+    - Profiled memory usage during typical operations
+    - Identified slow commands or operations
+    - Listed optimization opportunities by impact
+    - Proposed ideas for any performance improvements identified
   `;
 }
 function securityReview() {
@@ -483,13 +1004,13 @@ function securityReview() {
 
     ## Definition of Done
 
-    - [ ] Searched for hardcoded secrets (API keys, passwords, tokens)
-    - [ ] Reviewed input validation and sanitization
-    - [ ] Checked authentication and authorization logic
-    - [ ] Verified sensitive data is not logged or exposed
-    - [ ] Ran dependency audit for known vulnerabilities
-    - [ ] Documented any findings with severity ratings
-    - [ ] Proposed ideas for any security issues found
+    - Searched for hardcoded secrets (API keys, passwords, tokens)
+    - Reviewed input validation and sanitization
+    - Checked authentication and authorization logic
+    - Verified sensitive data is not logged or exposed
+    - Ran dependency audit for known vulnerabilities
+    - Documented any findings with severity ratings
+    - Proposed ideas for any security issues found
   `;
 }
 function staleIdeas() {
@@ -519,11 +1040,11 @@ function staleIdeas() {
 
     ## Definition of Done
 
-    - [ ] Listed all ideas with their last modification date
-    - [ ] Identified ideas unchanged for 50+ commits
-    - [ ] Reviewed each stale idea for current relevance
-    - [ ] Promoted actionable ideas to tasks
-    - [ ] Deleted ideas that are no longer relevant
+    - Listed all ideas with their last modification date
+    - Identified ideas unchanged for 50+ commits
+    - Reviewed each stale idea for current relevance
+    - Promoted actionable ideas to tasks
+    - Deleted ideas that are no longer relevant
   `;
 }
 function testCoverage() {
@@ -554,10 +1075,10 @@ function testCoverage() {
 
     ## Definition of Done
 
-    - [ ] Identified modules with low or no test coverage
-    - [ ] Listed critical paths that lack tests
-    - [ ] Prioritized areas by risk and importance
-    - [ ] Proposed ideas for any test coverage gaps identified
+    - Identified modules with low or no test coverage
+    - Listed critical paths that lack tests
+    - Prioritized areas by risk and importance
+    - Proposed ideas for any test coverage gaps identified
   `;
 }
 function errorHandling() {
@@ -606,12 +1127,12 @@ function errorHandling() {
 
     ## Definition of Done
 
-    - [ ] Searched for empty catch blocks and silent error swallowing
-    - [ ] Identified patterns that discard error details
-    - [ ] Found fire-and-forget promises without error handling
-    - [ ] Reviewed error messages for actionability
-    - [ ] Compared error handling consistency across similar operations
-    - [ ] Proposed ideas for any error handling improvements identified
+    - Searched for empty catch blocks and silent error swallowing
+    - Identified patterns that discard error details
+    - Found fire-and-forget promises without error handling
+    - Reviewed error messages for actionability
+    - Compared error handling consistency across similar operations
+    - Proposed ideas for any error handling improvements identified
   `;
 }
 function globalState() {
@@ -661,13 +1182,13 @@ function globalState() {
 
     ## Definition of Done
 
-    - [ ] Searched for module-level mutable variables (let/var outside functions)
-    - [ ] Identified singleton patterns and getInstance methods
-    - [ ] Found global registries (Maps, Sets, Arrays modified at module level)
-    - [ ] Located functions with implicit dependencies on module-level state
-    - [ ] Checked for scattered process.env access
-    - [ ] Documented impact of each global state instance on testing
-    - [ ] Proposed ideas for refactoring global state to explicit dependencies
+    - Searched for module-level mutable variables (let/var outside functions)
+    - Identified singleton patterns and getInstance methods
+    - Found global registries (Maps, Sets, Arrays modified at module level)
+    - Located functions with implicit dependencies on module-level state
+    - Checked for scattered process.env access
+    - Documented impact of each global state instance on testing
+    - Proposed ideas for refactoring global state to explicit dependencies
   `;
 }
 function repositoryContext() {
@@ -711,12 +1232,12 @@ function repositoryContext() {
 
     ## Definition of Done
 
-    - [ ] \`.dust/repository.md\` exists and is up to date
-    - [ ] Document describes what the project does without referencing specific files
-    - [ ] Key capabilities and features are listed
-    - [ ] Design philosophy or guiding approach is captured
-    - [ ] Document is concise enough to fit comfortably in an agent context window
-    - [ ] A new agent reading only this document could make sensible high-level suggestions
+    - \`.dust/repository.md\` exists and is up to date
+    - Document describes what the project does without referencing specific files
+    - Key capabilities and features are listed
+    - Design philosophy or guiding approach is captured
+    - Document is concise enough to fit comfortably in an agent context window
+    - A new agent reading only this document could make sensible high-level suggestions
   `;
 }
 function slowTests() {
@@ -769,13 +1290,13 @@ function slowTests() {
 
     ## Definition of Done
 
-    - [ ] Ran test suite with timing information
-    - [ ] Listed tests exceeding duration thresholds (100ms unit, 1s integration)
-    - [ ] Identified tests using sleep/setTimeout/delay patterns
-    - [ ] Found tests with unmocked I/O (network, database, file system)
-    - [ ] Reviewed beforeEach/beforeAll for optimization opportunities
-    - [ ] Checked test parallelization configuration
-    - [ ] Proposed ideas for optimizing the slowest tests
+    - Ran test suite with timing information
+    - Listed tests exceeding duration thresholds (100ms unit, 1s integration)
+    - Identified tests using sleep/setTimeout/delay patterns
+    - Found tests with unmocked I/O (network, database, file system)
+    - Reviewed beforeEach/beforeAll for optimization opportunities
+    - Checked test parallelization configuration
+    - Proposed ideas for optimizing the slowest tests
   `;
 }
 function namingConsistency() {
@@ -826,13 +1347,13 @@ function namingConsistency() {
 
     ## Definition of Done
 
-    - [ ] Reviewed high-confidence factory/constructor naming consistency for equivalent creation APIs
-    - [ ] Constrained findings to \`build*\`, \`create*\`, \`make*\`, and \`new*\` naming variants with clearly equivalent intent
-    - [ ] Documented each finding with locations, inconsistent term set, canonical proposal, and migration strategy
-    - [ ] Chose incremental or one-shot migration strategy for each canonical proposal
-    - [ ] Avoided speculative broad renames
-    - [ ] Avoided artifact-list ordering/shape checks and broad terminology drift
-    - [ ] Proposed ideas for naming consistency improvements identified
+    - Reviewed high-confidence factory/constructor naming consistency for equivalent creation APIs
+    - Constrained findings to \`build*\`, \`create*\`, \`make*\`, and \`new*\` naming variants with clearly equivalent intent
+    - Documented each finding with locations, inconsistent term set, canonical proposal, and migration strategy
+    - Chose incremental or one-shot migration strategy for each canonical proposal
+    - Avoided speculative broad renames
+    - Avoided artifact-list ordering/shape checks and broad terminology drift
+    - Proposed ideas for naming consistency improvements identified
   `;
 }
 function primitiveObsession() {
@@ -901,13 +1422,13 @@ function primitiveObsession() {
 
     ## Definition of Done
 
-    - [ ] Reviewed high-confidence existing-type drift for domain string literals and numeric magic values
-    - [ ] Constrained findings to cases where canonical domain types or clear constant/wrapper opportunities already exist
-    - [ ] Documented each finding with locations, primitive pattern, constant/type opportunity, and incremental migration path
-    - [ ] Documented numeric findings with locations, numeric pattern, constant/type opportunity, and incremental migration path
-    - [ ] Preserved Functional Core, Imperative Shell boundaries in recommendations
-    - [ ] Avoided speculative introduction of entirely new types
-    - [ ] Proposed ideas for primitive obsession improvements identified
+    - Reviewed high-confidence existing-type drift for domain string literals and numeric magic values
+    - Constrained findings to cases where canonical domain types or clear constant/wrapper opportunities already exist
+    - Documented each finding with locations, primitive pattern, constant/type opportunity, and incremental migration path
+    - Documented numeric findings with locations, numeric pattern, constant/type opportunity, and incremental migration path
+    - Preserved Functional Core, Imperative Shell boundaries in recommendations
+    - Avoided speculative introduction of entirely new types
+    - Proposed ideas for primitive obsession improvements identified
   `;
 }
 function singleResponsibilityViolations() {
@@ -968,12 +1489,12 @@ function singleResponsibilityViolations() {
 
     ## Definition of Done
 
-    - [ ] Reviewed high-confidence function-level findings where 3+ distinct responsibilities are combined
-    - [ ] Included runtime code and test helpers in scope
-    - [ ] Documented each finding with location, responsibility split, severity, and suggested extraction plan
-    - [ ] Preserved Functional Core, Imperative Shell boundaries in recommendations
-    - [ ] Kept recommendations high-confidence only with clear concern boundaries
-    - [ ] Proposed ideas for substantial responsibility-splitting work identified
+    - Reviewed high-confidence function-level findings where 3+ distinct responsibilities are combined
+    - Included runtime code and test helpers in scope
+    - Documented each finding with location, responsibility split, severity, and suggested extraction plan
+    - Preserved Functional Core, Imperative Shell boundaries in recommendations
+    - Kept recommendations high-confidence only with clear concern boundaries
+    - Proposed ideas for substantial responsibility-splitting work identified
   `;
 }
 function ubiquitousLanguage() {
@@ -1021,12 +1542,520 @@ function ubiquitousLanguage() {
 
     ## Definition of Done
 
-    - [ ] Identified key domain terms from project documentation
-    - [ ] Reviewed recent commits for terminology consistency
-    - [ ] Compared code naming against documentation vocabulary
-    - [ ] Checked user-facing text for alignment with code terms
-    - [ ] Documented any terminology drift or inconsistencies found
-    - [ ] Proposed ideas for standardizing inconsistent terminology
+    - Identified key domain terms from project documentation
+    - Reviewed recent commits for terminology consistency
+    - Compared code naming against documentation vocabulary
+    - Checked user-facing text for alignment with code terms
+    - Documented any terminology drift or inconsistencies found
+    - Proposed ideas for standardizing inconsistent terminology
+  `;
+}
+function designPatterns() {
+  return dedent`
+    # Design Patterns
+
+    Identify refactoring opportunities to recognized design patterns using code smell triggers.
+
+    ${ideasHint}
+
+    ## Scope
+
+    This audit surfaces opportunities to apply design patterns systematically using code smell triggers rather than structural heuristics. Use a low threshold for flagging patterns and let users filter relevance.
+
+    ## Code Smell Triggers
+
+    Flag patterns based on code smells that suggest pattern opportunities:
+
+    1. **Switch statements on type** - Multiple switch/if-else chains branching on a type field suggest **Strategy** pattern (or discriminated unions in functional codebases)
+    2. **Repeated object construction** - Similar multi-step object creation scattered across files suggests **Factory** pattern
+    3. **Inconsistent interfaces** - Multiple implementations of similar behavior with different method signatures suggest interface **formalization**
+    4. **Complex conditional creation logic** - Functions with many parameters or conditional object assembly suggest **Builder** pattern
+    5. **State with multiple transitions** - Objects with mode/status fields and complex state transition logic suggest **State** pattern
+    6. **Notification chains** - Manual event propagation or callback chains suggest **Observer** pattern
+
+    ## Analysis Steps
+
+    1. Search for switch statements and if-else chains that branch on type/kind/mode fields
+    2. Look for similar object construction patterns repeated across multiple files
+    3. Identify classes/interfaces with inconsistent method signatures for similar operations
+    4. Find functions with 4+ parameters for object creation or complex conditional assembly
+    5. Search for status/state/mode fields with multiple transition conditions
+    6. Look for manual notification or callback propagation patterns
+
+    ## Output Per Finding
+
+    For each finding, provide:
+    - **Location** - File and line range
+    - **Code smell** - What triggered this recommendation (switch on type, repeated construction, etc.)
+    - **Recommended pattern** - The suggested design pattern (Gang of Four name where applicable, or modern alternative)
+    - **Trade-off analysis** - Pros (e.g., "Easier to add new types without modifying existing code") and cons (e.g., "Adds indirection, may be overkill for 2-3 cases")
+    - **Migration complexity** - Low/Medium/High estimate with brief rationale
+
+    ## Tech-Stack Considerations
+
+    - Mention Gang of Four patterns by name where applicable
+    - Note when patterns may not apply:
+      - **Strategy** is less relevant in functional codebases where functions are first-class
+      - **Visitor** can often be replaced with discriminated unions and exhaustive pattern matching
+      - **Observer** may be superseded by reactive frameworks or event emitters
+    - Suggest modern alternatives where appropriate (e.g., discriminated unions, higher-order functions, dependency injection)
+
+    ## Principles
+
+    - [Functional Core, Imperative Shell](../principles/functional-core-imperative-shell.md) - Preserve pure core and thin shell boundaries in recommendations
+    - [Make the Change Easy](../principles/make-the-change-easy.md) - Pattern adoption should simplify future changes
+    - [Decoupled Code](../principles/decoupled-code.md) - Patterns should reduce coupling, not add complexity
+    - [Design for Testability](../principles/design-for-testability.md) - Pattern recommendations should improve testability
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Searched for switch statements on type/kind/mode fields
+    - Identified repeated object construction patterns
+    - Found inconsistent interfaces for similar behavior
+    - Located complex conditional creation logic
+    - Searched for state fields with multiple transitions
+    - Identified notification chain patterns
+    - Documented each finding with location, code smell, recommended pattern, trade-offs, and migration complexity
+    - Noted tech-stack considerations where Gang of Four patterns may or may not apply
+    - Proposed ideas for any design pattern improvements identified
+  `;
+}
+function testAssertions() {
+  return dedent`
+    # Test Assertions
+
+    Review test assertions for quality signals beyond comprehensive assertions.
+
+    ${ideasHint}
+
+    ## Background
+
+    The [Comprehensive Assertions](../principles/comprehensive-assertions.md) principle covers asserting whole objects rather than fragments. The [Self-Diagnosing Tests](../principles/self-diagnosing-tests.md) principle covers making failure messages informative. This audit addresses complementary assertion quality signals not covered by existing principles.
+
+    ## Scope
+
+    ### Deterministic Assertions
+
+    Assertions should produce the same result regardless of execution timing or environment. Anti-patterns include:
+
+    - Asserting on timestamps or dates without mocking time
+    - Asserting on random values without seeding
+    - Asserting on iteration order of unordered collections (objects, Sets, Maps)
+    - Asserting on process IDs, file handles, or other system-allocated values
+
+    Example:
+    \`\`\`javascript
+    // Non-deterministic: order depends on JS engine
+    expect(Object.keys(result)).toEqual(['a', 'b', 'c'])
+
+    // Deterministic: sort before comparison
+    expect(Object.keys(result).sort()).toEqual(['a', 'b', 'c'])
+    \`\`\`
+
+    ### Fixed Delay Anti-patterns
+
+    Tests should not use arbitrary fixed delays (\`setTimeout\`, \`sleep\`) to wait for async operations. Fixed delays are:
+
+    - Flaky (may fail on slower machines or under load)
+    - Slow (must wait the full delay even when the operation completes early)
+    - Non-deterministic (timing varies across environments)
+
+    Instead, tests should:
+    - Use promise resolution (\`await\`/\`.then()\`)
+    - Poll with short intervals until a condition is met
+    - Use test framework utilities (\`vi.useFakeTimers()\`, \`waitFor()\`)
+    - Inject controllable time dependencies
+
+    Example:
+    \`\`\`javascript
+    // Bad: arbitrary 50ms delay
+    await new Promise(r => setTimeout(r, 50))
+    expect(state).toBe('ready')
+
+    // Better: wait for the condition
+    await vi.waitFor(() => expect(state).toBe('ready'))
+
+    // Best: control time explicitly
+    vi.useFakeTimers()
+    vi.advanceTimersByTime(50)
+    expect(state).toBe('ready')
+    \`\`\`
+
+    ### Precise but Not Exhaustive Assertions
+
+    Assertions should verify the behavior under test without over-constraining implementation details. Exhaustive assertions that check every property can:
+
+    - Couple tests tightly to implementation
+    - Require test updates for unrelated changes
+    - Obscure what the test is actually verifying
+
+    This works in tension with [Comprehensive Assertions](../principles/comprehensive-assertions.md). Let context determine the balance:
+    - Public API contracts → comprehensive assertions
+    - Internal implementation tests → precise assertions
+    - Snapshot tests → consider \`toMatchSnapshot()\` with care
+
+    Example:
+    \`\`\`javascript
+    // Exhaustive: breaks if any internal field changes
+    expect(result).toEqual({
+      id: 'abc',
+      name: 'test',
+      _internal: {},
+      _meta: { version: 1 },
+      _cache: null,
+    })
+
+    // Precise: verifies only the relevant properties
+    expect(result).toMatchObject({
+      id: 'abc',
+      name: 'test',
+    })
+    \`\`\`
+
+    ### One Logical Assertion Per Test
+
+    Tests should ideally verify one behavior or scenario. When a test has multiple unrelated assertions, a failure in the first masks all subsequent ones.
+
+    This does not mean "one \`expect\` call per test". A single logical assertion may require multiple \`expect\` calls to express (especially for complex state). The [Comprehensive Assertions](../principles/comprehensive-assertions.md) principle often allows collapsing multiple calls into one whole-object assertion.
+
+    The anti-pattern to avoid:
+    \`\`\`javascript
+    test('user validation', () => {
+      // Multiple unrelated behaviors in one test
+      expect(validateEmail('bad')).toBe(false)
+      expect(validateEmail('good@example.com')).toBe(true)
+      expect(validatePassword('short')).toBe(false)
+      expect(validatePassword('LongEnough123!')).toBe(true)
+    })
+    \`\`\`
+
+    Prefer separate tests for separate behaviors:
+    \`\`\`javascript
+    test('rejects invalid email format', () => {
+      expect(validateEmail('bad')).toBe(false)
+    })
+
+    test('accepts valid email format', () => {
+      expect(validateEmail('good@example.com')).toBe(true)
+    })
+    \`\`\`
+
+    ## Analysis Steps
+
+    1. Search for assertions on \`Date.now()\`, \`new Date()\`, or timestamp fields without fake timers
+    2. Look for assertions on \`Object.keys()\` or property iteration without sorting
+    3. Find \`setTimeout\`, \`sleep\`, or fixed delays in test files
+    4. Identify tests with many unrelated assertions covering multiple behaviors
+    5. Review snapshot usage for overly broad snapshots that capture internal details
+    6. Check for assertions on random or system-allocated values (PIDs, UUIDs without seeding)
+
+    ## Output
+
+    For each finding, provide:
+    - **Location** - File path and line number
+    - **Pattern** - Which category of issue (non-deterministic, fixed delay, exhaustive, multiple behaviors)
+    - **Impact** - How this affects test reliability or maintainability
+    - **Suggestion** - Specific fix (sort keys, use fake timers, split test, use toMatchObject, etc.)
+
+    ## Principles
+
+    - [Comprehensive Assertions](../principles/comprehensive-assertions.md) — Tension with "precise but not exhaustive"; balance depends on context
+    - [Self-Diagnosing Tests](../principles/self-diagnosing-tests.md) — Informative failures require precise assertions
+    - [Keep Unit Tests Pure](../principles/keep-unit-tests-pure.md) — Determinism is essential for purity
+    - [Reproducible Checks](../principles/reproducible-checks.md) — Deterministic assertions support reproducibility
+    - [Test Isolation](../principles/test-isolation.md) — Fixed delays can cause race conditions between tests
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Searched for non-deterministic assertions (timestamps, object key order, random values)
+    - Identified fixed delay patterns in test files
+    - Reviewed assertions for over-constraining internal details
+    - Found tests covering multiple unrelated behaviors
+    - Documented each finding with location, pattern, impact, and suggestion
+    - Proposed ideas for any assertion quality improvements identified
+  `;
+}
+function algorithms() {
+  return dedent`
+    # Algorithms
+
+    Evaluate algorithmic complexity and identify performance bottlenecks.
+
+    ${ideasHint}
+
+    ## Scope
+
+    Focus on these areas:
+
+    1. **Nested loops or recursive calls** - Functions with O(n²) or worse complexity due to nested iteration
+    2. **Linear search inside loops** - Use of \`.includes()\`, \`.indexOf()\`, or \`.find()\` inside loops (potential O(n²))
+    3. **Missing Map/Set usage** - Repeated lookups in arrays where O(1) data structures would help
+    4. **Repeated string operations in loops** - Substring, split, join operations creating unnecessary allocations
+    5. **Missing early returns or break conditions** - Loops that continue processing after the result is found
+    6. **Graph/tree operations without cycle protection** - Recursive traversals that may infinite loop on cyclic structures
+
+    ## Analysis Steps
+
+    1. Search for nested \`for\`/\`while\`/\`forEach\` loops and recursive functions
+    2. Look for \`.includes()\`, \`.indexOf()\`, \`.find()\` calls inside loop bodies
+    3. Identify arrays used for repeated membership testing that could be Sets
+    4. Find string operations (\`substring\`, \`split\`, \`join\`, \`+\` concatenation) inside loops
+    5. Check loops for opportunities to \`break\` or \`return\` early
+    6. Review recursive functions for visited/seen tracking in graph-like structures
+
+    ## Output Per Finding
+
+    For each finding, provide:
+    - **Function name and location** - File path, line number, and function name
+    - **Current complexity analysis** - Big-O notation with explanation (e.g., "O(n²) due to nested iteration over items array")
+    - **Data structures involved** - What collections are being processed
+    - **Suggested optimization** - Specific fix (e.g., "Convert users array to Set for O(1) lookup", "Add visited Set to prevent cycles")
+    - **Acceptable complexity assessment** - Whether the current complexity is acceptable given expected input sizes (e.g., "Acceptable for small configs (<100 items), problematic for large datasets")
+
+    ## Principles
+
+    - [Fast Feedback Loops](../principles/fast-feedback-loops.md) — Efficient algorithms contribute to fast feedback
+    - [Maintainable Codebase](../principles/maintainable-codebase.md) — Understanding complexity aids maintenance
+    - [Context-Optimised Code](../principles/context-optimised-code.md) — Simple, efficient code is easier to understand
+    - [Functional Core, Imperative Shell](../principles/functional-core-imperative-shell.md) — Keep pure analysis logic separate from output formatting
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Searched for nested loops and recursive functions
+    - Identified linear search operations inside loops
+    - Found arrays that could benefit from Set/Map conversion
+    - Located repeated string operations in loops
+    - Reviewed loops for missing early exit conditions
+    - Checked recursive graph/tree operations for cycle protection
+    - Documented each finding with function name, location, complexity, data structures, optimization, and acceptability assessment
+    - Proposed ideas for any algorithmic improvements identified
+  `;
+}
+function loggingAndTraceability() {
+  return dedent`
+    # Logging and Traceability
+
+    Review logging practices for runtime observability and diagnostic usefulness.
+
+    ${ideasHint}
+
+    ## Scope
+
+    Focus on these areas:
+
+    1. **Runtime observability** - Is it easy to understand what's happening when the application runs?
+    2. **Diagnostic usefulness** - Is it easy for agents and humans to use logs to diagnose issues at development time?
+    3. **Log levels** - Are appropriate log levels used (debug, info, warn, error)?
+    4. **Contextual information** - Do logs include enough context to trace execution flow?
+    5. **Structured logging** - Are logs structured (e.g., JSON) for easy parsing?
+    6. **Log consistency** - Do similar operations produce similar log output?
+
+    ## Analysis Steps
+
+    1. Identify logging calls throughout the codebase (\`console.log\`, \`logger.info\`, etc.)
+    2. Review error handling paths for appropriate error logging
+    3. Check if logs include enough context (operation name, relevant IDs, timestamps)
+    4. Look for silent failures - catch blocks without logging
+    5. Evaluate whether running the application produces understandable output
+    6. Test whether logs help diagnose common failure scenarios
+
+    ## Output
+
+    For each finding, provide:
+    - **Location** - File path and line number
+    - **Category** - Which area of concern (observability, diagnostic usefulness, log levels, context, structure, consistency)
+    - **Issue** - What's missing or problematic
+    - **Impact** - How this affects debugging or understanding system behavior
+    - **Suggestion** - Specific improvement (add logging, change level, add context, etc.)
+
+    ## Principles
+
+    - [Development Traceability](../principles/development-traceability.md) - Structured logging helps agents understand system behavior
+    - [Debugging Tooling](../principles/debugging-tooling.md) - Agents need effective tools for diagnosing issues
+    - [Actionable Errors](../principles/actionable-errors.md) - Error logs should guide next steps
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Reviewed logging coverage across the codebase
+    - Identified silent failures (catch blocks without logging)
+    - Evaluated log levels for appropriateness
+    - Checked logs for sufficient context (operation names, IDs, relevant state)
+    - Assessed whether running the application produces understandable output
+    - Tested whether logs help diagnose common failure scenarios
+    - Proposed ideas for any logging improvements identified
+  `;
+}
+function testPyramid() {
+  return dedent`
+    # Test Pyramid
+
+    Evaluate whether tests follow the test pyramid pattern.
+
+    ${ideasHint}
+
+    ## Background
+
+    The test pyramid model suggests:
+    - **Many fast unit tests** (base) — pure, isolated, testing single units
+    - **Fewer integration tests** (middle) — testing interactions between components
+    - **Minimal end-to-end tests** (top) — slow, broad tests exercising full systems
+
+    Projects with an inverted pyramid suffer from slow feedback loops and difficulty isolating failures.
+
+    ## Scope
+
+    ### Test Classification
+
+    Determine test types by examining project structure. Common patterns include:
+
+    - **Directory conventions**: \`unit/\`, \`integration/\`, \`e2e/\`, or co-located tests vs \`system-tests/\`
+    - **Test runners**: Different runners for different types (e.g., vitest for unit, bun test for system)
+    - **Configuration**: Look at test config files for exclusions or separate setups
+
+    First identify how this specific project organizes tests, then classify accordingly.
+
+    ### Time Analysis
+
+    Include execution time per tier, not just test count. A pyramid with 100 unit tests taking 10 seconds each and 10 e2e tests taking 1 second each has problems the count alone wouldn't reveal.
+
+    Guidance on obtaining timing:
+    - For vitest: \`npx vitest run --reporter=json\` provides per-test duration
+    - For jest: \`jest --json\` provides timing data
+    - For bun test: parse verbose output
+
+    ## Analysis Steps
+
+    1. Examine project structure to understand how tests are organized
+    2. Identify the test classification strategy used (directories, config files, runners)
+    3. Count tests in each category (unit, integration, e2e)
+    4. Run tests with timing output to measure execution time per tier
+    5. Look for "unit" tests that perform I/O (process spawning, network calls, file system access)
+    6. Evaluate pyramid shape based on counts and timing
+
+    ## Output
+
+    Report the following:
+
+    1. **Test distribution** — counts and percentages per category
+    2. **Time distribution** — total execution time per tier
+    3. **Pyramid health** — flag obvious inversions:
+       - More e2e tests than unit tests
+       - More time spent in integration/e2e than unit tests
+    4. **Miscategorized tests** — tests that appear to be in the wrong tier based on their behavior (e.g., "unit" tests with I/O)
+    5. **Recommendations** — specific actions to improve the pyramid shape
+
+    ## Relative Guidance
+
+    Flag obvious problems without prescribing exact ratios. Examples of problems:
+    - More end-to-end tests than unit tests
+    - More time spent in integration/e2e than unit tests
+    - Unit tests that perform I/O (process spawning, network calls, file system access)
+
+    ## Principles
+
+    - [Fast Feedback Loops](../principles/fast-feedback-loops.md) — Unit-heavy pyramids enable fast feedback
+    - [Keep Unit Tests Pure](../principles/keep-unit-tests-pure.md) — Defines what makes a test a "unit test"
+    - [Unit Test Coverage](../principles/unit-test-coverage.md) — Values unit tests for specific, fast feedback
+    - [Design for Testability](../principles/design-for-testability.md) — Testable code enables unit tests; untestable code forces integration tests
+    - [Functional Core, Imperative Shell](../principles/functional-core-imperative-shell.md) — Keep audit definition pure
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Identified how this project organizes and classifies tests
+    - Counted tests per category (unit, integration, e2e)
+    - Measured execution time per tier
+    - Flagged obvious pyramid inversions (more e2e than unit, more time in e2e)
+    - Identified miscategorized tests (e.g., unit tests with I/O)
+    - Provided specific recommendations to improve pyramid shape
+    - Proposed ideas for any substantial test restructuring needed
+  `;
+}
+function idiomaticStyle() {
+  return dedent`
+    # Idiomatic Style
+
+    Review recent changes to ensure implementation follows idiomatic practices for the technology stack.
+
+    ${ideasHint}
+
+    ## Scope
+
+    Focus on these areas:
+
+    1. **Language idioms** - Does code follow language-specific patterns and conventions? (e.g., Python comprehensions, JavaScript destructuring, TypeScript type narrowing)
+    2. **Framework patterns** - Are framework/library APIs used as intended? (e.g., React hooks rules, Express middleware patterns, test framework best practices)
+    3. **Style consistency** - Do recent changes match the established code style in this codebase?
+    4. **Anti-patterns** - Are common pitfalls for this stack being avoided?
+    5. **Modern alternatives** - Are deprecated or outdated approaches being used where better alternatives exist?
+
+    ## Analysis Steps
+
+    1. Identify the technology stack by examining package.json, config files, or file extensions
+    2. Review recent commits (last 10-20 commits) to understand what changed
+    3. For each change, evaluate against idiomatic practices for that language/framework
+    4. Check for deviations from established patterns in the existing codebase
+    5. **IMPORTANT**: If uncertain about current best practices (e.g., due to stale training data), consult official documentation or authoritative sources for the latest guidance before flagging issues
+
+    ## Output
+
+    For each finding, provide:
+    - **Location** - File path and line numbers
+    - **Pattern** - What the code is currently doing
+    - **Idiom issue** - How this deviates from idiomatic practice
+    - **Best practice** - What the idiomatic approach would be (with reference to documentation if applicable)
+    - **Impact** - Why this matters (readability, performance, maintainability, community expectations)
+
+    ## Tech-Stack Considerations
+
+    Be specific to the detected stack. Examples:
+
+    - **TypeScript**: Prefer type narrowing over type assertions, use \`const\` assertions, leverage discriminated unions
+    - **React**: Follow hooks rules, prefer controlled components, avoid inline function definitions in JSX for performance
+    - **Node.js**: Use async/await over callbacks, prefer native ES modules, handle streams properly
+    - **Testing**: Use framework-specific matchers, follow Arrange-Act-Assert pattern, avoid test interdependence
+
+    When the technology or its ecosystem is evolving rapidly, explicitly note when findings should be verified against current documentation.
+
+    ## Principles
+
+    - [Context-Optimised Code](../principles/context-optimised-code.md) - Idiomatic code is easier for agents and humans to understand
+    - [Maintainable Codebase](../principles/maintainable-codebase.md) - Following conventions reduces cognitive load
+    - [Consistent Naming](../principles/consistent-naming.md) - Naming should follow language conventions
+    - [Boy Scout Rule](../principles/boy-scout-rule.md) - Leave code better than you found it
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Identified the technology stack in use
+    - Reviewed recent commits for idiom issues
+    - Checked code against language and framework best practices
+    - Verified current documentation for any uncertain cases
+    - Evaluated code style consistency with rest of codebase
+    - Identified anti-patterns or deprecated approaches
+    - Proposed ideas for any idiomaticity improvements identified
   `;
 }
 function uxAudit() {
@@ -1089,26 +2118,504 @@ function uxAudit() {
 
     ## Definition of Done
 
-    - [ ] Identified the application type (web, terminal, hybrid, or no UI)
-    - [ ] Listed key user scenarios
-    - [ ] Captured screenshots or output at each stage of key scenarios
-    - [ ] Reviewed evidence for UX issues
-    - [ ] Documented findings with evidence and recommendations
-    - [ ] Included verification criteria for each issue
-    - [ ] Created ideas for any UX improvements needed
+    - Identified the application type (web, terminal, hybrid, or no UI)
+    - Listed key user scenarios
+    - Captured screenshots or output at each stage of key scenarios
+    - Reviewed evidence for UX issues
+    - Documented findings with evidence and recommendations
+    - Included verification criteria for each issue
+    - Created ideas for any UX improvements needed
+  `;
+}
+function dependencyHealth() {
+  return dedent`
+    # Dependency Health
+
+    Review project dependencies for maintenance and security concerns beyond CVE scanning.
+
+    ${ideasHint}
+
+    ## Context
+
+    Healthy dependencies require more than security patches. Unmaintained packages, version drift, and deprecated packages all impact project health and can introduce agent confusion when outdated documentation or APIs don't match reality.
+
+    ## Scope
+
+    Focus on these areas:
+
+    1. **Packages with no recent releases** - Identify dependencies that haven't been updated in 2+ years (potential abandonment)
+    2. **Major version drift** - Find dependencies more than 2 major versions behind latest (missing features, eventual migration pain)
+    3. **Deprecated packages** - Detect packages marked as deprecated on npm
+    4. **Better-maintained alternatives** - Flag packages with known successors (e.g., \`request\` → \`node-fetch\` or \`got\`)
+
+    ## Analysis Steps
+
+    ### 1. Check Package Release Dates
+
+    For each dependency in \`package.json\`:
+
+    1. Run \`npm view <package-name> time --json\` to get release history
+    2. Check the date of the latest release
+    3. Flag packages where the latest release is more than 2 years old
+
+    Example:
+    \`\`\`bash
+    npm view lodash time --json | jq -r 'to_entries | sort_by(.value) | last | .value'
+    \`\`\`
+
+    ### 2. Identify Major Version Drift
+
+    Compare installed versions against latest:
+
+    1. Run \`npm outdated --json\` to see current vs latest versions
+    2. Parse version numbers to identify major version differences
+    3. Flag dependencies more than 2 major versions behind
+
+    Example output to parse:
+    \`\`\`json
+    {
+      "example-package": {
+        "current": "2.1.0",
+        "wanted": "2.5.0",
+        "latest": "5.0.0"
+      }
+    }
+    \`\`\`
+
+    In this case, the package is 3 major versions behind (2.x → 5.x).
+
+    ### 3. Detect Deprecated Packages
+
+    Check deprecation status:
+
+    1. Run \`npm view <package-name> deprecated\` for each dependency
+    2. If the field exists and is non-empty, the package is deprecated
+    3. The deprecation message often suggests an alternative
+
+    Example:
+    \`\`\`bash
+    npm view request deprecated
+    # Output: "request has been deprecated..."
+    \`\`\`
+
+    ### 4. Identify Better-Maintained Alternatives
+
+    Known package migrations to check for:
+
+    | Deprecated/Unmaintained | Recommended Alternative |
+    |------------------------|------------------------|
+    | \`request\` | \`node-fetch\`, \`got\`, \`axios\` |
+    | \`moment\` | \`date-fns\`, \`dayjs\`, \`luxon\` |
+    | \`uuid\` v3 or earlier | \`uuid\` v8+ or \`crypto.randomUUID()\` |
+    | \`rimraf\` | \`fs.rm\` (Node 14.14+) |
+    | \`mkdirp\` | \`fs.mkdir\` with \`recursive: true\` |
+    | \`node-fetch\` | native \`fetch\` (Node 18+) |
+    | \`colors\` | \`chalk\`, \`picocolors\` |
+    | \`faker\` | \`@faker-js/faker\` |
+    | \`left-pad\` | \`String.prototype.padStart()\` |
+    | \`underscore\` | \`lodash\` or native methods |
+
+    Search for these packages in \`package.json\` and flag any matches.
+
+    ## Output
+
+    For each concern found, document:
+
+    - **Package name** - The npm package name
+    - **Current version** - Version installed in the project
+    - **Type of concern** - One of: \`unmaintained\`, \`outdated\`, \`deprecated\`, \`superseded\`
+    - **Details** - Last release date, version gap, deprecation message, or successor package
+    - **Suggested action** - One of:
+      - \`update\` - Upgrade to latest version
+      - \`replace\` - Migrate to a successor package
+      - \`remove\` - Remove if no longer needed
+      - \`accept\` - Accept the risk with documented rationale
+
+    Example findings:
+
+    \`\`\`markdown
+    ### moment (v2.29.4)
+
+    - **Concern**: superseded
+    - **Details**: moment is in maintenance mode; the team recommends date-fns, Luxon, or Day.js for new projects
+    - **Action**: replace with \`date-fns\` for tree-shaking benefits, or \`dayjs\` for API compatibility
+
+    ### request (v2.88.2)
+
+    - **Concern**: deprecated
+    - **Details**: Package deprecated in February 2020. Message: "request has been deprecated"
+    - **Action**: replace with \`node-fetch\` (for simple cases) or \`got\` (for advanced features)
+
+    ### some-legacy-lib (v1.0.0)
+
+    - **Concern**: unmaintained
+    - **Details**: Last release was 3 years ago (2021-01-15)
+    - **Action**: evaluate if still needed; if so, consider forking or finding alternative
+    \`\`\`
+
+    ## Principles
+
+    - [Minimal Dependencies](../principles/minimal-dependencies.md) - Avoid coupling to specific tools; healthy dependencies are easier to swap
+    - [Maintainable Codebase](../principles/maintainable-codebase.md) - Maintained dependencies reduce maintenance burden
+    - [Agent Autonomy](../principles/agent-autonomy.md) - Agents benefit from up-to-date dependencies with accurate documentation
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Checked package release dates for all dependencies
+    - [ ] Identified packages with no releases in 2+ years
+    - [ ] Ran \`npm outdated\` to find major version drift
+    - [ ] Flagged packages more than 2 major versions behind
+    - [ ] Checked deprecation status of all dependencies
+    - [ ] Searched for packages with known better-maintained alternatives
+    - [ ] Documented each concern with package name, version, type, and suggested action
+    - [ ] Created ideas for any dependency health improvements needed
+  `;
+}
+function ciDevelopmentParity() {
+  return dedent`
+    # CI / Development Parity
+
+    Identify discrepancies between checks run locally via \`dust check\` and those run in CI.
+
+    ${ideasHint}
+
+    ## Context
+
+    When developers run different checks locally than CI runs remotely, several problems emerge:
+
+    1. **False confidence** - CI might pass while local checks fail, or vice versa
+    2. **Wasted cycles** - Developers push code that passes locally only to have CI fail
+    3. **Agent confusion** - AI agents rely on consistent feedback; discrepancies trigger incorrect debugging paths
+
+    The [Reproducible Checks](../principles/reproducible-checks.md) principle ensures the same checks run everywhere.
+
+    ## Scope
+
+    This audit performs a bidirectional comparison:
+
+    1. **Checks in dust but not in CI** (local-only checks)
+    2. **Checks in CI but not in dust** (CI-only checks)
+
+    ## Analysis Steps
+
+    ### 1. Detect Local Checks
+
+    Read \`.dust/config/settings.json\` to identify checks configured for \`dust check\`:
+
+    \`\`\`json
+    {
+      "checks": [
+        { "name": "lint", "command": "eslint ." },
+        { "name": "typecheck", "command": "tsc --noEmit" },
+        { "name": "test", "command": "vitest run" }
+      ]
+    }
+    \`\`\`
+
+    Extract check names and commands for comparison.
+
+    ### 2. Parse CI Configuration
+
+    Search for CI workflow files and parse them for check commands:
+
+    - \`.github/workflows/*.yml\` (GitHub Actions)
+    - \`.gitlab-ci.yml\` (GitLab CI)
+    - \`.circleci/config.yml\` (CircleCI)
+
+    Look for these check categories in CI:
+
+    - **linting** - eslint, oxlint, biome lint, ruff, golangci-lint
+    - **formatting** - prettier, oxfmt, biome format, black, gofmt
+    - **type-checking** - tsc, mypy, pyright
+    - **build** - npm/bun/yarn build, go build, cargo build
+    - **unit-tests** - vitest, jest, pytest, go test, cargo test
+    - **unused-code** - knip
+
+    ### 3. Follow Indirect References
+
+    When CI runs commands like \`npm run check\` or \`./scripts/check.sh\`, follow one level of indirection:
+
+    1. If CI runs \`npm run check\`, check \`package.json\` scripts for what \`check\` executes
+    2. If CI runs a script file, read that script to identify the actual checks
+    3. Map these resolved commands back to check categories
+
+    Example indirect reference resolution:
+    \`\`\`yaml
+    # CI workflow runs:
+    - run: npm run check
+    \`\`\`
+
+    \`\`\`json
+    // package.json scripts section:
+    "check": "eslint . && tsc --noEmit"
+    \`\`\`
+
+    This resolves to: linting and type-checking in CI.
+
+    ### 4. Bidirectional Comparison
+
+    Compare check categories between local (dust) and CI:
+
+    | Category | In Dust | In CI | Gap |
+    |----------|---------|-------|-----|
+    | linting | ✓ | ✓ | None |
+    | type-checking | ✓ | ✗ | CI missing |
+    | tests | ✗ | ✓ | Dust missing |
+
+    ## Output
+
+    For each gap found, create an idea file with:
+
+    ### For Local-Only Checks (in dust, not in CI)
+
+    \`\`\`markdown
+    # Add [Check Name] to CI
+
+    The \`[check-name]\` check runs locally via \`dust check\` but is not run in CI.
+
+    ## Impact
+
+    - Developers may push code that passes locally but fails CI on other checks
+    - CI provides no coverage for [check category]
+    - The [Stop the Line](../principles/stop-the-line.md) principle is violated - problems aren't caught before merge
+
+    ## Suggested Fix
+
+    Add to \`.github/workflows/ci.yml\`:
+
+    \`\`\`yaml
+    - name: [Check Name]
+      run: [command]
+    \`\`\`
+
+    Or ensure CI runs \`dust check\` which includes this check.
+    \`\`\`
+
+    ### For CI-Only Checks (in CI, not in dust)
+
+    \`\`\`markdown
+    # Add [Check Name] to dust check
+
+    The \`[check-name]\` check runs in CI but is not configured in \`dust check\`.
+
+    ## Impact
+
+    - Developers don't get [check category] feedback until CI runs
+    - [Fast Feedback Loops](../principles/fast-feedback-loops.md) are broken - local checks give incomplete picture
+    - Agents may make changes that pass local checks but fail CI
+
+    ## Suggested Fix
+
+    Add to \`.dust/config/settings.json\`:
+
+    \`\`\`json
+    { "name": "[check-name]", "command": "[command]" }
+    \`\`\`
+    \`\`\`
+
+    ## Principles
+
+    - [Reproducible Checks](../principles/reproducible-checks.md) - Ensures same checks run everywhere
+    - [Stop the Line](../principles/stop-the-line.md) - Problems are caught at source, not downstream
+    - [Fast Feedback Loops](../principles/fast-feedback-loops.md) - Developers get consistent feedback locally before pushing
+    - [Agent Autonomy](../principles/agent-autonomy.md) - Agents can trust that passing local checks means CI will pass
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Read \`.dust/config/settings.json\` and extracted check categories
+    - [ ] Parsed CI configuration files for check commands
+    - [ ] Followed indirect references (npm run scripts, shell scripts) one level deep
+    - [ ] Identified local-only checks (in dust but not CI)
+    - [ ] Identified CI-only checks (in CI but not dust)
+    - [ ] Created idea files for each gap with suggested fix
+    - [ ] Each idea links to relevant principles
+  `;
+}
+function commitMessageQuality() {
+  return dedent`
+    # Commit Message Quality
+
+    Review recent commits for message quality and traceability issues.
+
+    ${ideasHint}
+
+    ## Context
+
+    The [Traceable Decisions](../principles/traceable-decisions.md) principle emphasizes that commit history should explain why changes were made. Good commit messages help agents understand project history and make better decisions. This audit evaluates commit message quality itself, not the code changes.
+
+    ## Scope
+
+    Analyze the last 50 commits for these quality issues:
+
+    1. **Generic messages** - Non-descriptive messages like "fix", "update", "WIP", "changes", "stuff", "misc"
+    2. **Missing why** - Messages that describe what changed but not why
+    3. **Breaking changes** - Breaking commits without explanation of impact
+    4. **Multi-concern commits** - Commits that bundle unrelated changes
+    5. **Missing links** - Commits without links to related issues, tasks, or context
+
+    ## Analysis Steps
+
+    ### 1. Gather Recent Commits
+
+    Run \`git log -50 --pretty=format:"%H|%s|%b---END---"\` to get recent commits with their full messages.
+
+    ### 2. Detect Generic Messages
+
+    Flag commits where the subject line:
+    - Is a single word like "fix", "update", "changes", "WIP", "stuff", "misc", "cleanup"
+    - Starts with generic verbs without context: "Fix bug", "Update file", "Change code"
+    - Is very short (under 10 characters) without meaningful content
+
+    Example findings:
+    \`\`\`markdown
+    ### Generic: abc1234
+    - **Message**: "fix"
+    - **Issue**: Single-word message provides no context
+    - **Suggestion**: Describe what was fixed and why, e.g., "Fix null pointer when user has no email"
+    \`\`\`
+
+    ### 3. Detect Missing "Why"
+
+    Flag commits where:
+    - The subject describes what changed but the body is empty or doesn't explain motivation
+    - Technical changes lack business or user context
+    - Refactoring commits don't explain why the refactoring was needed
+
+    Look for these patterns that suggest missing "why":
+    - "Add X" without explaining why X was needed
+    - "Remove X" without explaining why X was unnecessary
+    - "Refactor X" without explaining what problem the refactoring solves
+
+    Example finding:
+    \`\`\`markdown
+    ### Missing Why: def5678
+    - **Message**: "Add caching to API calls"
+    - **Issue**: Doesn't explain why caching was added (performance problem? rate limits? user experience?)
+    - **Suggestion**: Include the motivation, e.g., "Add caching to API calls to reduce rate limit errors during high traffic"
+    \`\`\`
+
+    ### 4. Flag Breaking Changes Without Impact
+
+    Identify breaking changes by looking for:
+    - Subject contains "BREAKING", "breaking", or "!"
+    - Changes to public APIs, configuration schemas, database migrations
+    - Removal of features or options
+
+    Flag if the body doesn't explain:
+    - What exactly breaks
+    - Who is affected
+    - How to migrate
+
+    Example finding:
+    \`\`\`markdown
+    ### Breaking Without Impact: ghi9012
+    - **Message**: "BREAKING: Remove legacy auth"
+    - **Issue**: Doesn't explain impact or migration path
+    - **Suggestion**: Add body explaining: "Removes support for v1 auth tokens. Users must regenerate tokens via /settings. This affects deployments using tokens created before 2024."
+    \`\`\`
+
+    ### 5. Detect Multi-Concern Commits
+
+    Use \`git show --stat <hash>\` to get changed files per commit.
+
+    Flag commits that appear to bundle unrelated changes:
+    - Files across multiple unrelated modules or directories
+    - Mix of feature code and unrelated refactoring
+    - Multiple distinct logical changes in one commit
+
+    Look for signals like:
+    - Changes to both frontend and backend for unrelated features
+    - Test files for different features modified together
+    - Configuration changes bundled with unrelated code changes
+
+    Example finding:
+    \`\`\`markdown
+    ### Multi-Concern: jkl3456
+    - **Message**: "Add user dashboard and fix email validation"
+    - **Files Changed**: src/dashboard/*, src/email/*, tests/email/*
+    - **Issue**: Bundles unrelated features - dashboard addition and email validation fix
+    - **Suggestion**: Split into atomic commits: one for the dashboard feature, one for the email fix
+    \`\`\`
+
+    ### 6. Check for Missing Links
+
+    Flag commits that reference issues or tasks without links:
+    - Mentions "the bug", "the issue", "the task" without a link or ID
+    - Describes a problem without linking to where it was reported
+    - References external context without providing a way to access it
+
+    Also note commits for significant features or bug fixes that lack any external reference.
+
+    Example finding:
+    \`\`\`markdown
+    ### Missing Link: mno7890
+    - **Message**: "Fix the authentication bug reported last week"
+    - **Issue**: References a bug report but doesn't link to it
+    - **Suggestion**: Include issue reference, e.g., "Fix authentication timeout (fixes #123)" or link to discussion
+    \`\`\`
+
+    ## Output
+
+    For each quality issue found, create an idea file documenting:
+
+    1. **Commit hash and message** - The specific commit with the issue
+    2. **Type of issue** - One of: generic, missing-why, breaking-without-impact, multi-concern, missing-link
+    3. **Suggested improvement** - Concrete guidance for future commits
+
+    Group related issues into a single idea file if they suggest a systemic pattern (e.g., "Multiple commits lack issue links" rather than one idea per commit).
+
+    ## Principles
+
+    - [Traceable Decisions](../principles/traceable-decisions.md) - Commit history should explain why changes were made
+    - [Atomic Commits](../principles/atomic-commits.md) - Each commit should tell a complete story
+    - [Agent Autonomy](../principles/agent-autonomy.md) - Agents learn from commit history to understand project patterns
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - [ ] Reviewed last 50 commits for quality issues
+    - [ ] Identified commits with generic/non-descriptive messages
+    - [ ] Identified commits missing "why" context
+    - [ ] Identified breaking changes without impact documentation
+    - [ ] Identified commits bundling unrelated changes
+    - [ ] Identified commits missing links to issues/tasks
+    - [ ] Created idea files for patterns found
+    - [ ] Each idea includes concrete suggestions for improvement
   `;
 }
 var stockAuditFunctions = {
   "agent-developer-experience": agentDeveloperExperience,
+  "agent-instruction-quality": agentInstructionQuality,
+  algorithms,
+  "checks-audit": checksAuditTemplate,
+  "ci-development-parity": ciDevelopmentParity,
+  "commit-message-quality": commitMessageQuality,
+  "dependency-health": dependencyHealth,
+  "documentation-drift": documentationDrift,
   "component-reuse": componentReuse,
   "coverage-exclusions": coverageExclusions,
   "data-access-review": dataAccessReview,
   "dead-code": deadCode,
+  "design-patterns": designPatterns,
   "error-handling": errorHandling,
   "facts-verification": factsVerification,
+  "feedback-loop-speed": feedbackLoopSpeed,
   "global-state": globalState,
   "ideas-from-commits": ideasFromCommits,
   "ideas-from-principles": ideasFromPrinciples,
+  "idiomatic-style": idiomaticStyle,
+  "logging-and-traceability": loggingAndTraceability,
   "naming-consistency": namingConsistency,
   "performance-review": performanceReview,
   "primitive-obsession": primitiveObsession,
@@ -1118,12 +2625,14 @@ var stockAuditFunctions = {
   "single-responsibility-violations": singleResponsibilityViolations,
   "slow-tests": slowTests,
   "stale-ideas": staleIdeas,
+  "test-assertions": testAssertions,
   "test-coverage": testCoverage,
+  "test-pyramid": testPyramid,
   "ubiquitous-language": ubiquitousLanguage,
   "ux-audit": uxAudit
 };
 function loadStockAudits() {
-  return Object.entries(stockAuditFunctions).sort(([a], [b]) => a.localeCompare(b)).map(([name, render]) => {
+  return Object.entries(stockAuditFunctions).toSorted(([a], [b]) => a.localeCompare(b)).map(([name, render]) => {
     const template = render();
     const description = extractOpeningSentence(template);
     return { name, description, template };
@@ -1173,7 +2682,7 @@ function buildAuditsRepository(fileSystem, dustPath) {
     }
     if (fileSystem.exists(userAuditsPath)) {
       const files = await fileSystem.readdir(userAuditsPath);
-      const mdFiles = files.filter((f) => f.endsWith(".md")).sort();
+      const mdFiles = files.filter((f) => f.endsWith(".md")).toSorted();
       for (const file of mdFiles) {
         const name = basename(file, ".md");
         const filePath = `${userAuditsPath}/${file}`;
@@ -1195,7 +2704,7 @@ function buildAuditsRepository(fileSystem, dustPath) {
   return {
     async listAudits() {
       const auditsMap = await loadAllAudits();
-      return Array.from(auditsMap.values()).sort((a, b) => a.name.localeCompare(b.name));
+      return Array.from(auditsMap.values()).toSorted((a, b) => a.name.localeCompare(b.name));
     },
     async parseAudit(options) {
       const auditsMap = await loadAllAudits();