@ssheleg/sheleg-dev 0.10.4 → 0.11.0

package/CHANGELOG.md

@@ -4,6 +4,106 @@ 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.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
+target home's `~/.claude/plugins/installed_plugins.json` before writing anything under
+`~/.claude/skills/`. If the sheleg-dev **plugin** is installed there, the install is
+**refused with exit 3**: a plain copy beside a plugin shadows the plugin's skill of the
+same name and serves the frozen version forever, and until this release neither channel
+looked at all. Reproduced live in the family on 2026-08-29: a bare
+`npx @ssheleg/telegram-dev` shipped three shadows while the plugin was enabled.
+
+- `installed_plugins.json` is the signal, because it is the record of what is actually
+  installed. A check keyed on the `plugins/marketplaces/<name>` directory alone — the
+  shape other family members carried — is the fail-open class: a marketplace added from
+  a local `directory` source has no dir there, and plugin names differ from marketplace
+  names. The directory is kept only as a fallback signal.
+- The refusal names its remedy with the **real spec read from the JSON**
+  (`claude plugin marketplace update sheleg-dev`, `claude plugin update <spec>`), plus
+  the family launcher line, and offers `--force` as the explicit override for running
+  two channels deliberately.
+- An absent or corrupt `installed_plugins.json` reads as "no plugin": the check fails
+  open and never crashes an install — the fresh HOME is the common case.
+- New suite `test/installer_test.js` (11 cases, both channels, throwaway HOMEs), wired
+  into `npm test` and CI. **Watched failing first**: run against the pre-refusal
+  installers it went red on 7 of 11 cases, each showing the shadow landing at exit 0.
+- Both success paths now end by saying how the next version arrives — the update line —
+  and `install.sh` gained `--force`/usage parsing (unknown argument exits 2) to carry
+  the same contract as the npm channel.
+- `.claude-plugin/marketplace.json` still said "Six integration skills" while seven
+  ship (the validator counts 7; README and SECURITY say seven). It now says seven and
+  names error tracking — the second hand-written count this repository has caught after
+  the fact, which is why the new suite derives the roster from the tree.
+- `SECURITY.md`'s installer contract moved with the behaviour: the read surface now
+  includes the two read-only looks at the target home, and the I/O-surface grep line
+  count was re-measured (twelve, and it was already twelve before this change — the
+  "eleven" had rotted when a comment naming `rm -rf` arrived).
+
 ## v0.10.4 — the channel that sends the installs, on npm too
 
 - The `skills.sh` badge and the canonical `homepage` reached GitHub in the previous cycle and stopped

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).
 
@@ -118,6 +118,12 @@ a Lighthouse score.
 npx @ssheleg/sheleg-dev
 ```
 
+If the sheleg-dev **plugin** is already installed in that home, the npm installer
+and `install.sh` refuse with exit 3 instead of writing plain copies — a plain
+copy shadows the plugin's skill of the same name and serves the frozen version
+forever. The refusal prints the plugin-channel update commands; `--force`
+overrides it, deliberately.
+
 **Any of 70+ agents:**
 
 ```bash

package/SECURITY.md

@@ -33,7 +33,7 @@ no socket; the greps below prove all three.
 | `plugins/sheleg-dev/hooks/money-gate.js` | 1 | Runs on a tool call, when the plugin is enabled. Requires `path` and its own decision module — nothing else. Reads stdin, writes one JSON line, exits 0 on every path. |
 | `plugins/sheleg-dev/hooks/lib/moneygate.js` | 1 | Pure. Payload and environment in, verdict out. No `require` at all, no filesystem, no clock. |
 | `bin/sheleg-dev.js` — the npm installer | 1 | Runs only when you invoke it. Node built-ins only: `fs`, `path`, `os`. |
