@ssheleg/sheleg-dev 0.11.7 → 0.12.0

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

@@ -89,13 +89,36 @@ covered by default instead of leaking until someone updates a list.
 ```python
 import re
 
-_URL_CREDENTIALS = re.compile(r"(?P<scheme>[a-zA-Z][a-zA-Z0-9+.-]*://)(?P<user>[^:/@\s]+):(?P<pw>[^@/\s]+)@")
 _REDACTED = "<redacted>"
 
+# userinfo: scheme://[user][:password]@host — the username is OPTIONAL, so
+# `redis://:AUDIT_FAKE_PASSWORD@host` (empty user) is caught, not skipped; the
+# password may be percent-encoded. Keep the (possibly empty) user and the host,
+# redact only the password.
+_URL_USERINFO = re.compile(
+    r"(?P<scheme>[a-zA-Z][a-zA-Z0-9+.-]*://)(?P<user>[^:/?#@\s]*):(?P<pw>[^@/?#\s]+)@")
+
+# a secret in the PATH: a Telegram bot token is `/bot<id>:<secret>/…`, and the
+# secret is in the path, not the userinfo — the userinfo regex never sees it.
+_URL_PATH_BOT_TOKEN = re.compile(r"(?P<pre>/bot)(?P<tok>\d+:[A-Za-z0-9_-]+)")
+
+# a credential in the QUERY STRING: ?access_token=… &token=… &api_key=… — the
+# value, never the key, is redacted so the shape stays readable.
+_URL_QUERY_SECRET = re.compile(
+    r"(?P<pre>[?&](?:access_token|auth_token|api_key|apikey|auth|token|key|"
+    r"password|passwd|secret|session|sig|signature)=)(?P<val>[^&#\s]+)",
+    re.IGNORECASE)
+
 def scrub_text(value):
     if not isinstance(value, str):
         return value
-    return _URL_CREDENTIALS.sub(rf"\g<scheme>\g<user>:{_REDACTED}@", value)
+    # Every secret is replaced BEFORE the string can be logged: userinfo first,
+    # then the path token, then the query value. A safe URL (a lone user, a
+    # non-secret query key) matches none of them and keeps its useful shape.
+    value = _URL_USERINFO.sub(rf"\g<scheme>\g<user>:{_REDACTED}@", value)
+    value = _URL_PATH_BOT_TOKEN.sub(rf"\g<pre>{_REDACTED}", value)
+    value = _URL_QUERY_SECRET.sub(rf"\g<pre>{_REDACTED}", value)
+    return value
 
 def scrub_values(event, _hint=None):
     def walk(node):
@@ -116,6 +139,11 @@ Three properties that matter:
 
 - **Keep the user and host.** A fully redacted URL is useless for debugging.
   Redact the password only.
+- **Three places a credential hides — userinfo, path, query.** `user:pw@` is
+  the obvious one, but a Telegram token sits in the PATH (`/bot<id>:<secret>/`)
+  and an access token sits in the QUERY (`?access_token=…`); the scrubber
+  covers all three, and the username in userinfo may be EMPTY
+  (`redis://:pw@host`) or the redis leak walks straight through.
 - **Scheme-agnostic.** `amqps://`, `redis://`, `mongodb+srv://` leak the same way.
 - **Never return `None`.** In `before_send` that discards the event. A bug in
   the scrubber then reads as "Sentry is quiet", which is indistinguishable from
@@ -153,6 +181,41 @@ default, the test tells you to stop carrying it yourself.
 same shape. A test that asserts a password is scrubbed, while carrying that
 password in the repository, has moved the leak rather than closed it.
 
+## Every OUTBOUND CHANNEL has its own hook — or it is not covered
+
+`before_send` sees ERROR EVENTS and nothing else. Sentry ships several outbound
+channels, each with its own hook, and a scrubber wired into one of them says
+nothing about the rest — the table below is the claim, per channel, and a
+channel without a hook is **UNSUPPORTED: stated, never promised away as a
+universal scrub**:
+
+| Channel | Hook | Status |
+|---|---|---|
+| error events | `before_send` (wired above) | covered |
+| transactions | `before_send_transaction` — `before_send` does NOT see these | covered once wired |
+| breadcrumbs | `before_breadcrumb` | covered once wired |
+| logs (Sentry Logs) | `before_send_log` where the SDK version ships it | covered on that SDK; on an older SDK the channel is UNKNOWN — gate or disable it |
+| attachments | **no scrub hook exists** — attachment bytes go out untouched | UNSUPPORTED: do not attach files that may carry secrets |
+
+```python
+import sentry_sdk
+
+sentry_sdk.init(
+    dsn=DSN,
+    before_send=scrub_values,
+    before_send_transaction=scrub_values,
+    before_breadcrumb=lambda crumb, _hint: scrub_values(crumb),
+    # before_send_log=scrub_values,   # only where this SDK version has it;
+    #                                 # absent => the logs channel is UNKNOWN
+)
+```
+
+**The fixture suite runs the SAME secret fixtures through EVERY channel the
+table claims** — an event, a transaction, a breadcrumb — and a channel the
+hooks cannot reach is reported UNKNOWN/UNSUPPORTED, never green. A green that
+covers one channel while four others ship raw is the universal-scrub promise
+this section exists to refuse.
+
 ## Re-measuring after an SDK upgrade
 
 Both facts on this page are version-dependent. After any `sentry-sdk` bump:

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

