← Commit history

Dev skill: shipping behavior means shipping docs — skills, then pkg, then release. Records that knowing the release-vs-pkg trap did not prevent it, which is why it is now a ship gate.

John Lauer ·828d755172 ·3mo ago ·parent 1fb70b7
1 file changed +25
dev-skills/pup-bridge-dev/SKILL.md+25
@@ -1129,3 +1129,28 @@ persistent multi-thread container the natural way to satisfy that is a profile e - **Verify a config change took effect in a FRESH shell, don't assume the write was the fix.** I claimed   the profile fix worked; one `echo` of the variable proved it hadn't. Reported as adom/adom-desktop#37,   asking for a global `--ai-thread` flag so the CORRECT mechanism is also the ergonomic one.++## Shipping behavior means shipping DOCS: skills, then pkg, then release (John, 2026-07-25)++When you change what a verb returns or how it behaves, the change is not delivered until the CONSUMER's+skill says so. pup ships hints programmatically (`_verifyRender`, `renderCheck`, `_reportIssues`,+`_hint`), and those are the primary channel — but the container-side `SKILL.md` is what an AI reads when+it is deciding *how to use pup at all*, and a concept that appears only in a response is easy to skip.++**The rule: on any behavior change, update `SKILL.md` FIRST, publish the pkg tarball SECOND, cut the+release zip THIRD.** Full recipe + the verification commands live in the `pup-bridge-publish` skill; the+reason it is a rule and not a preference is that both halves failed silently in one day:++- **Stale skill.** Native-first, `renderCheck`/`_verifyRender`, AI-thread naming and the bug-report+  invitation all shipped; a grep of the user-facing skill found 5 of 6 concepts absent. Users would have+  installed a skill describing a pup that no longer existed.+- **Release outran the pkg.** Releases 1.9.94→1.9.104 shipped while the last `pkg publish` sat at 1.9.93.+  Because a release and a pkg share one version list and the resolver takes the MAX row, the max row was+  a tarball-less release and **every constraint install of the page 404'd** (`pkg update` →+  `STALE_INSTALL: the registry no longer resolves it`). The release pipeline reported success throughout.++**Why this class of bug keeps happening here:** the release half is loud (gates, hashes, on-disk+verification) and the docs/pkg half is silent. Nothing fails when the skill is stale. So it needs a+checklist item and a gate (`ship.sh` GATE 2b now checks the pkg tarball resolves at the shipped+version), not a good intention. I wrote the release-vs-pkg trap into this very skill in the morning and+still walked into it in the afternoon, which is the argument for enforcement over knowledge.