-| `install.sh` — the shell installer | 1 | **Not in the tarball** — `files` ships `bin/` and `plugins/`, so this one reaches you only through a clone. Runs when you invoke it. Coreutils only: `cd`, `pwd`, `dirname`, `basename`, `mkdir`, `rm`, `cp`, `echo`. It is the destructive channel: `rm -rf` per skill, then `cp -R`. |
+| `install.sh` — the shell installer | 1 | **Not in the tarball** — `files` ships `bin/` and `plugins/`, so this one reaches you only through a clone. Runs when you invoke it. Shell tools only: `cd`, `pwd`, `dirname`, `basename`, `mkdir`, `rm`, `cp`, `echo`, plus `sed` and `head` to read the plugin registry it refuses to shadow. It is the destructive channel: `rm -rf` per skill, then `cp -R`. |
 | `plugins/sheleg-dev/skills/*/fixtures/*.json` — webhook payloads | 16 | Data. Placeholder ids only; no key, token, signing secret or real customer id. |
 | `plugins/sheleg-dev/skills/*/fixtures/*.mjs` — the assertion packs and their reference implementations | 4 | Runs only when you invoke it. Reads the JSON beside it with `readFileSync` and nothing else: no `child_process`, no `fetch`, no write, no `process.env`. |
 | `plugins/sheleg-dev/skills/*/fixtures/manifest.json` and its `README.md` | 4 | Text. The invariant-to-fixture-to-document map, which `test/validate.py` reads. |
@@ -61,24 +61,32 @@ nothing but the CLI you typed.
 ## What the installers read and write
 
 Both do one thing: copy the seven skill directories out of the package into