@@ -8,7 +8,6 @@ refused and you need to tell a policy problem from an auth problem.
 - [Install](#install)
 - [Authenticate](#authenticate)
 - [Token taxonomy — which kind can do what](#token-taxonomy--which-kind-can-do-what)
-- [Find what already exists](#find-what-already-exists)
 - [Create a project](#create-a-project)
 - [Get the DSN and wire it in](#get-the-dsn-and-wire-it-in)
 - [Declare the MCP server](#declare-the-mcp-server)

package/plugins/sheleg-dev/skills/frontend-performance/SKILL.md

@@ -28,24 +28,39 @@ Optimize frontend applications for maximum Lighthouse scores and real-user perfo
 
 ## Core Web Vitals, and the diagnostics beside them
 
-**Three metrics are Core Web Vitals. The other three are not**, and the difference
-is not pedantry: only the first three are what Google reports and ranks on, and
-only they are field-measurable. TBT is a *lab* metric — web.dev says it "is not
-part of the Core Web Vitals set because they are not field-measurable" — and it
-stands in for INP when you have no field data. Telling a client their Speed Index
-is a failing Core Web Vital is telling them about a thing Google does not measure.
-
-| Core Web Vital | Good | Needs Work | Poor |
-|--------|------|------------|------|
-| LCP (Largest Contentful Paint) | < 2.5s | 2.5-4.0s | > 4.0s |
-| INP (Interaction to Next Paint) | < 200ms | 200-500ms | > 500ms |
-| CLS (Cumulative Layout Shift) | < 0.1 | 0.1-0.25 | > 0.25 |
-
-| Lab diagnostic | Good | Needs Work | Poor | Stands in for |
-|--------|------|------------|------|---|
-| FCP (First Contentful Paint) | < 1.8s | 1.8-3.0s | > 3.0s | early LCP signal |
-| TBT (Total Blocking Time) | < 200ms | 200-600ms | > 600ms | INP, in the lab |
-| SI (Speed Index) | < 3.4s | 3.4-5.8s | > 5.8s | perceived load |
+**Two INDEPENDENT axes, and conflating them is the common error.** Axis one:
+**is it a Core Web Vital** — what Google reports and ranks on (LCP, INP, CLS)
+— or not. Axis two: **where can you measure it** — in the FIELD (real users,
+CrUX) or only in the LAB (a synthetic run). These do not line up: a metric can
+be not-CWV and still field-measurable. **FCP is the case that breaks the
+one-axis story — it is NOT a Core Web Vital, yet it IS field-measurable**
+(CrUX reports FCP; web.dev lists both lab and field tools for it). The earlier
+claim that "only the three CWV are field-measurable" was wrong.
+
+| Metric | Core Web Vital? | Field-measurable? | Good | Needs Work | Poor |
+|---|---|---|---|---|---|
+| LCP | yes | yes (CrUX) | < 2.5s | 2.5-4.0s | > 4.0s |
+| INP | yes | yes (CrUX) | < 200ms | 200-500ms | > 500ms |
+| CLS | yes | yes (CrUX) | < 0.1 | 0.1-0.25 | > 0.25 |
+| FCP | no | **yes (CrUX)** | < 1.8s | 1.8-3.0s | > 3.0s |
+| TBT | no | no (lab only) | < 200ms | 200-600ms | > 600ms |
+| SI | no | no (lab only) | < 3.4s | 3.4-5.8s | > 5.8s |
+
+**A field claim carries its provenance, always: p75** (the 75th-percentile
+value Google classifies on, never a mean), the **device/cohort** (phone vs
+desktop, and which population), the **period** (CrUX is a 28-day trailing
+window), and the **sample size** (a thin origin has no field data — that is
+`unknown`, not `good`). A number without these four is a lab number wearing a
+field label.
+
+**TBT is a diagnostic CORRELATE of INP, never a substitute for its evidence.**
+A good lab TBT is a hint that INP may be fine; it does NOT PROVE INP, because
+INP is measured on real interactions the lab did not perform. So a page with
+CrUX FCP data and a Lighthouse TBT but **no field INP** reports **FCP =
+field-supported, INP = unknown** — never "INP passed by TBT". Telling a client
+their Speed Index is a failing Core Web Vital is telling them about a thing
+Google does not rank; telling them INP passed because TBT did is telling them
+about a measurement nobody took.
 
 Thresholds and the classification verified against `web.dev/articles/vitals`,
 2026-08-16.
@@ -61,15 +76,28 @@ Thresholds and the classification verified against `web.dev/articles/vitals`,
 - **Use `font-display: swap`** -- Prevents invisible text during load (FOIT).
 - **Remove unused preconnects** -- If fonts are self-hosted, `preconnect` to font CDNs is dead weight.
 
+**Before any of these changes: MEASURE, don't prescribe.** The items below are
+optimization HEURISTICS, not blanket rules — each is conditional on evidence,
+and applied blind it can lose function for a score. Before changing anything,
+check three things: the **performance trace + the scenarios** (what a low-end
+device on a slow network actually waits for), the **browser-support contract**
+(who must the page still work for), and the **accessibility owner** (structure
+is theirs, not the score's). A change ships only with acceptance covering:
+low-end/slow-network scenarios, keyboard + heading structure intact, the
+supported-browser matrix still served, NO new unapproved CSP origin, and
+several comparable before/after measurements showing the win **with no
+functional loss**.
+
 ### JavaScript (TBT, FCP, LCP)
 
-- **Code split aggressively** -- Lazy-load below-the-fold sections. Only hero + nav in initial bundle.
+- **Code split by the MEASURED waterfall** -- lazy-load what the trace shows the first paint does not need; "only hero + nav in the initial bundle" is a starting hypothesis, not a rule — a section the scenario needs above the fold stays, whatever the score says.
 - **Defer third-party scripts** -- GA, analytics, chat widgets load after interactive (`afterInteractive` or `defer`).
-- **Target modern browsers** -- Set `browserslist` to avoid shipping polyfills for `Array.prototype.at`, `Object.fromEntries`, etc.:
+- **Target the browsers your USERS run** -- `browserslist` follows a stated user-support policy (your analytics, your contract), not a default "last 2". The `last 2` line below is an EXAMPLE; shipping it without checking who it drops is how a working browser stops being served for a polyfill saving:
   ```
+  # example only — replace with your measured support matrix
   last 2 Chrome versions, last 2 Firefox versions, last 2 Safari versions, last 2 Edge versions
   ```
-- **Tree-shake imports** -- Named imports only. No `import * as`.
+- **Tree-shake imports** -- prefer named imports where the bundle analyzer shows `import * as` pulling dead weight; it is a tree-shaking aid, not a ban — a namespace import that costs nothing measured is not a defect.
 - **Analyze bundles** -- Use `@next/bundle-analyzer`, `source-map-explorer`, or `vite-plugin-visualizer`.
 
 ### CSS & Animations (CLS)
@@ -98,7 +126,7 @@ Thresholds and the classification verified against `web.dev/articles/vitals`,
 
 ### Content Security Policy (Best Practices)
 
-- **Whitelist all loaded origins** -- CSP blocks = console errors = lower Best Practices score.
+- **Approve origins by FUNCTIONAL NECESSITY, not for the score** -- an origin enters the CSP because the page genuinely needs it, and each is reviewed; whitelisting everything the page happens to load to silence console errors trades the whole point of a CSP for a Best-Practices number. No new origin ships unapproved.
 - **Audit after every third-party change** -- Adding analytics, fonts, or CDN scripts requires CSP updates.
 - **Tighten after migration** -- If you move from external fonts to self-hosted, remove the old CSP entries.
 - **Common CSP origins**:
@@ -111,7 +139,7 @@ Thresholds and the classification verified against `web.dev/articles/vitals`,
 These directly affect the Lighthouse Accessibility score:
 
 - **Contrast ratio** -- WCAG AA requires 4.5:1 for normal text, 3:1 for large text. Avoid opacity modifiers on text colors (e.g., `text-primary/80` in Tailwind reduces contrast). Use full-opacity color tokens.
-- **Heading hierarchy** -- Sequential: `h1` -> `h2` -> `h3`. Never skip levels. Use non-heading elements (`<p>`) for visual-only "headings" (e.g., footer column titles).
+- **Heading hierarchy follows STRUCTURE, decided with the accessibility owner** -- sequential `h1`->`h2`->`h3`, no skipped levels. Demote a heading to `<p>` only when it is genuinely NOT a section title; downgrading a real footer-section heading to `<p>` to quiet a Lighthouse audit removes structure a screen-reader user navigates by. Accessibility is the owner here, not the score.
 - **Alt text** -- Decorative images next to identical text get `alt=""`. Informative images get descriptive alt. Never duplicate adjacent text.
 - **Tap targets** -- Minimum 48x48px on mobile. Applies to buttons, links, form inputs.
 

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

@@ -86,7 +86,7 @@ request = google.auth.transport.requests.Request()
 credentials.refresh(request)
 ```
 
-ADC search order: attached service account → `gcloud auth application-default login` file → `GOOGLE_APPLICATION_CREDENTIALS` env var.
+ADC search order (env var FIRST — this line was reversed): `GOOGLE_APPLICATION_CREDENTIALS` env var → `gcloud auth application-default login` file → attached service account (metadata). Print the RESOLVED principal and source (no secret) before configuring — with more than one present, only the resolved source names which you are actually using.
 
 For detailed ADC setup and service account usage, see [references/adc-and-service-accounts.md](references/adc-and-service-accounts.md).
 
@@ -259,6 +259,18 @@ if credentials.expired and credentials.refresh_token:
 - 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 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
+- **Fail closed on a missing production secret.** The session signing secret,
+  and any credential-store key, is REQUIRED in production with NO dev fallback —
+  a hardcoded default signs every deployment's cookies with a key that lives in
+  the repo. Missing → refuse to boot, never a warning-and-continue (DV-07).
+- **Logs are sanitized; a credential never reaches one.** No token, no
+  `client_secret`, no `refresh_token`, no session value in a log line, a stack
+  trace, or an error message — a token in a log is a token anyone with log
+  access holds. Redact by allow-list, not by trying to strip the secret out.
+- **HTTPS is mandatory and the credential store can fail.** The auth cookie is
+  `Secure` and the callback refuses plain HTTP (an OAuth code over `http://` is a
+  code on the wire); and a credential-store read/write that FAILS is an auth
+  failure — re-prompt or 503, never proceed as if the credentials loaded.
 - **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-auth/references/adc-and-service-accounts.md

@@ -3,19 +3,6 @@
 
 ## Contents
 
-- [Table of Contents](#table-of-contents)
-- [ADC Overview](#adc-overview)
-- [ADC Search Order](#adc-search-order)
-- [Setting Up ADC](#setting-up-adc)
-- [Using ADC in Code](#using-adc-in-code)
-- [Service Account Keys (JWT)](#service-account-keys-jwt)
-- [Compute Credentials](#compute-credentials)
-- [Impersonated Credentials](#impersonated-credentials)
-- [Downscoped Client](#downscoped-client)
-- [ID Tokens](#id-tokens)
-- [Environment Variables](#environment-variables)
-
-## Table of Contents
 - [ADC Overview](#adc-overview)
 - [ADC Search Order](#adc-search-order)
 - [Setting Up ADC](#setting-up-adc)
@@ -33,9 +20,19 @@ Application Default Credentials (ADC) automatically finds credentials based on t
 
 ## ADC Search Order
 
-1. **Attached service account** — via GCP metadata server (Compute Engine, Cloud Run, GKE, etc.)
-2. **`gcloud auth application-default login`** — local credential file
-3. **`GOOGLE_APPLICATION_CREDENTIALS`** — env var pointing to a credential JSON file
+Google resolves these **in this order — env var FIRST**, and the earlier match
+wins. The old text here had it reversed (attached account first), which points
+you at the wrong lever when the resolved identity is not what you expect:
+
+1. **`GOOGLE_APPLICATION_CREDENTIALS`** — env var pointing to a credential JSON file
+2. **`gcloud auth application-default login`** — local credential file (well-known path)
+3. **Attached service account** — via GCP metadata server (Compute Engine, Cloud Run, GKE, etc.)
+
+**Before configuring, print the ACTUALLY-resolved principal and source** — which
+of the three won, and the account email — **without the secret**. On a VM with a
+metadata identity AND an env var set, only the resolved source tells you which
+one your code is actually using; a config change made against the wrong source
+is a change that does nothing.
 
 Credential file locations from `gcloud auth application-default login`:
 - **macOS/Linux**: `$HOME/.config/gcloud/application_default_credentials.json`