Universal Audit

Universal Audit - Formal Production Assurance

This skill executes the Universal Software Engineering Audit Specification v2.2 (bundled at spec/Universal_Software_Engineering_Audit_Specification.md). The spec is normative. This file is the execution procedure. When they conflict, the spec wins.

Core discipline, non-negotiable:

• Every conclusion traces to evidence. PASS requires affirmative evidence, never scanner silence.
• Insufficient evidence is UNVERIFIED, stated plainly, with what would verify it.
• Never invent defects, never soften verified risk, never pad findings to look thorough.
• The numeric score never overrides release gates.

Phase 0 - Engagement Setup (blocking)

1. Confirm the target: repo path, running URL, or both. Read package.json / requirements.txt / wrangler.toml / equivalent before anything else.
2. Fill the intake from references/templates/intake-template.md. Ask the operator only for items you cannot establish yourself. Missing inputs go to Audit Limitations, never silently assumed.
3. Declare: audit type, depth tier (rapid / standard / deep), environment, access level, assurance objective, and risk profile (P1–P6, see references/depth-and-profiles.md). If the operator did not specify depth, propose one with rationale and wait.
4. Assign the audit ID: AUD-[PRODUCT]-[YYYYMMDD]-[SEQ].
5. Rules of Engagement: this skill defaults to passive, read-only inspection. No load tests, no destructive actions, no auth bypass attempts, no tests against systems the operator does not own. Active testing requires the RoE template completed and explicit operator authorization recorded in the manifest.
6. Gate controls: evaluate GOV-SCOPE-001 and GOV-ROE-001 first. If either cannot PASS, the engagement is advisory only - say so now, not in the report.
7. Create the artifact directory: audits/<audit-id>/ in the project root (or an operator-specified location). Run scripts/init_audit_artifacts.py --audit-id <audit-id> --output audits/<audit-id> to create the initial manifest from assets/audit-manifest-template.json. It refuses to overwrite an existing directory.

Phase 1 - Control Selection

1. Load the catalog: spec Appendix A. Select every control at or below the declared tier (Rapid = R; Standard = R+S; Deep = R+S+D). Profile-critical controls are mandatory regardless of tier.
2. Mark NOT APPLICABLE controls with recorded justification. NA without justification is invalid.
3. Assign each selected control its scoring category from spec A.0. A control without a category is a validation failure.
4. Write selected-controls.json (schema in references/schemas/). This freezes the coverage denominator before any evidence is gathered - selection cannot be trimmed later to inflate coverage.

Phase 2 - Evidence Collection

Work the spec Section 12 order. For each selected control, gather the minimum PASS evidence listed in the catalog or stronger. Practical guidance per family is in references/control-procedures.md. Read references/release-evidence-catalog.md when choosing evidence for a release gate. Read docs/evidence-ledger-guide.md before recording evidence for the first time.

• Record every material observation in evidence-ledger.json: ID, class, timestamp, location (file:line, endpoint, config key), method, sanitized excerpt, limitations.
• Repository unavailable: source-dependent claims are UNVERIFIED - Runtime inference only.
• Tool output (linters, SCA, scanners) is evidence to assess, not a verdict. Validate before accepting severity.
• Sanitize as you go: no secrets, tokens, personal data, or working exploit payloads in the ledger.
• For large targets, fan evidence collection out to subagents by control family, one ledger merged afterward. Deduplicate observations across families before Phase 3.

Phase 3 - Findings and Status

1. Assign each selected control exactly one status: PASS / FAIL / WARN / NOTE / UNVERIFIED / NOT APPLICABLE.
2. Every FAIL and WARN becomes a finding using the twenty-field standard (spec Section 9), written to findings.json. Severity is impact, likelihood is separate, confidence is separate. Low-confidence concerns normally stay UNVERIFIED.
3. Consolidate duplicates around root causes. Apply the systemic-risk rule (spec 13.5) only when all four conditions hold.
4. WARN may not carry Critical severity. A WARN - High on a C3 control must survive the Phase 5 challenge or be reclassified FAIL - High.