sshlg-skills 1.3.0 → 1.3.2

package/CHANGELOG.md

@@ -1,3 +1,55 @@
+## v1.3.2 — half of yesterday's fixture could not run, and the live page said so
+
+v1.3.1 shipped a check asserting that every `Person` reference carries `@id` and
+nothing else. **That half of it was unreachable.** A reference is `{"@id": …}` with
+no `@type`, and the walker collected only nodes where `@type === 'Person'` — so it
+never saw a single reference, and the id-match assertion was dead code. A wrong id
+in an author reference would have passed.
+
+Found by the live page, not by reading it: the post-deploy probe printed `refs=0`
+on all five templates, which is impossible for a site that emits two references per
+page. The count was the walker, not the site.
+
+The walker now also collects the value of any `author`, `publisher`, `creator` or
+`maintainer` key, and the check ends with `refsSeen > 0` — because without that line
+it passes on a site emitting no references at all, which is exactly the state that
+hid the defect. Three plants, each caught: a reference pointing at a **different**
+person id (the one v1.3.1 could not see), a reference that re-describes the person,
+and every reference deleted.
+
+Two versions in a row where the finding was in the instrument rather than the
+subject. That is now written into `docs/evidence/retro.md` as a standing
+instruction: **a probe reporting zero is a claim about the probe until the probe has
+been shown finding one.**
+
+## v1.3.1 — the pass shipped the defect it was about, and the check that finds it did not exist
+
+Post-deploy verification of v1.3.0 found **two `Person` nodes on the front page**
+with no id linking them: the layout's publisher, plus an inline copy under
+`WebSite.author` and another under `SoftwareApplication.author`. That is not one
+entity stated twice — it is two candidates a consumer has to guess are the same,
+which is precisely what v1.3.0 shipped to fix. One `@id` now
+(`https://skills.sshlg.me/#person`); every other reference is `{"@id": …}` and
+describes nothing.
+
+**`test/site_test.js` had thirty checks and none of them parsed the structured
+data.** That is why it shipped. Two fixtures now `JSON.parse` every `ld+json` block
+on every built page and walk the objects: one asserts each page carries an
+identified publisher, the other that exactly one node *describes* the person and
+every other reference carries `@id` and nothing else. Both were watched failing
+against planted defects before being kept — re-describing the person fails one,
+removing the `@id` fails two.
+
+**The instrument note, recorded because it is the more useful half.** The first
+post-deploy check reported the entity missing from all four pages, and it was
+wrong: the pattern had a space in `"@type": "Person"` and the served JSON is
+minified. **The grep was broken, not the site.** A check that greps rendered HTML
+for a formatted substring is testing the formatter — which is also why the new
+fixtures parse rather than match. It re-opens yesterday's `faq-schema-partial`
+disagreement as less certain than it was recorded: an instrument that disagreed
+with a hand-check was resolved in the site's favour once today, and the cause was
+the pattern.
+
 ## v1.3.0 — the page most likely to be quoted was the one saying least about itself
 
 An audit of the live site, measured rather than recalled. Two leaks and one gain

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sshlg-skills",
-  "version": "1.3.0",
+  "version": "1.3.2",
   "description": "One launcher/updater for the ssheleg skill family (super-ux, task-pipeline, agent-sync, make-skill, sheleg-design, seo-aeo-audit, sheleg-dev, agent-stack) across every agent — Claude Code, Cursor, OpenCode, Kilo, Kimi, Hermes, OpenClaw, Codex, and more.",
   "bin": {
     "sshlg-skills": "bin/sshlg-skills.js"