synapse-hub 2.2.4 → 2.4.1

package/.agents/skills/synthetic-test-data-generator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: synthetic-test-data-generator
-description: "Generate idempotent, boundary-value synthetic test data with unique runtime timestamps."
+description: "Generate idempotent, boundary-value synthetic test data with unique runtime timestamps. Use when generating idempotent, unique test data for creation tests."
 ---
 
 # Synthetic Test Data Generator & Edge-Case Fuzzing Skill
@@ -81,8 +81,8 @@ Transform functional tests into input sanitization and robustness validation by
 
 ```bash
 # Query CLI catalog for specific field vectors
-python tools/fuzz_payloads.py --field username --type string
-python tools/fuzz_payloads.py --category sqli --json
+python3 ~/.zcode/synapse-hub/tools/fuzz_payloads.py --field username --type string
+python3 ~/.zcode/synapse-hub/tools/fuzz_payloads.py --category sqli --json
 ```
 
 ### Recipe D: Harmless SQLi Polyglot Sanity

package/.agents/skills/synthetic-test-data-generator/examples/idempotent_data_recipe.json

@@ -0,0 +1,9 @@
+{
+  "entity": "user",
+  "prefix": "AUTO_",
+  "timestampPattern": "EPOCH_MS",
+  "fields": {
+    "email": "AUTO_USER@example-qa.com",
+    "phone": "+15551234567"
+  }
+}

