audit-domain-12-missing

name	audit-domain-12-missing
description	Audit what a normal production app at this scale would have but is absent — health checks, error tracking, feature flags, audit logs, on-call. Run as part of /audit Phase E.

Skill: Audit Domain 12 — What's Missing But Expected

This skill audits one specific domain. It runs in an isolated subagent context spawned by the audit-orchestrator. The subagent loads this skill and the audit rules, runs against the audit scope, and returns a ~2K-token findings report.

Pre-flight

view @.claude/context/audit-rules.md

If you have findings from previous audit phases (hard stops, Tambon, blind spots), the orchestrator passes them as input. Use them — don't re-discover findings other phases already produced. Specifically:

• Hard stops related to this domain: (none — this domain has no hard-stop classes routing to it)
• Blind spots that route to this domain: (none — this domain has no blind-spot classes routing to it)

If the orchestrator didn't pass you these inputs, do NOT re-run the hard-stops or blind-spots walks. Audit your domain only and trust the orchestrator to stitch.

Scope

What's absent that should be present at this stage: health checks, error tracking (Sentry/etc.), feature flags, audit logs, on-call rotation, runbooks, incident response process.

Key questions to answer

For each, find the evidence and report it. The questions are the audit's spine — every finding maps back to one of them.

1. Is there a /health endpoint?
2. Is error tracking integrated (Sentry, Rollbar, Honeycomb)?
3. Is there a feature-flag system, or is everything env-toggled?
4. Are sensitive operations (admin changes, deletes) audit-logged?
5. Is there an on-call rotation / runbook?
6. Are backups configured and tested?

Files most likely to have findings

Don't read everything. Read these files first:

• anywhere a /health route would be
• main app initialization (where Sentry would init)
• any 'feature_flag' module
• audit log infrastructure
• backup scripts

If you exhaust these and the budget allows, expand outward. Otherwise, report what you found and note what you didn't read.

Process

1. Re-read the rules. R1-R7 apply to every finding. Especially R2 (quote before cite) — for a domain skill running in a subagent, the subagent's context is fresh; don't assume you remember a file from a previous turn.

2. Walk the key questions. For each question, run the relevant detection commands (greps, file reads, schema lookups). Capture evidence at path:line. Verify by reading the actual code.

3. Cross-reference orchestrator inputs. If the orchestrator passed hard-stops or blind-spots findings tagged for this domain, include them in your report. Don't re-investigate; just include with the provided evidence.

4. Triage. For each finding, set severity per the audit rubric and exploitability per R4.

5. Produce the domain report.

Output format

═══════════════════════════════════════════════════════════════════════
  DOMAIN 12: What's Missing But Expected
═══════════════════════════════════════════════════════════════════════

▶ FOUNDER VIEW

[2-4 sentences in plain English. Sample tone:]
What would an experienced engineer expect to see in a production app, that this app doesn't have? Absence is itself a signal.

▶ TECHNICAL EVIDENCE

Scope of this domain audit:
  Files read:        <count>
  Files skipped:     <count> (reason: outside scope or low-priority)

Findings:

  F-12.1 — <one-line title>
    Severity:        Critical | High | Medium | Low
    Exploitability:  EXPLOITABLE-NOW | EXPLOITABLE-LOW-EFFORT | BAD-PRACTICE | UNKNOWN
    Hard-stop:       H<N> if applicable
    Blind-spot:      B<N> if applicable

    Evidence:
      <path:line>  <one-line description>

    What's wrong:
      <one paragraph>

    Why it matters:
      <one sentence>

    Recommended fix:
      <one paragraph; for full fix prompt, use /audit-fix F-12.1>

    Verification after fix:
      <command>

  F-12.2 ...

Summary:
  Total findings: <count>
  By severity:    <counts>
  Most urgent:    <which finding ID>

[SECTION COMPLETE: Domain 12]

If the domain has zero findings:

▶ TECHNICAL EVIDENCE

  ✅ No findings in this domain.

  Verification:
    <commands run that produced no signal>

  Confidence: High | Medium | Low
  Reason for low confidence: <if applicable>

Failure modes to refuse

• ❌ Producing findings without path:line citations (R1)
• ❌ Citing a path you didn't read (R2)
• ❌ Re-running hard-stops or blind-spots walks (orchestrator did this)
• ❌ Including findings outside this domain's scope (route them to the right domain instead)
• ❌ Soft-pedaling a Critical to Medium because "it's a small app" (R3)
• ❌ Skipping section completion marker (R6)