@joshski/dust 0.1.108 → 0.1.109

package/dist/audits.js

@@ -510,6 +510,72 @@ function deadCode() {
     - No changes to files outside \`.dust/\`
   `;
 }
+function directoryHierarchy() {
+  return dedent`
+    # Directory Hierarchy
+
+    Review directory structure and create improvement ideas.
+
+    ${ideasHint}
+
+    ## Scope
+
+    Analyze the project's directory organization for these issues:
+
+    1. **Concern mixing** - Directories containing files that serve different purposes
+    2. **Missing grouping** - Related files scattered across multiple locations
+    3. **Depth inconsistency** - Similar directories at inconsistent depths
+    4. **Naming inconsistency** - Directory names that don't follow established patterns
+    5. **Singleton directories** - Directories with only a single file or subdirectory
+    6. **Orphaned files** - Files at inappropriate directory levels
+
+    ## Analysis Steps
+
+    1. **Explore the directory tree** - Walk the project's file system recursively, excluding \`node_modules\`, \`.git\`, \`dist\`, \`build\`, \`coverage\`, and other common build artifact directories
+    2. **Identify issues** - For each of the issue types listed above, look for concrete examples in the directory structure
+    3. **Create ideas** - For each issue found, create an idea file in \`.dust/ideas/\` with:
+       - Descriptive filename based on the issue type and affected paths
+       - The specific paths affected
+       - Why the current structure is problematic
+       - A proposed reorganization
+       - Migration complexity estimate (low/medium/high)
+
+    ## Output Format
+
+    Each idea file should follow this structure:
+
+    \`\`\`markdown
+    # [Issue Type]: [Brief Description]
+
+    ## Current Structure
+
+    [List specific paths from affectedPaths]
+
+    ## Problem
+
+    [Description of why this is problematic]
+
+    ## Proposed Solution
+
+    [Suggested reorganization]
+
+    ## Migration Complexity
+
+    [Low/Medium/High with brief rationale]
+    \`\`\`
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Explored the directory tree excluding standard build/tool directories
+    - Created idea files for all findings in \`.dust/ideas/\`
+    - Each idea includes specific paths, problem description, proposed solution, and complexity
+    - No changes to files outside \`.dust/\`
+  `;
+}
 function documentationDrift() {
   return dedent`
     # Documentation Drift
@@ -660,6 +726,110 @@ function factsVerification() {
     - No changes to files outside \`.dust/\`
   `;
 }