package/.agents/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: systematic-debugging
+description: "Investigate root cause through four disciplined phases before proposing any fix for a test failure, bug, or unexpected behavior. Use when a test fails, a defect appears, or a fix attempt has already failed and guessing is tempting."
+---
+
+# Systematic Debugging — Enterprise Root-Cause Standard
+
+Specialized skill for failure investigation in test automation: always find root cause before attempting fixes. Symptom fixes are failure.
+
+---
+
+## 1. The Iron Law
+
+```
+NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+```
+
+If Phase 1 is not complete, proposing fixes is prohibited. This applies ESPECIALLY when: under time pressure (emergencies make guessing tempting), a "quick fix" seems obvious, or previous fixes did not work.
+
+## 2. The Four Phases
+
+```mermaid
+flowchart TD
+    P1["<b>Phase 1: Root Cause Investigation</b><br/>Read errors, reproduce, check changes, gather evidence"] --> P2["<b>Phase 2: Pattern Analysis</b><br/>Compare against working examples"]
+    P2 --> P3["<b>Phase 3: Hypothesis & Testing</b><br/>One hypothesis, minimal change"]
+    P3 --> P4["<b>Phase 4: Implementation</b><br/>Failing test first, single fix, verify"]
+```
+
+### Phase 1: Root Cause Investigation (before ANY fix)
+
+1. **Read error messages completely** — stack traces, line numbers, error codes often contain the exact cause.
+2. **Reproduce consistently** — exact steps, every time. Not reproducible means gather more data (flaky scoring via `tools/flaky_detector.py`), do not guess.
+3. **Check recent changes** — git diff, recent commits, new dependencies, config drift.
+4. **Gather evidence at component boundaries** — for multi-layer systems (CI → build → run; API → service → DB), log what enters and exits each boundary once, to see WHICH layer breaks, then investigate that layer.
+5. **Trace data flow backward** — where does the bad value originate? Fix at source, never at symptom.
+
+### Phase 2: Pattern Analysis
+
+- Find working examples of similar behavior in the same codebase; list every difference from the broken path, however small.
+- Read reference implementations completely before applying a pattern — partial understanding guarantees bugs.
+
+### Phase 3: Hypothesis and Testing
+
+- State one specific hypothesis: "X is the root cause because Y."
+- Test it with the SMALLEST possible change, one variable at a time. Do not stack fixes.
+- Confirmed → Phase 4. Rejected → form a NEW hypothesis; do not pile fix onto fix.
+
+### Phase 4: Implementation
+
+1. **Create the failing test case first** — the reproduction is the RED test (see `test-driven-development`).
+2. **Implement a single fix** at the identified root cause. No "while I'm here" improvements, no bundled refactoring.
+3. **Verify the fix** — test passes, full suite still green, claim backed by output per `verification-before-completion`.
+4. **If the fix does not work:** STOP. Count attempts. Fewer than 3 → return to Phase 1 with the new information.
+5. **If 3+ fixes failed:** question the architecture, not the code — each fix revealing a new problem elsewhere is the signature of a wrong pattern. Discuss with the user before a fourth attempt.
+
+## 3. Hub Tooling Chain
+
+| Step | Tool | Role in investigation |
+|---|---|---|
+| Isolate | `python3 tools/pinpoint_failure.py` | Extract exact failing line, exception, stack trace from JUnit XML in ~0.1s |
+| Diagnose | `python3 tools/auto_heal.py` | Closed-loop triage and healing plan; reflexion lessons after each successful heal |
+| Reuse | `python3 tools/cache_resolver.py query "<error>"` | 0-token lookup of previously solved, similar defects before re-investigating |
+| Classify | `python3 tools/flaky_detector.py` | Separate non-deterministic flakiness from genuine defects |
+| Ticket | `python3 tools/bug_reporter.py` | Auto-generate the bug ticket with RCA once root cause is proven |
+
+Escalation order: `failure-analyst` performs the autopsy; `quality-gatekeeper` re-verifies after the fix lands.
+
+## 4. Red Flags — STOP and Return to Phase 1
+
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- Adding multiple changes and running tests together
+- "Skip the test, I'll manually verify"
+- Proposing solutions before tracing the data flow
+- "One more fix attempt" after 2+ failures
+- Each fix revealing a new problem in a different place (architecture question)
+
+## 5. When Investigation Finds No Root Cause
+
+If disciplined investigation proves the issue is genuinely environmental or timing-dependent: document what was investigated, implement appropriate handling (retry, timeout, error message), add monitoring for future investigation — and remember: most "no root cause" conclusions are incomplete investigation. Hand residual non-determinism to `flaky-test-sentinel-and-quarantine` for scoring and quarantine instead of declaring it unsolvable.
+
+## 6. Boundary vs Sibling Skills (Do Not Confuse)
+
+| Sibling | Owns | Hand-off |
+|---|---|---|
+| `failure-autopsy-and-healing` | Mechanical triage/healing mechanics from JUnit XML, screenshots, PR automation | This skill is the investigation DISCIPLINE; autopsy tooling executes its Phase 1/4 |
+| `test-driven-development` | The RED-GREEN-REFACTOR cycle | Phase 4 hands the reproduced bug over as the failing test |
+| `flaky-test-sentinel-and-quarantine` | Flakiness scoring and quarantine lifecycle | Receives non-reproducible findings after Phase 1 |
+| `self-healing-locator` | Semantic locator healing | Consumes the verified root cause for locator-class defects |
+
+## 7. Reference Documentation
+
+- `python3 tools/pinpoint_failure.py <report>` — first command on any failed run.
+- `python3 tools/auto_heal.py` — closed-loop triage after isolation.
+- `python3 tools/cache_resolver.py query "<error message>"` — 0-token known-defect lookup.
+- [Four-phase worked case (`four_phase_case.md`)](examples/four_phase_case.md): a timeout failure traced to root cause.
+
+## 8. Attribution
+
+Adapted from **superpowers** skill `systematic-debugging` (https://github.com/obra/superpowers) — MIT License, Copyright (c) 2025 Jesse Vincent. The Iron Law, four-phase process, 3-fix architecture rule, and rationalization guardrails are re-scoped for enterprise QA automation in Synapse Hub; wording, structure, and tooling chain modified.

package/.agents/skills/systematic-debugging/examples/four_phase_case.md

@@ -0,0 +1,44 @@
+# Example: Four-Phase Investigation of a Timeout Failure
+
+Symptom: `TC-220_ExportReport` fails intermittently with
+`TimeoutError: waiting for selector '.export-toast'` after 30s.
+
+## Phase 1 — Root Cause Investigation (NO fixes yet)
+
+- Read the full stack trace: timeout is on the toast selector, not the
+  export click itself.
+- Reproduce: fails ~1 in 5 runs on large datasets; never on small ones.
+  Evidence-gathering, not guessing: the dataset-size correlation is recorded.
+- Recent changes: export endpoint moved to a queued job last sprint
+  (git log).
+- Component-boundary check (run once): UI click reaches the API (201 logged);
+  API enqueues the job (job row appears); job worker completes in 8-45s
+  depending on dataset size. The UI waits a fixed 30s. Which layer breaks?
+  The assumption "export finishes quickly" — not any single component.
+
+## Phase 2 — Pattern Analysis
+
+- Working example: the import flow already polls a job-status endpoint with
+  a completion condition instead of waiting on a fixed toast timeout.
+- Difference list: export flow waits on a UI toast; import flow polls the
+  job resource with a condition. One difference, however small it looks.
+
+## Phase 3 — Hypothesis
+
+> "The failure is caused by waiting on a time-bounded UI toast instead of
+> polling the export job status; large datasets exceed the toast window."
+
+Minimal test: poll the job endpoint until `state == 'done'` (condition-based
+wait) on the large dataset, 10 consecutive runs. No other change.
+
+## Phase 4 — Implementation
+
+1. RED test: large-dataset export asserts on the polled job state — fails
+   against the toast-wait implementation (reproduces the defect honestly).
+2. Single fix: replace the toast wait with the condition-based job poll,
+   mirroring the import flow pattern. Toast assertion kept as a secondary
+   visible-feedback check (never cut existing validation).
+3. Verify: RED test passes; full project suite re-run — output quoted in
+   the report; lessons recorded via `tools/cache_resolver.py record-lesson`.
+4. Anti-pattern rejected: bumping the timeout to 90s would have hidden the
+   root cause and broken the small-dataset UX latency signal.

package/.agents/skills/test-driven-development/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: test-driven-development
+description: "Enforce the RED-GREEN-REFACTOR cycle: no production or automation code is written before a failing test exists and has been watched failing. Use when implementing new helpers, Page Class logic, bug fixes, or any behavior change in test codebases."
+---
+
+# Test-Driven Development — Enterprise Red-Green-Refactor Standard
+
+Specialized skill for writing test-automation and tool code test-first: write the test, watch it fail for the right reason, write minimal code to pass, then refactor while staying green.
+
+---
+
+## 1. The Iron Law
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+- Code written before the test is deleted — not kept "as reference", not "adapted while writing tests". Delete means delete; implement fresh from the tests.
+- "Violating the letter of the rules is violating the spirit of the rules." Thinking "skip TDD just this once" is rationalization, not judgment.
+
+## 2. The Cycle
+
+```mermaid
+flowchart LR
+    R["<b>RED</b><br/>Write failing test"] --> VR{"Fails<br/>correctly?"}
+    VR -- no --> R
+    VR -- yes --> G["<b>GREEN</b><br/>Minimal code"]
+    G --> VG{"Passes +<br/>suite green?"}
+    VG -- no --> G
+    VG -- yes --> F["<b>REFACTOR</b><br/>Clean up, stay green"]
+    F --> R
+```
+
+### RED — Write the Failing Test
+
+- One behavior per test; a name that describes the behavior; real code (mocks only when unavoidable).
+- **Verify RED is mandatory:** run the test and confirm it fails for the expected reason — feature missing, not a typo. A test that passes immediately is testing existing behavior; fix the test, not the code.
+
+### GREEN — Minimal Code
+
+- Simplest code that passes the test. No features, no refactoring of other code, no "improvements" beyond what the test demands.
+- **Verify GREEN is mandatory:** the new test passes AND the project suite still passes. A green single file is not a green suite — run the project's test command before calling the change done. Any failure that run shows, including one you did not cause, goes into your report by name; a red test scrolled past unmentioned is a report falsified by omission.
+
+### REFACTOR — Clean Up While Green
+
+- Remove duplication, improve names, extract helpers. Keep tests green; add no behavior.
+
+## 3. Good Tests
+
+| Quality | Good | Bad |
+|---|---|---|
+| Minimal | One thing; "and" in the name means split it | `test('validates email and domain and whitespace')` |
+| Clear | Name describes behavior | `test('test1')` |
+| Intent-revealing | Demonstrates the desired API | Obscures what the code should do |
+| Honest | Asserts real behavior; you can name the production change that would make it fail | Asserts on mock behavior only |
+
+## 4. Hub Integration
+
+- **Fake-pass synergy:** test-first pairs with `python3 tools/infer_linter.py` (flags 0-assert and tautological tests) and Gate 8 — `python3 tools/micro_mutator.py` requires Mutation Score >= 80%, which a test written AFTER the code rarely achieves honestly.
+- **Bug fixes:** the bug reproduction IS the RED test. Never fix a bug without a test that fails before the fix and passes after.
+- **Locator logic:** selector helpers and Page Class methods follow the same cycle; live verification (Stage 2 of `playwright-live-interaction`, 100% hit rate under 200ms) is the RED check for locator changes.
+
+## 5. Common Rationalizations (All Rejected)
+
+| Excuse | Reality |
+|---|---|
+| "Too simple to test" | Simple code breaks; the test takes 30 seconds. |
+| "I'll test after" | Tests written after pass immediately — which proves nothing. You never watched it fail, so you never proved it can catch the bug. |
+| "Already manually tested" | Ad-hoc checking has no record and no repeatability; "worked when I tried it" is not coverage. |
+| "Keep as reference, write tests first" | You will adapt it. That is testing after. Delete means delete. |
+| "Need to explore first" | Fine — explore, throw the exploration away, start with TDD. |
+| "Test hard = skip" | Hard to test means hard to use; listen to the design signal. |
+| "TDD will slow me down" | TDD catches bugs before commit and lets you refactor without fear; the pragmatic shortcut is debugging in production. |
+
+## 6. Red Flags — Stop and Start Over
+
+- Code before test; test written after implementation
+- Test passes immediately on first run
+- Cannot explain why the test failed
+- Tests promised "later", or rationalizing "just this once"
+
+All of these mean: delete the code and restart the cycle from RED.
+
+## 7. Verification Checklist
+
+Before marking any implementation complete:
+
+- [ ] Every new function/method has a test
+- [ ] Each test was watched failing, for the expected reason
+- [ ] Minimal code was written to pass each test
+- [ ] The project's full test command was run and its output quoted
+- [ ] Output is pristine (no errors, warnings)
+- [ ] Edge cases and error paths covered
+
+Cannot check all boxes? The cycle was skipped — start over.
+
+## 8. Boundary vs Sibling Skills (Do Not Confuse)
+
+| Sibling | Owns | Hand-off |
+|---|---|---|
+| `systematic-debugging` | Root-cause investigation of failures | Phase 4 hands the reproduced bug to this skill as the RED test |
+| `verification-before-completion` | Evidence protocol for completion claims | This skill's GREEN check feeds the evidence that protocol quotes |
+| `antigravity-test-sentinel` | Hard completion blocking on gates | The sentinel enforces what this skill produces (fresh, watched, honest tests) |
+| `surgical-coding-principles` | Diff discipline | Goal-Driven Execution (principle 4) is operationalized by this cycle |
+
+## 9. Reference Documentation
+
+- `python3 tools/infer_linter.py` — AST scan for fake passes and 0-assert tests.
+- `python3 tools/micro_mutator.py` — Gate 8 mutation floor (>= 80%) validating test honesty.
+- [Worked QA example (`red_green_refactor_qa.md`)](examples/red_green_refactor_qa.md): full cycle for a retry helper in a test utility.
+
+## 10. Attribution
+
+Adapted from **superpowers** skill `test-driven-development` (https://github.com/obra/superpowers) — MIT License, Copyright (c) 2025 Jesse Vincent. The Iron Law, RED-GREEN-REFACTOR cycle, and rationalization table are re-scoped for enterprise QA automation in Synapse Hub; wording, structure, and examples modified.

package/.agents/skills/test-driven-development/examples/red_green_refactor_qa.md

@@ -0,0 +1,78 @@
+# Example: RED-GREEN-REFACTOR for a Test Utility Retry Helper
+
+Task: "Our Playwright API calls occasionally race the dev server; add retry
+to the request helper."
+
+## RED — write the failing test first
+
+```typescript
+test('retries a failing request up to 3 attempts then succeeds', async () => {
+  let attempts = 0;
+  const flakyCall = async () => {
+    attempts += 1;
+    if (attempts < 3) throw new Error('ECONNRESET');
+    return { status: 200 };
+  };
+
+  const result = await requestWithRetry(flakyCall);
+
+  expect(result.status).toBe(200);
+  expect(attempts).toBe(3);
+});
+```
+
+## Verify RED — MANDATORY
+
+```text
+$ npx vitest run tests/unit/retry.spec.ts
+FAIL: requestWithRetry is not a function
+```
+
+Fails for the right reason: the feature does not exist yet. (An error like
+"cannot read properties of undefined" would mean a typo — fix the test
+before writing code.)
+
+## GREEN — minimal implementation
+
+```typescript
+export async function requestWithRetry<T>(
+  call: () => Promise<T>,
+  maxAttempts = 3,
+): Promise<T> {
+  let lastError: unknown;
+  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
+    try {
+      return await call();
+    } catch (error) {
+      lastError = error;
+    }
+  }
+  throw lastError;
+}
+```
+
+## Verify GREEN — MANDATORY
+
+```text
+$ npx vitest run tests/unit/retry.spec.ts
+PASS 1/1
+$ npm test            # the PROJECT suite, not just this file
+PASS 214/214
+```
+
+A green single file is not a green suite — the project command is the
+acceptance run, and its output is quoted in the report.
+
+## REFACTOR — while green
+
+No duplication to remove yet; the next failing test (e.g. "gives up after 3
+attempts and rethrows") starts the next cycle. Adding exponential backoff NOW
+would be speculative — nobody asked for it.
+
+## Honesty check
+
+- The test uses real behavior (a counting closure), not a mock asserting on
+  itself.
+- Gate 8 wiring: `tools/micro_mutator.py` inverts the attempt boundary — the
+  test must survive the mutant (kill it), keeping Mutation Score >= 80%.
+- `tools/infer_linter.py` finds both assertions present and meaningful.

package/.agents/skills/token-and-context-optimizer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: token-and-context-optimizer
-description: "Optimize prompt context, distill verbose logs, and prevent context rot in Antigravity."
+description: "Optimize prompt context, distill verbose logs, and prevent context rot in Antigravity. Use when optimizing prompts or reducing token and context overhead."
 ---
 
 # Token & Context Optimizer — Antigravity Engineering Standard

package/.agents/skills/token-and-context-optimizer/examples/distilled_log_sample.txt

@@ -0,0 +1,3 @@
+[RAW CLI LOG: 3,200 lines truncated by distill_log.py]
+FAILED tests/checkout.spec.ts:42:15 -> TimeoutError: Waiting for selector `button.order-confirm`
+Status: 1 failed, 12 passed in 14.2s

package/.agents/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: verification-before-completion
+description: "Require fresh verification evidence — a command run in the current session with its real output — before any claim that work is complete, fixed, or passing. Use when about to report success, commit, open a PR, or close a task."
+---
+
+# Verification Before Completion — Enterprise Evidence Protocol
+
+Specialized skill for the evidence discipline behind every success claim in the hub: no completion statement exists without fresh verification output. This is the operational form of the Truth Anchor (No Fake Pass) rule in `AGENTS.md` Section 3.
+
+---
+
+## 1. The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If the verification command was not run in the current message turn, the claim cannot be made. "Evidence before claims, always."
+
+## 2. The Gate Function
+
+Run before claiming ANY status or expressing satisfaction:
+
+1. **IDENTIFY** — which command proves this claim?
+2. **RUN** — execute the full command, fresh and complete (not a partial rerun, not a memory of an earlier run).
+3. **READ** — full output, exit code, failure count.
+4. **VERIFY** — does the output actually confirm the claim? If no: state the real status with the evidence. If yes: state the claim WITH the evidence.
+5. **ONLY THEN** — make the claim.
+
+Skipping any step is lying, not verifying.
+
+## 3. Claim → Required Evidence Matrix
+
+| Claim | Requires | Not Sufficient |
+|---|---|---|
+| Tests pass | Test command output in this session: 0 failures | Previous run, "should pass" |
+| 9 Quality Gates pass | `python3 tools/verify_all.py --mode hub` output: 9/9 | Gates passing last week |
+| No fake passes | `python3 tools/infer_linter.py` output: 0 findings | "Assertions look fine" |
+| Mutation floor met | `python3 tools/micro_mutator.py` score >= 80% | Tests exist, so "they must kill mutants" |
+| Bug fixed | Reproduction test passes now | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified (watched fail, then pass) | Test passes once |
+| Subagent finished | Its diff inspected + its claims re-verified independently | Agent reports "success" |
+| Requirements met | Line-by-line checklist against the original request | Tests passing |
+
+## 4. Red Flags — STOP
+
+- Using "should", "probably", "seems to", "definitely works"
+- Expressing satisfaction before verification ("Perfect!", "Done!")
+- About to commit, push, or open a PR without verification in this turn
+- Trusting a subagent's success report without independent re-verification
+- Relying on a partial check (linter passed, therefore build must pass)
+- Thinking "just this once"
+
+## 5. Rationalization Prevention
+
+| Excuse | Reality |
+|---|---|
+| "Should work now" | RUN the verification. |
+| "I'm confident" | Confidence is not evidence. |
+| "Just this once" | No exceptions — one unverifiable claim poisons the whole report. |
+| "Linter passed" | The linter is not the compiler; linter does not equal build. |
+| "Agent said success" | Verify independently; subagent reports are claims, not evidence. |
+| "Partial check is enough" | Partial proves nothing about the whole. |
+| "Different words, so the rule doesn't apply" | Spirit over letter — paraphrases and implications of success are covered. |
+
+## 6. Key Patterns
+
+**Tests:** run command, quote `N/N pass`, then claim "all tests pass". Never "looks correct".
+
+**Regression (TDD red-green):** write test, run (MUST FAIL), apply fix, run (passes), quote both runs. A regression test without a watched failure is unproven.
+
+**Quality gates:** `python3 tools/verify_all.py --mode hub` fresh output with the 9/9 line quoted — required before any "task done" statement in swarm Stage 5.
+
+**Subagent delegation:** agent reports success, orchestrator inspects the diff and re-runs the decisive command before relaying any success upward.
+
+**Requirements:** re-read the original request, build the checklist, verify each item, report gaps or completion — "tests pass, phase complete" without the checklist is insufficient.
+
+## 7. When To Apply
+
+Always before: ANY success or completion claim, ANY positive statement about work state, committing or PR creation, task closure, moving to the next task, delegating to subagents.
+
+Applies to exact phrases, paraphrases, synonyms, and any communication implying completion or correctness.
+
+## 8. Boundary vs Sibling Skills (Do Not Confuse)
+
+| Sibling | Owns | Hand-off |
+|---|---|---|
+| `antigravity-test-sentinel` | Hard completion blocking until tests and gates pass | The sentinel is the enforcement gate; this skill is the evidence protocol the agent follows to pass it honestly |
+| `test-driven-development` | RED-GREEN-REFACTOR cycle | GREEN verification output feeds the evidence quoted here |
+| `systematic-debugging` | Root-cause investigation | Phase 4 fix verification uses this protocol for its "fixed" claim |
+
+## 9. Reference Documentation
+
+- `python3 tools/verify_all.py --mode hub` — the 9-gate acceptance command for hub work.
+- `python3 tools/infer_linter.py` — fake-pass scan required before any "tests are honest" claim.
+- [Evidence log example (`evidence_log_example.md`)](examples/evidence_log_example.md): claim/evidence pairing for a swarm task closure.
+
+## 10. Attribution
+
+Adapted from **superpowers** skill `verification-before-completion` (https://github.com/obra/superpowers) — MIT License, Copyright (c) 2025 Jesse Vincent. The Iron Law, gate function, claim-evidence matrix, and rationalization table are re-scoped for enterprise QA automation in Synapse Hub; wording, structure, and hub tooling modified.

package/.agents/skills/verification-before-completion/examples/evidence_log_example.md

@@ -0,0 +1,46 @@
+# Example: Claim/Evidence Log for a Swarm Task Closure
+
+Task: "Fix the flaky export test and get the suite green."
+Subagent: test-runner -> failure-analyst -> quality-gatekeeper (Stage 5).
+
+## Claim 1: "The flaky root cause is fixed"
+
+| Field | Value |
+|---|---|
+| Claim | Export timeout root cause fixed via condition-based job poll |
+| Evidence command | `npx playwright test tests/e2e/TC-220_export.spec.ts --repeat-each=10` |
+| Fresh output (this turn) | `10 passed (94.2s)` |
+| Verdict | Claim SUPPORTED — quoted with the output |
+
+## Claim 2: "The full suite is green"
+
+| Field | Value |
+|---|---|
+| Claim | Project suite green after the fix |
+| Evidence command | `npm test` (the project command, not one file) |
+| Fresh output (this turn) | `Tests: 2 failed, 214 passed` |
+| Verdict | Claim REFUTED — report states 2 failures in TC-118/TC-140 with
+  distilled failure blocks (tools/distill_log.py). Work is NOT done. |
+
+The 2 failures were pre-existing and not caused by the fix — still reported
+by name. A red test scrolled past unmentioned is a report falsified by
+omission.
+
+## Claim 3 (after the second fix cycle): "Task complete, 9/9 gates"
+
+| Field | Value |
+|---|---|
+| Evidence commands | `npm test` -> `Tests: 216 passed`; then
+  `python3 tools/verify_all.py --mode hub` |
+| Fresh output (this turn) | `Gate 0..8: PASS — 9/9 gates` and mutation score
+  `0.86 (>= 0.80)` |
+| Requirement checklist | Original request re-read; both requested items
+  (stabilize export test; suite green) verified line by line |
+| Verdict | "Task complete" claim MADE — with all evidence attached |
+
+## Anti-pattern (rejected)
+
+> "All good, the suite is green now, ready to merge."
+
+No command, no output, no turn — this is a claim without evidence. Under the
+Iron Law it is not verification, it is a guess wearing a checkmark.

package/.agents/skills/visual-regression-sentinel/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: visual-regression-sentinel
-description: "Run pixel and layout shift visual regression checks with anti-flake masking."
+description: "Run pixel and layout shift visual regression checks with anti-flake masking. Use when comparing screenshots for visual regressions with anti-flake masking."
 ---
 
 # Visual Regression Sentinel Skill
@@ -60,3 +60,23 @@ When visual regression fails:
 2. Determine if it is a **Real Regression** (CSS bug, broken layout) or **Intentional Redesign**.
 3. If intentional redesign: update baseline snapshots via `npx playwright test --update-snapshots`.
 4. If bug: file bug report with side-by-side artifact comparison.
+
+---
+
+## 4. Assert on Extracted Data, Not on the Model's Claim
+
+> *Borrowed and adapted from the Midscene.js prompting model (MIT license, web-infra-dev/midscene).*
+
+When an AI/vision agent reports a step as "done", that claim is **not evidence**:
+
+1. **Extract the visible state first** — pull structured data from what is
+   actually rendered (accessibility tree text, OCR'd region, or `aiQuery`-style
+   structured extraction), never the model's self-report.
+2. **Assert on the extracted values** — pair every extraction with a real
+   assertion (`expect(...)`/`verify...`) against the expected value; a vision
+   model can read a screen, but only an assertion can *prove* it.
+3. **Vision sees pixels, not DOM internals** — assertions on tab counts,
+   network state, or hidden attributes are invisible to the model; assert on
+   what is rendered.
+4. **Only then run the visual diff** — feed the §3 autopsy protocol; a green
+   extraction plus a clean diff is proven, everything else is owed.

package/.agents/skills/visual-regression-sentinel/examples/visual_mask_rules.json

@@ -0,0 +1,9 @@
+{
+  "maskSelectors": [
+    ".dynamic-timestamp",
+    ".live-chart-canvas",
+    ".user-avatar-badge"
+  ],
+  "thresholdSSIM": 0.98,
+  "maxDiffPixels": 25
+}

package/.agents/skills/wcag-audit-patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wcag-audit-patterns
-description: "Audit WCAG 2.2 accessibility (A/AA), keyboard navigation, and ARIA roles."
+description: "Audit WCAG 2.2 accessibility (A/AA), keyboard navigation, and ARIA roles. Use when auditing accessibility against WCAG 2.2 A/AA criteria."
 ---
 
 # WCAG 2.2 Accessibility Audit Patterns
@@ -70,8 +70,8 @@ Agent can automatically audit accessibility for any HTML file or live page URL v
 
 ```bash
 # Audit a local HTML snapshot
-python tools/wcag_audit.py path/to/page.html -o docs/wcag_audit_report.md
+python3 ~/.zcode/synapse-hub/tools/wcag_audit.py path/to/page.html -o docs/wcag_audit_report.md
 
 # Audit a live application URL directly
-python tools/wcag_audit.py https://staging.example.com --url -o docs/wcag_audit_report.md
+python3 ~/.zcode/synapse-hub/tools/wcag_audit.py https://staging.example.com --url -o docs/wcag_audit_report.md
 ```

package/.agents/skills/wcag-audit-patterns/examples/wcag_compliance_checklist.json

@@ -0,0 +1,10 @@
+{
+  "conformanceLevel": "AA",
+  "criteria": [
+    "1.4.3 Contrast (Minimum)",
+    "2.1.1 Keyboard",
+    "2.4.7 Focus Visible",
+    "4.1.2 Name, Role, Value"
+  ],
+  "auditTool": "axe-core"
+}