@ccoalm/ccl-skills 0.8.0 → 0.9.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/web-react-dev/references/web-quality-release.md

@@ -20,6 +20,20 @@ For API-backed pages, centralize these mechanics in the client or the narrowest
 | User error mapping | Show readable state near the affected region; keep raw transport details for logs/devtools, not UI copy | Component test asserts visible message and retry/next action |
 | Long work | Expose task id/status, polling/retry/backoff, stale result protection, refresh recovery, and final status | API-client test plus browser smoke for one pending-to-final flow |
 
+## Streaming Client Mechanics (SSE / WebSocket Chat, Live Logs, Progressive Results)
+
+For AI-chat, live-log, or progressive-result surfaces consuming SSE/WebSocket streams, centralize these behaviors in the stream client wrapper (visible streaming *states* are enumerated in `references/complex-workspace-patterns.md`; provider-call retry/continuation semantics are owned by `llm-inference-integration/references/llm-client-gateway.md`):
+
+- **Retry asymmetry**: automatic connection retry (bounded exponential backoff plus a connect timeout) is safe only when establishing the connection cannot re-trigger the operation — i.e. when subscribing/reconnecting to an existing server-issued operation or stream id, or when the send carries an idempotency key with an acknowledged dispatch boundary. Once a stream has consumed ANY event whose handler has a non-idempotent effect — a start/processing event that fired analytics or stateful handlers counts, not only visible deltas or dispatched tool events — automatic resubscription additionally requires a resume position — a resume cursor / SSE `Last-Event-ID` whose delivery semantics are verified strictly-after (an inclusive cursor or ambiguous-disconnect boundary replay re-delivers the boundary event), or paired with stable per-event ids plus client-side deduplication and idempotent side-effect handling — because a server that replays history or delivers at-least-once around the disconnect hands the new attempt events the stale-attempt guard reads as current, double-applying text, analytics, or tool side effects; without a resume mechanism, terminate for explicit user retry instead, and cover the overlapping-replay-after-disconnect case with a regression test. Per-tab attempt tokens, latches, and dedup state do not span browsing contexts: when two tabs can subscribe to the same operation, side-effectful handlers (tool dispatch, analytics, mutations) need server-side idempotency keyed by operation/event id as the primary control; a client-side single-executor election is an acceptable supplement ONLY with an atomic exclusive mechanism — the Web Locks API, or a lease with expiry and a fencing token the server validates — because two tabs reading ordinary shared state can both observe "no executor" and both claim it; without one of these, both tabs will independently execute the same replayed events. A POST-style send that starts billed generation or dispatches work server-side before the first delta arrives must NOT be auto-resubmitted on connect timeout or lost response — and a lost acknowledgement is an UNKNOWN dispatch, not a failure: the server may have accepted the operation, so the user-driven retry must reuse the original idempotency key or first reconcile the operation's server-side status before a new send is allowed, or the "safe" manual retry double-charges and repeats tool side effects; and never blind-retry a stream that already emitted visible deltas or dispatched tool calls — a replay duplicates them (the partial-stream discipline on the provider side owns when continuation is safe; ambiguous provider-call retry policy routes to `llm-inference-integration`). When no eligible resume/deduplication mechanism exists — or its retry budget is exhausted — mid-stream failure becomes a terminal error state with an explicit user-driven retry/regenerate, never an automatic reconnect-and-replay.
+- **Guaranteed terminal state**: when the current attempt's transport closes — mid-stream error, abnormal close, or a NORMAL close — without an already-latched recognized terminal event, and the close is not eligible for automatic resubscription (per the retry-asymmetry rule above) or the reconnect budget is exhausted, synthesize a local terminal event and push it through the same message pipeline, so every streamed message provably reaches done/error/canceled (cover the clean-close-after-unknown-status case in a regression: a newer server emitting an unrecognized terminal status then closing normally must not leave the operation pending forever). While an eligible resubscription is still in budget, supersede the closed attempt first, suppress its terminal callback, and keep the operation visibly pending until the final transport attempt resolves — latching failure on a transient disconnect fires terminal side effects that a successful reconnect then cannot cleanly undo. A spinner that can never resolve on mid-stream drop is the recurring production bug this prevents. Terminal state is a per-attempt latch: the first end/error/canceled transition for an attempt wins, closes/aborts that attempt's transport, and every later callback for that attempt token — later terminal, close, and error callbacks AND ordinary data/tool events from a late open or buffered delivery on the same transport — is rejected; one failing connection can fire error then abnormal-close, or deliver a buffered delta after the UI went terminal, and without the full-coverage latch those double-fire state transitions, analytics, or tool-result handling.
+- **Stale-stream guard covers synthesized events too**: tag each connection attempt with a monotonic token; every consumer — incoming stream events AND the locally synthesized terminal/close/error callbacks above — checks the token and drops anything from a superseded attempt, and abort the previous `AbortController` before opening a successor. Aborting the predecessor fires its own close/error handler, so an unguarded synthesized terminal event from the dead attempt overwrites the successor's UI state; an intentional abort of a superseded attempt emits nothing, and user cancellation of the *current* attempt is modeled as `cancel-requested` until the transport confirms teardown — if a buffered server `end` arrives first, resolve the operation as completed (the work may already be done and billed) and surface that instead of a `canceled` state whose retry would repeat the charge; only an unconfirmed teardown synthesizes `canceled` (branch on the abort reason, not just on "closed abnormally").
+- **Reconnect policy is declared data, not scattered constants**: `{enabled, maxRetries, initialDelayMs, maxDelayMs, connectTimeoutMs, idleTimeoutMs}` on the transport wrapper; connect-timeout fires its own event so the UI distinguishes "still connecting" from "failed", and the idle/heartbeat timeout catches the proxy-buffered stall where the connection opened successfully but no event, close, or error ever arrives — without it the terminal-state guarantee (which triggers on closure) never fires and the UI stays pending forever.
+- **Transport behind one interface, with declared degradation**: WS/SSE/polling behind a single event-surface interface so SSE-hostile networks (buffering proxies, restrictive gateways) degrade to polling without changing consumers — degradation is conditional on the server actually exposing the fallback protocol; when no polling/read endpoint exists (a WebSocket-only backend), a blocked transport resolves to the explicit unsupported/network-error terminal state rather than emitting semantically incompatible requests. Fetch-based SSE libraries need deliberate settings: background-tab behavior, abort wiring, and suppressing the library's built-in auto-retry when the wrapper owns retry policy.
+- **Status enum → UI state via one lookup table**: map the wire message-status enum (e.g. start/processing/executed/end/error/canceled) to loading/disabled/retry UI in one table — not scattered conditionals per component. An unknown status maps to an explicit unsupported/error presentation with telemetry, keeping send/retry controls conservatively disabled until a recognized terminal event resolves the operation; treating unknown as "not loading" re-enables actions while the server may still be working and double-fires them.
+- **Reload recovery is server-replayed history** through the same message pipeline with an `isHistory` flag that suppresses side effects (no tool re-execution, no analytics double-fire); add client-side partial-message persistence only when the product genuinely needs offline drafts.
+- **Client-executed tool/action failures report back into the agent loop** as a terminal tool result; a console-only error leaves the backend agent waiting forever — that is a hang, not an error state.
+- **Trace propagation applies mid-stream**: read the trace id from the stream response headers or first event and attach it to the message state, so a broken stream is supportable like any failed request.
+
 ## Test Layers
 
 - Unit tests: pure mapping, validation, reducers, derived data, error translation, and utility behavior.