+function factsExpansion() {
+  return dedent`
+    # Facts Expansion
+
+    Review the codebase for significant facts that should be documented in \`.dust/facts/\`.
+
+    ${ideasHint}
+
+    ## Context
+
+    Facts capture how things work today, providing context for agents and contributors. However, not all significant aspects of the codebase are currently documented as facts. This creates gaps where agents working in specific areas may lack important context that isn't obvious from scanning code or having prior framework knowledge.
+
+    ## Applicability
+
+    This audit applies to all codebases. If \`.dust/facts/\` does not exist, the audit will identify initial facts to document.
+
+    ## Scope
+
+    Analyze the codebase for undocumented facts across these areas:
+
+    ### Architectural Decisions
+    - Separation of concerns patterns not enforced by directory structure
+    - Dependency flow rules (e.g., what can depend on what)
+    - Layer boundaries and their purposes
+    - Module initialization order requirements
+    - Plugin or extension mechanisms
+
+    ### Implementation Conventions
+    - Naming patterns for specific types of code (factories, builders, validators)
+    - Error handling conventions (when to throw vs return errors)
+    - Async/await patterns and Promise handling
+    - Resource cleanup patterns
+    - State management approaches
+
+    ### External Integration Points
+    - CLI command structure and parsing approach
+    - Event emission patterns
+    - File system conventions
+    - Process spawning patterns
+    - Network communication protocols
+
+    ### Performance Characteristics
+    - Known performance bottlenecks
+    - Caching strategies
+    - Lazy loading patterns
+    - Resource pooling approaches
+    - Optimization trade-offs
+
+    ### Historical Context
+    - Migration paths from previous approaches
+    - Deprecated patterns still present in legacy code
+    - Trade-offs made in past decisions
+    - Features that were removed and why
+
+    ## Analysis Approach
+
+    1. **Scan for patterns** - Look for repeated implementation patterns across multiple files
+    2. **Identify conventions** - Find coding conventions that aren't enforced by linters
+    3. **Review configuration** - Document configuration systems and their purposes
+    4. **Trace data flows** - Identify how data moves through the system
+    5. **Check existing facts** - Compare findings against what's already documented in \`.dust/facts/\`
+    6. **Filter for significance** - Only suggest facts that would genuinely help future agents (facts that aren't obvious from code inspection or general framework knowledge)
+
+    ## Significance Criteria
+
+    A fact is worth documenting if:
+    - It's not obvious from reading the code in isolation
+    - It represents a project-specific decision or convention
+    - Future agents would benefit from knowing it before making changes
+    - It documents framework patterns actually used in this project
+
+    ## Output Format
+
+    For each suggested fact, create an idea file in \`.dust/ideas/\` that includes:
+
+    ### Fact Title
+    A clear, concise title for the proposed fact.
+
+    ### Why This Matters
+    Explanation of why this fact would be valuable to document (what gaps it fills, what problems it prevents).
+
+    ### What to Document
+    Specific aspects to cover in the fact file.
+
+    ### Where to Look
+    File paths or code locations that demonstrate this fact.
+
+    ### Example Content
+    A sketch of what the fact file might contain (2-3 sentences showing the style and key points).
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Analyzed codebase for undocumented patterns across all specified areas
+    - Compared findings against existing facts in \`.dust/facts/\`
+    - Applied significance criteria to filter suggestions
+    - Created idea files for each suggested fact with complete metadata
+    - Each idea includes: fact title, why it matters, what to document, where to look, example content
+    - No changes to files outside \`.dust/\`
+  `;
+}
 function feedbackLoopSpeed() {
   return dedent`
     # Feedback Loop Speed
@@ -670,7 +840,7 @@ function feedbackLoopSpeed() {
 
     ## 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.
+    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.
 
@@ -1116,6 +1286,223 @@ function ideasFromPrinciples() {
     - No changes to files outside \`.dust/\`
   `;
 }
