@ssheleg/sheleg-dev 0.9.0 → 0.9.2

package/CHANGELOG.md

@@ -4,6 +4,41 @@ All notable changes to this project are documented here.
 Format: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 Versioning: [SemVer](https://semver.org/spec/v2.0.0.html).
 
+## v0.9.2 — the README stops claiming a command the package cannot run
+
+The README told a reader to run commands the published package cannot run: it ships no
+`test/` directory, so `npm test` resolves in a clone and nowhere else. Measured against the
+published tarball on 2026-08-25. Shipping the suite does not fix it — the plants live in
+`.github/workflows/`, which no packaging npm can express puts in a tarball — so the document
+now names where the command runs instead of claiming it, beside a marker the umbrella's
+validator reads. Naming a dead command is this family's own rule; claiming one is the defect.
+
+
+## v0.9.1 — 2026-08-24
+
+### The skill was wrong at the exact place its author then tripped
+
+`error-tracking` shipped telling readers to take the release version from
+`HEROKU_SLUG_COMMIT`. Using it on a real project the same evening produced the
+failure it exists to prevent: that variable is **not a config var** — it is dyno
+metadata, injected only when the `runtime-dyno-metadata` labs feature is on, and
+absent in silence otherwise. With the feature off, the SDK reported no release at
+all while Sentry held a release with a deploy nothing would ever attach to.
+Nothing errored.
+
+Two more measurements from the same hour: `heroku config:get` never prints it,
+even when it is working, because it is never a config var; and enabling the
+feature takes effect on the next **release**, not on a restart.
+
+`references/releases.md` now names the trap, gives the three commands that tell
+you which state you are in, and recommends not depending on the variable alone —
+set `RELEASE` from the deploy, which needs no platform feature and cannot drift
+because one command produces both sides.
+
+Also added, from the same mistake one level up: create the Sentry release for the
+**deployed** commit, not for local HEAD. They differ the moment commits are
+pushed but not deployed, and the result is a release nobody's events belong to.
+
 ## v0.9.0 — 2026-08-24
 
 ### The pack that wires integrations had nothing about knowing when they break

package/README.md

@@ -222,6 +222,10 @@ correctly. It does not tell you which one to trust.
 
 ## Verify
 
+<!-- commands-run-in: a clone -->
+These run **in a clone of this repository**. The published npm package ships no
+`test/` directory, so from an install they are names, not commands.
+
 ```bash
 npm test    # the validator, the manual gate's 65 fixtures, the money fixtures' 13 checks
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ssheleg/sheleg-dev",
-  "version": "0.9.0",
+  "version": "0.9.2",
   "description": "Six integration skills for the layer a product reaches once it has users: Stripe subscription billing, crypto payments, ad and conversion tracking under Consent Mode v2, Google sign-in and the wider Google auth surface, and Core Web Vitals. This package is the installer CLI.",
   "bin": {
     "sheleg-dev": "bin/sheleg-dev.js"

package/plugins/sheleg-dev/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "sheleg-dev",
   "displayName": "Sheleg Dev",
   "description": "The integration layer a product needs once it has users: Stripe subscription billing reconciled into your own database, crypto payments that survive over-payment and duplicate webhooks, ad and conversion tracking under Consent Mode v2, Google sign-in with the account-linking guards, the wider Google auth surface, and Core Web Vitals work that moves the score, and Sentry error tracking wired so it does not forward your own credentials to a third party and so a stack trace names the commit that caused it.",
-  "version": "0.9.0",
+  "version": "0.9.2",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

package/plugins/sheleg-dev/skills/error-tracking/SKILL.md

@@ -14,7 +14,7 @@ description: >-
   uptime vendor.
 license: MIT
 metadata:
-  version: 0.9.0
+  version: 0.9.2
 ---
 
 # error-tracking — Sentry wired so it does not leak, and so a stack trace names a commit

package/plugins/sheleg-dev/skills/error-tracking/references/releases.md

@@ -6,6 +6,7 @@ commits, or when a service reports healthy while serving nobody.
 ## Contents
 
 - [The version contract](#the-version-contract)
+  - [The Heroku trap](#the-heroku-trap-the-variable-is-absent-unless-you-turned-it-on)
 - [The four release commands](#the-four-release-commands)
 - [In a deploy script, non-fatally](#in-a-deploy-script-non-fatally)
 - [What set-commits --auto needs](#what-set-commits---auto-needs)
@@ -24,7 +25,7 @@ Pick one source and use it on both sides.
 
 | Platform | The value | Read in the app as |
 |---|---|---|
-| Heroku | slug commit | `os.getenv("HEROKU_SLUG_COMMIT")` |
+| Heroku | slug commit | `os.getenv("HEROKU_SLUG_COMMIT")` — **see the trap below** |
 | Vercel | commit SHA | `os.getenv("VERCEL_GIT_COMMIT_SHA")` |
 | GitHub Actions | `github.sha` | `os.getenv("GITHUB_SHA")` |
 | Anywhere | `git rev-parse HEAD` | inject it at build time |
@@ -41,6 +42,40 @@ VERSION="$(git rev-parse HEAD)"    # the same string, on the other side
 `sentry release propose-version` will invent one, which is convenient and
 exactly the thing that drifts. Prefer an explicit value both sides can derive.
 
+### The Heroku trap: the variable is absent unless you turned it on
+
+`HEROKU_SLUG_COMMIT` is **not a config var**. It is dyno metadata, injected into
+the dyno only when the `runtime-dyno-metadata` labs feature is enabled, and
+absent in silence otherwise. Three consequences, all measured on 2026-08-24:
+
+- `heroku config:get HEROKU_SLUG_COMMIT` prints nothing **even when it is
+  working** — it is never a config var. Read it from inside a dyno instead.
+- With the feature off, `release=os.getenv("HEROKU_SLUG_COMMIT")` is `None`, so
+  the SDK reports no release at all while Sentry holds a release with a deploy
+  that nothing will ever attach to. Nothing errors.
+- Enabling it takes effect on the **next release**, not on a restart.
+
+```bash
+heroku labs -a <app> | grep runtime-dyno-metadata      # is it on?
+heroku labs:enable runtime-dyno-metadata -a <app>
+heroku run -a <app> -- printenv HEROKU_SLUG_COMMIT     # from INSIDE a dyno
+```
+
+Do not depend on it alone. Set the value from the deploy itself, which needs no
+platform feature and cannot drift because one command produces both sides:
+
+```bash
+heroku config:set RELEASE="$(git rev-parse HEAD)" -a "$APP"   # inside the down window
+```
+
+Then read `HEROKU_SLUG_COMMIT or RELEASE`: the platform's answer when it is
+available, because it names the commit actually running, and the deploy's answer
+otherwise.
+
+**And create the Sentry release for the DEPLOYED commit, not for local HEAD.**
+They differ the moment you have commits pushed but not deployed — the same
+mistake one level up, and it produces a release nobody's events belong to.
+
 ## The four release commands
 
 ```bash