refactor(skills): retrofit the corpus to the ADR-0020 context contract (#129)

Retrofits all 39 skills to ADR-0020's description/body context contract, then fixes what six rounds of independent review found in that retrofit — including four ways the hot gate itself failed open.

Closes #99, #107, #108, #110, #111, #114, #115, #120.

## The retrofit (waves 1-5)

| | Start | Now |
|---|---|---|
| Description FAILs (>400 chars) | 26 | **0** |
| Body FAILs (>900 words, body-only) | 9 | **0** |
| Dangling routing targets | 2 | **0** |
| `Kyberforge.CompositionNote` | 10 | **0** |
| Preload tax | 21,005 chars | **~10,500** |

Under the 12,000-char success criterion. Per-wave detail is on #99.

## The review fixes

**The gate failed open four ways, three of them found after the retrofit shipped.** An unrecognised follower token made a dangling target vanish. A skill directory with no `SKILL.md` resolved as a valid target, so a commit could be green locally and red in a fresh clone — three existing fixtures were relying on that, one of which made the install-leak A/B pass vacuously. Then the free-standing `/name` sweep turned out to be gated on the sentence carrying a boundary marker, so route notation in any other sentence was invisible — not an ERROR, not a SUGGESTION, not an INFO — which left the documented "`/name` always blocks" promise false from a second direction. All four fixed and pinned.

**Two checks were silently not running.** `validate-provenance.sh` checks 7-8 were dead across nine skills. Waking them exposed a deeper problem: they assume `Research doc:` names a source index, but 30 of 121 entries point at topic content documents, so every new check-7 INFO was a false positive and check 8 was saved from a false-FAIL flood only by an *unannounced* skip. Checks 7/8 are now scoped to source indexes and every skip announces itself (#121).

**The retrofit's own anti-goal, four times.** ADR-0020 warns that a blunt gate gets satisfied by deleting content rather than relocating it. `diagnose` and `skill-audit` relocated prose and then read it unconditionally; `prototype` and `vale-config` deleted rules outright that survived nowhere. All four addressed.

## Verification

- `bash tests/run-tests.sh --strict` — 24 suites, 0 skipped, 0 failed
- `bash tests/run-bats.sh` — 325 tests, 0 failures
- `pre-commit run --all-files` — 17/17
- `pre-commit run --hook-stage pre-push --all-files` — 16/16, with `apm marketplace check` and `apm pack --check-clean` run against the remote, not skipped
- `scripts/skill-size-check.sh` over all 39 skills — rc 0, 0 ERROR/FAIL, SUGGESTION-only
- Preload tax measured at **10,498 chars**, max description 390 — both inside budget
- Every new test proven non-vacuous by a deliberate mutation of the behaviour it covers

**Per-commit sync, stated accurately:** the ten commits from the latest review round each pass `check-plugin-content-sync` in isolation, verified by checking each out in a detached worktree with a clean between. The earlier gitea window (`dfacf05..bedbd1d`, nine commits) does **not** — its mirror was regenerated in one batch at `bbc7300`. An earlier revision of this description claimed the property held for every commit; it does not, and a bisect through that window lands on a red commit. **Squash-merge** to collapse it, or accept that this range is not bisectable.

## Version bump

Six plugins and the catalog take a **patch**, not a minor. The branch is **89 commits — 40 `fix` / 30 `refactor` / 12 `docs` / 5 `chore` / 2 `test` — zero `feat`, zero `!`, zero `BREAKING CHANGE`** — and adds no skill, agent, command or hook. (Two earlier revisions of this section cited a stale histogram, most recently 78 commits; the figures above are measured at HEAD.) Both rules this repo ships (`forge/references/version-bump.md`, landing in this PR, and `git-commits/references/conventional-commits-spec.md`) make that a patch, and the catalog set is unchanged at 7 entries.

Not settled by that: four published files were removed from the installed tree, three moved, and `caveman` gained `disable-model-invocation`, retiring its old triggers. Under a strict reading those are major-class and currently ship under `refactor:` with no marker. Whether the deployed skill surface is a public contract is written down nowhere — worth deciding, but it outlives this PR.

## Deliberately not in scope

#112 (cherry-pick ownership, now resolved in favour of `git-commits`), #113 (`rtk git` normalisation), #116 (research fan-out), #101 (audit-skill merge), #122 (non-spec skill-root files), #123 (no PRD producer) stay open. #117 is the one worth reading: the contract's remedy is to move prose into `references/`, which is exactly where neither the size gate nor Vale looks — and the blind spot is wider than #117 currently records, since there is no root `.vale.ini` at all, so every ADR, `CONTEXT.md` and `README.md` is unlinted too.

That blind spot let this branch carry two `level: error` `Kyberforge.SentenceOpenerThereIs` violations into `references/` files it created — `provider-adapter-author/references/provider-matrix.md:31` and `agent-audit/references/finding-criteria.md:95`. Both are reworded in `afadaae`, confirmed by routing each file through the audit's own `vale-wrap.sh` (1 error each before, 0 after). Five further occurrences sit in `references/` files already on `main`; those are the pre-existing corpus and stay with #117, which is the real fix.

Also unfixed and not this PR's: `apm install` appends a duplicate `SessionStart` entry to `.claude/settings.json`, so a fresh clone cannot get pre-push green without an edit AGENTS.md warns against. Reproduces identically on `main`.

Co-authored-by: Defame1297 <gitea@rkdr.net>
Reviewed-on: https://git.dev.rkdr.net/Defame1297/holocron/pulls/129
Co-authored-by: Claude Code AI - Gitea MCP <claude@noreply.git.dev.rkdr.net>
Co-committed-by: Claude Code AI - Gitea MCP <claude@noreply.git.dev.rkdr.net>

plugins/lint/skills/vale-run/README.md

@@ -19,5 +19,5 @@ Describe what you want to lint and how (human-readable output, CI/JSON output, f
 | File | Purpose |
 |------|---------|
 | `SKILL.md` | Core invocation, key flags, output format guidance, false-positive triage order |
-| `references/troubleshooting.md` | Inline suppression syntax, rule-specific disabling, spelling ignore lists, pre-commit integration, CI edge cases |
+| `references/troubleshooting.md` | Load when a rule appears not to apply, when writing inline suppression or spelling-ignore syntax, or when wiring Vale into pre-commit: resolved-config diagnostic (`vale ls-config`), format-specific suppression markup, rule-specific disabling, spelling ignore lists, pre-commit integration, CI edge cases |
 | `references/sources.md` | Research provenance |

plugins/lint/skills/vale-run/SKILL.md

@@ -1,28 +1,22 @@
 ---
 name: vale-run
 description: >
-  Use when running Vale (a prose/style linter) against files or directories in an
-  already-configured project — one that already has a .vale.ini — and interpreting
-  or reporting its results: choosing an output format for humans vs. CI, filtering
-  by severity, handling Vale's exit codes in scripts, or resolving common runtime
-  issues like false positives and unexpected CI failures. Use even if the user
-  doesn't say "vale" explicitly, e.g. "lint the docs", "check prose style", "run
-  the style linter", "why is CI failing on the docs check". Do not use when the
-  project has no .vale.ini yet, or needs styles installed/configured — that's the
-  vale-config skill.
+  Use when running Vale (a prose/style linter) on a project that already has a
+  .vale.ini and acting on its output — even when the user does not say "Vale",
+  as in "lint the docs", "check prose style", or "why is CI failing on the docs
+  check". Not setting up Vale config or styles -> `vale-config`.
 metadata:
-  version: "0.1.1"
+  version: "0.1.3"
   category: lint
   source_keys:
     - context7-websites-vale-sh
+    - house-vale-3-15-2-repro
 ---
 
 ## Gotchas
 
-- Vale's exit code is driven by `error`-level alerts only. `warning` and `suggestion` alerts are reported but still exit `0`. `MinAlertLevel` and `--minAlertLevel` control display, never the exit code — no flag makes warnings fail. A rule that must gate CI or a commit hook has to be `level: error`. This is the single most common way a Vale gate silently passes everything.
-- `vale ls-config` prints the fully-resolved, currently active configuration as JSON — the fastest way to check why a rule "isn't applying" is what's actually active, not what's written in `.vale.ini`.
-- Inline suppression syntax is format-specific: Markdown uses HTML comments `<!-- vale off -->` / `<!-- vale on -->`, MDX uses `{/* vale off */}` / `{/* vale on */}`, Org mode uses `# vale off` / `# vale on`. The MDX form does nothing in a plain `.md` file — the alert still fires. Don't assume one syntax works across formats.
-- Before calling the `vale` binary directly, check whether the target repo documents its own wrapper script for Vale (look in its README, CONTRIBUTING docs, pre-commit config, or a `scripts/` directory). Some projects wrap `vale` to work around real bugs — e.g. a scope that silently stops matching multi-line YAML block-scalar frontmatter fields — and calling bare `vale` in a repo that has such a wrapper silently skips whatever the wrapper works around. If a wrapper is documented, invoke it with the same arguments instead of calling `vale` directly; otherwise fall back to the default below.
+- Vale's exit code keys off `error`-level alerts only — `warning` and `suggestion` alerts print and still exit `0`, and `MinAlertLevel`/`--minAlertLevel` filter what is displayed, never the exit code — no flag makes warnings fail. A rule that must gate CI or a commit hook has to be `level: error`. This is the most common way a Vale gate silently passes everything.
+- Check whether the target repo documents its own `vale` wrapper script (README, CONTRIBUTING, pre-commit config, `scripts/`) before calling the binary. Some projects wrap `vale` to work around real bugs — e.g. a `text.frontmatter.<key>` scope that silently stops matching multi-line values (`>` folded scalars, plain continuation lines and quoted multi-line scalars all go unmatched; a `|` literal block scalar still works) — so bare `vale` skips whatever the wrapper fixes. Invoke the documented wrapper with the same arguments.
 
 ## Running vale
 
@@ -41,18 +35,22 @@ Key flags:
 | `--no-exit` | Suppresses the nonzero exit that `error`-level alerts would otherwise cause; a no-op when no rule is `error`-level. Use in CI stages that should surface lint output without hard-failing the build. |
 | `--ignore-syntax` | Treats input as plain text, skipping format-aware parsing — use when a file's syntax-aware parser produces noisy or wrong results. |
 
-`vale sync` downloads the packages/styles declared in `.vale.ini` — that's a one-time-per-change setup step (vale-config's territory), not part of a normal lint run. If a run behaves as though no styles are active, that's a sign `vale sync` hasn't been run yet, not a `vale-run` problem.
+`vale sync` downloads the packages/styles declared in `.vale.ini` — that's a one-time-per-change setup step (vale-config's territory), not part of a normal lint run. If a run behaves as though no styles are active, check `vale ls-config` before concluding it is a sync problem — an unrun `vale sync` is the usual cause, and not a `vale-run` problem. `ls-config` resolves config files, styles and `StylesPath` search paths; it never enumerates rules, so it cannot tell you a given rule is live.
 
 Prefer `--output=JSON` whenever the caller (a script, a CI step, another agent) needs to act on individual alerts rather than just get a pass/fail signal — `CLI` and `line` are for humans reading the terminal.
 
 ## Fixing false positives
 
+Before writing any inline suppression markup (steps 2 and 3 below), read `references/troubleshooting.md`: the form follows the parser the config picks, not the file extension, and the wrong form suppresses nothing while Vale reports no error.
+
+`.mdx` is the trap — the two parsers take opposite forms, so read `.vale.ini` first. Under `[formats] mdx = md` (what `vale-config` recommends) it is Markdown: `<!-- vale off -->` suppresses, `{/* vale off */}` does not. Without that mapping Vale takes the native MDX path, which needs the external `mdx2vast` binary (`npm install -g mdx2vast`); missing, the whole invocation dies — `E100 [lintMDX] ... mdx2vast not found`, exit 2 — leaving every other file in the run unlinted too.
+
 Scope the fix as narrowly as possible, in this order:
 
 1. **Mentioning banned phrasing rather than using it**: wrap it in backticks or a fenced code block. Vale skips code spans and fences, so no suppression is needed at all. Try this before any suppression markup.
 2. **One-off**: inline-suppress the specific text run with the format's `vale off`/`vale on` markup.
-3. **Recurring known-exception string, one rule**: disable that specific rule for that specific match inline (e.g. `<!-- vale Style.Redundancy["ACT test","OTHER"] = NO -->` ... `= YES`), rather than the whole rule.
-4. **Known project term failing spell check**: add it to the style's `ignore` list, not an inline suppression.
+3. **Recurring known-exception string, one rule**: disable that specific rule for that specific match inline (in Markdown, e.g. `<!-- vale Style.Redundancy["ACT test","OTHER"] = NO -->` ... `= YES`), rather than the whole rule.
+4. **Known project term failing spell check**: add it to the style's `ignore` list, not an inline suppression — and put the listed file at the `StylesPath` root, because an `ignore` path that resolves nowhere is a silent no-op (`references/troubleshooting.md`).
 
 Never disable a rule project-wide to fix one false positive — editing `.vale.ini`/`BasedOnStyles` is vale-config's job, and it silences the rule everywhere, not just the false-positive case.
 
@@ -60,4 +58,4 @@ If output looks wrong because Vale mis-parsed a file's format, rerun with `--ign
 
 For CI that fails solely because Vale returned non-zero on `error`-level alerts — not because the content is wrong for that pipeline stage — add `--no-exit` rather than disabling the rule. If the failing alerts are warnings or suggestions, Vale is not what failed the build; look elsewhere.
 
-If setting up Vale as a pre-commit hook or need the full inline-suppression/spelling-ignore syntax reference, read `references/troubleshooting.md`.
+If a rule appears not to apply, if you need the spelling-ignore syntax, if a CI failure still needs diagnosing, or if setting Vale up as a pre-commit hook, read `references/troubleshooting.md`.

plugins/lint/skills/vale-run/references/sources.md

@@ -7,3 +7,11 @@
 - **Research doc:** plugins/lint/docs/research/docs/vale/sources.md
 - **Contributing files:** SKILL.md, references/troubleshooting.md
 - **Status:** `extracted`
+
+## house-vale-3-15-2-repro
+
+- **URL:** (house-verified — reproduced locally against the `vale` binary, not an external source)
+- **Description:** Behaviour of Vale 3.15.2 established by running it against purpose-built fixtures in this repo, where vale.sh documents nothing or documents it wrongly: `.mdx` has no built-in support and needs either `[formats] mdx = md` or an external `mdx2vast` binary (absent, the whole invocation exits 2 with `E100 [lintMDX]`), the inline-suppression form inverts between those two configurations, the `spelling` check's `ignore` paths resolve against `StylesPath` or the working directory but never against the rule file's own directory and fail silently when they resolve nowhere, `ls-config` reports styles and paths but never rules, and the `text.frontmatter.<key>` scope matrix across multi-line YAML forms.
+- **Research doc:** none — house-verified reproduction, not part of the plugin's research corpus (no `plugins/lint/docs/research/` topic file backs this entry)
+- **Contributing files:** SKILL.md, references/troubleshooting.md
+- **Status:** `extracted`

plugins/lint/skills/vale-run/references/troubleshooting.md

@@ -1,20 +1,77 @@
 ---
 source_keys:
   - context7-websites-vale-sh
+  - house-vale-3-15-2-repro
 ---
 
 # Vale troubleshooting reference
 
+## Why a rule isn't applying
+
+`vale ls-config` prints the fully-resolved, currently active configuration as JSON. Check that
+before rereading `.vale.ini` — what is written in the config file is not necessarily what is
+active, and the resolved output is the fastest way to see which config files, styles and
+`StylesPath` directories a run actually loaded.
+
+It stops at styles. It does not enumerate rules, and neither does any other Vale 3.15.2
+subcommand — `ls-config`, `ls-dirs`, `ls-vars` and `ls-metrics` were each checked and none
+names the rule. Against a config
+whose custom rule was demonstrably firing on the target file, `ls-config` reported
+`"SBaseStyles": {"*.md": ["MyStyle"]}` and the two `StylesPath` search paths, but
+`"Checks": null`, `"SChecks": {"*.md": {}}` and `"RuleToLevel": {}` — the firing rule's own name
+appeared nowhere in the output. So `ls-config` answers "is this style loaded, and from where",
+not "is this rule live". For the latter, run Vale over a small fixture that should trigger the
+rule and see whether it alerts.
+
 ## Inline suppression syntax by format
 
-Markdown uses HTML comments — the MDX `{/* */}` form does not suppress anything in a plain `.md` file:
+### Prerequisite: `.mdx` needs a decision before it lints at all
+
+Vale 3.15.2 has no built-in MDX support. If `.vale.ini` does **not** map the extension, Vale takes
+the native MDX path and shells out to an external `mdx2vast` binary. Without it on `PATH` the run
+dies before linting anything:
+
+```
+$ vale .            # doc.md and doc.mdx both present, no [formats] mapping
+E100 [lintMDX] Runtime error
+
+mdx2vast not found
+
+Execution stopped with code 1.
+$ echo $?
+2
+```
+
+That is the whole invocation, not just the `.mdx` file — the `.md` alongside it produced no output
+either. Fix it one of two ways, and the choice is not cosmetic because it also decides the
+suppression syntax:
+
+| `.vale.ini` | Prerequisite | Parser | Suppression form that works |
+|---|---|---|---|
+| `[formats]` maps `mdx = md` (what `vale-config` recommends) | none | Markdown | `<!-- vale off -->` |
+| no `mdx` mapping (native MDX) | `npm install -g mdx2vast` | MDX | `{/* vale off */}` |
+
+Key the markup to that config row, never to the file extension. Verified against Vale 3.15.2, same
+three fixtures under each config:
+
+| File | Mapped `mdx = md` | Native MDX (`mdx2vast` installed) |
+|---|---|---|
+| no suppression (control) | alert, exit 1 | alert, exit 1 |
+| `<!-- vale off -->` | suppressed, exit 0 | `E100 ... failed to parse MDX: Unexpected character` `` `!` ``, exit 2 |
+| `{/* vale off */}` | **not suppressed**, exit 1 | suppressed, exit 0 |
+
+Under the mapping the JSX comment is worse than inert: it is linted as prose, so
+`{/* vale Vale.Repetition = NO */}` produced three alerts where the un-suppressed file produced
+one — its own markup tripped the rule twice more.
+
+Markdown, and `.mdx` mapped onto it — HTML comments:
 ```markdown
 <!-- vale off -->
 This text will be ignored.
 <!-- vale on -->
 ```
 
-MDX:
+Native MDX only (no `[formats]` mapping, `mdx2vast` on `PATH`):
 ```mdx
 {/* vale off */}
 This text will be ignored.
@@ -39,7 +96,8 @@ This is some text ACT test
 <!-- vale Style.Redundancy["ACT test","OTHER"] = YES -->
 ```
 
-MDX:
+Native MDX only — under `[formats] mdx = md` an `.mdx` file takes the Markdown form above, and
+this one silences nothing:
 ```mdx
 {/* vale Style.Redundancy["ACT test","OTHER"] = NO */}
 This is some text ACT test
@@ -59,6 +117,36 @@ ignore:
   - ignore2.txt
 ```
 
+**Where the file goes, and why a wrong answer is invisible.** Each entry resolves against the
+`StylesPath` root, or against the working directory `vale` is invoked from. It does **not** resolve
+against the rule file's own directory — which is the natural reading of the YAML above, since the
+path sits inside the rule, and it is wrong. Verified against Vale 3.15.2 across four fresh trees,
+each with the same rule and the same unknown word:
+
+| Where `ignore1.txt` was placed | Result |
+|---|---|
+| `<StylesPath>/ignore1.txt` | word ignored, exit 0 |
+| `./ignore1.txt` in the directory `vale` runs from | word ignored, exit 0 |
+| `<StylesPath>/<Style>/ignore1.txt`, beside the rule | word still flagged, exit 1 |
+| file absent entirely | word still flagged, exit 1 |
+
+The two failing rows emit no warning, no error, and no diagnostic of any kind: the output is
+byte-identical to the same rule with the `ignore` key deleted. A misplaced ignore list looks exactly
+like a list that was read and did not contain the word.
+
+Prefer the `StylesPath` root. The run-directory form is the fragile one — move the invocation and it
+silently stops working. Same tree, same file, only the working directory changed:
+
+```
+$ cd project && vale doc.md                                  # ignore1.txt at project root
+✔ 0 errors, 0 warnings and 0 suggestions in 1 file.          # exit 0
+
+$ cd /elsewhere && vale --config=project/.vale.ini project/doc.md
+ 1:5  error  Did you really mean 'zzqwidget'?  MyStyle.Spell  # exit 1
+```
+
+The `StylesPath` copy survives that move; the run-directory copy does not.
+
 ## Plain-text fallback
 
 If a file's syntax-aware parsing produces noisy or incorrect results (an unsupported or malformed format), rerun with `--ignore-syntax` to treat it as plain text instead of relying on the format-specific parser.