+function incidentalTestDetails() {
+  return dedent`
+    # Incidental Test Details
+
+    Identify tests with overly specific data and other incidental details that obscure test intent.
+
+    ${ideasHint}
+
+    ## Context
+
+    Test clarity suffers when tests include incidental complexity — details that aren't relevant to what's being tested. Overly specific data, unused properties, magic numbers, excessive mocking, and complex nested structures all make tests harder to understand and maintain. This audit identifies these patterns as candidates for simplification.
+
+    The audit flags patterns for review without making judgments about whether they're necessary in specific cases. Some tests legitimately need complex setup to verify specific behaviors; the goal is to surface candidates so agents can evaluate each case and simplify where appropriate.
+
+    ## Guidance
+
+    ### Readable Test Data
+
+    Test data setup should use natural structures that mirror what they represent.
+
+    When test data is easy to read, tests become self-documenting. A file system hierarchy expressed as a nested object immediately conveys structure, while a flat Map with path strings requires mental parsing to understand the relationships.
+
+    Prefer literal structures that visually match the domain:
+
+    \`\`\`javascript
+    // Avoid: flat paths that obscure hierarchy
+    const fs = createFileSystemEmulator({
+      files: new Map([['/project/.dust/principles/my-goal.md', '# My Goal']]),
+      existingPaths: new Set(['/project/.dust/ideas']),
+    })
+
+    // Prefer: nested object that mirrors file system structure
+    const fs = createFileSystemEmulator({
+      project: {
+        '.dust': {
+          principles: {
+            'my-goal.md': '# My Goal'
+          },
+          ideas: {}
+        }
+      }
+    })
+    \`\`\`
+
+    The nested form:
+    - Shows parent-child relationships through indentation
+    - Makes empty directories explicit with empty objects
+    - Requires no mental path concatenation to understand structure
+
+    ### Comprehensive Assertions
+
+    Assert the whole, not the parts.
+
+    When you break a complex object into many small assertions, a failure tells you *one thing that's wrong*. When you assert against the whole expected value, the diff tells you *what actually happened versus what you expected* — the full picture, in one glance.
+
+    Small assertions are like yes/no questions to a witness. A whole-object assertion is like asking "tell me what you saw."
+
+    Collapse multiple partial assertions into one comprehensive assertion:
+
+    \`\`\`javascript
+    // Fragmented — each failure is a narrow keyhole
+    expect(result.name).toBe("Alice");
+    expect(result.age).toBe(30);
+    expect(result.role).toBe("admin");
+
+    // Whole — a failure diff tells the full story
+    expect(result).toEqual({
+      name: "Alice",
+      age: 30,
+      role: "admin",
+    });
+    \`\`\`
+
+    If \`role\` is \`"user"\` and \`age\` is \`29\`, the fragmented version stops at the first failure. The whole-object assertion shows both discrepancies at once, in context.
+
+    ### Self-Diagnosing Tests
+
+    When a big test fails, it should be self-evident how to diagnose and fix the failure.
+
+    The more moving parts a test has — end-to-end, system, integration — the more critical this becomes. A test that fails with \`expected true, received false\` forces the developer (or agent) to re-run, add logging, and guess. A test that fails with a rich diff showing the actual state versus the expected state turns diagnosis into reading.
+
+    Anti-patterns:
+
+    **Boolean flattening** — collapsing a rich value into true/false before asserting:
+    \`\`\`javascript
+    // Bad: "expected true, received false" — what events arrived?
+    expect(events.some(e => e.type === 'check-passed')).toBe(true)
+
+    // Good: shows the actual event types on failure
+    expect(events.map(e => e.type)).toContain('check-passed')
+    \`\`\`
+
+    **Length-only assertions** — checking count without showing contents:
+    \`\`\`javascript
+    // Bad: "expected 2, received 0" — what requests were captured?
+    expect(requests.length).toBe(2)
+
+    // Good: shows the actual requests on failure
+    expect(requests).toHaveLength(2)  // vitest shows the array
+    \`\`\`
+
+    **Silent guards** — using \`if\` where an assertion belongs:
+    \`\`\`javascript
+    // Bad: silently passes when settings is undefined
+    if (settings) {
+      expect(JSON.parse(settings).key).toBeDefined()
+    }
+
+    // Good: fails explicitly if settings is missing
+    expect(settings).toBeDefined()
+    const parsed = JSON.parse(settings!)
+    expect(parsed.key).toBeDefined()
+    \`\`\`
+
+    ### Functional Core, Imperative Shell
+
+    Separate code into a pure "functional core" and a thin "imperative shell." The core takes values in and returns values out, with no side effects. The shell handles I/O and wires things together.
+
+    Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves.
+
+    The functional core contains business logic as pure functions that take values and return values. The imperative shell sits at the boundary, reading input, calling into the core, and performing side effects with the results. This keeps the majority of code easy to test (no mocks or stubs needed for pure functions) and makes the I/O surface area small and explicit.
+
+    ## Scope
+
+    Search for test files and analyze them for clarity issues:
+
+    1. **Test files** - Files matching \`*.test.ts\`, \`*.test.js\`, \`*.spec.ts\`, \`*.spec.js\`
+       - Include unit, integration, and system tests
+       - Exclude exploratory test files
+
+    2. **Patterns to identify**:
+       - Object literals with unused properties in test setup
+       - Magic numbers without semantic meaning
+       - Excessive mock/stub setup
+       - Complex nested structures where simpler ones would suffice
+       - Brittle string assertions coupled to formatting
+       - Boolean flattening (testing \`.toBe(true)\` instead of showing actual values)
+       - Length-only assertions (testing \`.length\` instead of \`.toHaveLength()\`)
+       - Silent guards (using \`if\` where assertions belong)
+
+    ## Analysis Steps
+
+    1. **Find test files**
+       - Search for \`**/*.test.ts\`, \`**/*.test.js\`, \`**/*.spec.ts\`, \`**/*.spec.js\`
+       - Filter out exploratory tests
+
+    2. **Analyze each test file**
+       - Look for object literals in test setup with properties that aren't used in assertions
+       - Identify numeric literals that lack semantic meaning (e.g., \`42\`, \`123\` without explaining what they represent)
+       - Count mock/stub setup lines relative to actual test logic
+       - Check for deeply nested test data structures (3+ levels)
+       - Find string assertions that compare exact formatting (spaces, newlines, etc.) rather than semantic content
+       - Detect boolean flattening patterns (\`.some()\`, \`.every()\`, \`.includes()\` followed by \`.toBe(true/false)\`)
+       - Find length checks using \`.length\` property instead of \`.toHaveLength()\`
+       - Locate conditional logic in tests (\`if\` statements) that should be assertions
+
+    3. **Create ideas for issues found**
+       - Group issues by test file
+       - For each file with issues, create an idea file documenting:
+         - Test file path
+         - List of patterns found with line numbers
+         - Pattern categories
+         - Current problematic patterns
+         - Recommended refactoring approaches
+
+    ## Output Format
+
+    For each test file with clarity issues, create an idea file with:
+
+    ### Title
+    "Simplify test data in [filename]"
+
+    ### Content Structure
+    \`\`\`markdown
+    # Simplify test data in [filename]
+
+    The test file \`[path]\` contains incidental details that obscure test intent.
+
+    ## Issues Found
+
+    ### [Pattern Name] (line X)
+    - **Current**: \`[code snippet]\`
+    - **Issue**: [explanation of how this obscures intent]
+    - **Recommendation**: [specific simplification guidance]
+
+    [Repeat for each issue]
+    \`\`\`
+
+    ## Applicability
+
+    This audit applies to codebases with test files. If the codebase has no test files (\`*.test.ts\`, \`*.spec.js\`, etc.), document that finding and skip the detailed analysis.
+
+    ## Focus
+
+    This audit focuses purely on test clarity — whether tests clearly communicate intent. It does not evaluate test performance or execution speed.
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Searched for all test files in the codebase
+    - Analyzed test files for incidental complexity patterns
+    - Identified tests with unused properties in setup data
+    - Found magic numbers lacking semantic meaning
+    - Flagged excessive mock/stub setup
+    - Located complex nested structures
+    - Detected brittle string assertions
+    - Found boolean flattening patterns
+    - Located length-only assertions
+    - Identified silent guards (if statements in tests)
+    - Created idea files for each test file with findings
+    - Each idea includes: file path, issues with line numbers, pattern categories, current patterns, recommendations
+    - No changes to files outside \`.dust/\`
+  `;
+}
 function commitReview() {
   return dedent`
     # Commit Review
@@ -1126,7 +1513,13 @@ function commitReview() {
 
     ## Scope
 
-    Analyze commits since the last commit-review audit (check \`.dust/done/\` for previous runs). Focus on these signals:
+    Determine which commits to analyze:
+
+    1. Check VCS history for a prior commit-review run: \`git log --grep="Audit: Commit Review" -1 --format=%H\`
+    2. If found, analyze commits since that commit
+    3. If not found, analyze the last 20 commits as a fallback
+
+    Focus on these signals:
 
     1. **File churn** - Files modified frequently across multiple commits may have unclear responsibilities or be accumulating technical debt
     2. **Size growth** - Files that have grown significantly may benefit from decomposition
@@ -1743,7 +2136,7 @@ function testAssertions() {
 
     ## 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.
+    Comprehensive assertions (asserting the whole, not the parts) provide richer failure diagnostics. Self-diagnosing tests ensure that failures reveal enough context to guide a fix without re-running. This audit addresses complementary assertion quality signals not covered by those principles.
 
     ## Scope
 
@@ -1802,7 +2195,7 @@ function testAssertions() {
     - 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:
+    This works in tension with comprehensive assertions (asserting the whole, not the parts). Let context determine the balance:
     - Public API contracts → comprehensive assertions
     - Internal implementation tests → precise assertions
     - Snapshot tests → consider \`toMatchSnapshot()\` with care
@@ -1829,7 +2222,7 @@ function testAssertions() {
 
     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.
+    This does not mean "one \`expect\` call per test". A single logical assertion may require multiple \`expect\` calls to express (especially for complex state). Comprehensive assertions (asserting the whole, not the parts) often allow collapsing multiple calls into one whole-object assertion.
 
     The anti-pattern to avoid:
     \`\`\`javascript
@@ -1992,6 +2385,95 @@ function loggingAndTraceability() {
     - No changes to files outside \`.dust/\`
   `;
 }
