[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FTRSR14A0MWRM7PMDZW4N":3,"skill-same:01M71FTRSR14A0MWRM7PMDZW4N":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71FTRSR14A0MWRM7PMDZW4N","audit-go-test",null,"Go test-evidence audit methodology — judges the Go tests in scope against the product-tree and Go-specific evidence properties.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-test\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"audit","audit go test","go","test","Bash","audit methodology","use","methodology","tests","git","grep","tool","read","scope","product","diff","properties","evidence","tree","2026-11-10 10:12:30",false,"---\nname: audit-go-test\ndescription: >-\n  Go test-evidence audit methodology — judges the Go tests in scope against\n  the product-tree and Go-specific evidence properties.\nallowed-tools: Read, Grep, Glob, Bash(git diff:*), {{! tool('use_skill') !}}\n---\n\n\u003Cobjective>\nA verdict on Go test evidence — APPROVED, or REJECTED with each finding naming the assertion or evidence artifact, the failed evidence property, and the evidence gap.\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\nThis audit is read-only. Produce a verdict over test evidence; never edit tests, production code, specs, fixtures, harnesses, generators, or project configuration.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\n\u003Cprerequisites>\n\n{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-test-standards' %!}\n\n{!% require_skill 'product-tree:audit-tests' %!}\n\n{!% require_skill 'product-tree:test' %!}\n\nRead local overlay files — each routes skill behavior to the product's governing specs and decisions; overlays supplement skills and do not supersede them:\n\nRead `spx\u002Flocal\u002Fgo.md` and `spx\u002Flocal\u002Fgo-tests.md` when they exist; otherwise apply the loaded skills only.\n\nUse skill `product-tree:contextualize` on the spec node under audit — `\u003CPRODUCT_TREE_CONTEXT>` marker must be present before Gate 1.\n\nThis audit runs no deterministic verification — no `gofmt`, `go vet`, `go test`, `go test -cover`, or any other project command. Spend the whole audit reading the evidence chain.\n\n\u003C\u002Fprerequisites>\n\n\u003Caudit_scope>\n\nBegin with the current governing spec and its current evidence links. A deleted Go test or test-infrastructure path belongs to this audit only when a current `[test]` assertion still links it or a current linked test still imports it. When the current spec carries no `[test]` link to the deleted path and no current evidence chain references it, classify the retired path as outside current Go test-evidence scope and return `NOT_APPLICABLE` for that path. Never demand restoration of deterministic evidence solely because the base revision or changeset deletion names the retired path. When a current `[test]` assertion still links a missing path, report missing evidence against that current assertion.\n\nUse read-only `git diff` only when the supplied changeset scope requires confirming whether an evidence path was deleted. Run no other shell command from this concern skill.\n\n\u003C\u002Faudit_scope>\n\n\u003Cstructural_reading>\nBefore judging evidence, read the in-scope test files for structural defects — by reading, never by running the project's gate. These are reading observations folded into Gate 1, not a separate deterministic gate:\n\n- **Filename policy** — each file MUST match `\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>]_test.go` (`\u003Cevidence>` ∈ scenario\u002Fmapping\u002Fconformance\u002Fproperty\u002Fcompliance, `\u003Clevel>` ∈ l1\u002Fl2\u002Fl3). The project's validation owns this convention; note a mismatch as a `filename_policy` finding carrying property `alignment` from the base `\u002Faudit-tests` enum — a filename that misdeclares its evidence type or level misaligns the file with the assertion it claims to evidence — and do not re-validate it.\n- **Build constraint** — an `l2` or `l3` file whose first line is not the matching `\u002F\u002Fgo:build l2` or `\u002F\u002Fgo:build l3` constraint runs in the default lane against infrastructure it declares absent there; note it as a `filename_policy` finding carrying property `alignment`.\n- **Test-file bindings** — apply the base `\u002Faudit-tests` semantic binding screen before coupling. A `:=`, `var`, `const`, table-row literal, closure parameter, or property-generated parameter is valid when it only receives an actual result, source-owned contract, generated value, harness observation, callback input, resource handle, or fixture path and introduces no data or policy. Emit a finding carrying property `declarations` and the base `\u002Faudit-tests` rule label the choice matches — `test-owned configuration` for runner settings, seed policy, retries, setup policy, or lifecycle policy, and `test-owned data` for hand-picked data, boundary bags, expected outputs, fixture contents, generator domains, or a table of author-invented rows presented as a mapping. Keep the two labels distinct. Keep every predicate and `testing.T` failure call in the linked test function or subtest; a binding, closure, or `t.Helper()`-marked function that moves a predicate or failure call out carries property `predicate-ownership`, rule `assertion-seam`, remediation target `test-file`.\n- **Source-file reads** — a test that reads production `.go` files (`os.ReadFile`, `embed` of a source path, `go\u002Fparser` over production code) asserts on source text, not behavior → prose-coupling REJECT in Gate 1 step `four_properties`. Inert fixture data is read by path from `internal\u002Ftestinfra\u002Ffixtures\u002Ftestdata\u002F`; co-located `spx\u002F...\u002Ftests\u002F` remains the home of typed assertion files. When a loaded overlay points to a governing product spec or decision that explicitly amends this contract, follow that declaration; the overlay does not redefine fixture placement itself.\n- **Disabled evidence** — a bare `t.Skip()` (no reason), skip-by-early-return, `t.SkipNow()`, or `panic(\"TODO\")` in a test body provides no evidence → REJECT in Gate 1 carrying property `coverage` from the base `\u002Faudit-tests` enum, since execution never reaches the assertion-relevant path. A reasoned `t.Skip(\"...\")` is acceptable in an `.l3_test.go` file only when a loaded product spec or decision declares that credentialed Level 3 lane and the suite declares that evidence optional; a missing mandatory dependency fails through `t.Fatal`, so a skip on it rejects. Outside `.l3_test.go`, reasoned skip is misplaced.\n- **Generated mock signal** — `gomock`, `mockery`, `moq`, `mock.Mock`, or a reassigned package-level function variable in a test is read and judged in Gate 1 step `controlled_implementations` against `\u002Ftest` Stage 5 exceptions.\n\n\u003C\u002Fstructural_reading>\n\n\u003Cgate_1_assertion>\nEntry point is the spec, not the test file.\n\nFor each assertion in the spec's Assertions section, execute steps 1-8 in order. First step failure rejects that assertion and moves to the next assertion.\n\n\u003Cstep name=\"challenge\">\nChallenge the assertion:\n\n- Does the assertion derive from an ancestor PDR or ADR claim in `\u003CPRODUCT_TREE_CONTEXT>`, or is it floating?\n- Is the assertion type correct for the claim?\n- Does it overlap with another assertion in the same node or parent?\n\nRecord challenge findings and continue unless the assertion type is invalid. A `challenge` finding carries property `alignment` from the base `\u002Faudit-tests` enum — the claim itself is malformed or misaligned with its governing decision.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"scope\">\nDecompose the assertion text into testable clauses.\n\nExample:\n\n| Assertion                                          | Clauses                                              |\n| -------------------------------------------------- | ---------------------------------------------------- |\n| \"MUST exit 0 with no stdout for invalid hook JSON\" | (1) invalid JSON input, (2) exit 0, (3) empty stdout |\n\nThe linked tests must exercise every clause with an assertion. A single assertion for a multi-clause claim is a `scope` finding carrying property `coverage` from the base `\u002Faudit-tests` enum — clauses of the claim go unexercised.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"evidence\">\nMatch the Go evidence method to the assertion type:\n\n| Type        | Required Go evidence                                                                           | Reject if                                 |\n| ----------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------- |\n| Scenario    | concrete inputs through the governed function, package, or binary                              | only existence or truthiness is checked   |\n| Mapping     | table-driven `t.Run` cases iterating a source-owned enumeration with at least two members      | one example stands in for a mapping       |\n| Conformance | parser, schema, protocol harness, CLI contract, or toolchain oracle for compile-time contracts | manual shape checks replace the validator |\n| Property    | `rapid` through the property harness with meaningful generators and invariants                 | examples are wrapped in property syntax   |\n| Compliance  | violating fixture or analyzer harness for a current `[test]` link                              | no violating input or rule oracle exists  |\n\nFor property tests, inspect the generator domain. `rapid.Just`, one-value ranges, or tiny enumerations reduce the property to examples unless the spec explicitly declares a finite set.\n\nAn assertion tagged `[audit:{rule-slug}]`, or the pathless `[audit]` that the foundation admits for a toolchain without slug support, carries no assertion type and is outside Go test-evidence scope. Skip it rather than treating the marker as test evidence.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"controlled_implementations\">\nJudge controlled implementations against `\u002Ftest` exceptions:\n\n| Exception                | Legitimate Go pattern                                                    |\n| ------------------------ | ------------------------------------------------------------------------ |\n| 1. Failure modes         | interface implementation returning deterministic errors                  |\n| 2. Interaction protocols | recording implementation capturing calls                                 |\n| 3. Time\u002Fconcurrency      | injected clock, deterministic channels, `synctest` where available       |\n| 4. Safety                | recording or no-op implementation preserving the seam                    |\n| 5. Combinatorial cost    | configurable in-memory implementation with real-shaped behavior          |\n| 6. Observability         | capture implementation for `slog` handlers, events, or serialized output |\n| 7. Contract probes       | `httptest` stub validated against the same contract schema               |\n\nGenerated mock frameworks, reassigned package-level function variables, or stubs that bypass the governed seam reject the assertion unless a Stage 5 exception applies and the real interface or protocol remains intact. Such a rejection carries property `falsifiability` from the base `\u002Faudit-tests` enum — a severed seam means no production mutation can break the test.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"oracle\">\nIdentify the source of every expected value.\n\nReject with an `oracle` finding carrying property `oracle-independence` and remediation target `independent-oracle` from the base `\u002Faudit-tests` enum when the expected value is derived from the package under test. This is distinct from `falsifiability`: an expected result computed by the same path that produces the actual result passes even when both are wrong. Proceed when the expected value comes from an independent source: the spec, an exported constant owned by a different package, an external protocol\u002Fschema, a fixture transcript, or a value hand-computed in the test.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"harness_chain\">\nTrace every test-infrastructure import:\n\n- imports from `\u003Cmodule>\u002Finternal\u002Ftestinfra\u002Fharnesses`, `\u003Cmodule>\u002Finternal\u002Ftestinfra\u002Fgenerators`, and `\u003Cmodule>\u002Finternal\u002Ftestinfra\u002Ffixtures` — the canonical home per the product's `test-infrastructure` PDR\n- non-canonical legacy locations that must be flagged as misplaced infrastructure: an in-package `testutil` or `testhelpers` package, an `export_test.go` that hands a harness or fixture to a test, a `testdata\u002F` directory outside `internal\u002Ftestinfra\u002Ffixtures\u002F`, or a `tests\u002F` subdirectory carrying non-test Go files\n- local functions inside `spx\u002F...\u002Ftests\u002F` — these are misplaced infrastructure when they own setup, reusable cases, fixture handling, generator selection, harness behavior, diagnostics, or source vocabulary\n- binary harnesses that build or resolve the product binary and hand it to `os\u002Fexec`\n\nOpen each harness. If the harness replaces the governed package instead of exercising it, reject with a `harness_chain` finding. Trace imports until the chain terminates at production code, fixture data, or framework\u002Flibrary code. If a harness lives in a non-canonical legacy location, surface an `extraction_target` finding pointing at `internal\u002Ftestinfra\u002F`.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"four_properties\">\nApply the Go supplements:\n\n- Coupling: classified from the full `\u003Csupplement property=\"coupling\">` taxonomy below — every category it names, never a subset\n- Falsifiability: concrete mutation named for every codebase path or binary contract\n- Alignment: every assertion clause maps to exercised test behavior\n- Coverage: read whether the test drives execution into the governed source path; no coverage tool is run\n\nFirst property failure rejects the assertion.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"coverage\">\nEstablish coverage by reading, never by running `go test -cover` or any other coverage tool. This audit runs no deterministic verification.\n\nTrace, by reading, whether the test drives execution into the governed source path:\n\n1. Read the governed source the assertion names and identify the assertion-relevant functions, branches, and lines.\n2. Read the test and follow what it calls into that source — directly, through a harness, or through the harness-provided binary for a binary contract.\n3. Judge whether the test's execution reaches the assertion-relevant path.\n\nA test that compiles against the governed package but never drives execution into the assertion-relevant path → REJECT with `coverage`; name the path the test fails to reach, traced from the code. When the assertion-relevant path is trivially total, annotate `saturated`.\n\u003C\u002Fstep>\n\nGate 1 status:\n\n- PASS if every assertion verdict is PASS.\n- FAIL if any assertion verdict is REJECT.\n\n\u003C\u002Fgate_1_assertion>\n\n\u003Cgate_2_architectural>\nRuns only if Gate 1 is PASS. Scan in-scope tests for repeated setup patterns that belong in shared test infrastructure.\n\nTrigger: two or more in-scope tests share any of these patterns:\n\n- identical product-binary build or resolution setup\n- repeated hook JSON builders\n- repeated transcript fixture writers\n- repeated tempdir\u002Fhome-directory scaffolding beyond a bare `t.TempDir()`\n- repeated stdout\u002Fstderr\u002Fexit-code comparison functions\n- repeated `slog` or debug capture setup\n\nEach finding names the pattern, lists at least two occurrences with file and line, and proposes the canonical home under `internal\u002Ftestinfra\u002F` — `harnesses` for shared resource mediators, `generators` for input factories, or `fixtures` for fixture-resolving code.\n\nGate 2 status:\n\n- PASS if no repeated setup pattern appears in two or more in-scope tests.\n- FAIL if any repeated setup pattern appears in two or more in-scope tests.\n\n\u003C\u002Fgate_2_architectural>\n\n\u003Cgo_supplements>\nApplied during Gate 1.\n\n\u003Csupplement property=\"coupling\">\n\nThis supplement specializes each category of the coupling taxonomy `\u002Faudit-tests` owns to Go paths. Classify from the table below rather than a subset of it; every category the canonical taxonomy names appears here, so a category missing from this table would silently narrow the verdict.\n\n| Category           | Definition                                                                                                                        | Verdict                                         |\n| ------------------ | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Direct             | Test calls the governed Go function, type, package, or binary                                                                     | Proceed                                         |\n| Indirect           | Test calls test infrastructure that calls the governed path                                                                       | Proceed after harness tracing                   |\n| Transitive         | Test calls a public consumer of the governed path                                                                                 | Proceed if the level matches                    |\n| Laundered indirect | Calls an `internal\u002Ftestinfra` package that exists only to expose hardcoded values back to the test                                | REJECT — laundering                             |\n| False              | Test imports the package but never calls assertion-relevant symbols                                                               | REJECT                                          |\n| Partial            | Test calls the right package with wrong inputs or wrong path                                                                      | REJECT                                          |\n| None               | Test imports only `testing` and third-party modules, with zero product-package coupling                                           | REJECT — tautology                              |\n| Severed            | Test or harness replaces the governed behavior with a mock, fake, generated mock, reassigned function variable, or bypassing stub | REJECT — coupling severed                       |\n| Prose-coupling     | Reads an authored prose\u002Fdoc body and asserts its content, including through a harness constant or an infrastructure reader        | REJECT — couples to authored text, not behavior |\n\nFramework\u002Flibrary imports such as `testing`, `context`, `os\u002Fexec`, `net\u002Fhttp\u002Fhttptest`, `pgregory.net\u002Frapid`, and `github.com\u002Fgoogle\u002Fgo-cmp\u002Fcmp` do not count as coupling by themselves. A harness-provided product binary run through `os\u002Fexec` counts as coupling to the named binary contract. The Prose-coupling row is the table-side form of the source-file read that `\u003Cstructural_reading>` screens for; both reach the same REJECT.\n\n\u003C\u002Fsupplement>\n\n\u003Csupplement property=\"falsifiability\">\nFor each codebase path, name a concrete mutation that would fail the test.\n\nExample:\n\n```text\nPackage: internal\u002Finstall\nMutation: Install writes block hook entries under PreToolUse instead of Stop\nImpact: install-tooling scenario test comparing settings JSON fails\n```\n\nReject when no mutation can be named, when generated mocks replace the governed behavior, or when golden files only capture hand-built fixtures.\n\u003C\u002Fsupplement>\n\n\u003Csupplement property=\"alignment\">\nAlignment passes when every assertion clause is exercised by at least one assertion and the test's evidence method matches the assertion type.\n\nReject when the test covers a nearby behavior, collapses clauses, uses one example for a mapping, or tests runtime behavior for a compile-time contract.\n\u003C\u002Fsupplement>\n\n\u003Csupplement property=\"coverage\">\nCoverage passes when reading the test against the governed source shows the test drives execution into the assertion-relevant path, or that path is trivially total (`saturated`) and the other three properties pass. No coverage tool is run — this audit establishes coverage by reading.\n\nCoverage notes do not rescue missing coupling, falsifiability, or alignment.\n\u003C\u002Fsupplement>\n\n\u003C\u002Fgo_supplements>\n\n\u003C\u002Faudit_workflow>\n\n\u003Cverdict_format>\n\nThis skill composes the base `\u002Faudit-tests` verdict: the row names (`gate-1-assertion`, `gate-2-architectural`) and the JSON schema are defined in its `\u003Cverdict_format>` and are not redefined here. This skill contributes Go-specific finding detail into those rows. The audit emits no `gate-0-deterministic` row — it runs no deterministic verification; the structural reading observations from `\u003Cstructural_reading>` are folded into the Gate 1 (`gate-1-assertion`) findings. Gate 2 extraction target: a package under `internal\u002Ftestinfra\u002F`, e.g. `internal\u002Ftestinfra\u002Fharnesses`, `internal\u002Ftestinfra\u002Fgenerators`, or `internal\u002Ftestinfra\u002Ffixtures` — never an in-package `testutil` or a `testdata\u002F` directory outside the fixtures package, which are legacy non-canonical locations.\n\nWhen `\u003Caudit_scope>` finds that a retired path has no current `[test]` assertion or current evidence-chain owner, emit this alternate concern result instead of the inherited rows:\n\n```json\n{\n  \"status\": \"NOT_APPLICABLE\",\n  \"subjects\": [\"\u003Cretired-repository-relative-path>\"],\n  \"explanation\": \"No current [test] assertion or evidence chain references the retired path.\"\n}\n```\n\nEmit this shape only when every supplied subject is outside current Go test-evidence scope. A current broken `[test]` link remains applicable and produces the inherited `REJECTED` verdict.\n\n\u003C\u002Fverdict_format>\n\n\u003Csuccess_criteria>\n\nThe Go test verdict is sound when:\n\n- Every applicable rule was judged: each in-scope assertion received every Gate 1 step and the `\u003Cstructural_reading>` observations (filename, build constraint, source-reads, disabled evidence, mock signals); Gate 2 was judged when Gate 1 passed and omitted only when Gate 1 rejected the evidence.\n- Every deleted Go test or test-infrastructure path was classified from current spec links and current evidence chains, with retired evidence returned as `NOT_APPLICABLE` and current broken `[test]` links reported as missing evidence.\n- Applicable scope states an overall `APPROVED` \u002F `REJECTED` with no assertion left unevaluated; a composition-only retired-path scope emits the defined `NOT_APPLICABLE` result.\n- Each `REJECT` finding is falsifiable: it names the assertion or evidence artifact, the failed property, the gate and step, and how the test could pass while the assertion is unfulfilled.\n- The same test node yields the same verdict regardless of run order (reproducible).\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nA verdict on Go test evidence — APPROVED, or REJECTED with each finding naming the assertion or evidence artifact, the failed evidence property, and the evidence gap.\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\nThis audit is read-only. Produce a verdict over test evidence; never edit tests, production code, specs, fixtures, harnesses, generators, or project configuration.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\n\u003Cprerequisites>\n\n{!% require_skill 'go:go-code-standards' %!}\n\n{!% require_skill 'go:go-test-standards' %!}\n\n{!% require_skill 'product-tree:audit-tests' %!}\n\n{!% require_skill 'product-tree:test' %!}\n\nRead local overlay files — each routes skill behavior to the product's governing specs and decisions; overlays supplement skills and do not supersede them:\n\nRead `spx\u002Flocal\u002Fgo.md` and `spx\u002Flocal\u002Fgo-tests.md` when they exist; otherwise apply the loaded skills only.\n\nUse skill `product-tree:contextualize` on the spec node under audit — `\u003CPRODUCT_TREE_CONTEXT>` marker must be present before Gate 1.\n\nThis audit runs no deterministic verification — no `gofmt`, `go vet`, `go test`, `go test -cover`, or any other project command. Spend the whole audit reading the evidence chain.\n\n\u003C\u002Fprerequisites>\n\n\u003Caudit_scope>\n\nBegin with the current governing spec and its current evidence links. A deleted Go test or test-infrastructure path belongs to this audit only when a current `[test]` assertion still links it or a current linked test still imports it. When the current spec carries no `[test]` link to the deleted path and no current evidence chain references it, classify the retired path as outside current Go test-evidence scope and return `NOT_APPLICABLE` for that path. Never demand restoration of deterministic evidence solely because the base revision or changeset deletion names the retired path. When a current `[test]` assertion still links a missing path, report missing evidence against that current assertion.\n\nUse read-only `git diff` only when the supplied changeset scope requires confirming whether an evidence path was deleted. Run no other shell command from this concern skill.\n\n\u003C\u002Faudit_scope>\n\n\u003Cstructural_reading>\nBefore judging evidence, read the in-scope test files for structural defects — by reading, never by running the project's gate. These are reading observations folded into Gate 1, not a separate deterministic gate:\n\n- **Filename policy** — each file MUST match `\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>]_test.go` (`\u003Cevidence>` ∈ scenario\u002Fmapping\u002Fconformance\u002Fproperty\u002Fcompliance, `\u003Clevel>` ∈ l1\u002Fl2\u002Fl3). The project's validation owns this convention; note a mismatch as a `filename_policy` finding carrying property `alignment` from the base `\u002Faudit-tests` enum — a filename that misdeclares its evidence type or level misaligns the file with the assertion it claims to evidence — and do not re-validate it.\n- **Build constraint** — an `l2` or `l3` file whose first line is not the matching `\u002F\u002Fgo:build l2` or `\u002F\u002Fgo:build l3` constraint runs in the default lane against infrastructure it declares absent there; note it as a `filename_policy` finding carrying property `alignment`.\n- **Test-file bindings** — apply the base `\u002Faudit-tests` semantic binding screen before coupling. A `:=`, `var`, `const`, table-row literal, closure parameter, or property-generated parameter is valid when it only receives an actual result, source-owned contract, generated value, harness observation, callback input, resource handle, or fixture path and introduces no data or policy. Emit a finding carrying property `declarations` and the base `\u002Faudit-tests` rule label the choice matches — `test-owned configuration` for runner settings, seed policy, retries, setup policy, or lifecycle policy, and `test-owned data` for hand-picked data, boundary bags, expected outputs, fixture contents, generator domains, or a table of author-invented rows presented as a mapping. Keep the two labels distinct. Keep every predicate and `testing.T` failure call in the linked test function or subtest; a binding, closure, or `t.Helper()`-marked function that moves a predicate or failure call out carries property `predicate-ownership`, rule `assertion-seam`, remediation target `test-file`.\n- **Source-file reads** — a test that reads production `.go` files (`os.ReadFile`, `embed` of a source path, `go\u002Fparser` over production code) asserts on source text, not behavior → prose-coupling REJECT in Gate 1 step `four_properties`. Inert fixture data is read by path from `internal\u002Ftestinfra\u002Ffixtures\u002Ftestdata\u002F`; co-located `spx\u002F...\u002Ftests\u002F` remains the home of typed assertion files. When a loaded overlay points to a governing product spec or decision that explicitly amends this contract, follow that declaration; the overlay does not redefine fixture placement itself.\n- **Disabled evidence** — a bare `t.Skip()` (no reason), skip-by-early-return, `t.SkipNow()`, or `panic(\"TODO\")` in a test body provides no evidence → REJECT in Gate 1 carrying property `coverage` from the base `\u002Faudit-tests` enum, since execution never reaches the assertion-relevant path. A reasoned `t.Skip(\"...\")` is acceptable in an `.l3_test.go` file only when a loaded product spec or decision declares that credentialed Level 3 lane and the suite declares that evidence optional; a missing mandatory dependency fails through `t.Fatal`, so a skip on it rejects. Outside `.l3_test.go`, reasoned skip is misplaced.\n- **Generated mock signal** — `gomock`, `mockery`, `moq`, `mock.Mock`, or a reassigned package-level function variable in a test is read and judged in Gate 1 step `controlled_implementations` against `\u002Ftest` Stage 5 exceptions.\n\n\u003C\u002Fstructural_reading>\n\n\u003Cgate_1_assertion>\nEntry point is the spec, not the test file.\n\nFor each assertion in the spec's Assertions section, execute steps 1-8 in order. First step failure rejects that assertion and moves to the next assertion.\n\n\u003Cstep name=\"challenge\">\nChallenge the assertion:\n\n- Does the assertion derive from an ancestor PDR or ADR claim in `\u003CPRODUCT_TREE_CONTEXT>`, or is it floating?\n- Is the assertion type correct for the claim?\n- Does it overlap with another assertion in the same node or parent?\n\nRecord challenge findings and continue unless the assertion type is invalid. A `challenge` finding carries property `alignment` from the base `\u002Faudit-tests` enum — the claim itself is malformed or misaligned with its governing decision.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"scope\">\nDecompose the assertion text into testable clauses.\n\nExample:\n\n| Assertion                                          | Clauses                                              |\n| -------------------------------------------------- | ---------------------------------------------------- |\n| \"MUST exit 0 with no stdout for invalid hook JSON\" | (1) invalid JSON input, (2) exit 0, (3) empty stdout |\n\nThe linked tests must exercise every clause with an assertion. A single assertion for a multi-clause claim is a `scope` finding carrying property `coverage` from the base `\u002Faudit-tests` enum — clauses of the claim go unexercised.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"evidence\">\nMatch the Go evidence method to the assertion type:\n\n| Type        | Required Go evidence                                                                           | Reject if                                 |\n| ----------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------- |\n| Scenario    | concrete inputs through the governed function, package, or binary                              | only existence or truthiness is checked   |\n| Mapping     | table-driven `t.Run` cases iterating a source-owned enumeration with at least two members      | one example stands in for a mapping       |\n| Conformance | parser, schema, protocol harness, CLI contract, or toolchain oracle for compile-time contracts | manual shape checks replace the validator |\n| Property    | `rapid` through the property harness with meaningful generators and invariants                 | examples are wrapped in property syntax   |\n| Compliance  | violating fixture or analyzer harness for a current `[test]` link                              | no violating input or rule oracle exists  |\n\nFor property tests, inspect the generator domain. `rapid.Just`, one-value ranges, or tiny enumerations reduce the property to examples unless the spec explicitly declares a finite set.\n\nAn assertion tagged `[audit:{rule-slug}]`, or the pathless `[audit]` that the foundation admits for a toolchain without slug support, carries no assertion type and is outside Go test-evidence scope. Skip it rather than treating the marker as test evidence.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"controlled_implementations\">\nJudge controlled implementations against `\u002Ftest` exceptions:\n\n| Exception                | Legitimate Go pattern                                                    |\n| ------------------------ | ------------------------------------------------------------------------ |\n| 1. Failure modes         | interface implementation returning deterministic errors                  |\n| 2. Interaction protocols | recording implementation capturing calls                                 |\n| 3. Time\u002Fconcurrency      | injected clock, deterministic channels, `synctest` where available       |\n| 4. Safety                | recording or no-op implementation preserving the seam                    |\n| 5. Combinatorial cost    | configurable in-memory implementation with real-shaped behavior          |\n| 6. Observability         | capture implementation for `slog` handlers, events, or serialized output |\n| 7. Contract probes       | `httptest` stub validated against the same contract schema               |\n\nGenerated mock frameworks, reassigned package-level function variables, or stubs that bypass the governed seam reject the assertion unless a Stage 5 exception applies and the real interface or protocol remains intact. Such a rejection carries property `falsifiability` from the base `\u002Faudit-tests` enum — a severed seam means no production mutation can break the test.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"oracle\">\nIdentify the source of every expected value.\n\nReject with an `oracle` finding carrying property `oracle-independence` and remediation target `independent-oracle` from the base `\u002Faudit-tests` enum when the expected value is derived from the package under test. This is distinct from `falsifiability`: an expected result computed by the same path that produces the actual result passes even when both are wrong. Proceed when the expected value comes from an independent source: the spec, an exported constant owned by a different package, an external protocol\u002Fschema, a fixture transcript, or a value hand-computed in the test.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"harness_chain\">\nTrace every test-infrastructure import:\n\n- imports from `\u003Cmodule>\u002Finternal\u002Ftestinfra\u002Fharnesses`, `\u003Cmodule>\u002Finternal\u002Ftestinfra\u002Fgenerators`, and `\u003Cmodule>\u002Finternal\u002Ftestinfra\u002Ffixtures` — the canonical home per the product's `test-infrastructure` PDR\n- non-canonical legacy locations that must be flagged as misplaced infrastructure: an in-package `testutil` or `testhelpers` package, an `export_test.go` that hands a harness or fixture to a test, a `testdata\u002F` directory outside `internal\u002Ftestinfra\u002Ffixtures\u002F`, or a `tests\u002F` subdirectory carrying non-test Go files\n- local functions inside `spx\u002F...\u002Ftests\u002F` — these are misplaced infrastructure when they own setup, reusable cases, fixture handling, generator selection, harness behavior, diagnostics, or source vocabulary\n- binary harnesses that build or resolve the product binary and hand it to `os\u002Fexec`\n\nOpen each harness. If the harness replaces the governed package instead of exercising it, reject with a `harness_chain` finding. Trace imports until the chain terminates at production code, fixture data, or framework\u002Flibrary code. If a harness lives in a non-canonical legacy location, surface an `extraction_target` finding pointing at `internal\u002Ftestinfra\u002F`.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"four_properties\">\nApply the Go supplements:\n\n- Coupling: classified from the full `\u003Csupplement property=\"coupling\">` taxonomy below — every category it names, never a subset\n- Falsifiability: concrete mutation named for every codebase path or binary contract\n- Alignment: every assertion clause maps to exercised test behavior\n- Coverage: read whether the test drives execution into the governed source path; no coverage tool is run\n\nFirst property failure rejects the assertion.\n\u003C\u002Fstep>\n\n\u003Cstep name=\"coverage\">\nEstablish coverage by reading, never by running `go test -cover` or any other coverage tool. This audit runs no deterministic verification.\n\nTrace, by reading, whether the test drives execution into the governed source path:\n\n1. Read the governed source the assertion names and identify the assertion-relevant functions, branches, and lines.\n2. Read the test and follow what it calls into that source — directly, through a harness, or through the harness-provided binary for a binary contract.\n3. Judge whether the test's execution reaches the assertion-relevant path.\n\nA test that compiles against the governed package but never drives execution into the assertion-relevant path → REJECT with `coverage`; name the path the test fails to reach, traced from the code. When the assertion-relevant path is trivially total, annotate `saturated`.\n\u003C\u002Fstep>\n\nGate 1 status:\n\n- PASS if every assertion verdict is PASS.\n- FAIL if any assertion verdict is REJECT.\n\n\u003C\u002Fgate_1_assertion>\n\n\u003Cgate_2_architectural>\nRuns only if Gate 1 is PASS. Scan in-scope tests for repeated setup patterns that belong in shared test infrastructure.\n\nTrigger: two or more in-scope tests share any of these patterns:\n\n- identical product-binary build or resolution setup\n- repeated hook JSON builders\n- repeated transcript fixture writers\n- repeated tempdir\u002Fhome-directory scaffolding beyond a bare `t.TempDir()`\n- repeated stdout\u002Fstderr\u002Fexit-code comparison functions\n- repeated `slog` or debug capture setup\n\nEach finding names the pattern, lists at least two occurrences with file and line, and proposes the canonical home under `internal\u002Ftestinfra\u002F` — `harnesses` for shared resource mediators, `generators` for input factories, or `fixtures` for fixture-resolving code.\n\nGate 2 status:\n\n- PASS if no repeated setup pattern appears in two or more in-scope tests.\n- FAIL if any repeated setup pattern appears in two or more in-scope tests.\n\n\u003C\u002Fgate_2_architectural>\n\n\u003Cgo_supplements>\nApplied during Gate 1.\n\n\u003Csupplement property=\"coupling\">\n\nThis supplement specializes each category of the coupling taxonomy `\u002Faudit-tests` owns to Go paths. Classify from the table below rather than a subset of it; every category the canonical taxonomy names appears here, so a category missing from this table would silently narrow the verdict.\n\n| Category           | Definition                                                                                                                        | Verdict                                         |\n| ------------------ | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Direct             | Test calls the governed Go function, type, package, or binary                                                                     | Proceed                                         |\n| Indirect           | Test calls test infrastructure that calls the governed path                                                                       | Proceed after harness tracing                   |\n| Transitive         | Test calls a public consumer of the governed path                                                                                 | Proceed if the level matches                    |\n| Laundered indirect | Calls an `internal\u002Ftestinfra` package that exists only to expose hardcoded values back to the test                                | REJECT — laundering                             |\n| False              | Test imports the package but never calls assertion-relevant symbols                                                               | REJECT                                          |\n| Partial            | Test calls the right package with wrong inputs or wrong path                                                                      | REJECT                                          |\n| None               | Test imports only `testing` and third-party modules, with zero product-package coupling                                           | REJECT — tautology                              |\n| Severed            | Test or harness replaces the governed behavior with a mock, fake, generated mock, reassigned function variable, or bypassing stub | REJECT — coupling severed                       |\n| Prose-coupling     | Reads an authored prose\u002Fdoc body and asserts its content, including through a harness constant or an infrastructure reader        | REJECT — couples to authored text, not behavior |\n\nFramework\u002Flibrary imports such as `testing`, `context`, `os\u002Fexec`, `net\u002Fhttp\u002Fhttptest`, `pgregory.net\u002Frapid`, and `github.com\u002Fgoogle\u002Fgo-cmp\u002Fcmp` do not count as coupling by themselves. A harness-provided product binary run through `os\u002Fexec` counts as coupling to the named binary contract. The Prose-coupling row is the table-side form of the source-file read that `\u003Cstructural_reading>` screens for; both reach the same REJECT.\n\n\u003C\u002Fsupplement>\n\n\u003Csupplement property=\"falsifiability\">\nFor each codebase path, name a concrete mutation that would fail the test.\n\nExample:\n\n```text\nPackage: internal\u002Finstall\nMutation: Install writes block hook entries under PreToolUse instead of Stop\nImpact: install-tooling scenario test comparing settings JSON fails\n```\n\nReject when no mutation can be named, when generated mocks replace the governed behavior, or when golden files only capture hand-built fixtures.\n\u003C\u002Fsupplement>\n\n\u003Csupplement property=\"alignment\">\nAlignment passes when every assertion clause is exercised by at least one assertion and the test's evidence method matches the assertion type.\n\nReject when the test covers a nearby behavior, collapses clauses, uses one example for a mapping, or tests runtime behavior for a compile-time contract.\n\u003C\u002Fsupplement>\n\n\u003Csupplement property=\"coverage\">\nCoverage passes when reading the test against the governed source shows the test drives execution into the assertion-relevant path, or that path is trivially total (`saturated`) and the other three properties pass. No coverage tool is run — this audit establishes coverage by reading.\n\nCoverage notes do not rescue missing coupling, falsifiability, or alignment.\n\u003C\u002Fsupplement>\n\n\u003C\u002Fgo_supplements>\n\n\u003C\u002Faudit_workflow>\n\n\u003Cverdict_format>\n\nThis skill composes the base `\u002Faudit-tests` verdict: the row names (`gate-1-assertion`, `gate-2-architectural`) and the JSON schema are defined in its `\u003Cverdict_format>` and are not redefined here. This skill contributes Go-specific finding detail into those rows. The audit emits no `gate-0-deterministic` row — it runs no deterministic verification; the structural reading observations from `\u003Cstructural_reading>` are folded into the Gate 1 (`gate-1-assertion`) findings. Gate 2 extraction target: a package under `internal\u002Ftestinfra\u002F`, e.g. `internal\u002Ftestinfra\u002Fharnesses`, `internal\u002Ftestinfra\u002Fgenerators`, or `internal\u002Ftestinfra\u002Ffixtures` — never an in-package `testutil` or a `testdata\u002F` directory outside the fixtures package, which are legacy non-canonical locations.\n\nWhen `\u003Caudit_scope>` finds that a retired path has no current `[test]` assertion or current evidence-chain owner, emit this alternate concern result instead of the inherited rows:\n\n```json\n{\n  \"status\": \"NOT_APPLICABLE\",\n  \"subjects\": [\"\u003Cretired-repository-relative-path>\"],\n  \"explanation\": \"No current [test] assertion or evidence chain references the retired path.\"\n}\n```\n\nEmit this shape only when every supplied subject is outside current Go test-evidence scope. A current broken `[test]` link remains applicable and produces the inherited `REJECTED` verdict.\n\n\u003C\u002Fverdict_format>\n\n\u003Csuccess_criteria>\n\nThe Go test verdict is sound when:\n\n- Every applicable rule was judged: each in-scope assertion received every Gate 1 step and the `\u003Cstructural_reading>` observations (filename, build constraint, source-reads, disabled evidence, mock signals); Gate 2 was judged when Gate 1 passed and omitted only when Gate 1 rejected the evidence.\n- Every deleted Go test or test-infrastructure path was classified from current spec links and current evidence chains, with retired evidence returned as `NOT_APPLICABLE` and current broken `[test]` links reported as missing evidence.\n- Applicable scope states an overall `APPROVED` \u002F `REJECTED` with no assertion left unevaluated; a composition-only retired-path scope emits the defined `NOT_APPLICABLE` result.\n- Each `REJECT` finding is falsifiable: it names the assertion or evidence artifact, the failed property, the gate and step, and how the test could pass while the assertion is unfulfilled.\n- The same test node yields the same verdict regardless of run order (reproducible).\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":48},"Read, Grep, Glob, Bash(git diff:*), {{! tool('use_skill') !}}","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-test","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-12 11:34:11",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add outcomeeng\u002Fplugins --skill audit-go-test",{"tool":63,"command":64},"bunx","bunx skills add outcomeeng\u002Fplugins --skill audit-go-test",{"tool":66,"command":67},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill audit-go-test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fgo\u002Fskills\u002Faudit-go-test\u002FSKILL.md",true,[],[72,78,113,129,142,155],{"skillNo":73,"name":74,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":43},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[74],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":92,"publishedAt":43},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[84,87],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":43},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[120,121,122,123,124,100,111,125,126,112,127,128],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":43},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[135],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[137,138,27,139,140,36,141],"typescript","typescript test standards","standards","false","across",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":151,"publishedAt":43},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[148],{"categoryNo":149,"categoryName":150,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000030","开发工程师",[137,152,153,154,139,140,36,141],"code","typescript code standards","code standards",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":43},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[162,139,163,164,137,165,166,141,36,167,140,168],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]