Audit Code

Overview

Run an expert-panel audit with strict sequencing and one unified output document. Produce findings first, sorted by severity, with file references, exploit/perf/flow impact, and actionable fixes.

Load references/audit-framework.md before starting the analysis.

Required Inputs

Collect or infer the following:

• •Audit scope: paths, modules, PR diff, or whole repository.
• •Product context: PRD/spec/user stories, trust boundaries, and critical business flows.
• •Runtime context: deployment model, queue/cron/background jobs, traffic profile, data sensitivity, and abuse assumptions.
• •Constraints: timeline, acceptable risk, and preferred remediation style.

If product context is missing, state assumptions explicitly and continue.

Team Roles

Use exactly these roles:

• •Security expert
• •Performance expert
• •UX expert
• •DX expert
• •Edge case master
• •Tie-breaker team lead

The tie-breaker lead resolves conflicts, prioritizes issues, and produces the final single report.

Workflow

Follow this sequence every time:

1. •

   Build Context Read code + product flows. Identify assets, entry points, high-risk operations, privileged actions, external dependencies, and "failure hurts" journeys.

2. •

   Build Invariant Coverage Matrix Before specialist pass 1, map critical invariants to every mutating path (HTTP routes, webhooks, async jobs, scripts):

• •Data-integrity invariants: linked records, transaction boundaries, and conflict handling must preserve consistency.
• •Access lifecycle invariants: permission changes (disable/revoke/role change) must take effect across active credentials and privileged actions.
• •Input/protocol invariants: validation, canonicalization, parser behavior, and payload size/media-type policy must be consistent across equivalent paths.
• •State-transition invariants: lifecycle transitions (active/archived/deleted/expired) must be explicit, legal, and consistently enforced.
• •Idempotency/order invariants: retries, duplicates, and out-of-order events must not corrupt state or duplicate side effects.
• •Time-window invariants: timezone and boundary behavior (expiry, rollovers, DST) must be deterministic.
• •Resource-boundedness invariants: loops, fan-out, queues, and in-memory maps must have caps/backpressure/cleanup.
• •External dependency invariants: timeouts, partial failures, fallback behavior, and stale-cache behavior must be intentional.
• •Observability invariants: high-risk state changes and failures must emit actionable, traceable signals. Add domain-specific invariants discovered during context build; do not constrain to this list. Treat missing parity across equivalent paths as a finding candidate.

1. •Pass 1 Specialist Reviews Run role-specific analysis in this order:

• •Security
• •Performance
• •UX
• •DX
• •Edge case master Capture findings using the schema in references/audit-framework.md.

1. •Tie-Breaker Reconciliation Resolve disagreements:

• •Decide whether contested items are true issues.
• •Set severity and confidence.
• •Remove duplicates and merge overlapping findings.

1. •Cross-Review Pass 2 After edge-case findings, rerun specialists:

• •Security/Performance/UX/DX reassess prior findings and new edge-triggered scenarios.
• •Edge case master performs a final pass on residual risk after proposed mitigations.

1. •Final Report Publish one document from the tie-breaker lead with:

• •Findings first (ordered by severity, then blast radius, then exploitability).
• •Open questions/assumptions.
• •Remediation plan with priority, owner type, and verification tests.
• •Short executive summary at the end.

Quality Bar

Enforce these requirements:

• •Use concrete evidence with file references and line numbers where available.
• •Include reproduction steps for security/performance/edge findings when feasible.
• •Prefer actionable fixes over abstract advice.
• •Separate confirmed defects from speculative risks.
• •Mark confidence for each finding.
• •Run a cross-route consistency sweep: equivalent endpoints/jobs must enforce equivalent invariants.
• •Run a required runtime-agnostic edge sweep using references/audit-framework.md (Runtime-Agnostic Edge Sweep).
• •Verify deprecation path integrity: explicit failure semantics, replacement guidance, and docs/spec/skill parity.
• •For fan-out integration endpoints, verify bounded concurrency and partial-failure behavior expectations.
• •Verify state-switch UX integrity for whichever context selector exists in the product (for example workspace/account/tenant/environment): changing it should refresh active views and reset invalid local filters/groupings.
• •Verify partial-update invariants against resulting state (existing + patch), not only provided fields.
• •Verify remediation traceability: findings-to-fixes status should remain mapped in a live checklist/spec so handoff can continue without hidden assumptions.
• •For each High/Critical finding, include at least one focused regression test/check.

Safety and Policy Guardrails

Apply these guardrails while auditing:

• •Do not provide operational abuse instructions or exploit weaponization details.
• •Evaluate manipulative UX patterns as legal/trust/reputation risk, not as recommended growth tactics.
• •Prioritize user safety, system integrity, and maintainable engineering outcomes.

Output Format

Follow this response structure:

1. •

   Findings List only validated issues. Use the finding schema in references/audit-framework.md.

2. •

   Open Questions / Assumptions State missing context that could change priority or validity.

3. •

   Change Summary Summarize high-impact remediation themes in a few lines.

4. •

   Suggested Verification List focused tests/checks to confirm each major fix.

Runtime Heuristics

Always apply the runtime-agnostic checklist in references/audit-framework.md (Runtime-Agnostic Edge Sweep). If a stack-specific module exists in that file and matches the target stack, apply it as an additive overlay, not a replacement. If no module matches, infer and state the top stack-specific risk assumptions, then continue the audit.