@@ -33,12 +47,30 @@ For API-backed pages, centralize these mechanics in the client or the narrowest
 - Check bundle growth, code splitting, image optimization, caching headers, long tasks, unnecessary rerenders, list rendering, hydration/runtime errors, and Core Web Vitals risk.
 - Build-time environment variables must be explicit; do not hide production behavior behind local-only defaults.
 - Release checks should include build, smoke route, error monitoring, analytics event sanity, rollback or feature flag path, and cache invalidation/CDN implications when relevant.
+- **Request waterfalls are a top-priority review category** (Vercel's impact-ranked React guidance grades sequential-to-parallel fixes as the 2-10× class): start independent async work before awaiting and join with `Promise.all`, defer an `await` into the branch that actually consumes it, avoid chained sequential awaits in route handlers / server components / effects, and place Suspense boundaries so the shell streams while slow regions resolve.
+- **Bundle-size discipline**: import concrete module paths instead of barrel files (a barrel import can pull the whole package into the graph), keep import paths statically analyzable for tree-shaking, dynamic-import heavy or below-the-fold components, and preload on user intent (hover/focus) rather than eagerly.
+
+## SEO And Discoverability (Public-Facing Pages)
+
+Applies to marketing, content, docs, landing, and any page meant to be found via search or unfurled in social/chat previews. Auth-gated consoles and internal workbenches are exempt, but their public shells (landing, login, share/preview pages) are not. Grounded in Google Search Central, `schema.org`, and `ogp.me` (verified 2026-08); when in doubt those docs are authoritative, not memory.
+
+- **Indexable pages need a unique, descriptive `<title>` and meta description per page** — no boilerplate duplicated across routes, no keyword stuffing. For SPAs this means route-level title/description management (framework metadata API or a head manager), not one static `index.html` title.
+- **Variants whose primary content is duplicate or substantially equivalent declare `rel=canonical`** to pick the representative URL and consolidate signals; the canonical page carries a self-referential one. A parameterized URL is NOT automatically a duplicate — a filter/category landing page with distinct indexable content keeps its own canonical (canonicalizing it away tells the crawler it is non-representative and can drop it from results); decide indexability per parameterized route family, not by the presence of query parameters.
+- **Keep-out uses `noindex` (meta tag or `X-Robots-Tag`), and the page must NOT be blocked by robots.txt** — a robots.txt block hides the `noindex` from the crawler; robots.txt manages crawl traffic, it does not remove pages from the index. Blocking a should-be-indexed page's JS/CSS in robots.txt also breaks rendering-based indexing.
+- **XML sitemap when the site is large, new, or weakly interlinked**; a small (~<500 well-linked pages) site usually doesn't need one.
+- **Structured data as JSON-LD** (Google's recommended format) with `schema.org` vocabulary for surfaces that qualify for rich results (articles, products, FAQs, breadcrumbs); validate with the Rich Results Test rather than eyeballing.
+- **Social preview: the Open Graph required set is `og:title`, `og:type`, `og:image`, `og:url`** (add `og:image:alt` with any `og:image`); with incomplete Open Graph metadata the preview becomes incomplete or platform-dependent (platforms may fall back to ordinary HTML metadata or their own tags). Verify the unfurl with the target platforms' debuggers when share traffic matters.
+- **Multilingual pages use bidirectional `hreflang`** (every variant lists itself plus all others — non-reciprocal tags are ignored), absolute URLs, and `x-default` for unmatched languages. Localized variants with distinct content (different languages, or regional pages with real differences) keep their own self-referential canonical — canonicalizing translations to the default-language URL marks them non-representative and removes them from localized results, defeating the hreflang set; same-language regional near-duplicates may share a canonical representative per the duplicate rule above, and hreflang then annotates the canonical set.
+- **Client-rendered React has JS-SEO constraints**: Google renders JS in a deferred headless-Chromium queue, so (1) navigation must be real `<a href>` links (router `<Link>` components render one; click-handler-only navigation is invisible to crawling), (2) no fragment-based routing for indexable content — use History API paths, (3) soft-404s need a real 404/410 status (or a JS-injected `noindex` when the server can't), (4) primary content must not require user interaction to load, and (5) Google itself still recommends SSR/pre-rendering for critical content ("not all bots can run JavaScript"). For content-heavy public surfaces this is an SSR/SSG/Islands adoption signal per `Framework-Era Patterns` below.
+- **Core Web Vitals are used by Google's ranking systems** (good thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1, at the 75th percentile of field data) and mobile-first indexing is fully rolled out — the mobile rendering is the indexed one, so mobile CWV and mobile-rendered content parity are the release-gate numbers for public pages.
+- **Verify deterministically**: Lighthouse SEO category, the Rich Results Test, or a fetch-and-parse check beats hand review; for changed public routes assert title/description/canonical/OG in a component test or the browser smoke — asserting canonical VALUE per route class, not mere presence: distinct indexable pages self-canonicalize, duplicate variants resolve to their intended representative, and the canonical target is a successful indexable URL (not a redirect or error) — a presence-only check stays green while every route canonicalizes to the home page and drops out of results; keep the check in CI for the marketing/content app rather than re-auditing by hand each release.
+- Primary pages per rule cluster (all under `developers.google.com/search/docs` unless noted): titles/descriptions → `appearance/title-link`, `appearance/snippet`; canonical → `crawling-indexing/consolidate-duplicate-urls`; noindex vs robots → `crawling-indexing/block-indexing`, `crawling-indexing/robots/intro`; sitemap → `crawling-indexing/sitemaps/overview`; structured data → `appearance/structured-data/intro-structured-data`; social preview → `ogp.me`; hreflang → `specialty/international/localized-versions`; JS SEO → `crawling-indexing/javascript/javascript-seo-basics` and `.../lazy-loading`; CWV/mobile-first → `appearance/page-experience`, `appearance/core-web-vitals`, `crawling-indexing/mobile/mobile-sites-mobile-first-indexing`.
 
 ## Build Tooling Currency
 
 - **Vite 8 (released 2026-03) is the current stable**, shipping Rolldown as the default Rust-based bundler (10-30x faster builds, full plugin compatibility per Vite's own announcement). **Vite 7** (Node.js 20.19+/22.12+ required, Node 18 dropped; ESM-only distribution) remains the previous stable line for teams not yet ready for the Rolldown migration trade-off (Rust-toolchain debugging, plugin compat audit). Migration cadence: upgrade Node first if pinned to Node 18; then plan Vite 7 → 8 with a build-perf + plugin-compat smoke before flipping defaults. The historical `rolldown-vite` opt-in package is no longer the path forward — Vite 8 ships Rolldown directly.
 - **Tailwind CSS v4 (stable Jan 2025) uses CSS-first configuration**: no `tailwind.config.js` for new projects; configure via `@theme { --color-brand: ... }` directives in the same CSS file that imports Tailwind. The first-party Vite plugin + automatic content detection eliminates most config; full builds 5x faster, incremental 100x faster than v3. Migration from v3 to v4 is not free (config shape, plugin API, some utility-class differences) — the migration guide is authoritative; do not infer migration steps from training-data memory.
-- **Biome v2 (June 2025, "Biotype") for formatter + linter** when the team wants ESLint + Prettier collapsed into one Rust tool. Type-aware linting without TypeScript compiler dependency (Biome implements its own type inference for lint rules — this does NOT replace `tsc --noEmit` in CI for full type-check); 502 rules from ESLint sources; CSS + GraphQL formatting stable; `biome migrate eslint` automates most config porting. Trade-off: smaller plugin ecosystem than ESLint; if the project depends on niche ESLint plugins (custom org rules, framework-specific lint), audit those before migrating. ESLint flat config + Prettier remains valid for teams with deep ESLint plugin investment.
+- **Biome v2 (June 2025, "Biotype") for formatter + linter** when the team wants ESLint + Prettier collapsed into one Rust tool. Type-aware linting without TypeScript compiler dependency (Biome implements its own type inference for lint rules — this does NOT replace `tsc --noEmit` in CI for full type-check); 520+ lint rules (many inspired by other linters — verified 526 as of 2026-08); CSS formatting/linting stable since v1.9; `biome migrate eslint` automates most config porting. Trade-off: smaller plugin ecosystem than ESLint; if the project depends on niche ESLint plugins (custom org rules, framework-specific lint), audit those before migrating. ESLint flat config + Prettier remains valid for teams with deep ESLint plugin investment.
 - **React Compiler ESLint plugin**: when React Compiler is enabled (per `react-architecture.md`), keep `eslint-plugin-react-hooks` at the version that ships the compiler-aware preset; the recommended preset enforces the rules Compiler relies on (no mutating props, deterministic render, etc.). Without it the compiler may silently skip components that violate its assumptions.
 
 ## Framework-Era Patterns (When To Adopt, When To Defer)
@@ -50,7 +82,7 @@ Several React-adjacent architectures became visible in industry conversation (RS
 - **Adoption condition**: the app is on a framework/runtime with **production-supported RSC and Server Functions enabled for this app path** — Next.js App Router in RSC mode is the canonical example; other frameworks ship RSC as opt-in or experimental on specific paths. Framework-native loaders / actions (Remix / React Router framework mode, Modern.js, RedwoodJS) are valid server data patterns but are NOT automatically RSC / Server Actions — `loader` / `action` / `useFetcher` are their own primitive. Mixing hand-rolled RSC into a Vite + React Router v6 SPA is a research project, not a delivery path.
 - **Where RSC pays off**: content-heavy pages with mostly read traffic and small mutation surface (marketing, docs, dashboards with a stable read shape, list/detail screens). The data dependency moves to the server; the client bundle shrinks; first-load latency drops.
 - **Where it does not**: highly-interactive workbench surfaces (the chart/table workbenches in `react-architecture.md`'s heavy-dashboard pattern), live-collaboration editors, anything whose interactivity-to-content ratio is high. The "use server" / "use client" boundary becomes a maintenance tax that outweighs the SSR win.
-- **Server Actions / Server Functions** (`'use server'`) are async network calls with serializable args, designed for mutations / form POST paths where the framework owns revalidation. They can replace some fetch-based form submissions on RSC frameworks (progressive enhancement: form works without JS). They are NOT a general data-fetching replacement and they are not meant for retrofitting the API surface on a non-RSC framework.
+- **Server Actions / Server Functions** (`'use server'`) are async network calls with serializable args, designed for mutations / form POST paths where the framework owns revalidation. They can replace some fetch-based form submissions on RSC frameworks (progressive enhancement: form works without JS). They are NOT a general data-fetching replacement and they are not meant for retrofitting the API surface on a non-RSC framework. **Every Server Action is a publicly reachable HTTP endpoint regardless of where it sits in the component tree — authenticate and authorize inside each action body**; UI-level gating or "the button is only rendered for admins" is not access control. On Next App Router, declare fetch caching semantics explicitly (`cache` / `next.revalidate` per the pinned major's docs) rather than relying on implicit defaults, which have changed across majors.
 - **Streaming SSR with `<Suspense>` boundaries** is independent of RSC and works in plain React 18+: choose Suspense boundaries that match user-visible regions (header / nav / primary content / secondary panel) so the slowest region does not block the rest. Boundary placement is design — every fallback geometry must match the resolved region or layout jumps when the fallback resolves. Pair with `ErrorBoundary` at the same node — Suspense alone catches loading, not failure.
 - **Don't pick the framework for the buzz; pick it for the deploy story.** Many SaaS / admin / data-console apps already work on Vite + React Router + TanStack Query and would gain little from migrating to App Router; the migration cost (auth, middleware, build pipeline, hosting, third-party SSR compatibility) is real.
 
@@ -81,7 +113,7 @@ When the front-end build output (HTML, JS, CSS, assets) is served from object st
 - **Storage layout**: the build artifacts of each lane live under a stable prefix; the lane prefix is the unit of isolation. The standard lane (production baseline) has its own well-known prefix. The router resolves an inbound request to a `(lane, prefix, path)` tuple and serves the matching object.
 - **Bucket separation by trust**: protected lanes (canary, preview, tenant-isolated, internal) and the public production baseline MUST live in separate buckets — the production baseline can be public-readable for CDN performance; protected lanes MUST be in a private bucket with identity-bound or network-bound origin access control. Mixing public and protected lanes in one bucket is a finding, because any per-prefix policy is easy to misconfigure into a public exposure.
 - **Origin access control choice depends on the topology, but the lane-resolution contract is the same**: when a managed CDN fetches directly from object storage, use the provider's CDN-bound origin-access mechanism (S3 OAC bound to CloudFront, OSS-CDN equivalent) — but direct CDN-to-bucket is valid only for immutable public baseline assets that need no lane resolution, token exchange, manifest verification, or response-header control. Any path that needs lane resolution / preview-token validation / response-header policy / structured logging MUST go through the router; routing it directly via CDN bypasses the entire trust model. When a custom router proxies bytes from object storage, the router authenticates with its own IAM / service-account identity that has the minimum required permissions, and the bucket policy restricts access to that identity (and to the CDN-bound identity if a CDN sits in front). Do not rely on `Referer`-based bucket policies — `Referer` is client-set and trivially spoofable by non-browser clients (curl, scripts, native apps). The "TOS equivalent" or any other provider's equivalent must be identity-bound or network-bound and resistant to client-supplied header spoofing.
-- **Immutable artifact prefixes**: each deployment writes to a fresh content-addressed prefix (e.g. `<commit-sha>/`); existing prefixes are never overwritten. The deploy step uploads all artifacts, verifies them against a generated build manifest (per-file expected size + content checksum via the provider's authoritative checksum API — `x-amz-checksum-*` on S3, equivalents on OSS / GCS / TOS), and only then flips the active manifest to the new prefix. ETag is not a reliable content checksum for multipart uploads — do not equate ETag match with content match.
+- **Immutable artifact prefixes**: each deployment writes to a fresh content-addressed prefix (e.g. `<commit-sha>/`); existing prefixes are never overwritten. The deploy step uploads all artifacts, verifies them against a generated build manifest (per-file expected size + content checksum via the provider's authoritative checksum API — `x-amz-checksum-*` on S3, equivalents on OSS / GCS / TOS; for multipart uploads use the full-object checksum type where the algorithm/provider supports it; when only a parts-composite checksum is available, do not compare it against the manifest's whole-file digest — verify by independently reading back the completed object and hashing it with the manifest's algorithm), and only then flips the active manifest to the new prefix. ETag is not a reliable content checksum for multipart uploads — do not equate ETag match with content match.
 - **Artifact retention and GC**: old immutable prefixes are kept for at least `max(CDN cache TTL, browser cache TTL, service-worker cache TTL, rollback window)` after they stop being active. Premature GC orphans live clients still holding old HTML that references old chunks → blank screens and chunk-load errors. Retention policy is part of the deployment contract, not an afterthought; GC is a separate scheduled job with explicit safety margins, never tied to "deploy succeeded" timing.
 
 ### Trust Model For Lane Selection
@@ -170,7 +202,7 @@ For portfolios with multiple React apps sharing a back-end:
 
 - PR gate must run remotely (GitLab CI / GitHub Actions / equivalent), not only as a local pre-commit hook. Pre-commit catches obvious lint/format problems; PR-level gates catch what locally was skipped, what dirty branches drag in, and what the merge introduces.
 - Required PR gate stages, in this order: install (frozen lockfile) → type check (`tsc --noEmit`) → lint → unit/component tests → build. Skipping any of these because "the local hook ran" is a recurring source of broken main branches.
-- Husky + lint-staged + `verify-commit` are the local layer; they enforce style and message format. They are not a substitute for the PR gate.
+- Husky + lint-staged + `verify-commit` are the local layer; they enforce style and message format. They are not a substitute for the PR gate — local hooks vanish under `--no-verify`, and correctness lint rules downgraded to `warn` severity gate nothing anywhere; rules that matter are `error` in the remote gate.
 - Lane / environment separation in CI (online vs offline lanes, canary vs production deploy targets) belongs at the deploy stage, not at the build stage. Build artifacts should be lane-independent where possible; lane choice is a deploy-time variable.
 - A portfolio without remote PR gates is a deliberate trade-off (fast iteration, small team, single owner) or an oversight; document which. Adding PR gates retroactively to ten apps is expensive — start one app at a time with the lightest gate (type check + lint + build) and expand.
 
@@ -188,3 +220,4 @@ A portfolio with **zero unit tests, zero component tests, and zero E2E** across
 - Dead dependencies (declared in package.json with zero imports) are a recurring finding when multiple authors edit shared starter templates. Lint or a per-CI step (e.g., `depcheck`) catches them.
 - Per-app `@umijs/max` / `next` / `vite` major-version skew (`4.0.x` to `4.4.x` across apps in the same portfolio) is a finding; cap the skew and run a periodic bump pass on the lowest-pinned app.
 - Generated outputs (OneAPI clients, Hertz/Kitex stubs, OpenAPI clients) check into the repo and run formatter-skip rules; CI should fail when generated output is stale relative to the IDL/schema source.
+- Optional deterministic React health scan: `react-doctor` (npm; by the react-scan/Million authors; young 0.x line — verified real and maintained 2026-08) scans correctness/performance/security/accessibility and outputs a 0–100 score; `--scope changed` restricts findings to files changed vs the base branch, which makes a cheap "score must not regress" PR ratchet. Supplement to — not replacement for — the ecosystem ESLint/typed-lint executors in `testing-strategy/references/fitness-functions.md` §4.1.3; pin the version in CI rather than `@latest`, and never wire any scanner mode that fetches and obeys remote playbook prompts at run time (remote-instruction execution is an untrusted-content hole, per `llm-inference-integration` trust rules).

package/dist/assets/marketplace/plugins/ccl-skills/skills/web-react-dev/references/web-ui-quality.md

@@ -12,11 +12,19 @@
   - Behavioral: pending, disabled, retry, cancel, duplicate-submit, offline/stale, partial, and interrupted states are visible where relevant.
   - Psychology: the screen reduces uncertainty, waiting anxiety, fear of mistakes, and loss of control.
 
+## Design-Token Diff Review
+
+Before declaring a visible UI change complete, review the diff itself against the design-token source (design-system tokens, theme variables, documented semantic values — token/`DESIGN`-doc ownership per `product-ui-ux-design`):
+
+- Scan the changed paths for likely hard-coded visual values, e.g. `rg -n '#[0-9a-fA-F]{3,8}\b|rgba?\(|hsla?\(|box-shadow:|linear-gradient|font-family:' -- <changed-paths>` — keep the `--` option terminator and collect the path list without shell word-splitting against an explicit review range — `git diff --name-only -z <base>...HEAD` for committed changes, `git diff --cached --name-only -z` for staged ones (a bare `git diff --name-only` sees only unstaged edits and silently yields an empty list on a committed candidate — treat an empty path list as a failed scan, not a pass) — so a repository-controlled filename starting with `-` cannot be parsed as an `rg` option (`--pre` would execute content instead of scanning it). Tune the pattern to the styling system (Tailwind arbitrary values `[...]`, styled-components literals, inline `style=`).
+- Classify every hit three ways: (1) approved token/primitive usage or a documented exception (e.g. chart-adapter series colors); (2) pre-existing code outside the requested change — do not report it as caused by this change, and do not copy it either: an old component carrying a non-compliant value is not permission to repeat that value; (3) a new violation — fix it by referencing the theme/token primitive instead of restating its literal value.
+- If the requested visual result cannot be achieved with the defined tokens/patterns, stop and route the gap to the design-system owner (`product-ui-ux-design`'s design-system source-of-truth path) instead of silently inventing a new color, radius, shadow, or type style; record the escalation in the change.
+
 ## Accessibility
 
 - Prefer semantic HTML before ARIA. Use buttons for actions and links for navigation.
 - Every interactive control needs an accessible name, keyboard reachability, visible focus, and a clear disabled/loading state.
-- Forms need labels, validation messages associated with fields, error summary when useful, and keyboard-friendly submit/retry behavior.
+- Forms need labels, validation messages associated with fields, error summary when useful, and keyboard-friendly submit/retry behavior. Form micro-contract worth enforcing in review: never block paste; keep submit enabled while the user is still editing, but latch an accepted submission synchronously — before the first await of validation/serialization/token acquisition — so a second click or Enter cannot dispatch twice, releasing the latch on the submission's terminal state (failure, and success too for reusable same-page forms like chat/comment/search); Enter submits the focused input and ⌘/Ctrl+Enter submits from a textarea; validate after input instead of blocking free typing; on failed submit, focus the first invalid field; warn before route-leave with unsaved changes; stay password-manager/2FA compatible (real inputs with `autocomplete` attributes).
 - Modals, popovers, menus, and drawers need focus management, escape/outside-click behavior where appropriate, and return focus on close.
 - Check contrast, text wrapping, zoom/text scaling, and screen reader names for icon-only controls.
 
@@ -25,6 +33,7 @@
 - Define stable dimensions for fixed-format UI such as grids, toolbars, tables, boards, and controls.
 - Define the primary viewport, stress viewport, and collapse rule before coding. Secondary panels, filters, metadata, and previews should collapse or dock before the primary reading/editing region becomes unusable.
 - Use virtualization or pagination for large lists/tables when rendering cost becomes visible.
+- Numeric floors worth enforcing in code review: interactive hit targets ≥ 24×24 CSS px (WCAG 2.2 SC 2.5.8 AA — spacing/inline/UA-default exceptions exist; platform HIGs recommend ~44-48 px on touch), mobile input font-size ≥ 16px (prevents iOS focus zoom), never disable user zoom (`user-scalable=no` / `maximum-scale=1` in the viewport meta is an accessibility finding), and flex/grid text truncation needs `min-width: 0` on the shrinking child or `overflow` clipping never engages.
 - Preserve useful URL state for shareable/filterable pages.
 - Handle back/forward, reload, auth expiry, offline/stale data, and browser storage expiry deliberately.
 - Long task and upload/review pages should model route-leave, reload, polling timeout, stale task, and terminal failure as component states when the user could lose work or confidence.

package/dist/assets/release.json

@@ -1,8 +1,8 @@
 {
   "schema": 1,
   "npmPackage": "@ccoalm/ccl-skills",
-  "version": "0.8.0",
-  "sourceCommit": "840a2439852b50273156c27d2b2168aaf79fc7c4",
+  "version": "0.9.0",
+  "sourceCommit": "b001ca5b8c8663c579fbc1c815ca493418d97183",
   "sourceState": "clean",
   "files": [
     {
@@ -252,7 +252,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/app-cross-platform-dev/references/mobile-quality-release.md",
-      "sha256": "1c6043c2cf8027de355729da130979d232cc0d2b1043bcb7d2ec985d8f2c8e19",
+      "sha256": "a17804e52b7e6f3d9914c49d3ad7dd93ff22b596a92a1d1f6a1d6947f45262fb",
       "mode": 420
     },
     {
@@ -277,7 +277,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/code-review/references/manual-invocation-and-prompts.md",
-      "sha256": "c03ebde3da86957ec1a386a5121ef8b02f7f38177a47d1b01c4395d14dfd309f",
+      "sha256": "7e2fba79714418428748dfbc055d06a67c048ec6e12f1b6b3a441f81d2c05a24",
       "mode": 420
     },
     {
@@ -517,7 +517,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/defect-diagnosis/SKILL.md",
-      "sha256": "8d3f667c85391156d025e79e8a5854475e8d0fe2f972891959c0e9406425901c",
+      "sha256": "134b5313c5ee63d6b297f969a1a85ee96369cdc4d0efccb1d8268131095158b5",
       "mode": 420
     },
     {
@@ -532,7 +532,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/feature-risk-router/SKILL.md",
-      "sha256": "f8b1a265dff049f055934c4fc9ef578ee4c37826bf6e35994532991c997c162b",
+      "sha256": "a60b3c557274c1256e6ec9103d8d6545e285c2f154303b6ede88acae8e44611e",
       "mode": 420
     },
     {
@@ -547,7 +547,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/go-microservice-architecture/references/architecture-playbook.md",
-      "sha256": "8a887d3c577c14424796699092256fbd2ce1f82b8b77724c41529d8ba0f21d61",
+      "sha256": "fb8a7068c722e4f861014b830d72ae4b84b17a146b5f101121bf21f83f374d35",
       "mode": 420
     },
     {
@@ -617,7 +617,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/go-microservice-architecture/references/multi-tenant-isolation.md",
-      "sha256": "d16df5bf977e47976b4918bbc4848161893a28ffbabcd151a8000270a88e2c0b",
+      "sha256": "420e7394792e0207a67031bca902f404260e8126fa310daae9246f7bcda4b54e",
       "mode": 420
     },
     {
@@ -817,7 +817,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/go-microservice-dev/references/state-machine-task-patterns.md",
-      "sha256": "72e0a90686756526648cf4403daac973ea3443d141c25b643a3ff4fb4452a1ce",
+      "sha256": "63a517682277577630cb385f38060431f59ee2453b32b6f842c2d7f41b412c7a",
       "mode": 420
     },
     {
@@ -927,17 +927,17 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/llm-inference-integration/references/inference-capacity-operations.md",
-      "sha256": "0e7241c1925d183101f304b805510663a21601fa7a4709e8ebb126f7e8def98d",
+      "sha256": "277da0425806778dfd5dd02886fec6d5b695d5e0a9b3cc461e71b67014dc37a6",
       "mode": 420
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/llm-inference-integration/references/llm-client-gateway.md",
-      "sha256": "439b1aea5504480ba4e3185b31237dca69330adfdec4572c099097a0bc49aa23",
+      "sha256": "c528c26e39ad9fd9a3d3482bd472c855f9ff5eef1b2e1743d234365f744e2f66",
       "mode": 420
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/llm-inference-integration/references/model-prompt-evaluation.md",
-      "sha256": "8c1a38ed0e4007fdc1912046680ed146d762a15a6c3d8eef98f1c26ceb1d3547",
+      "sha256": "e1b5913ef3f229f79a2874660d58b2d9991ab4a307ec29864b7c63d114d69900",
       "mode": 420
     },
     {
@@ -957,7 +957,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/miniapp-product-dev/references/contracts-and-state.md",
-      "sha256": "5b1af907df6f6ec5ded21ece86784f3abad7ed52b7ac5ec38cdb60616991880d",
+      "sha256": "2b74b8ccb20fbd0067744d876914f503365849bdef4fb647a41502df03028bf7",
       "mode": 420
     },
     {
@@ -1057,7 +1057,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/nodejs-service-dev/references/async-lifecycle-and-performance.md",
-      "sha256": "fac8085c40bbce3355a3908c406691a74dc8a0e7a3d8b811dd907085cf7b5075",
+      "sha256": "0cc63ac7259ed1f83a90aec1cfa0f43ea61db6227d7499a929ef74cabb2a36f3",
       "mode": 420
     },
     {
@@ -1112,7 +1112,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/platform-observability/references/metrics-conventions.md",
-      "sha256": "b6d7c74c64fd27649b0ff237be04a29db38597dc35d4abe77c5b9c1f4cb50797",
+      "sha256": "910403cdad807963602db76767dbddc0b3d8c7a7f45420034a79efe271e7004a",
       "mode": 420
     },
     {
@@ -1122,7 +1122,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/platform-observability/references/sli-slo-design.md",
-      "sha256": "a073fd9fdc7b6626698a9477c9dca11da63faf6037c02bdde5738c26138c4321",
+      "sha256": "9287f4512677528f3e1ebc0cd0a20be87086ed7a75f9c968beb27864ff282397",
       "mode": 420
     },
     {
@@ -1132,7 +1132,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/platform-observability/SKILL.md",
-      "sha256": "42929080361c5ed3b533f4a86da51fd09c76644f5288754ee2d1d765a2da81fc",
+      "sha256": "1d73a36f4d4e9511df81588054eba288a1db1efb5f2437a515929326142a15a8",
       "mode": 420
     },
     {
@@ -1142,7 +1142,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/platform-release-engineering/references/canary-and-rollout-strategy.md",
-      "sha256": "f256dcac4bc9ce1299af495dcbbe6cd5a265db0bcf2181474e5082d2c537997c",
+      "sha256": "f00a767d9bf9c90834a60b709fb51e6453c6866d4a95fc4b8bbbf54f3a59f0b7",
       "mode": 420
     },
     {
@@ -1182,7 +1182,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/platform-release-engineering/references/promotion-gate-and-review.md",
-      "sha256": "b271dfb0f3db3c85612b032562d48119fcb6e39fec235723dcdcca5b01eb2f41",
+      "sha256": "0dc8cfd330ec779556a8d8133e370da77b75d7d8537eca10e9c6081af427bff7",
       "mode": 420
     },
     {
@@ -1322,7 +1322,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/code-review-checklist.md",
-      "sha256": "d101ef16e8315e6f2e05b2ed07331646b35bba4e3788d436b13a9705441d5b07",
+      "sha256": "5ec943716a500eb43399162f02e628229886df10320b6bcae3842690b1f24630",
       "mode": 420
     },
     {
@@ -1332,7 +1332,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/delivery-lifecycle.md",
-      "sha256": "ef1f90bdd8037a02432981be15cfd156524cdad5e7de5ad9880ae15b04a60a23",
+      "sha256": "adb63f5aa873dea2292e43b1478eecac1557f3fd0382cea1202826bb70c26cbd",
       "mode": 420
     },
     {
@@ -1417,7 +1417,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/rd-standards-doc-family-checklist.md",
-      "sha256": "e78204b4385397b4cf31da4f0cf89cd67f9c5b4292ace831a9b3f1e3061c4978",
+      "sha256": "f88d85cfb4ebd7ec292a46472df365d8c97ca776b6ab4a5024d7bfe54bc093f3",
       "mode": 420
     },
     {
@@ -1472,7 +1472,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-rd-workflow/SKILL.md",
-      "sha256": "b6ded1af9e5f376ffe238a3d8cca4e8c5c5b15efe1634f0d540e97fa62e60a40",
+      "sha256": "163284827131517277532acd6f67b08b17efa1d31a74db465a733587962a9f65",
       "mode": 420
     },
     {
@@ -1517,7 +1517,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/design-system-source-of-truth.md",
-      "sha256": "6e61cff6c897a676790385d1ad9431bd8c1c8f18f5cfaf0ec7eee09cb236f14f",
+      "sha256": "278753a7e7502859e8ae3aa6ac20a48003563961f112fbb9cdf360c2298b7139",
       "mode": 420
     },
     {
@@ -1557,7 +1557,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/platform-mobile-patterns.md",
-      "sha256": "05089c50c1b2b3e8eb2e2328dcde01199b7167f7178853433a468f77751ab95d",
+      "sha256": "a27ad0c10ac35e2f98b221bdb6b49ea1d07a05bd7039e0ff7e50bc9808f72e45",
       "mode": 420
     },
     {
@@ -1592,7 +1592,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/tokens-and-components.md",
-      "sha256": "7ae97f516103251dd80a01ba110c640b2bc5ca1315e098cb93bcf0e70504eb6b",
+      "sha256": "449871eab22e2c21b54e18c0dda3d7842b601e5d1bac1fd53d117fe79380bc39",
       "mode": 420
     },
     {
@@ -1602,7 +1602,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/ui-ux-audit.md",
-      "sha256": "87ec661418e8ac77d79d814e35f82e1ed506d5a083200060c4862e48d1f4b739",
+      "sha256": "5b2e7d1ac1a4b68193e11eb54bda556cc8071e5110bfea7799b4afba48dd7de0",
       "mode": 420
     },
     {
@@ -1687,7 +1687,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/python-service-architecture/references/multi-tenant-isolation.md",
-      "sha256": "2860ef59351fe8bf37c0ec6013697fe03b9e6fec76401c6145963b27cb0b9dc7",
+      "sha256": "a90db84925cf6b60dbcc81066e447f95424e00784ffc9757a8cc669496c3a82f",
       "mode": 420
     },
     {
@@ -1832,7 +1832,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/python-service-dev/references/state-machine-task-patterns.md",
-      "sha256": "ee51be3015a6d72b5a54aed0db44c2d7cb9d63c6de26ebd5e5910d4824d616dd",
+      "sha256": "f3220c9f041bcd7fdc0e0dd6e36ab6483563a6bf1fc3b590a23ec66a7e673354",
       "mode": 420
     },
     {
@@ -1897,7 +1897,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/release-coordination/SKILL.md",
-      "sha256": "c53f4d6d1f0683b53b981218ed0075b4de195ca186e13ada8c94e08c9b7a8c4c",
+      "sha256": "60018442768303688817af99187fa7d7d803d534a78c29ddf45fc75607cbba7a",
       "mode": 420
     },
     {
@@ -2007,12 +2007,12 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/description-authoring.md",
-      "sha256": "295ddc849ffe1cfcfef3ffc8a6b012191250f7b0404ad994080e7b2da5db6b5f",
+      "sha256": "ea77cc38146edd8e1afd1dd5c220b04aff9269b531bdf25b768d25e33ce3ee86",
       "mode": 420
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/dual-track-review-gate.md",
-      "sha256": "d5ae0cc9cf0ec46987a8b4deece103f5a5873def6ad4c99aa157cd67cdb1402f",
+      "sha256": "087a55c0d819f7482d445bc6a375a730231af5c1b4b71ac48731901c26f6a9dd",
       "mode": 420
     },
     {
@@ -2117,12 +2117,12 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/source-register.md",
-      "sha256": "1955441d60ee461b9d50dc12f8db6c42a75cae9e44228e30d2ad0d162bb8998b",
+      "sha256": "6e754e1eed7e9bfcecab72840cf28d5d90d2897c50c15f1d701c77cc74acaf0a",
       "mode": 420
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/source-to-skill-extraction.md",
-      "sha256": "f7076733a89eb3bbd91ae150b204d918b5cba41e0704d3dba632c73535bdc0d4",
+      "sha256": "8ea17e4e71159252de8d162e579a1909eed9f1eca170b87e206930adc3073eec",
       "mode": 420
     },
     {
@@ -2477,7 +2477,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/SKILL.md",
-      "sha256": "5fcb4441765f24cc7aa2190230fba27e632b5802ba1de055517dadf110444a60",
+      "sha256": "6cbf106acc98bb26f63f8b81c6288aaaa41902e7018dbd1ecd2cf08ebc0ed609",
       "mode": 420
     },
     {
@@ -2542,7 +2542,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/test-artifact-management/references/classical-test-design-techniques.md",
-      "sha256": "ada5001f4edbb40d3366dfab194065b222e6878ace96616fbd7a77cdfb2bd4d9",
+      "sha256": "193bda4e4751c9bbab4225542fa9986ea57a26066872a85fef1906e8eea994e5",
       "mode": 420
     },
     {
@@ -2602,7 +2602,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/test-artifact-management/references/tc-review-and-prioritization.md",
-      "sha256": "604fe1879b3ef7ac072b18fa57ee19ef0cab7991fcd49c4a14288fad8277dd0a",
+      "sha256": "0c49f201de768fcb3490f046fb89617d1f481b7f3dfefab8d311eb619e18a208",
       "mode": 420
     },
     {
@@ -2612,7 +2612,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/test-artifact-management/references/update-lifecycle.md",
-      "sha256": "1698f76165dc2678f9b06621923069541cd5e4e3890897f93271a3335c551089",
+      "sha256": "0872518408b0967aedbd9ff69b58527298006b1731bc72e8e35e88d2d0d338c6",
       "mode": 420
     },
     {
@@ -2627,7 +2627,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/testing-strategy/references/ci-fixtures-and-flake-control.md",
-      "sha256": "f35c12479559a56701338e715101a7a5eccba1f2ccbcee4827e9696def8cfc33",
+      "sha256": "139a79639c172c7b67f2960c254d5bd258a961bac57d619025b549967f2933cd",
       "mode": 420
     },
     {
@@ -2647,7 +2647,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/testing-strategy/references/e2e-real-flow-testing.md",
-      "sha256": "0f3d5aba65c38842d542ebfe3f1ee1d0cf1400624252f4764a3281c3cc21c8c8",
+      "sha256": "32d0442895af48e5ea6fdb741ac7a1d28299c178686fb5674fd59b2969db6c23",
       "mode": 420
     },
     {
@@ -2657,7 +2657,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/testing-strategy/references/integration-contract-testing.md",
-      "sha256": "4a9ebe52b21bc03c06d806f12f0a1a0c1a31edabf108e2777d41e449b07c3550",
+      "sha256": "533a9da3c6bdade5232d7f16ab90c20da467cd4393c75f753a31d6155a2c034c",
       "mode": 420
     },
     {
@@ -2692,7 +2692,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/testing-strategy/references/test-code-authoring-patterns.md",
-      "sha256": "e5340d8a49291562f1cf8f2a4824d591b6d20c1f7ebe26a47d358494563c45e8",
+      "sha256": "099f95cf4ab5cbf291e16ba7e8b7363ba49922b443bd4ff24deca32cb3a0ad8b",
       "mode": 420
     },
     {
@@ -2702,7 +2702,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/testing-strategy/references/test-topology-and-commands.md",
-      "sha256": "d423b9f62708d0e873d598cb7f48c697640f29fb5b475f093a8d4e79891129ad",
+      "sha256": "d808af85d5a91b12b8650535ab86446a2b8ff35196d011e61bd6a989b5386dd7",
       "mode": 420
     },
     {
@@ -2762,7 +2762,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/testing-strategy/SKILL.md",
-      "sha256": "9efe5339d5bb047c8259d472a716ba15991c266ea174eeb907e875bbb32ef000",
+      "sha256": "db42b8dcf62c77ce6374abc3926e84cbcd45ab04f6a7f7663e88c55cf2507eff",
       "mode": 420
     },
     {
@@ -2770,6 +2770,11 @@
       "sha256": "8f4178ff2287485c40f9b3f9eb765a0626360a35796f239186943d8e91e8aaa9",
       "mode": 420
     },
+    {
+      "path": "marketplace/plugins/ccl-skills/skills/tighten-doc/references/annotation-driven-revision.md",
+      "sha256": "eaf5adc225ecd47e555611e5a1b9768fbe725204384dd96461408b81646c7fd1",
+      "mode": 420
+    },
     {
       "path": "marketplace/plugins/ccl-skills/skills/tighten-doc/references/comment-safe-feishu.md",
       "sha256": "c930ab39dd676da34c202c46c798441fdf2699271a5aff17d52c1dbd87df77f7",
@@ -2797,7 +2802,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/tighten-doc/references/figure-and-table-craft.md",
-      "sha256": "15fb3f231595b49730315a9e1f12918e0f268f9d7831523a62d92c5831d0d92d",
+      "sha256": "49c9701f114b7194d72b34fc5eba4bf25445ca1ac32d57af1be2c234131be3af",
       "mode": 420
     },
     {
@@ -3072,7 +3077,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/tighten-doc/SKILL.md",
-      "sha256": "63706d33ddc954bbf4a11cd872f4944feb531dda30c83755b4709554df69ec3e",
+      "sha256": "75b0c8fb65803056d9b7535b300a37a3a26fb0125b20adbbcd7cb14ba7461991",
       "mode": 420
     },
     {
@@ -3092,7 +3097,7 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/web-react-dev/references/react-architecture.md",
-      "sha256": "83f474ac72981969aee08919101eccd0502b455207dd70f32f2938be659dd99c",
+      "sha256": "0635db0d1931b531fba67a921edd7bb83689594b565ff82ac2140deaf966a9f8",
       "mode": 420
     },
     {
@@ -3102,17 +3107,17 @@
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/web-react-dev/references/web-quality-release.md",
-      "sha256": "91101f3ba3bee3280a1a98eaa4d20a473275920bdc0bc4ef22375c5140559194",
+      "sha256": "35fc6b18e8809c1abeba12069fcb8be983e0e629d7760c5bd2ef52f150e276f4",
       "mode": 420
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/web-react-dev/references/web-ui-quality.md",
-      "sha256": "f55ad80ef6da82529b92b37f5f414d301f784774e13020f3f67f3b74995fb404",
+      "sha256": "48672a5a63af505a34d9ccb0e03ef1d2b02e79460e7d227b8b4ae82a4648b6bc",
       "mode": 420
     },
     {
       "path": "marketplace/plugins/ccl-skills/skills/web-react-dev/SKILL.md",
-      "sha256": "282c45dd66c9071794ac4b2a2da9c7643514ec5476111570a34853ea2c9c8651",
+      "sha256": "3d60fa18aa37299dc0b9672126243146ee62c9c41d8707bf09e455e810506cb9",
       "mode": 420
     },
     {
@@ -3308,5 +3313,5 @@
       "mode": 420
     }
   ],
-  "snapshotHash": "fc94accc7fe6f6faea57ae99b70bc3995f38b10c1b670c1857935f0ff8aa9a2b"
+  "snapshotHash": "360d37909bfd9e874a189e5013f5aaf2c65fea33329bc3f4fba9c7078c052d83"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ccoalm/ccl-skills",
-	"version": "0.8.0",
+	"version": "0.9.0",
   "description": "Reusable workflows that help coding agents plan, build, test, review, and release software — for Claude Code, Codex, and OpenCode",
 	"keywords": ["skills", "agent-skills", "claude", "claude-code", "codex", "opencode", "agent", "ai", "ai-agents", "cli", "anthropic", "developer-tools"],
   "type": "module",