[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6N9S702HVT41PJYVG5F4WCF":3,"skill-same:01M6N9S702HVT41PJYVG5F4WCF":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":30,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6N9S702HVT41PJYVG5F4WCF","bubbles-test-integrity",null,"Enforce real, specification-driven test quality during any test work. Use when writing tests, implementing scope test plans, reviewing test coverage, or validating DoD test items. Triggers include writing tests, adding test coverage, implementing scope tests, reviewing test plans, marking test DoD items, and verifying Gherkin scenario coverage.","pkirsanov\u002Fsmackerel","pkirsanov","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F138962?v=4","01M6N8NAPD2KXMVC17X6GJ0WZ5","01M6N8NATQ9SAZ00H9D61R0TPV",1,"MIT","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-test-integrity\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"test","bubbles test integrity","integrity","tests","writing","implementing","scope","dod","driven","triggers","scenario","plans","writing tests","enforce","specification","test coverage","use","coverage","work","quality","2026-11-10 10:12:30",false,"---\nname: bubbles-test-integrity\ndescription: Enforce real, specification-driven test quality during any test work. Use when writing tests, implementing scope test plans, reviewing test coverage, or validating DoD test items. Triggers include writing tests, adding test coverage, implementing scope tests, reviewing test plans, marking test DoD items, and verifying Gherkin scenario coverage.\n---\n\n# Bubbles Test Integrity\n\n## Goal\nEnsure every test is real, validates planned behavior from specifications, covers all Gherkin scenarios, and contains no fakes, shortcuts, or silent-pass patterns.\n\n## When to Use\n- Writing or modifying tests for any scope or bug\n- Implementing test plan items from `scopes.md`\n- Reviewing test coverage before marking DoD items\n- Validating that tests match Gherkin scenarios in scope artifacts\n- Checking test quality during audit or review phases\n\n## Non-Negotiable Principles\n\n1. **Tests validate specifications, not implementation** — derive tests from `spec.md`, `design.md`, and scope Gherkin scenarios. Never weaken a test to match broken code.\n2. **Tests must be real** — every test must execute real code paths against real systems (for live categories) or real logic (for unit categories). No stubs, no fakes, no canned responses.\n3. **No shortcuts** — no partial coverage presented as complete, no reduced-scope tests presented as full validation, no proxy assertions substituting for real behavior checks.\n4. **Every Gherkin scenario must have a test** — each Given\u002FWhen\u002FThen scenario in scope artifacts maps to at least one executable test. No scenario left untested.\n5. **Scenario contracts are durable** — when `scenario-manifest.json` exists, tests must preserve the linked `SCN-*` contracts unless the scenario has been explicitly invalidated and replaced.\n\n---\n\n## Pre-Test-Writing Checklist\n\nBefore writing any test:\n\n- [ ] Read the Gherkin scenarios in the scope artifact (`scopes.md` or `scopes\u002F*\u002Fscope.md`)\n- [ ] Read `spec.md` and `design.md` for expected behavior definitions\n- [ ] Identify ALL scenarios: happy path, error paths, boundary conditions, parameter permutations\n- [ ] Determine required test categories per the Canonical Test Taxonomy (`unit`, `functional`, `integration`, `ui-unit`, `e2e-api`, `e2e-ui`, `stress`, `load`)\n- [ ] Verify the Test Plan table in the scope artifact has a row for each required test\n\n---\n\n## Test Quality Gates\n\n### Gate 1: Gherkin Coverage\n\nEvery Gherkin scenario in scope artifacts MUST map to at least one test.\n\nWhen `scenario-manifest.json` exists, every `SCN-*` entry marked `regressionRequired: true` MUST map to at least one live-system test and evidence reference.\n\n**Verification:**\n```\nCount Gherkin scenarios → Count matching tests → They must be equal or tests > scenarios\n```\n\n**Prohibited:**\n- Gherkin scenario exists but no corresponding test\n- Test claims to cover a scenario but asserts different behavior\n- Multiple scenarios collapsed into one test that only checks one path\n\n### Gate 2: No Internal Mocks (Live Categories)\n\nTests classified as `integration`, `e2e-api`, or `e2e-ui` MUST hit the real running stack.\n\n**Prohibited interception patterns (scan before marking done):**\n```bash\ngrep -rn 'page\\.route\\|context\\.route\\|intercept(\\|cy\\.intercept\\|msw\\|nock\\|wiremock' [test-files]\n```\n\nIf any match is found in a file classified as live-system, either:\n- Reclassify the test to `ui-unit` or `unit` (mocked category), OR\n- Remove the interception and test against the real stack\n\n**Rule:** A mocked test MUST NOT satisfy a live-stack DoD item.\n\n### Gate 3: No Silent-Pass Patterns\n\nRequired tests MUST fail when the feature is missing or broken.\n\n**Prohibited patterns (scan before marking done):**\n```bash\nbash .github\u002Fbubbles\u002Fscripts\u002Fregression-quality-guard.sh [test-files]\nbash .github\u002Fbubbles\u002Fscripts\u002Fregression-quality-guard.sh --bugfix [test-files]  # bug-fix scopes only\n```\n\n**Rules:**\n- Missing required selector → test MUST fail via direct assertion (e.g., `expect(locator).toBeVisible()`)\n- No early-return paths after entering a required scenario\n- No redirect\u002Fauth bailout branches such as `if (page.url().includes('\u002Flogin')) { return; }`\n- Persistence tests MUST assert concrete field values, not just null\u002Fdefined checks\n- UI tests MUST assert user-visible outcomes (computed styles, DOM state, round-trip reload)\n\n### Gate 4: Real Assertions\n\nEvery test MUST contain assertions that prove the specified behavior.\n\n**Prohibited:**\n- Tests without assertions\n- Tests that only check HTTP status codes without validating response content\n- Tests that assert \"returns 200 or 404\" (proxy assertions)\n- Tests that log output without asserting on it\n- `\u002F\u002F TODO: add assertions` or equivalent\n\n**Required:**\n- Assert the EXACT behavior described in the Gherkin scenario\n- Assert error messages, field values, state transitions — not just success\u002Ffailure signals\n- For data mutations: assert round-trip (write → read → verify persisted state)\n\n### Gate 5: Test Plan ↔ DoD Parity\n\nEvery row in the Test Plan table MUST have a corresponding DoD checkbox item, and vice versa.\n\n**Verification:**\n```\nCount Test Plan rows == Count DoD test-related items\n```\n\nMismatch is a BLOCKING issue — scope cannot be marked Done.\n\n### Gate 6: Adversarial Regression Coverage (Bug Fixes)\n\nBug-fix regression tests MUST include at least one adversarial test case — a test using input that would FAIL if the bug were reintroduced.\n\n**What makes a test adversarial:**\n- Filter\u002Fgate bugs: test data does **not** match the buggy filter, and still must pass\n- Auth\u002Fredirect bugs: direct assertion that the failure condition does **not** occur, with no bailout-return\n- Persistence\u002Fdata-shape bugs: round-trip with the edge-case input that triggered the original bug\n\n**Prohibited (tautological tests):**\n- All test data already satisfies the broken code path\n- Test setup mirrors the exact condition the buggy filter checks for\n- No negative or adversarial scenario exists in any regression case\n\n**Prohibited (false-negative bailouts):**\n- `if (page.url().includes('\u002Flogin')) { return; }`\n- `if (!hasControl) { return; }`\n- Any conditional early return in a required test body that exits without asserting on the failure path\n\nThis gate applies to bug fixes and regression scopes. Feature-only scopes are exempt unless they claim to close an existing bug.\n\n### Gate 7: No Self-Validating Test Setup\n\nEvery test assertion MUST verify a value **produced by the code under test**, not a value the test itself hardcoded or injected.\n\n**The core rule:** The path from test input to test assertion MUST pass through real production code that meaningfully transforms, validates, computes, queries, or routes the data.\n\n**Prohibited patterns:**\n- Test creates hardcoded data → passes it through trivial\u002Fpass-through code → asserts on the same hardcoded values\n- Test injects mock response `{ score: 0.912, tier: \"Tier 1\" }` → asserts `score == 0.912` (testing what the mock returns, not what the code computes)\n- E2E test seeds exact literal values → asserts on those literals without verifying real code processed them\n- Test constructs expected output → calls code that returns input unchanged → asserts output matches expected\n\n**Detection heuristic:** If the code under test were replaced with `return input` or `return hardcodedLiteral`, would the test still pass? If yes → the test is self-validating and MUST be rewritten.\n\n**Valid assertion patterns:**\n- Computed output: `assert add(2, 3) == 5` — value `5` is the product of real logic\n- Structural correctness: element exists, content is numeric, value is within valid range, format matches spec\n- Round-trip transformation: write via API → read back → values persisted correctly and format is correct\n- Behavioral contracts: given known input, code produces output matching the spec's defined transformation\n\n**For unit tests with mocks:** Mocking external dependencies is allowed, but assert that the code under test *responded correctly* to the mock's behavior — not that the mock returned what it was told to return.\n\n**For dynamic data sources** (connectors, simulators, feeds): Prefer structural assertions (shape, type, range, cardinality) over exact-value assertions on magic literals the test invented.\n\n**Scan before marking done:**\nReview each test and ask: \"Does this assertion prove the code did something, or does it only prove the test setup was correct?\"\n\nThis gate applies to ALL test categories.\n\n---\n\n## Per-Category Requirements\n\n| Category | What \"Real\" Means |\n|----------|-------------------|\n| `unit` | Tests real code paths, no mocking of internal modules. Only external third-party deps may be mocked. |\n| `functional` | May use real dependencies (DB, filesystem). Tests actual function behavior with real inputs. |\n| `integration` | Multi-component, real dependencies, zero mocks. Tests actual service interactions. |\n| `ui-unit` | Component-level tests with mocked backend are acceptable. Must assert visual\u002Fbehavioral output. |\n| `e2e-api` | Full API workflow against live system. No request interception. Real HTTP calls, real responses. |\n| `e2e-ui` | Full UI workflow against live system. No `page.route()` or mock interceptors. Real browser, real backend. |\n| `stress` | Burst load against live system. Must verify behavior under pressure, not just \"no crash\". |\n| `load` | Sustained load against live system. Must verify throughput and latency SLAs. |\n\n---\n\n## Verification Workflow\n\nWhen completing test work, execute this sequence:\n\n### Step 1: Scenario Traceability\nFor each Gherkin scenario in scope artifacts, confirm a test exists that:\n- Sets up the Given precondition\n- Performs the When action\n- Asserts the Then outcome\n\n### Step 2: Anti-Mock Scan (live categories)\nRun interception pattern scan against all files classified as `integration`, `e2e-api`, or `e2e-ui`.\n\n### Step 3: Anti-False-Positive Scan\nRun silent-pass pattern scan against all required test files.\n\n### Step 4: Assertion Audit\nVerify every test body contains at least one behavior-proving assertion matching the corresponding Gherkin scenario.\n\n### Step 5: Self-Validating Test Audit\nFor each test, trace the asserted value backward. If it originates from the test's own setup (hardcoded literal, mock return value, fixture constant) and passes through trivial or pass-through code, the test is self-validating. Apply the replacement heuristic: would the test still pass if the code under test were replaced with `return input`? If yes, the test must be rewritten to assert on values actually produced by the code.\n\n### Step 6: Adversarial Regression Audit\nFor bug-fix scopes, verify at least one regression case would fail if the bug returned and that no bailout patterns convert the bug back into a pass.\n\n### Step 7: Test Plan ↔ DoD Cross-Check\nCount Test Plan rows. Count DoD test items. Confirm parity.\n\n### Step 8: Execute and Record Evidence\nRun all tests. Capture raw terminal output (≥10 lines per test category). Record in `report.md`.\n\nFor live categories (`integration` \u002F `e2e-api` \u002F `e2e-ui` \u002F `stress` \u002F `load`) against a `wired` stack, ALSO run **trace-driven defect discovery** (see `bubbles-observability-adapter`): mine the validate-plane traces for error spans, latency outliers, and fan-out\u002FN+1, and file any finding as a bug. A green run over a sick trace is an undiscovered bug, not a pass.\n\n---\n\n## Decision Tree: Is This Test Real?\n\n```\nDoes the test execute real production code?\n├─ NO → ❌ FAKE — rewrite to use real code paths\n└─ YES\n   Does the assertion verify output PRODUCED BY the code under test (not the test's own setup data)?\n   ├─ NO → ❌ SELF-VALIDATING — rewrite to assert on code-produced output, not test-injected values\n   └─ YES\n      Does it assert the exact behavior from a Gherkin scenario or spec requirement?\n      ├─ NO → ❌ PROXY — rewrite assertions to match spec\n      └─ YES\n         For live categories: does it hit the real stack without interception?\n         ├─ NO → ❌ MOCKED — reclassify or remove interception\n         └─ YES\n            Can the test fail if the feature is broken or missing?\n            ├─ NO → ❌ SILENT-PASS — add direct failure assertions\n            └─ YES\n               For bug fixes: is at least one regression case adversarial rather than tautological?\n               ├─ NO → ❌ TAUTOLOGICAL — rewrite the regression case with adversarial input\n               └─ YES → ✅ REAL TEST\n```\n\n---\n\n## References\n- `agents\u002Fbubbles_shared\u002Ftest-core.md`\n- `agents\u002Fbubbles_shared\u002Ftest-fidelity.md`\n- `agents\u002Fbubbles_shared\u002Fquality-gates.md`\n- `agents\u002Fbubbles_shared\u002Fcritical-requirements.md`\n- `agents\u002Fbubbles_shared\u002Fevidence-rules.md`\n- `agents\u002Fbubbles_shared\u002Fscope-workflow.md`\n- `agents\u002Fbubbles_shared\u002Ffeature-templates.md`\n- `docs\u002Fguides\u002FCONTROL_PLANE_SCHEMAS.md`\n","# Bubbles Test Integrity\n\n## Goal\nEnsure every test is real, validates planned behavior from specifications, covers all Gherkin scenarios, and contains no fakes, shortcuts, or silent-pass patterns.\n\n## When to Use\n- Writing or modifying tests for any scope or bug\n- Implementing test plan items from `scopes.md`\n- Reviewing test coverage before marking DoD items\n- Validating that tests match Gherkin scenarios in scope artifacts\n- Checking test quality during audit or review phases\n\n## Non-Negotiable Principles\n\n1. **Tests validate specifications, not implementation** — derive tests from `spec.md`, `design.md`, and scope Gherkin scenarios. Never weaken a test to match broken code.\n2. **Tests must be real** — every test must execute real code paths against real systems (for live categories) or real logic (for unit categories). No stubs, no fakes, no canned responses.\n3. **No shortcuts** — no partial coverage presented as complete, no reduced-scope tests presented as full validation, no proxy assertions substituting for real behavior checks.\n4. **Every Gherkin scenario must have a test** — each Given\u002FWhen\u002FThen scenario in scope artifacts maps to at least one executable test. No scenario left untested.\n5. **Scenario contracts are durable** — when `scenario-manifest.json` exists, tests must preserve the linked `SCN-*` contracts unless the scenario has been explicitly invalidated and replaced.\n\n---\n\n## Pre-Test-Writing Checklist\n\nBefore writing any test:\n\n- [ ] Read the Gherkin scenarios in the scope artifact (`scopes.md` or `scopes\u002F*\u002Fscope.md`)\n- [ ] Read `spec.md` and `design.md` for expected behavior definitions\n- [ ] Identify ALL scenarios: happy path, error paths, boundary conditions, parameter permutations\n- [ ] Determine required test categories per the Canonical Test Taxonomy (`unit`, `functional`, `integration`, `ui-unit`, `e2e-api`, `e2e-ui`, `stress`, `load`)\n- [ ] Verify the Test Plan table in the scope artifact has a row for each required test\n\n---\n\n## Test Quality Gates\n\n### Gate 1: Gherkin Coverage\n\nEvery Gherkin scenario in scope artifacts MUST map to at least one test.\n\nWhen `scenario-manifest.json` exists, every `SCN-*` entry marked `regressionRequired: true` MUST map to at least one live-system test and evidence reference.\n\n**Verification:**\n```\nCount Gherkin scenarios → Count matching tests → They must be equal or tests > scenarios\n```\n\n**Prohibited:**\n- Gherkin scenario exists but no corresponding test\n- Test claims to cover a scenario but asserts different behavior\n- Multiple scenarios collapsed into one test that only checks one path\n\n### Gate 2: No Internal Mocks (Live Categories)\n\nTests classified as `integration`, `e2e-api`, or `e2e-ui` MUST hit the real running stack.\n\n**Prohibited interception patterns (scan before marking done):**\n```bash\ngrep -rn 'page\\.route\\|context\\.route\\|intercept(\\|cy\\.intercept\\|msw\\|nock\\|wiremock' [test-files]\n```\n\nIf any match is found in a file classified as live-system, either:\n- Reclassify the test to `ui-unit` or `unit` (mocked category), OR\n- Remove the interception and test against the real stack\n\n**Rule:** A mocked test MUST NOT satisfy a live-stack DoD item.\n\n### Gate 3: No Silent-Pass Patterns\n\nRequired tests MUST fail when the feature is missing or broken.\n\n**Prohibited patterns (scan before marking done):**\n```bash\nbash .github\u002Fbubbles\u002Fscripts\u002Fregression-quality-guard.sh [test-files]\nbash .github\u002Fbubbles\u002Fscripts\u002Fregression-quality-guard.sh --bugfix [test-files]  # bug-fix scopes only\n```\n\n**Rules:**\n- Missing required selector → test MUST fail via direct assertion (e.g., `expect(locator).toBeVisible()`)\n- No early-return paths after entering a required scenario\n- No redirect\u002Fauth bailout branches such as `if (page.url().includes('\u002Flogin')) { return; }`\n- Persistence tests MUST assert concrete field values, not just null\u002Fdefined checks\n- UI tests MUST assert user-visible outcomes (computed styles, DOM state, round-trip reload)\n\n### Gate 4: Real Assertions\n\nEvery test MUST contain assertions that prove the specified behavior.\n\n**Prohibited:**\n- Tests without assertions\n- Tests that only check HTTP status codes without validating response content\n- Tests that assert \"returns 200 or 404\" (proxy assertions)\n- Tests that log output without asserting on it\n- `\u002F\u002F TODO: add assertions` or equivalent\n\n**Required:**\n- Assert the EXACT behavior described in the Gherkin scenario\n- Assert error messages, field values, state transitions — not just success\u002Ffailure signals\n- For data mutations: assert round-trip (write → read → verify persisted state)\n\n### Gate 5: Test Plan ↔ DoD Parity\n\nEvery row in the Test Plan table MUST have a corresponding DoD checkbox item, and vice versa.\n\n**Verification:**\n```\nCount Test Plan rows == Count DoD test-related items\n```\n\nMismatch is a BLOCKING issue — scope cannot be marked Done.\n\n### Gate 6: Adversarial Regression Coverage (Bug Fixes)\n\nBug-fix regression tests MUST include at least one adversarial test case — a test using input that would FAIL if the bug were reintroduced.\n\n**What makes a test adversarial:**\n- Filter\u002Fgate bugs: test data does **not** match the buggy filter, and still must pass\n- Auth\u002Fredirect bugs: direct assertion that the failure condition does **not** occur, with no bailout-return\n- Persistence\u002Fdata-shape bugs: round-trip with the edge-case input that triggered the original bug\n\n**Prohibited (tautological tests):**\n- All test data already satisfies the broken code path\n- Test setup mirrors the exact condition the buggy filter checks for\n- No negative or adversarial scenario exists in any regression case\n\n**Prohibited (false-negative bailouts):**\n- `if (page.url().includes('\u002Flogin')) { return; }`\n- `if (!hasControl) { return; }`\n- Any conditional early return in a required test body that exits without asserting on the failure path\n\nThis gate applies to bug fixes and regression scopes. Feature-only scopes are exempt unless they claim to close an existing bug.\n\n### Gate 7: No Self-Validating Test Setup\n\nEvery test assertion MUST verify a value **produced by the code under test**, not a value the test itself hardcoded or injected.\n\n**The core rule:** The path from test input to test assertion MUST pass through real production code that meaningfully transforms, validates, computes, queries, or routes the data.\n\n**Prohibited patterns:**\n- Test creates hardcoded data → passes it through trivial\u002Fpass-through code → asserts on the same hardcoded values\n- Test injects mock response `{ score: 0.912, tier: \"Tier 1\" }` → asserts `score == 0.912` (testing what the mock returns, not what the code computes)\n- E2E test seeds exact literal values → asserts on those literals without verifying real code processed them\n- Test constructs expected output → calls code that returns input unchanged → asserts output matches expected\n\n**Detection heuristic:** If the code under test were replaced with `return input` or `return hardcodedLiteral`, would the test still pass? If yes → the test is self-validating and MUST be rewritten.\n\n**Valid assertion patterns:**\n- Computed output: `assert add(2, 3) == 5` — value `5` is the product of real logic\n- Structural correctness: element exists, content is numeric, value is within valid range, format matches spec\n- Round-trip transformation: write via API → read back → values persisted correctly and format is correct\n- Behavioral contracts: given known input, code produces output matching the spec's defined transformation\n\n**For unit tests with mocks:** Mocking external dependencies is allowed, but assert that the code under test *responded correctly* to the mock's behavior — not that the mock returned what it was told to return.\n\n**For dynamic data sources** (connectors, simulators, feeds): Prefer structural assertions (shape, type, range, cardinality) over exact-value assertions on magic literals the test invented.\n\n**Scan before marking done:**\nReview each test and ask: \"Does this assertion prove the code did something, or does it only prove the test setup was correct?\"\n\nThis gate applies to ALL test categories.\n\n---\n\n## Per-Category Requirements\n\n| Category | What \"Real\" Means |\n|----------|-------------------|\n| `unit` | Tests real code paths, no mocking of internal modules. Only external third-party deps may be mocked. |\n| `functional` | May use real dependencies (DB, filesystem). Tests actual function behavior with real inputs. |\n| `integration` | Multi-component, real dependencies, zero mocks. Tests actual service interactions. |\n| `ui-unit` | Component-level tests with mocked backend are acceptable. Must assert visual\u002Fbehavioral output. |\n| `e2e-api` | Full API workflow against live system. No request interception. Real HTTP calls, real responses. |\n| `e2e-ui` | Full UI workflow against live system. No `page.route()` or mock interceptors. Real browser, real backend. |\n| `stress` | Burst load against live system. Must verify behavior under pressure, not just \"no crash\". |\n| `load` | Sustained load against live system. Must verify throughput and latency SLAs. |\n\n---\n\n## Verification Workflow\n\nWhen completing test work, execute this sequence:\n\n### Step 1: Scenario Traceability\nFor each Gherkin scenario in scope artifacts, confirm a test exists that:\n- Sets up the Given precondition\n- Performs the When action\n- Asserts the Then outcome\n\n### Step 2: Anti-Mock Scan (live categories)\nRun interception pattern scan against all files classified as `integration`, `e2e-api`, or `e2e-ui`.\n\n### Step 3: Anti-False-Positive Scan\nRun silent-pass pattern scan against all required test files.\n\n### Step 4: Assertion Audit\nVerify every test body contains at least one behavior-proving assertion matching the corresponding Gherkin scenario.\n\n### Step 5: Self-Validating Test Audit\nFor each test, trace the asserted value backward. If it originates from the test's own setup (hardcoded literal, mock return value, fixture constant) and passes through trivial or pass-through code, the test is self-validating. Apply the replacement heuristic: would the test still pass if the code under test were replaced with `return input`? If yes, the test must be rewritten to assert on values actually produced by the code.\n\n### Step 6: Adversarial Regression Audit\nFor bug-fix scopes, verify at least one regression case would fail if the bug returned and that no bailout patterns convert the bug back into a pass.\n\n### Step 7: Test Plan ↔ DoD Cross-Check\nCount Test Plan rows. Count DoD test items. Confirm parity.\n\n### Step 8: Execute and Record Evidence\nRun all tests. Capture raw terminal output (≥10 lines per test category). Record in `report.md`.\n\nFor live categories (`integration` \u002F `e2e-api` \u002F `e2e-ui` \u002F `stress` \u002F `load`) against a `wired` stack, ALSO run **trace-driven defect discovery** (see `bubbles-observability-adapter`): mine the validate-plane traces for error spans, latency outliers, and fan-out\u002FN+1, and file any finding as a bug. A green run over a sick trace is an undiscovered bug, not a pass.\n\n---\n\n## Decision Tree: Is This Test Real?\n\n```\nDoes the test execute real production code?\n├─ NO → ❌ FAKE — rewrite to use real code paths\n└─ YES\n   Does the assertion verify output PRODUCED BY the code under test (not the test's own setup data)?\n   ├─ NO → ❌ SELF-VALIDATING — rewrite to assert on code-produced output, not test-injected values\n   └─ YES\n      Does it assert the exact behavior from a Gherkin scenario or spec requirement?\n      ├─ NO → ❌ PROXY — rewrite assertions to match spec\n      └─ YES\n         For live categories: does it hit the real stack without interception?\n         ├─ NO → ❌ MOCKED — reclassify or remove interception\n         └─ YES\n            Can the test fail if the feature is broken or missing?\n            ├─ NO → ❌ SILENT-PASS — add direct failure assertions\n            └─ YES\n               For bug fixes: is at least one regression case adversarial rather than tautological?\n               ├─ NO → ❌ TAUTOLOGICAL — rewrite the regression case with adversarial input\n               └─ YES → ✅ REAL TEST\n```\n\n---\n\n## References\n- `agents\u002Fbubbles_shared\u002Ftest-core.md`\n- `agents\u002Fbubbles_shared\u002Ftest-fidelity.md`\n- `agents\u002Fbubbles_shared\u002Fquality-gates.md`\n- `agents\u002Fbubbles_shared\u002Fcritical-requirements.md`\n- `agents\u002Fbubbles_shared\u002Fevidence-rules.md`\n- `agents\u002Fbubbles_shared\u002Fscope-workflow.md`\n- `agents\u002Fbubbles_shared\u002Ffeature-templates.md`\n- `docs\u002Fguides\u002FCONTROL_PLANE_SCHEMAS.md`\n",{"name":5,"description":7},"main","ed893cc338281a0bb9bb9ecf3415716cb242bb3f",".github\u002Fskills\u002Fbubbles-test-integrity",0,"https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel","https:\u002F\u002Fgithub.com\u002Fpkirsanov","2026-11-07 02:54:37",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add pkirsanov\u002Fsmackerel --skill bubbles-test-integrity",{"tool":69,"command":70},"bunx","bunx skills add pkirsanov\u002Fsmackerel --skill bubbles-test-integrity",{"tool":72,"command":73},"pnpm","pnpm dlx skills add pkirsanov\u002Fsmackerel --skill bubbles-test-integrity","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-test-integrity\u002FSKILL.md",true,[],[78,104,131,159,180,207],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":85,"publishedAt":51},"01M6N9V5TBHQT20V5SCCJ1VRBC","smackerel-trace-capture","Wire Smackerel's concrete validate-plane stack into the framework trace-driven defect-discovery method. Use when running live-category tests (integration\u002Fe2e\u002Fe2e-ui\u002Fstress) against the ephemeral test stack; capturing SLO or trace evidence; hunting latency\u002Ferror\u002Fperf bugs from spans; querying the test-stack Jaeger or Prometheus; or touching `.specify\u002Fruntime\u002Fobservability`. Concrete smackerel endpoints + the exact `capture-slo.sh` command; do NOT duplicate `bubbles-observability-adapter` — this only adds the wiring.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsmackerel-trace-capture\u002FSKILL.md",[84],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[86,87,88,89,90,91,92,93,94,47,95,96,97,98,99,100,34,101,102,103],"trace","capture","smackerel trace capture","perf","observability","prometheus","specify","e2e","discovery","slo","only","evidence","do","latency","runtime","adapter","error","bugs",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":113,"publishedAt":51},"01M6N9TZDEV26RZ7W34HEFPQE9","smackerel-no-defaults","Enforce Smackerel's NO-DEFAULTS \u002F fail-loud SST policy. Use when editing config, Docker Compose, deploy adapters, docs, instructions, skills, env handling, host bind addresses, or any runtime value that could be hidden by fallback syntax.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsmackerel-no-defaults\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",[114,115,116,117,118,119,120,121,122,47,123,44,100,124,125,126,127,128,129,130],"smackerel no defaults","docker","policy","config","deploy","docker compose","syntax","editing","instructions","compose","bind","env","host","Adapters","sst","addresses","value",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":140,"publishedAt":51},"01M6N9TJRS5PF83JH2W4614D4W","bubbles-workflow-mode-resolution","Resolve a Bubbles workflow mode against `bubbles\u002Fworkflows.yaml`, including template inheritance, status ceilings, gate wiring, and decision policy. Use when picking a mode for a request, when a guard reports a mode-related failure, or when extending workflows.yaml with a new mode or template. Covers natural-language intent routing and the workflow registry consistency rules.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-workflow-mode-resolution\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[141,142,143,144,116,145,146,147,148,149,150,47,151,152,153,154,155,156,157,158],"workflow","resolution","mode","bubbles workflow mode resolution","workflows","routing","guard","template","decision","Rules","reports","intent","inheritance","with","consistency","natural-language","for","wiring",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":51},"01M6N9TC98D6DJR0D64SSN0SN3","bubbles-workflow-execution-loops","Run per-round synchronous workflow execution loops correctly. Use when orchestrating a multi-round workflow, dispatching specialist subagents, handling round-based remediation, or interpreting a workflow mode's execution policy. Covers authorized direct execution, dispatch-and-wait, batch-then-summarize prohibition, and mapped-mode execution.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-workflow-execution-loops\u002FSKILL.md",[165],{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},[141,167,168,169,170,116,171,172,173,174,175,47,176,177,178,179,143],"execution","loops","bubbles workflow execution loops","summarize","run","batch","remediation","direct","subagents","dispatch","wait","multi","multi-round",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":190,"publishedAt":51},"01M6N9SYXQNJDQ1T1YT81JH2BG","bubbles-vscode-agent-constraints","Design agents that fit the VS Code Copilot Chat runtime instead of fighting it. Use when authoring or editing any `*.agent.md`; when adding `tools:`, `agents:`, `handoffs:`, `model:`, `user-invocable:`, or `disable-model-invocation:` frontmatter; when designing an orchestrator that dispatches specialists; when a design implies agent-calls-agent-calls-agent chaining; when a subagent dispatch silently no-ops or an agent cannot be selected in the dropdown; or when writing a governance rule about delegation that the runtime cannot actually enforce. Prevents multi-level-subagent designs, prose-only dispatch laws, and frontmatter\u002Fbody contradictions.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-vscode-agent-constraints\u002FSKILL.md",[186,189],{"categoryNo":187,"categoryName":188,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},[191,192,193,194,35,195,196,197,198,199,200,201,121,202,96,100,203,204,205,206],"vscode","constraints","bubbles vscode agent constraints","design","copilot","code","delegation","Tools","subagent","model","chaining","orchestrator","authoring","fit","subagent dispatch","frontmatter",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":213,"publishedAt":51},"01M6N9SD78SK12PRT9KBRZ6TB3","bubbles-upkeep-cadence","How to schedule, dispatch, and record recurring operational upkeep tasks (backup, restore-drill, BCDR-drill, patch-cycle, secret-rotation, flag-cleanup, compliance-sweep). Use when authoring or modifying `config\u002Fupkeep-calendar.yaml`, when investigating a missed task, when reading the upkeep ledger, or when adding a new task type.","https:\u002F\u002Fgithub.com\u002Fpkirsanov\u002Fsmackerel\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbubbles-upkeep-cadence\u002FSKILL.md",[],[214,215,216,217,218,219,220,221,47,222,223,224,225,226,227,228,229,230,231,232],"cadence","bubbles upkeep cadence","tasks","cleanup","backup","sweep","schedule","recurring","patch","restore","task","cycle","record","missed","type","drill","how to","new task","rotation"]