audit-go-architecture

{!% require_skill 'go:go-code-standards' %!}

{!% require_skill 'go:go-architecture-standards' %!}

<objective> A JSON verdict on a Go architecture scope — APPROVED, or REJECTED with concern rows for dependency injection testability, mocking prohibition, execution-level accuracy, Go anti-patterns, and ancestor consistency. </objective>

<constraints>

• Read-only over the audited repository. Never edit files, stage changes, commit, or open pull requests.
• Produce only the JSON verdict described in <verdict_format>; finding messages state the violated rule and consequence, while corrective examples remain in references and standards.
• Judge only Go-specific architecture concerns: dependency injection, no-mocking, execution-level accuracy, Go anti-patterns, and ancestor consistency. Generic decision-record section structure, atemporal voice, and per-rule tag validity are outside this subject — a structural, voice, or tag finding is out of scope even when the target is an ADR.
• Treat PASS | FAIL | NOT_APPLICABLE as the only row vocabulary for this skill.

</constraints>

<audit_workflow> This audit judges the target it is given — an implementation architecture scope or an ADR's Go concerns — against the governing decision hierarchy already loaded when it runs.

After loading the shared Go standards, check for spx/local/go.md, spx/local/go-architecture.md, and spx/local/go-tests.md at the repository root. Read each file that exists and apply each as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.

Procedure:

1. Read repo-local Go overlays when present (spx/local/go.md, spx/local/go-architecture.md, spx/local/go-tests.md)
2. Read the architecture target completely — the implementation files or the ADR supplied as the target
3. Check testability constraints — ADR targets express them in ## Verification / ### Audit; implementation targets must conform to the loaded architecture decisions' DI and no-mocking constraints
4. Check for mocking language or invalid DI claims
5. Verify level accuracy when testing levels are mentioned
6. Check Go anti-patterns
7. Check consistency with ancestor ADRs/PDRs when applicable
8. Output the JSON verdict with overall set to APPROVED or REJECTED and every concern row populated

</audit_workflow>

<principles_to_enforce>

This skill checks only the Go-specific concerns:

1. Testability constraints: ADR targets express DI seams in ## Verification / ### Audit; implementation targets conform to loaded architecture decisions.
2. Mocking prohibition — a generated mock (gomock, mockery, moq) is never a DI seam; the prohibited and permitted seam shapes are <di_patterns> in /go-architecture-standards
3. Level accuracy when testing levels are mentioned — a remote API, SaaS system, browser UI, or deployed environment is Level 3, never Level 2; a boundary that reaches such a collaborator jumps from Level 1 to Level 3 with no Level 2 in between, per /go-architecture-standards <level_context>
4. Go anti-patterns — package-level mutable state, interfaces defined at the producer with one implementation, context.Context stored in structs, unowned goroutines, unsafe bypassing type design; the authoritative catalog and corrective examples are <anti_patterns>, <values_pointers_and_sharing>, <package_boundaries>, and <concurrency_and_context> in /go-code-standards
5. Ancestor consistency for product-tree work

Section structure, atemporal voice, and per-rule tag validity are NOT this skill's concern — they are judged against the canonical decision template, outside this Go-architecture subject.

</principles_to_enforce>

<what_to_avoid>

• Do not cite line numbers as the finding's identity; cite the rule, the seam, and the section of the ADR or the package of the implementation.
• Do not approve on an interface definition alone; a seam counts only when a Verification rule mandates its use or the implementation injects it.
• Do not accept "dependency injection" paired with a generated mock; DI delivers a controlled real implementation.
• Do reference the standards section a finding rests on by name, so the author reads the corrective example there.

</what_to_avoid>

<verdict_format>

Emit a structured verdict. The skill's entire output is the verdict payload.

The skill's overall is APPROVED iff every concern row is PASS or NOT_APPLICABLE; it is REJECTED if any concern is FAIL. Every NOT_APPLICABLE row explains why its concern does not apply. An unavailable required inspection is FAIL, never NOT_APPLICABLE. Findings use severity blocking or debt.

{
  "schema_version": 1,
  "skill": "audit-go-architecture",
  "target": "<architecture-scope>",
  "overall": "APPROVED | REJECTED",
  "rows": [
    { "name": "testability-in-verification", "status": "PASS | FAIL | NOT_APPLICABLE", "explanation": "<required when NOT_APPLICABLE>", "findings": [] },
    { "name": "mocking-prohibition", "status": "PASS | FAIL | NOT_APPLICABLE", "explanation": "<required when NOT_APPLICABLE>", "findings": [] },
    { "name": "level-accuracy", "status": "PASS | FAIL | NOT_APPLICABLE", "explanation": "<required when NOT_APPLICABLE>", "findings": [] },
    { "name": "anti-patterns", "status": "PASS | FAIL | NOT_APPLICABLE", "explanation": "<required when NOT_APPLICABLE>", "findings": [] },
    { "name": "ancestor-consistency", "status": "PASS | FAIL | NOT_APPLICABLE", "explanation": "<required when NOT_APPLICABLE>", "findings": [] }
  ],
  "metadata": { "branch": "<branch>" }
}

Each finding's rule carries the violation pattern (e.g., missing-testability, mocking-language, saas-l2); file is the relevant implementation file or ADR path; message carries the one-line violated rule and consequence, while observed and expected carry the evidence. Corrective examples and remediation narrative stay in the referenced example and standards files rather than the verdict.

</verdict_format>

<example_reference>

Read ${CLAUDE_SKILL_DIR}/references/example-audit.md for a complete rejected architecture review in Go terms.

</example_reference>

<success_criteria>

The verdict is sound when:

• Every applicable Go architecture concern row is evaluated, with inapplicable concerns marked NOT_APPLICABLE and explained rather than skipped.
• overall is REJECTED when any concern row is FAIL and APPROVED when every concern row is PASS or explained NOT_APPLICABLE; missing required context produces a failing row and REJECTED.
• Each rejecting finding names the relevant implementation file or ADR path, violated rule and consequence in message, and concrete evidence in observed and expected.
• No finding judges generic ADR structure, atemporal voice, or per-rule tag validity.
• The same architecture scope and governing context produce the same JSON verdict.

</success_criteria>