feat(ci): make the PR report easy to read and scan (STE, folds, colour, icons)

mods/coherence/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "coherence",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "description": "Coherence's hooks through one warm process per session, with its verdicts where the user reads them",
   "author": { "name": "PostHog" },
   "types": "./types/index.d.ts"

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@posthog/coherence",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "description": "A prosthetic for proprioception: specs, invariants, and the readings that keep an agent balanced.",
   "type": "module",
   "license": "MIT",

plugins/declared/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "declared",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "pluginApi": 2,
   "provides": {
     "declaredLanguages": true

plugins/python/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "python",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "pluginApi": 2,
   "provides": {
     "language": "python"

plugins/rust/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rust",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "pluginApi": 2,
   "provides": {
     "language": "rust"

plugins/typescript/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "typescript",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "pluginApi": 2,
   "provides": {
     "language": "typescript"

src/lifecycle/Lifecycle.spec.md

@@ -1283,13 +1283,16 @@ The gyroscope delivered through harness events: orient at start, regulate at sto
   because: in the comment mode, findings are reported and never fail the job, while a run that never happened is never mistaken for a clean one; a report read from the latest verdicts instead of the session's run would show a pass from another branch
   refuted: buildReport read every run in each project instead of the CI session's, so another session's later pass hid the failing verdict -> "ci report carries each project's problems, chokepoint verdicts, spec gaps and guard failures as Markdown, and fails only when Coherence did not finish" went red in ci.test.ts on its own assertion; restored byte for byte, green batched and alone (2026-10-09)
   kinds: none
-- the CI report says what each finding means and what to do: Under its counts the report says in plain words whether there is anything to fix, never claiming that when Coherence did not finish or a project's spec gaps were not read; it says that findings do not fail the check and can come from files the pull request did not change; each section with a finding says what that kind of finding means and how to fix it, a spec gap section says how many more the adoption baseline holds and why they are not listed, and a guard failure section says it carries no changed-file mark. Given --base, or else in a GitHub pull request run the pull request's fixed base commit from the triggering event, falling back to the base branch GITHUB_BASE_REF names, it says how many findings are in files changed since that commit, or why it could not tell — saying so without claiming none are when only some projects' changes were read — and marks each one, including a registry problem in a changed top-level config and a failing chokepoint attributed by its recorded files as well as its bypasses.
-  over: a report with nothing to fix, one Coherence could not finish or read every gap for, a spec problem, a failing chokepoint with a bypass and one attributed only by its own recorded file, a guard failure, an open spec gap beside one the adoption baseline holds, a spec problem and a gap in files the pull request changed, a registry problem in a changed config, findings in none it changed, a project read beside one that was not, a base git cannot diff against at a project or at the registry top, a file name git would quote, and --base, an event's fixed base commit, GITHUB_BASE_REF and neither read from a real repository
+- the CI report says what each finding means and what to do: Under its counts the report says in plain words whether there is anything to fix, never claiming that when Coherence did not finish or a project's spec gaps were not read; it says that findings do not fail the check and can come from files the pull request did not change; it says in one sentence what Coherence is; it names each kind of finding by what it means to the reader (a spec file error, a broken rule, an unchecked input, a bug that came back) in short active sentences with the fix as a list, shows spec syntax only as code to type, and leaves out a section with nothing in it; it gives the verdict as a coloured GitHub alert (TIP when there is nothing to fix, NOTE for findings outside the pull request's files, IMPORTANT when some are in them, WARNING when Coherence could not check everything), puts an icon before each kind of finding and on the changed-file mark, and lists each section's findings first, with what Coherence is and what each finding means folded in a details block that a familiar reader can skip; each section with a finding says what that kind of finding means, and how to fix it except for a bug that came back, which says only what it means since Coherence cannot tell the fix; an unchecked input section says how many more the adoption baseline holds and why they are not listed, and when an input's route goes further than its own component names where it reaches; and a guard failure section says it carries no changed-file mark. Given --base, or else in a GitHub pull request run the pull request's fixed base commit from the triggering event, falling back to the base branch GITHUB_BASE_REF names, it says how many findings are in files changed since that commit, or why it could not tell — saying so without claiming none are when only some projects' changes were read — and marks each one, including a registry problem in a changed top-level config and a failing chokepoint attributed by its recorded files as well as its bypasses.
+  over: a report with nothing to fix, one Coherence could not finish or read every gap for, a spec problem, a failing chokepoint with a bypass and one attributed only by its own recorded file, a guard failure, an open spec gap beside one the adoption baseline holds, a spec problem and a gap in files the pull request changed, a registry problem in a changed config, findings in none it changed, a project read beside one that was not, a base git cannot diff against at a project or at the registry top, a file name git would quote, a path or name holding backticks or Markdown, and --base, an event's fixed base commit, GITHUB_BASE_REF and neither read from a real repository
   via: ci report says what each finding means and what to do
   because: an adopter read a report of spec problems, spec gaps, traced controls and an adoption baseline and could not tell what any of it meant, whether the pull request caused it, or what to change; a report a reader cannot act on is noise on every pull request
   refuted: put back the old spec gap words in ci-report.ts, "no traced control" for what the gap means -> "ci report says what each finding means and what to do" went red in ci.test.ts on the spec gap case; restored byte for byte, green (2026-10-25)
   refuted: made the changed-file mark in ci-report.ts never mark a finding -> "ci report says what each finding means and what to do" went red in ci.test.ts, 4 of 10 cases; restored byte for byte, green (2026-10-25)
   refuted: dropped the GITHUB_BASE_REF default in ci-report.ts -> "ci report says what each finding means and what to do" went red in ci.test.ts on the base branch case; restored byte for byte, green (2026-10-25)
+  refuted: dropped the sentence that says what Coherence is from ci-report.ts -> "ci report says what each finding means and what to do" went red in ci.test.ts, 2 of 17 cases; restored byte for byte, green (2026-10-25)
+  refuted: made folded() in ci-report.ts print its text with no details block -> "ci report says what each finding means and what to do" went red in ci.test.ts, 6 of 17 cases; restored byte for byte, green (2026-10-25)
+  refuted: made code() in ci-report.ts wrap its text in single backticks -> "ci report says what each finding means and what to do" went red in ci.test.ts, 2 of 21 cases; restored byte for byte, green (2026-10-25)
   kinds: none
 - a closure mirror is named at the edit that breaks it: At PostToolUse, a write to a file in the value-import closure a declared mirror names is read again, and each file the closure now reaches that the list does not name is added to the edit's context as advice, never a block, naming the file that imports it and the list's file and line; a type-only import adds nothing, and the file the closure grew by is watched from then on.
   over: a fixture of the b37627e shape: a list of the page's modules, the closure of page.ts, a type-only import added to a closure file, then a value import of a file the list omits