-`~/.claude/skills/<name>`.
-
-- **Read:** only files inside the package.
+`~/.claude/skills/<name>` — unless the sheleg-dev **plugin** is already installed
+in that home, in which case both refuse with exit 3 rather than write plain
+copies that would shadow the plugin's skills and serve this frozen version
+forever. `--force` overrides the refusal, deliberately.
+
+- **Read:** files inside the package, plus two read-only looks at the target
+  home to decide the refusal above: `~/.claude/plugins/installed_plugins.json`
+  (the record of installed plugins; a missing or unparsable file reads as "no
+  plugin", so the check fails open and never crashes an install) and whether
+  `~/.claude/plugins/marketplaces/sheleg-dev` exists, kept only as a fallback
+  signal.
 - **Write:** only `~/.claude/skills/` — seven directories, named for the seven skills.
   Nothing else on the filesystem, nothing outside `$HOME`.
 - **Network: none.** Neither file opens a socket or resolves a hostname.
   `bin/sheleg-dev.js` requires `fs`, `path` and `os` and nothing else — no
   `child_process`, no `fetch`, no `http` — so it spawns no process at all;
-  `install.sh` runs only the coreutils named above. The grep below prints the
-  whole surface of both files in eleven lines.
+  `install.sh` runs only the shell tools named above. The grep below prints the
+  whole surface of both files in twelve lines.
 - **No telemetry, no analytics, no phone-home.** Nothing here has anywhere to
   send anything.
 
 **One destructive difference between the two installers.** `bin/sheleg-dev.js`
 skips a skill that is already installed and says so, unless you pass `--force`
-(`bin/sheleg-dev.js:45-46`). `install.sh` does not ask: for each of the seven names
+(`bin/sheleg-dev.js:89-90`). `install.sh` does not ask: for each of the seven names
 it runs `rm -rf` on the destination and re-copies, every time
-(`install.sh:21-22`). If you have hand-edited an installed skill, the shell
+(`install.sh:62-63`). If you have hand-edited an installed skill, the shell
 installer deletes your edits and the node installer does not.
 
 ## Credentials
@@ -193,14 +201,22 @@ node test/moneygate_test.js
 # The command prints its own count.
 node test/fixtures_test.js
 
+# Both installers against throwaway HOMEs: fresh install, rerun, --force, and the
+# plugin-present refusal — exit 3, the remedy naming the real plugin spec, nothing
+# written; a corrupt ~/.claude/plugins/installed_plugins.json fails open. The command
+# prints its own count.
+node test/installer_test.js
+
 # What the assertion packs cannot reach: NO OUTPUT, and grep exits 1 because it
 # matched nothing. `readFileSync` of the fixtures beside them is their whole I/O.
 grep -rnE "child_process|\bfetch\(|require\('(http|https|net|dns|tls)'\)|spawn\(|execFile|writeFileSync|appendFileSync|unlinkSync|process\.env\." \
   plugins/sheleg-dev/skills/*/fixtures/*.mjs
 
-# The entire I/O surface of the only two executable files: eleven lines. Three
-# built-in requires, the copy/mkdir/remove calls, homedir, and install.sh's
-# rm -rf + cp -R. No process, no socket, no network.
+# The entire I/O surface of the only two executable files: twelve lines. Three
+# built-in requires, the copy/mkdir/remove calls, homedir, install.sh's
+# rm -rf + cp -R, and one comment naming rm -rf. No process, no socket, no
+# network — the plugin-registry read that decides the shadow refusal is
+# readFileSync in the node file and sed in the shell one.
 grep -nE "require|child_process|exec|spawn|fetch|socket|rm -rf|cp -R|copyFileSync|mkdirSync|rmSync|homedir" bin/sheleg-dev.js install.sh
 
 # Live-key shapes across the skill payload: one line, and it is a placeholder.

package/bin/sheleg-dev.js

@@ -17,6 +17,44 @@ const os = require('os');
 const ROOT = path.resolve(__dirname, '..');
 const REPO = 'ssheleg/sheleg-dev';
 
+// Exit codes are the contract: 0 installed or skipped, 1 corrupted package,
+// 2 usage error, 3 refused — the plugin channel owns this agent (--force overrides).
+const EXIT_PLUGIN_PRESENT = 3;
+
+/**
+ * The plugin spec (`<name>@<marketplace>`) installed for `name` in this home,
+ * or null.
+ *
+ * `installed_plugins.json` is the record of what is actually installed. The
+ * `plugins/marketplaces/<name>` directory — the check other members of this
+ * family keyed on until 2026-08-29 — under-reports: a marketplace added from a
+ * local `directory` source has no dir there at all, and plugin names differ
+ * from marketplace names, so a check keyed on it stays green while the shadow
+ * lands. Absence and corruption both read as "no plugin": the fresh HOME is
+ * the common case, and an installer that crashes on a parse error refuses the
+ * machines that need it most.
+ */
+function installedPluginSpec(home, name) {
+  try {
+    const raw = fs.readFileSync(
+      path.join(home, '.claude', 'plugins', 'installed_plugins.json'), 'utf8');
+    const parsed = JSON.parse(raw);
+    const plugins =
+      parsed && typeof parsed === 'object' &&
+      parsed.plugins && typeof parsed.plugins === 'object'
+        ? parsed.plugins
+        : parsed;
+    if (!plugins || typeof plugins !== 'object') return null;
+    for (const spec of Object.keys(plugins)) {
+      if (spec === name) return `${name}@${name}`;
+      if (spec.startsWith(name + '@')) return spec;
+    }
+  } catch {
+    // missing or corrupt = no plugin — fail open on absence, never crash
+  }
+  return null;
+}
+
 function usage() {
   console.log(`sheleg-dev installer
 
@@ -25,6 +63,12 @@ Usage:
                                        into ~/.claude (skip existing unless --force)
   npx @ssheleg/sheleg-dev --help
 
+Exit codes:
+  0 installed or skipped   2 usage error
+  1 corrupted package      3 refused: the sheleg-dev PLUGIN is installed in
+                             this home — plain copies would shadow its skills
+                             (pass --force to write them anyway)
+
 Other install paths:
   Claude Code plugin:  /plugin marketplace add ${REPO}
                        /plugin install sheleg-dev@sheleg-dev
@@ -84,6 +128,39 @@ function main(argv) {
   }
 
   const home = os.homedir();
+
+  // One channel per agent. Plain copies under ~/.claude/skills/ beside the
+  // installed sheleg-dev plugin are a second listing of the same skills, and
+  // the stale copies win — the exact shadow this family's canon forbids.
+  // Refuse rather than create them, and refuse LOUDLY: a marketplaces/-dir
+  // check alone is the fail-open class (a directory-sourced marketplace has no
+  // dir there, plugin names differ from marketplace names), and a refusal that
+  // exits 0 reads as success to every script above it. Reproduced live
+  // 2026-08-29: a bare `npx @ssheleg/telegram-dev` shipped three shadows past
+  // exactly that hole while the plugin was enabled.
+  const spec = installedPluginSpec(home, 'sheleg-dev');
+  const marketplace = path.join(home, '.claude', 'plugins', 'marketplaces', 'sheleg-dev');
+  const viaMarketplaceDir = !spec && fs.existsSync(marketplace);
+  if ((spec || viaMarketplaceDir) && !force) {
+    const found = spec
+      ? `installed as the Claude Code plugin ${spec}\n` +
+        '         (declared in ~/.claude/plugins/installed_plugins.json)'
+      : `registered as a Claude Code marketplace\n         (${marketplace})`;
+    console.error(
+      `refused: sheleg-dev is already ${found}.\n` +
+      `         Plain copies in ~/.claude/skills/ would shadow the plugin's\n` +
+      `         ${names.length} skills and serve this frozen version forever. Update the\n` +
+      '         plugin channel instead:\n' +
+      '           claude plugin marketplace update sheleg-dev\n' +
+      `           claude plugin update ${spec || 'sheleg-dev@sheleg-dev'}\n` +
+      '         Family launcher (updates every member, prunes shadow copies):\n' +
+      '           npx --yes sshlg-skills@latest update\n' +
+      '         Pass --force to write the plain copies anyway — a deliberate choice\n' +
+      '         to run two channels, where the stale one wins.'
+    );
+    return EXIT_PLUGIN_PRESENT;
+  }
+
   for (const name of names) {
     installOne(
       `${name} skill`,
@@ -111,6 +188,15 @@ function main(argv) {
     console.log('skills copy. To get it here, register it yourself — README.md, section');
     console.log('"The manual gate", has the settings snippet. Nothing enforces this step.');
   }
+  // The last line says how the next version arrives — "Installed" is not a
+  // complete sentence. Auto-update is off on purpose: this member composes
+  // with its family, and per-marketplace autoUpdate moves each member on its
+  // own clock, into combinations nobody tested together.
+  console.log(
+    '\nUpdates: rerun `npx @ssheleg/sheleg-dev@latest --force`, or refresh the\n' +
+    'whole family with `npx --yes sshlg-skills@latest update` (every channel,\n' +
+    'and it prunes plain copies that would shadow a plugin).'
+  );
   return 0;
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ssheleg/sheleg-dev",
-  "version": "0.10.4",
+  "version": "0.11.0",
   "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"
@@ -43,8 +43,8 @@
     "skill"
   ],
   "scripts": {
-    "test": "python3 test/validate.py && node test/moneygate_test.js && node test/fixtures_test.js",
+    "test": "python3 test/validate.py && node test/moneygate_test.js && node test/fixtures_test.js && node test/installer_test.js",
     "test:negatives": "python3 test/negatives.py",
-    "test:all": "python3 test/validate.py && node test/moneygate_test.js && node test/fixtures_test.js && python3 test/negatives.py"
+    "test:all": "python3 test/validate.py && node test/moneygate_test.js && node test/fixtures_test.js && node test/installer_test.js && python3 test/negatives.py"
   }
 }

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.4",
+  "version": "0.11.0",
   "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
@@ -323,32 +336,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
@@ -45,7 +45,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 +134,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 +147,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 +155,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 +252,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/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**