+function testDeterminism() {
+  return dedent`
+    # Test Determinism
+
+    Audit unit tests for non-deterministic patterns that cause tests to produce inconsistent results across different environments or executions.
+
+    ${ideasHint}
+
+    ## Context
+
+    Tests must produce the same result regardless of where they run. Non-deterministic tests undermine confidence in CI, make debugging harder, and waste developer time chasing phantom failures. This audit identifies patterns that introduce non-determinism: time dependencies, randomness, environment variable access, filesystem operations, real timers, and platform-specific behavior.
+
+    ## Scope
+
+    Search for unit test files and analyze them for determinism issues:
+
+    1. **Unit test files** - Files matching \`*.test.ts\`, \`*.test.js\`, \`*.spec.ts\`, \`*.spec.js\`
+       - Exclude system test files (files containing 'system-test' or in 'system-tests/' directories)
+       - Exclude exploratory test files
+
+    2. **Issue categories to detect**:
+       - Time dependencies (\`Date.now()\`, \`new Date()\`) — should use dependency injection or stubbed time
+       - Randomness (\`Math.random()\`, \`crypto.randomBytes()\`, \`randomUUID()\`) — should use seeded random or injection
+       - Environment variables (\`process.env.VARIABLE\` without \`stubEnv\`) — should use \`stubEnv()\` or pass env as a parameter
+       - Filesystem operations (file reads/writes in unit tests) — should use in-memory filesystem or ensure cleanup
+       - Real timers (\`setTimeout\`, \`setInterval\` without fake timers) — should use \`vi.useFakeTimers()\`
+       - Platform-specific code (\`process.platform\`, \`__dirname\`, \`os.EOL\`) — should use dependency injection or normalize paths
+
+    ## Analysis Steps
+
+    1. **Find unit test files**
+       - Search for \`**/*.test.ts\`, \`**/*.test.js\`, \`**/*.spec.ts\`, \`**/*.spec.js\`
+       - Filter out system test files and exploratory tests
+
+    2. **Analyze each test file**
+       - Read the file content
+       - Look for the patterns listed above
+       - Note: patterns used inside stub/mock setups (\`vi.fn()\`, \`vi.mock()\`, \`vi.spyOn()\`), function parameter type annotations, or \`stubEnv()\` calls are not issues — they represent proper test practices
+
+    3. **Create ideas for issues found**
+       - Group issues by test file
+       - For each file with issues, create an idea file documenting:
+         - Test file path
+         - List of issues with line numbers
+         - Issue categories
+         - Current problematic patterns
+         - Recommended refactoring approaches
+
+    ## Output Format
+
+    For each test file with determinism issues, create an idea file with:
+
+    ### Title
+    "Refactor [filename] for test determinism"
+
+    ### Content Structure
+    \`\`\`markdown
+    # Refactor [filename] for test determinism
+
+    The test file \`[path]\` contains non-deterministic patterns that should be refactored.
+
+    ## Issues Found
+
+    ### [Category Name] (line X)
+    - **Pattern**: \`[code snippet]\`
+    - **Issue**: [explanation of why this is non-deterministic]
+    - **Recommendation**: [specific refactoring guidance]
+
+    [Repeat for each issue]
+    \`\`\`
+
+    ## Applicability
+
+    This audit applies to codebases with unit tests. If the codebase has no unit test files (\`*.test.ts\`, \`*.spec.js\`, etc.), document that finding and skip the detailed analysis.
+
+    ## Blocked By
+
+    (none)
+
+    ## Definition of Done
+
+    - Searched for unit test files (\`*.test.ts\`, \`*.test.js\`, \`*.spec.ts\`, \`*.spec.js\`)
+    - Excluded system test and exploratory test files
+    - Analyzed each unit test file for determinism issues
+    - Created idea files for test files containing determinism issues
+    - Each idea includes specific line numbers, patterns, and refactoring guidance
+    - No changes to files outside \`.dust/\`
+  `;
+}
 function testPyramid() {
   return dedent`
     # Test Pyramid
@@ -2360,7 +2842,7 @@ function ciDevelopmentParity() {
     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.
+    Every check must produce the same result regardless of who runs it, when, or on what machine.
 
     ## Scope
 
@@ -2450,7 +2932,7 @@ function ciDevelopmentParity() {
 
     - 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
+    - Problems aren't caught before merge—any worker should halt and fix a problem the moment they detect it
 
     ## Suggested Fix
 
@@ -2474,7 +2956,7 @@ function ciDevelopmentParity() {
     ## 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
+    - Fast feedback loops are broken—local checks give incomplete picture
     - Agents may make changes that pass local checks but fail CI
 
     ## Suggested Fix
@@ -2512,7 +2994,7 @@ function commitMessageQuality() {
 
     ## 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.
+    Commit history should explain why changes were made, not just what changed. Good commit messages help agents understand project history and make better decisions. This audit evaluates commit message quality itself, not the code changes.
 
     ## Scope
 
@@ -2653,20 +3135,14 @@ function commitMessageQuality() {
   `;
 }
 function suggestAudits() {
-  const auditList = Object.entries(stockAuditFunctions).filter(([name]) => name !== "suggest-audits").toSorted(([a], [b]) => a.localeCompare(b)).map(([name, render]) => {
-    const template = render();
-    const description = extractOpeningSentence(template);
-    return `- **${name}**: ${description}`;
-  }).join(`
-`);
-  let content = dedent`
+  return dedent`
     # Suggest Audits
 
     Analyze recent commits and create tasks for relevant audits to run.
 
     ## Context
 
-    This audit examines recent commit history and suggests which stock audits would be valuable based on what changed. Rather than manually selecting audits, this provides an automated way to maintain codebase health by matching recent work to appropriate audits.
+    This audit examines recent commit history and suggests which audits would be valuable based on what changed. Rather than manually selecting audits, this provides an automated way to maintain codebase health by matching recent work to appropriate audits.
 
     ## Commit Range
 
@@ -2678,21 +3154,17 @@ function suggestAudits() {
 
     ## Available Audits
 
-  `;
-  content += `
-
-` + auditList + `
-`;
-  content += dedent`
+    Run \`dust audit\` to list all available audits (including both stock audits and any repository-specific audits configured in \`.dust/config/audits/\`). This will show the audit name and description for each available audit.
 
     ## Analysis Steps
 
-    1. **Gather commits** - Get the list of commits in the determined range with their messages and changed files
-    2. **Categorize changes** - Group commits by the type of work (features, fixes, refactoring, tests, docs, config)
-    3. **Match to audits** - For each relevant audit, explain why recent changes make it valuable:
+    1. **List audits** - Run \`dust audit\` to get the complete list of available audits with descriptions
+    2. **Gather commits** - Get the list of commits in the determined range with their messages and changed files
+    3. **Categorize changes** - Group commits by the type of work (features, fixes, refactoring, tests, docs, config)
+    4. **Match to audits** - For each relevant audit, explain why recent changes make it valuable:
        - What specific commits or file changes triggered the suggestion?
        - What might the audit uncover given this context?
-    4. **Create tasks** - For each suggested audit, create a task file in \`.dust/tasks/\`
+    5. **Create tasks** - For each suggested audit, create a task file in \`.dust/tasks/\`
 
     ## Output
 
@@ -2741,7 +3213,6 @@ function suggestAudits() {
     - Each task explains why the audit is valuable given recent changes
     - No changes to files outside \`.dust/\`
   `;
-  return content;
 }
 var stockAuditFunctions = {
   "agent-developer-experience": agentDeveloperExperience,
@@ -2757,7 +3228,9 @@ var stockAuditFunctions = {
   "data-access-review": dataAccessReview,
   "dead-code": deadCode,
   "design-patterns": designPatterns,
+  "directory-hierarchy": directoryHierarchy,
   "error-handling": errorHandling,
+  "facts-expansion": factsExpansion,
   "facts-verification": factsVerification,
   "feedback-loop-speed": feedbackLoopSpeed,
   "flaky-tests": flakyTests,
@@ -2765,6 +3238,7 @@ var stockAuditFunctions = {
   "commit-review": commitReview,
   "ideas-from-principles": ideasFromPrinciples,
   "idiomatic-style": idiomaticStyle,
+  "incidental-test-details": incidentalTestDetails,
   "logging-and-traceability": loggingAndTraceability,
   "primitive-obsession": primitiveObsession,
   "repository-context": repositoryContext,
@@ -2774,6 +3248,7 @@ var stockAuditFunctions = {
   "stale-ideas": staleIdeas,
   "suggest-audits": suggestAudits,
   "test-assertions": testAssertions,
+  "test-determinism": testDeterminism,
   "test-pyramid": testPyramid,
   "ubiquitous-language": ubiquitousLanguage,
   "ux-audit": uxAudit