skills: point every test-editing path at tests/STYLE.md

/recipe-upgrade --with-tests, /ci-test-review and /cc-ci-tests-update all author test changes, and all three had only 'never weaken a test' as guidance. That did not stop the plausible failure: the fixture INSERTed rows into the app's database, which was correct for v2 and silently wrong for v3, where a site must belong to a team. Events were acked 202 and discarded; the recipe sat RED for six weeks. The rule that would have prevented it — set state up through the app's own interface, not its database — now lives in tests/STYLE.md in the cc-ci repo, and each of the three paths is told to read it before editing a test.
2026-08-11 14:41:10 +00:00
parent 1db85a7e77
commit 6c91373357
3 changed files with 18 additions and 0 deletions
@@ -85,6 +85,14 @@ failure (AI — this is the `ci-test-review` step-3 diagnosis):

 ### 2. For each stale test — author the minimal test update (AI; never weaken)

+> **Read `tests/STYLE.md` in the cc-ci repo before writing the update.** It is the rulebook for test
+> changes, written from failures this pipeline actually produced. Most load-bearing: set state up
+> through the app's **own interface, never its database** (a plausible fixture that INSERTed rows
+> passed on v2 and silently broke on v3 — 202 acks, rows in postgres, nothing ingested — and held the
+> recipe RED for six weeks), **gate on version rather than supporting both** (old-version tests can be
+> deleted; the older version is only exercised via the upgrade tier), and correct the fixture or the
+> wait but **never the assertion**.
+
 Work on **one recipe at a time** (serialize — each verification deploys a recipe on the shared
 Swarm). For each `STALE_TESTS` entry: