@ssheleg/sheleg-dev 0.10.5 → 0.11.1

package/CHANGELOG.md

@@ -4,6 +4,112 @@ 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.11.1 — the evals stop being a plan, and the last tails get their receipts
+
+The 2026-08-29 skill audit left four tails (DEV-06 through DEV-08, DEV-10), and the
+eval suite's own RESULTS.md opened with "authored, schema-validated, never executed
+against a model". This release closes all four; that sentence is replaced by two dated
+model runs and the method that produced them.
+
+- **The behavioral evals cover all seven skills and carry dated runs** (DEV-10, board
+  B-103). Three scenarios are authored for the skills that had none — `crypto-payments`
+  (crediting under hostile deliveries), `error-tracking` (scrubbing layers and release
+  parity), `frontend-performance` (vitals moved and proven) — bringing `scenarios.json`
+  to six, green under `evals_validate.py` with the planted-defect self-test still
+  caught. Then the whole suite was executed on 2026-08-31: 14 trigger queries × 3 fresh
+  subagent sessions × 2 models (haiku, sonnet — 84 blind probes), plus all six
+  scenarios' expected-behavior lines scored against fresh sonnet implementation designs.
+  Haiku: train 23/24, validation 15/18. Sonnet: train 23/24, validation 16/18; scenario
+  lines 23/24 (s01's design named no refund-path test). Two findings are recorded
+  rather than tuned away: "Explain what LCP means" (q13, a negative case) pulls
+  `frontend-performance` in 5 of 6 runs across both models, and one sonnet run routed
+  the crypto implementation query to `task-pipeline` — coexistence changes routing,
+  exactly as the eval README warns. Method and its limits: `test/evals/RESULTS.md`.
+- **`ad-tracking`'s last two undated vendor facts were re-verified, and one was stale**
+  (DEV-06, B-104). The Enhanced Conversions step said `Tools → Conversions → …` — the
+  pre-redesign console path; checked 2026-08-31 against
+  `support.google.com/google-ads/answer/13258081`, the live path is **Goals →
+  Conversions → Settings → Enhanced conversions**, and the step now states it with its
+  date. The `_gcl_aw` claim was true but incomplete: the cookie's ~90-day default life
+  and the Safari ITP cap (JS-set cookies live 7 days, 24 hours after a link-decorated
+  navigation — which a gclid landing is) now sit beside the redirect-survival claim,
+  dated. Body ~4726 tokens of the 4750 house working limit.
+- **`google-signin` stops pointing installers at a private repository** (DEV-07,
+  B-102). The third sentence a reader met cited `web/server.py:1657` in the Prowl repo
+  as the live reference implementation — an address no installer can resolve (M-07).
+  The shipped `references/full-guide.md` FastAPI + JS skeleton is the reference
+  implementation, and the sentence now says so.
+- **`google-auth` states the major its own examples require** (DEV-08, B-101). The ADC
+  and JWT examples call `client.fetch()` while `npm install google-auth-library` pinned
+  nothing, so a reader on 9.x copied a method their client does not have. Checked
+  2026-08-31 against the library's CHANGELOG: the fetch-compatible API landed in
+  **10.1.0** (2025-06-12, PR #1939), `client.request()` is the 9.x form and survives in
+  the current 11.x. The install block now carries the floor, the fallback and the date.
+
+## v0.11.0 — a trigger literal gets one home, and four facts get their dates
+
+The 2026-08-29 skill audit found the pack's two Google skills advertising the same
+end-user sign-in triggers, one skill re-teaching another's contract more weakly, and
+three external facts stated without the date they were true on. All of it shipped green
+through a 23-check validator, because none of it was a check yet.
+
+- **`google-auth` and `google-signin` no longer compete for the same prompt** (audit
+  DEV-01, HIGH). Both front-matter descriptions carried `"google login"`, `"GIS"`,
+  `"Sign In with Google"` and «вход через Google» — four literal collisions between the
+  skill that owns end-user sign-in and the skill that owns the server library surface,
+  with which one loads left to the host's guess. The end-user set is stripped from
+  `google-auth`, whose description now speaks the server vocabulary (ADC, service
+  accounts and their keys, Workload Identity Federation, `verifyIdToken`); the
+  cross-deferral sentence stays. A new validator check,
+  `check_trigger_literals_have_one_home`, compares the quoted trigger literals of every
+  skill pair and refuses a collision — watched failing in both directions (a re-planted
+  `"google login"`, and a stale entry in `TRIGGERS_SHARED_BY_DESIGN`, the enumerated
+  exemption that carries the one deliberate share: `webhook signature`, which the
+  umbrella routes to `stripe-billing`). One new negative self-test in CI; the local
+  floor moves 42 → 43. The verdict line moves 23 → 24 checks.
+- **`google-auth` stops re-teaching ID-token verification with a weaker contract**
+  (DEV-02). Its section 3 taught the sign-in verification omitting the `nonce` binding
+  and `email_verified` — the two checks `google-signin`'s checklist adds above the
+  library call, drifting live under a section that duplicated the other skill's core
+  job. Cut to the bare `verifyIdToken` / `verify_oauth2_token` call plus an explicit
+  statement of what the call does NOT check and where the sign-in contract lives. The
+  partial `g_csrf_token` bullet in Security Best Practices is likewise now a pointer.
+- **The Stripe `apiVersion` pins carry their date** (DEV-03). `2026-07-29.dahlia` was
+  pinned undated in a document that itself says the API moves monthly — and it was
+  already one release behind: checked 2026-08-30 against `docs.stripe.com/changelog`,
+  where `2026-08-26.dahlia` is current. Both pin sites now say when they were true and
+  send the reader to the changelog before pinning.
+- **The crypto `sign()` block is labeled as ONE provider's scheme** (DEV-04). The
+  SKILL taught `md5(base64(json) + apiKey)` under a provider-neutral heading two
+  screens after claiming the section holds for four providers — it is Heleket's scheme
+  alone. Checked 2026-08-30: Coinbase Commerce signs HMAC-SHA256
+  (`X-CC-Webhook-Signature`), NOWPayments HMAC-SHA512 (`x-nowpayments-sig`), BTCPay
+  HMAC-SHA256 (`BTCPay-Sig`). The pattern transfers; the algorithm does not, and the
+  intro now says which is which.
+- **`allow_enhanced_conversions` moves to the tag it belongs on** (DEV-05). The setup
+  step put the flag on the GA4 `G-` config, where it enables nothing for Google Ads;
+  where it appears at all it belongs on the `AW-` config command. Checked 2026-08-30:
+  Google's current setup docs (`support.google.com/google-ads/answer/9888145`,
+  `…/13258081`) no longer document the flag — the live mechanism is the account-level
+  toggle plus `gtag('set', 'user_data', …)` — and the step now states both facts.
+- **`ad-tracking`'s UTM Attribution section moved into
+  `references/event-tracking.md`.** The DEV-05 fix pushed the body past the 4750-token
+  house working limit (23 tokens of headroom going in), and the house answer at the
+  limit is a split, not a trim — same seam as v0.10.0's cancellation split.
+  Body ~4753 tokens after the move; `stripe-billing`'s recomputed numbers in
+  `docs/evals/stripe-billing.md` moved with its dated pins (4737 tokens, 383 lines).
+- **The social card now names all five trades** (umbrella deferral, 2026-08-29). The
+  committed `docs/assets/social-preview.png` is compared pixel-for-pixel by the
+  umbrella's site test against the card it generates from its `skills.json` role cell,
+  and the role grows `errors` for the seventh skill. Regenerated with the umbrella's
+  own generator from the exact cell it will adopt — `integrations: money in, tracking,
+  errors, sign-in, speed` — verified by reproducing the previous committed card
+  byte-for-byte from the previous cell first. README and `marketplace.json` carry the
+  same five-trade phrasing. Measured while regenerating: at scale 3 the new eyebrow
+  paints to 1 px of the canvas edge, because the umbrella's `fitScale` measures without
+  the tracking `drawText` adds — nothing is truncated, and the fix (if wanted) belongs
+  in `og-card.js`, not here.
+
 ## v0.10.5 — the installers refuse the shadow they used to write
 
 Both install channels — `npx @ssheleg/sheleg-dev` and `install.sh` — now consult the

package/README.md

@@ -23,7 +23,7 @@ Agent Skills standard directly, scanning `~/.agents/skills` — where `npx skill
 add` puts this pack — at rank 500.
 
 The integration layer a product reaches once it has users: **money in, tracking,
-sign-in, and speed.**
+errors, sign-in, and speed.**
 
 Part of the [ssheleg skill family](https://github.com/ssheleg/sshlg-skills).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ssheleg/sheleg-dev",
-  "version": "0.10.5",
+  "version": "0.11.1",
   "description": "Seven integration skills for the layer a product reaches once it has users: Stripe subscription billing and cancellation retention, crypto payments, ad and conversion tracking under Consent Mode v2, Google sign-in and the wider Google auth surface, error tracking, 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.10.5",
+  "version": "0.11.1",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

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

@@ -157,7 +157,20 @@ Both share consent state, first-party cookies, and the dataLayer pipeline.
 
 Enhanced Conversions improve attribution by matching hashed user data (email, phone) with Google accounts. Setup:
 
-1. Enable in GA4 config: `allow_enhanced_conversions: true`
+1. Where the flag appears at all, it belongs on the **Google Ads config — the
+   `AW-` tag, never the GA4 `G-` tag** (an earlier revision of this skill put it
+   on the `G-` config, where it enables nothing for Ads):
+
+```javascript
+gtag('config', 'AW-XXXXXXXXX', { allow_enhanced_conversions: true });
+```
+
+   Checked 2026-08-30: Google's current setup docs
+   (`support.google.com/google-ads/answer/9888145`, `…/13258081`) no longer
+   document the flag at all — the live mechanism is the account-level toggle
+   (step 3) plus `user_data` (step 2). Keep the flag if your tag already
+   carries it; do not copy it onto the `G-` config.
+
 2. Set user data before conversion events fire:
 
 ```javascript
@@ -167,7 +180,10 @@ gtag('set', 'user_data', {
 });
 ```
 
-3. Enable in Google Ads console: Tools → Conversions → Enhanced conversions → Turn on
+3. Enable in the Google Ads console: **Goals → Conversions → Settings →
+   Enhanced conversions → "Turn on enhanced conversions"** (checked 2026-08-31
+   against `support.google.com/google-ads/answer/13258081`; the old
+   Tools → Conversions path is gone from the redesigned UI)
 
 ### user_id (Cross-Device Tracking)
 
@@ -182,7 +198,11 @@ gtag('config', 'G-XXXXXXXXXX', {
 
 ### gclid Preservation Through External Redirects
 
-The `gclid` from Google Ads auto-tagging is stored in the `_gcl_aw` first-party cookie. This cookie persists across external redirects (e.g. Stripe Checkout → return URL) because it's set on your domain. No additional code needed.
+The `gclid` from Google Ads auto-tagging is stored in the `_gcl_aw` first-party
+cookie (~90-day default life). It survives external redirects (Stripe Checkout →
+return URL) because only expiry ends a cookie on your own domain — no extra code.
+Checked 2026-08-31; the caveat is Safari, where ITP caps JS-set cookies at 7
+days — 24 hours after a link-decorated navigation, which a gclid landing is.
 
 ### Google Ads console setup
 
@@ -323,32 +343,10 @@ Strategies** for `next/script` strategy choice and SPA route changes.
   the parent page's.
 ## UTM Attribution
 
-### Capture Flow
-
-1. `UtmCapture` component reads UTM params from URL on page load → stores in localStorage
-2. On registration (credentials): read UTM from localStorage, send in POST body, save to DB
-3. On registration (OAuth): UTM persists in localStorage through redirect → synced after return via API call
-4. Mixpanel `people.set_once()` stores initial UTM as permanent user properties
-5. Clear localStorage after successful DB sync
-
-### UTM Parameters
-
-| Parameter | Purpose | Example |
-|---|---|---|
-| `utm_source` | Traffic source | `google`, `facebook`, `newsletter` |
-| `utm_medium` | Marketing medium | `cpc`, `social`, `email` |
-| `utm_campaign` | Campaign name | `spring_sale_2025` |
-| `utm_content` | Ad creative variant | `banner_a`, `text_link` |
-| `utm_term` | Paid search keyword | `ai+chatbot` |
-
-### gclid / fbclid / li_fat_id
-
-Google, Meta, and LinkedIn append their own click IDs to URLs:
-- `gclid` — Google Ads click ID (stored in `_gcl_aw` cookie by gtag.js automatically)
-- `fbclid` — Meta click ID (stored in `_fbc` cookie by fbevents.js automatically)
-- `li_fat_id` — LinkedIn click ID (handled by Insight Tag)
-
-These are handled automatically by the respective SDKs. Do not strip them from URLs.
+Read `references/event-tracking.md` → **UTM Attribution** for the capture flow
+(localStorage through OAuth redirects into the DB), the five-parameter table,
+and the platform click IDs (`gclid`/`fbclid`/`li_fat_id`) — which the SDKs
+handle automatically; do not strip them from URLs.
 
 ---
 

package/plugins/sheleg-dev/skills/ad-tracking/references/event-tracking.md

@@ -13,6 +13,8 @@
 - [Ecommerce Events](#ecommerce-events)
 - [SaaS / Subscription Events](#saas--subscription-events)
 - [trackEvent Wrapper Pattern](#trackevent-wrapper-pattern)
+- [User identification](#user-identification)
+- [UTM Attribution](#utm-attribution)
 
 ## Table of Contents
 
@@ -23,6 +25,8 @@
 - [Ecommerce Events](#ecommerce-events)
 - [SaaS / Subscription Events](#saas--subscription-events)
 - [trackEvent Wrapper Pattern](#trackevent-wrapper-pattern)
+- [User identification](#user-identification)
+- [UTM Attribution](#utm-attribution)
 
 ## Event Types
 
@@ -243,3 +247,38 @@ Moved out of `SKILL.md` on 2026-08-16: the body was 5273 tokens against a
 < 5000 budget, and identity is the other half of the question this file already
 owns — an event name says what happened, identity says who it happened to.
 
+
+---
+
+## UTM Attribution
+
+Moved out of `SKILL.md` on 2026-08-30: the body crossed the 4750-token house
+working limit when the Enhanced Conversions fix landed, and attribution
+parameters are schema — the question this file already owns.
+
+### Capture Flow
+
+1. `UtmCapture` component reads UTM params from URL on page load → stores in localStorage
+2. On registration (credentials): read UTM from localStorage, send in POST body, save to DB
+3. On registration (OAuth): UTM persists in localStorage through redirect → synced after return via API call
+4. Mixpanel `people.set_once()` stores initial UTM as permanent user properties
+5. Clear localStorage after successful DB sync
+
+### UTM Parameters
+
+| Parameter | Purpose | Example |
+|---|---|---|
+| `utm_source` | Traffic source | `google`, `facebook`, `newsletter` |
+| `utm_medium` | Marketing medium | `cpc`, `social`, `email` |
+| `utm_campaign` | Campaign name | `spring_sale_2025` |
+| `utm_content` | Ad creative variant | `banner_a`, `text_link` |
+| `utm_term` | Paid search keyword | `ai+chatbot` |
+
+### gclid / fbclid / li_fat_id
+
+Google, Meta, and LinkedIn append their own click IDs to URLs:
+- `gclid` — Google Ads click ID (stored in `_gcl_aw` cookie by gtag.js automatically)
+- `fbclid` — Meta click ID (stored in `_fbc` cookie by fbevents.js automatically)
+- `li_fat_id` — LinkedIn click ID (handled by Insight Tag)
+
+These are handled automatically by the respective SDKs. Do not strip them from URLs.

package/plugins/sheleg-dev/skills/crypto-payments/SKILL.md

@@ -24,7 +24,9 @@ production.
 This skill is provider-neutral. Concrete request/response shapes for one gateway
 live in [`references/heleket-provider.md`](references/heleket-provider.md);
 the invariants below hold for Coinbase Commerce, NOWPayments, BTCPay, Heleket
-and anything else that issues an invoice and calls you back.
+and anything else that issues an invoice and calls you back. One thing is NOT
+provider-neutral and is labeled where it appears: the webhook signature
+*algorithm*, which differs per gateway.
 
 > **Choosing a provider is a business and compliance decision, not a technical
 > one.** Crypto payment processors differ sharply in regulatory standing —
@@ -117,9 +119,20 @@ waterfall below.
 
 The callback is an unauthenticated public endpoint until you prove otherwise.
 
+**The `sign()` below is ONE provider's scheme — Heleket's:
+`md5(base64(json) + apiKey)`.** The *pattern* (constant-time compare, sign the
+raw body, verify before parsing) transfers; the algorithm does not. Checked
+2026-08-30: Coinbase Commerce signs with **HMAC-SHA256** of the raw body
+(`X-CC-Webhook-Signature`), NOWPayments with **HMAC-SHA512** of the
+sorted-key JSON (`x-nowpayments-sig`), BTCPay with **HMAC-SHA256**
+(`BTCPay-Sig`). Take the algorithm from your provider's own reference — for
+Heleket's full shapes see
+[`references/heleket-provider.md`](references/heleket-provider.md).
+
 ```ts
 import { createHash, timingSafeEqual } from 'node:crypto';
 
+// Heleket's scheme. Swap the digest for your provider — see the note above.
 function sign(payload: unknown, apiKey: string): string {
   const json = JSON.stringify(payload);
   return createHash('md5')

package/plugins/sheleg-dev/skills/google-auth/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: google-auth
 description: >-
-  Use when implementing Google authentication in a Node.js or Python web application — Google
-  login, OAuth 2.0 flows, verifying Google ID tokens, service account authentication,
-  Application Default Credentials, Google Identity Services, Workload Identity Federation, API
-  keys, or working with google-auth-library (Node.js) or google-auth (Python). Covers ID token
-  verification and security best practices. Triggers - "google auth", "google login", "google
-  sign in", "OAuth 2.0 Google", "google-auth-library", "Sign In with Google", "Google Identity
-  Services", "GIS", "ADC", "Application Default Credentials", "service account", "Google ID
-  token", "verifyIdToken", "GOOGLE_APPLICATION_CREDENTIALS", "Google SSO", "вход через Google",
-  "авторизация Google", "сервисный аккаунт", "проверить ID-токен", "гугл-логин". For end-user
-  web sign-in only, use the google-signin skill instead.
+  Use when a server authenticates to Google in a Node.js or Python application — OAuth 2.0
+  flows, verifying Google ID tokens server-side, service account authentication and keys,
+  Application Default Credentials, Workload Identity Federation, API keys, or working with
+  google-auth-library (Node.js) or google-auth (Python). Covers server-side ID token
+  verification and security best practices. Triggers - "google auth", "OAuth 2.0 Google",
+  "google-auth-library", "ADC", "Application Default Credentials", "service account",
+  "Workload Identity Federation", "Google ID token", "verifyIdToken",
+  "GOOGLE_APPLICATION_CREDENTIALS", "Google SSO", "авторизация Google", "сервисный аккаунт",
+  "ключи сервисного аккаунта", "проверить ID-токен". For end-user web sign-in only, use the
+  google-signin skill instead.
 ---
 
 # Google Authentication for Node.js & Python
@@ -27,6 +27,11 @@ npm install google-auth-library
 npm install googleapis
 ```
 
+The `client.fetch()` calls below require google-auth-library **≥ 10.1.0** (the
+fetch-compatible API landed in 10.1.0, 2025-06-12); on 9.x use
+`client.request()` with the same arguments. Checked 2026-08-31: latest is 11.x
+and keeps both methods.
+
 ### Python
 
 - `google-auth` — core auth library (google.oauth2, google.auth, credentials, transport)
@@ -45,7 +50,7 @@ pip install google-api-python-client
 |--------|----------|-------------------|---------------------------|
 | **ADC** | Same identity for all users, server-to-server | `GoogleAuth` | `google.auth.default()` |
 | **OAuth 2.0** | Actions on behalf of end users | `OAuth2Client` | `google_auth_oauthlib.flow.Flow` |
-| **Sign In with Google (GIS)** | User sign-in/sign-up on websites | GIS JS SDK + `verifyIdToken()` | GIS JS SDK + `id_token.verify_oauth2_token()` |
+| **Sign In with Google (GIS)** | User sign-in/sign-up on websites — the google-signin skill's ground | GIS JS SDK + `verifyIdToken()` | GIS JS SDK + `id_token.verify_oauth2_token()` |
 | **JWT / Service Account** | Server-to-server, single identity | `JWT` | `service_account.Credentials` |
 | **API Key** | Public data, no user context | `OAuth2Client({ apiKey })` | passed to `googleapiclient.discovery.build(developerKey=)` |
 | **Compute** | On GCP with attached service account | `Compute` | `google.auth.compute_engine.Credentials` |
@@ -134,7 +139,7 @@ credentials = flow.credentials
 
 For the complete OAuth 2.0 flow (parameters, token exchange, refresh, revocation, incremental auth), see [references/oauth2-web-server.md](references/oauth2-web-server.md).
 
-### 3. Sign In with Google — ID Token Verification
+### 3. Verifying a Google ID Token — the library call
 
 **Node.js**
 
@@ -147,10 +152,6 @@ const ticket = await client.verifyIdToken({
   audience: WEB_CLIENT_ID,
 });
 const payload = ticket.getPayload();
-const userId = payload['sub'];
-const email = payload['email'];
-const name = payload['name'];
-const picture = payload['picture'];
 ```
 
 **Python**
@@ -159,22 +160,14 @@ const picture = payload['picture'];
 from google.oauth2 import id_token
 from google.auth.transport import requests
 
-request = requests.Request()
-
-payload = id_token.verify_oauth2_token(
-    token,
-    request,
-    WEB_CLIENT_ID
-)
-user_id = payload['sub']
-email = payload['email']
-name = payload.get('name', '')
-picture = payload.get('picture')
+payload = id_token.verify_oauth2_token(token, requests.Request(), WEB_CLIENT_ID)
 ```
 
-Verification checks: JWT signature, `aud`, `exp`, `iss` (accounts.google.com).
-
-For GIS integration, CSRF protection, and hosted domain validation, see [references/sign-in-with-google.md](references/sign-in-with-google.md).
+The call checks signature, `aud`, `exp` and `iss` — **and nothing else**. That is
+the library contract, not the web sign-in contract: for the sign-in security
+checklist (`nonce` binding, `email_verified`, login-CSRF defense, account
+linking) use the **google-signin** skill — it is the one home for that contract,
+and this skill deliberately does not restate it.
 
 ### 4. JWT / Service Account
 
@@ -264,7 +257,7 @@ if credentials.expired and credentials.refresh_token:
 - Store `refresh_token` securely; it's only returned on first authorization
 - Validate external credential configurations before use (check `token_url`, `service_account_impersonation_url` point to googleapis.com)
 - Prefer Workload Identity Federation over service account keys for non-GCP environments
-- For GIS: verify `g_csrf_token` with double-submit-cookie pattern
+- For end-user web sign-in, apply the google-signin skill's full checklist — a partial restatement here is how the two skills drifted apart once already
 - **Python-specific**: reuse a single `google.auth.transport.requests.Request()` instance across verifications for connection pooling; do not create a new one per call in hot paths
 
 ## Reference Files

package/plugins/sheleg-dev/skills/google-signin/SKILL.md

@@ -17,9 +17,8 @@ description: >-
 Condensed operating instructions. Full narrative guide with diagrams, token
 anatomy, troubleshooting table, and a copy-paste FastAPI + JS skeleton:
 [references/full-guide.md](references/full-guide.md) — read it when
-implementing from scratch. A live reference implementation exists in the
-Prowl repo (`0xDEV`): `web/auth.py`, `web/server.py:1657`
-(`/api/auth/google`), `web/static/js/app.js:16-110`.
+implementing from scratch; its FastAPI + JS skeleton is the reference
+implementation this skill ships.
 
 ## Pick the right flow first
 

package/plugins/sheleg-dev/skills/stripe-billing/SKILL.md

@@ -90,6 +90,8 @@ export function getStripe(): Stripe {
   if (!client) {
     const key = process.env.STRIPE_SECRET_KEY;
     if (!key) throw new Error("STRIPE_SECRET_KEY is not set");
+    // Pin checked 2026-08-30 — 2026-08-26.dahlia was already newer. Confirm
+    // against Stripe's changelog before pinning; this line goes stale monthly.
     client = new Stripe(key, { apiVersion: "2026-07-29.dahlia", maxNetworkRetries: 2 });
   }
   return client;
@@ -171,7 +173,7 @@ await stripe.checkout.sessions.create({
 
 `{CHECKOUT_SESSION_ID}` is substituted by Stripe, not rendered by you. On
 `2026-03-25.dahlia`+ an `integration_identifier` label lets you compare flows in
-the Dashboard.
+the Dashboard (floor checked 2026-08-30 against Stripe's changelog).
 
 Three decisions belong to `stripe-best-practices`: **usage-based billing**
 (Metronome for anything new; Billing Meters is a low-level primitive), **tax**