Add CI, Kotlin/Swift dashboard, and repo-consistency cleanups (#4)

- Add a GitHub Actions workflow running all three pytest suites
  (benchmark tooling + both bundled skills) plus the sabotage check.
- Generate the missing Kotlin/Swift interactive dashboard
  (docs/kotlin-swift-results.html) from the committed scorecard, with a
  static preview in examples/ and README links alongside the other two.
- Drop the Kotlin/Swift repos from score_cross_language.py: the
  committed matrix was scored by the manifest-driven, module-scoped
  score_kotlin_swift_matrix.py, and rescoring them here (whole-repo,
  unscoped) would merge contradictory baselines into the cross-language
  scorecard.
- Correct the CHANGELOG claim that the C.1 instruments "now agree" —
  score.py and aggregate_results.py still match different textual forms
  of the stdlib mock.patch idiom.
- Frame reports/ as the coverage-driven control up front, so its
  mostly-"Worse" verdict matrix reads as the motivation for the quality
  experiment rather than a contradiction of it.
- Move the orphaned baseline_summary.md into reports/ and link it;
  clarify README's 185→59 A.2 claim (coverage-arm vs quality-arm, not
  vs baseline); fix SKILL.md's two stale python|js|go-only mentions;
  mark gen_prompts.py and verify_run.sh as historical coverage-control
  tooling.


Claude-Session: https://claude.ai/code/session_011BDzS3SyE6Sh3GE4nnSoWN

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Author: rollinsio

.claude/skills/test-quality/SKILL.md

@@ -34,7 +34,8 @@ model, drove the gain). The two reference docs are that experiment's distilled
 output:
 - `references/quality-contract.md` — 10 anti-fragility rules, each with the repair.
 - `references/scorecard.md` — the scoring axes, the improvement gate, the stop condition.
-- `scripts/score.py` — measures the auto-countable axes for any pytest suite.
+- `scripts/score.py` — measures the auto-countable axes for a suite in any
+  supported language (Python/pytest, JS/TS, Go, Kotlin, Swift).
 
 **Read both reference docs before starting.** They are the substance; this file
 is the procedure.
@@ -76,7 +77,7 @@ Identify the source package and its tests dir. Detect the **language/framework**
 ### 2. Capture the baseline (do this BEFORE changing anything)
 - Run the suite with branch coverage; record line % and branch % — this is the
   coverage floor.
-- `python <skill>/scripts/score.py --tests <tests_dir> [--lang python|js|go]`
+- `python <skill>/scripts/score.py --tests <tests_dir> [--lang python|js|go|kotlin|swift]`
   for the auto axes (`--lang` auto-detects if omitted).
 - Preserve the starting state so you can score against it: copy the tests dir
   aside, or note the git ref. Later runs use `--baseline <that copy>`.

.github/workflows/ci.yml

@@ -0,0 +1,25 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - name: Install measurement-tooling deps
+        run: pip install -r requirements-dev.txt
+      - name: Unit tests (benchmark tooling + both skills)
+        run: >
+          python -m pytest -q
+          tests/
+          .claude/skills/test-quality/tests/
+          .claude/skills/results-dashboard/tests/
+      - name: Sabotage check (curated mutations must all be caught)
+        run: python scripts/sabotage_check.py

CHANGELOG.md

@@ -35,8 +35,11 @@ the pre-fix scorer. Each fix has a named regression test in
   paren hid the `match=` kwarg.
 - **Python C.1 missed the stdlib `mock.patch` idiom** — `from unittest import
   mock; mock.patch(...)` / `mock.patch.object(...)` scored 0 (only `mocker`,
-  bare `patch(`, `Mock(`, `MagicMock` counted). `aggregate_results.py` already
-  counted `unittest.mock` — the instruments now agree.
+  bare `patch(`, `Mock(`, `MagicMock` counted). `score.py` now catches it via
+  a `mock.patch` alternative. Note the instruments still differ textually:
+  `aggregate_results.py` matches the literal `unittest.mock` (which does not
+  fire on `from unittest import mock` + `mock.patch(...)`) and lacks the
+  `mock.patch` alternative, so the two can disagree on that idiom.
 - **Go `test_def` missed testify suite methods and counted `TestMain`** — now
   matches an optional method receiver (`func (s *Suite) TestFoo(`) and
   excludes exactly `TestMain` (a `TestMainPage` still counts).

README.md

@@ -92,7 +92,8 @@ Across **27 quality-driven runs** (9 libraries × 3 iteration budgets),
 structural: the generated suites are dramatically **more LOC-efficient**
 than every baseline, carry **zero substring-match assertions** and **no
 hand mocks** of the code under test, cut private-symbol access sharply
-(185 → 59 across the Python matrix — though not to zero), and are more
+(the coverage-driven arms' 185 total fell to 59 under quality-driven
+across the Python matrix — though not to zero), and are more
 parametrized than most baselines.
 
 Three honest caveats the numbers also surfaced:
@@ -122,13 +123,18 @@ Three honest caveats the numbers also surfaced:
 - [`docs/python-results.html`](docs/python-results.html) — the
   Python dashboard, including the decomposition of *why* coverage-driven
   scored 2/9 and quality-driven scored 9/9.
+- [`docs/kotlin-swift-results.html`](docs/kotlin-swift-results.html) —
+  the Kotlin/Swift matrix dashboard: six libraries × three policies,
+  all 18 arms vs their maintainer-written baselines.
 - [`FINDINGS.md`](FINDINGS.md) — the full running analysis.
 
 Static previews live in [`examples/`](examples/) (GitHub renders the HTML
 dashboards as source, so open them locally for the interactive charts):
 
 [![Cross-language results — 18/18 arms beat the human baseline](examples/cross-language-results.png)](docs/cross-language-results.html)
 
+[![Kotlin + Swift matrix — all 18 arms beat their maintainer-written baselines](examples/kotlin-swift-results.png)](docs/kotlin-swift-results.html)
+
 ## The quality scorecard
 
 The criteria above are a multi-axis rubric; the scorer auto-counts the
@@ -195,7 +201,8 @@ green** — the three reds are all *oneshot* (one pass, no repair) and fail to
 green" pattern the Python/JS runs showed. Every W/L/T was re-scored independently
 of the generating agent, and every green count re-run from the real toolchain.
 The two largest repos (`kotlinx.serialization`, `swift-collections`) are scoped to
-a coherent core module, stated explicitly. See
+a coherent core module, stated explicitly. See the
+[interactive dashboard](docs/kotlin-swift-results.html),
 [`results-kotlin-swift-scorecard.md`](results-kotlin-swift-scorecard.md) and
 [`reports/kotlin-swift-generation.md`](reports/kotlin-swift-generation.md).
 (These profiles are heuristic, not the empirically-validated Python set, so read