@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.0

package/skills/frontend/legacy-jquery-to-modern-framework-review/references/dom-mutation-and-plugin-side-effects.md

@@ -0,0 +1,66 @@
+# DOM Mutation and Plugin Side Effects
+
+Use this reference when auditing third-party jQuery plugins and ad-hoc DOM-manipulation code for behavior that happens outside any framework render cycle — direct DOM mutation, global state writes, timers, and unsanitized HTML construction.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "The plugin has a small public API (`$(el).fancyPlugin({ options })`), so its footprint is small too."
+
+That is false for the overwhelming majority of jQuery-era UI plugins. A plugin's public API surface tells you nothing about:
+
+- how many DOM nodes it creates and where it puts them (often *outside* the element it was called on — appended to `body`, injected as siblings, or moved elsewhere in the tree),
+- whether it registers global listeners (`$(window).resize(...)`, `$(document).on('keydown', ...)`) that persist for the lifetime of the page regardless of whether the "widget" is still visible,
+- whether it holds module-level or `$.fancyPlugin.instances`-style singleton state shared across every instantiation on the page,
+- whether it starts timers (`setInterval` for polling/auto-rotation, `setTimeout` for debounce/animation) that are never cleaned up on the jQuery side either, but happen to not matter in a page-reload-based app the way they will matter in a long-lived SPA.
+
+A framework component's render cycle (mount → update → unmount) has no way to automatically clean up any of this. If the plugin's real behavior is not inventoried, the "equivalent" component will leak listeners, leak timers, or silently stop working the first time the framework unmounts and remounts the component (which jQuery-era pages never did — they reloaded instead).
+
+## Non-negotiable design rules
+
+### 1. Read the plugin's source, not just its call sites
+
+A call site like `$('.carousel').slick({ autoplay: true })` gives zero information about side effects. Locate the actual plugin source (vendored file, node_modules, or inlined script) and grep it directly for:
+
+- `document.body.append`/`appendChild`, `$('body').append(`, or any DOM insertion target that is not `this`/the plugin's own root element,
+- `setInterval`, `setTimeout` with no matching `clearInterval`/`clearTimeout` in a documented teardown/`destroy` method,
+- `$(window)`, `$(document)` listener registration,
+- module-level `var`/`let` outside any function scope, or properties attached to the jQuery plugin namespace itself (`$.fn.pluginName.defaults`, a shared cache object) — these persist across every instance and every page-lifecycle event.
+
+### 2. Distinguish "has a destroy/teardown method" from "is actually called"
+
+Many plugins document a `.pluginName('destroy')` API. Grep the *call sites*, not just the plugin source, for whether teardown is ever invoked. A legacy app that never unmounts widgets (because it never removes DOM nodes without a full page reload) commonly never calls teardown — meaning the migration is the first time this code path's absence becomes an observable bug (memory growth, duplicate global listeners after client-side navigation).
+
+### 3. Treat every `.html()`, `.append()`, `.prepend()`, `.after()`, `.before()`, `.replaceWith()`, or raw `.innerHTML =` assignment fed by non-literal data as a security finding
+
+"Non-literal" means anything built from a variable, template string, concatenation, `.val()`/`.text()` of another element, a server response, or a URL/query-string value — not a fixed string literal written by the developer. For each match:
+
+- record whether the source is attacker-influenceable (see the taint sources in this skill's sibling security-review skills: URL params, API responses rendering third-party/user content, `postMessage`, storage written by another origin),
+- flag explicitly if the *proposed* replacement is `dangerouslySetInnerHTML` (React) or `v-html` (Vue) — per the Context7-grounded React docs, `dangerouslySetInnerHTML` is a documented "Security Hole" when fed untrusted input directly; a framework migration must not be the moment an existing (bad) pattern becomes a *worse* one by skipping the sanitizer entirely,
+- never assume the plugin already sanitizes its input; verify by reading the plugin's actual string-construction code if the finding is high-severity enough to matter (public-facing, user-generated-content-adjacent).
+
+### 4. Global state and timers are migration blockers, not migration details
+
+If a plugin's side effects are genuinely global (a single page-wide autoplay ticker, a shared modal-stack z-index counter), the target architecture needs an explicit decision about where that state lives (a store, a context, a singleton service) — it cannot be silently absorbed into "just render the component and it'll work," because the framework component model assumes state is either component-local or explicitly lifted, not implicitly global via a shared jQuery-plugin-namespace object.
+
+## Minimal safe inventory progression
+
+1. Identify every `$(el).pluginName(...)` call site across the codebase and group by plugin.
+2. For each distinct plugin, locate its actual source (not just its call sites) and grep it for the side-effect categories in rule 1.
+3. For each plugin, check whether a teardown/destroy path exists in the source and whether it is ever invoked at any call site.
+4. Separately, grep the whole codebase (not just plugin source) for `.html(`, `.append(`, `.prepend(`, `.after(`, `.before(`, `.replaceWith(`, and `.innerHTML =` and classify each by literal vs. non-literal input.
+5. Cross-reference: does any plugin call site feed plugin options built from non-literal, potentially-attacker-influenceable data (e.g., a plugin's `content` option populated from an API response)? This is a compound finding — flag it distinctly from a plain `.html()` call, since the plugin's internal handling of that option is opaque without reading its source.
+
+## Verification targets
+
+- For any plugin flagged as holding global/singleton state, confirm by checking whether multiple instantiations on the same page actually interfere with each other in the current app (evidence: a bug report, a workaround comment in the code, or a code path that explicitly guards against double-initialization) versus being a theoretical risk only.
+- For any `.html()`/`.append()` finding proposed for replacement with `dangerouslySetInnerHTML`/`v-html`, confirm whether a sanitizer (DOMPurify or equivalent) is already present anywhere in the dependency tree before assuming one must be added from scratch.
+
+## When to push back
+
+Push back if the user asks to:
+
+- port a plugin's call site 1:1 into a `useEffect`/lifecycle-hook wrapper without first reading the plugin's own source for global listeners, timers, or singleton state — this reproduces every leak the plugin had, now inside a component that mounts/unmounts far more often than the legacy page ever did,
+- replace `.html()` with `dangerouslySetInnerHTML`/`v-html` as a mechanical find-and-replace with no sanitizer discussion — that is a downgrade, not a port, whenever the source data is non-literal,
+- mark a plugin "no side effects, safe to wrap" based on reading only its options API or its README, without having actually grepped its source.

package/skills/frontend/legacy-jquery-to-modern-framework-review/references/event-delegation-inventory.md

@@ -0,0 +1,60 @@
+# Event Delegation Inventory
+
+Use this reference when cataloguing jQuery/Backbone-era event-binding patterns before a framework migration — specifically `$(document).on(...)`-style global delegation, `$.fn` plugin custom events, and Backbone view `events` maps.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "Events are just `addEventListener` with extra syntax. I'll find every `.on(` call, rewrite it as an `onClick` prop, and move on."
+
+That is incomplete, and it is the single most common source of silent regressions in jQuery-to-framework ports. jQuery delegation and framework event handlers solve different problems:
+
+- **Delegation exists because elements come and go.** `$(document).on('click', '.tab', handler)` was written that way *because* `.tab` elements are added/removed dynamically (AJAX-loaded content, plugin-rendered markup) and a direct binding would miss elements that did not exist at bind time. A framework component only needs this pattern if it renders variable, dynamically-appearing children with no stable parent to attach the handler to — which is rare inside a component tree where the framework already re-renders and re-attaches handlers on every update.
+- **The delegation selector is not the same as ownership.** `$(document).on('click', '.modal-close', ...)` is bound once, globally, but the handler's *logic* may belong to a specific feature. Naively porting this to a single global `document.addEventListener` in the new app (instead of scoping it to the owning component) reproduces the original code smell instead of fixing it.
+- **Custom/synthetic events are easy to miss.** jQuery plugins frequently `.trigger('customEventName')` and other code listens with `.on('customEventName', ...)`. Grepping only for DOM event names (`click`, `submit`, `change`) misses this entire category of implicit coupling between unrelated-looking modules.
+- **Backbone view `events` maps use a different delegation model** (`{'click .save': 'onSave'}`), scoped to `this.el`, and typically calling `this.render()` internally — the "component" boundary is the Backbone view, not the DOM node the handler is nominally attached to.
+
+## Non-negotiable design rules
+
+### 1. Classify every handler by binding scope, not by event name
+
+For each match, record:
+
+- **Global** (`$(document).on(...)`, `$(window).on(...)`, `$('body').on(...)`) — highest risk; likely couples unrelated features.
+- **Container-scoped** (`$('#widget-container').on(...)`) — bound once to a stable ancestor; probably maps to a single component boundary.
+- **Element-direct** (`$('.button').click(...)` or `.on()` with no delegate selector) — bound at render time; will break silently if the plugin re-renders the DOM node without rebinding (a classic jQuery bug this inventory should surface, not silently port forward).
+- **Backbone view `events` map** — scoped to `this.el`; note the view class name and whether `render()` is called inside the handler.
+
+### 2. Do not assume the delegated selector's specificity survives the port
+
+A delegated selector like `.on('click', '.item.active', ...)` depends on class-toggling logic living somewhere else in the codebase. Trace where `.active` is added/removed before assuming the target framework's conditional rendering (`className` binding, `:class`, `[class.active]`) is an equivalent replacement — confirm the toggle logic itself is inventoried, not just the handler.
+
+### 3. Treat custom/synthesized events as first-class inventory items
+
+Grep for `.trigger(`, `.triggerHandler(`, and Backbone's `.trigger(` (models/collections/views all mix in Backbone.Events) alongside the corresponding `.on('eventName', ...)` listeners. Record the event name, the emitting module, and every listening module — this is often the only documentation of a cross-module dependency that exists.
+
+### 4. Distinguish "will the target framework's re-render make this delegation unnecessary" from "must this delegation pattern be explicitly reproduced"
+
+Framework component trees re-attach handlers on every re-render by design (React re-runs the component function; Vue/Angular re-bind via their own reactivity), which naturally replaces *element-direct* handlers that needed delegation only to survive jQuery's manual DOM churn. But a *genuinely* dynamic, framework-external DOM region (e.g., markup injected by a third-party widget the framework does not control) still needs an explicit delegation strategy — do not assume the framework's reactivity makes all delegation moot.
+
+## Minimal safe inventory progression
+
+1. Grep for `.on(`, `.bind(`, `.delegate(`, `.live(` (legacy jQuery <1.9 API — flag its presence as an age/version signal), `.click(`, `.trigger(`, `.triggerHandler(`, and Backbone `events:` object literals.
+2. For each match, classify by binding scope (see rule 1) and record the file, the selector/event name, and the handler body's actual side effect (state mutation, network call, DOM mutation, navigation).
+3. Group matches by the DOM region or feature they affect, not by file — a single feature's delegation logic is often split across an initializer file and a separate handler file.
+4. For every custom/triggered event, find both the emitter and every listener before marking the entry complete; an event with only an emitter found (no listener located) is an open item, not a non-issue.
+5. Produce the ownership mapping: each inventoried handler maps to a proposed owning component in the target architecture, or is marked "unresolved — requires product/design input" if no natural owner exists.
+
+## Verification targets
+
+- Confirm handler classification against actual runtime behavior where feasible (e.g., does the container the handler is bound to ever get replaced/re-rendered by innerHTML replacement elsewhere in the codebase — that would mean an element-direct binding silently stops firing, a bug worth flagging even before migration).
+- Cross-check every `.trigger('name', ...)` call against every `.on('name', ...)` listener; an emitter with zero listeners found in-repo may indicate a listener registered dynamically (e.g., via a plugin option callback) — mark as `inference, needs runtime confirmation` rather than silently dropping it.
+
+## When to push back
+
+Push back if the user asks to:
+
+- port event handlers file-by-file without first producing the ownership/ scope classification — this guarantees global delegation gets flattened into ad hoc per-component listeners that reintroduce the same "who owns this click" ambiguity the review exists to resolve,
+- skip the custom/triggered-event grep because "we only care about DOM events" — cross-module `.trigger()`/`.on()` coupling is frequently the least-visible and highest-risk-to-drop behavior in the entire codebase,
+- treat "the new framework re-renders automatically, so delegation is a non-issue" as true everywhere, without checking whether any DOM region is still externally/plugin-controlled.

package/skills/frontend/legacy-jquery-to-modern-framework-review/references/legacy-a11y-shim-audit.md

@@ -0,0 +1,58 @@
+# Legacy Accessibility Shim Audit
+
+Use this reference when checking whether a legacy jQuery/Backbone-era widget provides accessibility behavior that the replacement component must explicitly reproduce before being declared equivalent.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "The markup for this widget has no `role`, no `aria-*` attributes, and no `tabindex` in the HTML template — so it must have no accessibility behavior, and the replacement doesn't need any either."
+
+That is frequently false, and it is the single most common way a framework migration silently regresses keyboard and screen-reader support. Many jQuery UI-era plugins (jQuery UI's own dialog/tabs/autocomplete/datepicker widgets, and third-party clones of them) inject ARIA attributes, manage `tabindex`, and bind keyboard handlers **at runtime**, via JavaScript, into the DOM the plugin controls — none of it visible in the static HTML template or component markup a reviewer would normally read. Auditing only the markup and concluding "no accessibility behavior found" is a false negative, not a confirmed gap.
+
+Conversely, the opposite mistake also happens: assuming a plugin "must" handle accessibility because it is a mature, popular widget — some plugins (and especially most custom/homegrown ones) genuinely do nothing beyond visual behavior, and the accessibility gap being ported forward is real and already present, not a migration regression.
+
+Both mistakes are resolved the same way: verify, do not assume, in either direction.
+
+## Officially grounded shape (what the ARIA APG actually specifies)
+
+The W3C ARIA Authoring Practices Guide (APG) documents, per widget pattern (dialog, tabs, combobox/autocomplete, disclosure, menu, slider, etc.), the specific roles, states, properties, and keyboard interactions an accessible implementation of that pattern requires — e.g., a tabs widget needs `role="tablist"`/`role="tab"`/`role="tabpanel"`, `aria-selected`, and arrow-key navigation between tabs with roving `tabindex`; a modal dialog needs `role="dialog"`, `aria-modal="true"`, focus moved into the dialog on open, focus trapped within it, and focus returned to the triggering element on close. Use the APG pattern for the specific widget type as the checklist for what the *replacement* component must implement — regardless of what the legacy plugin did or did not do.
+
+## Non-negotiable design rules
+
+### 1. Check the plugin's actual runtime output, not the call-site markup
+
+For jQuery UI and comparable plugins, the accessibility-relevant code lives in the plugin source, in functions that run on initialization and on state change (e.g., open/close, select/deselect). Grep the plugin source for `.attr('role'`, `.attr('aria-`, `.attr('tabindex'`, `setAttribute('aria-`, and keydown/keyup handlers that check `event.which`/`event.key` against arrow keys, `Escape`, `Enter`, `Space`, `Tab`. Their presence means the plugin manages this at runtime; their absence (confirmed by actually reading the source, not by absence in the call-site HTML) means it does not.
+
+### 2. Separately verify focus management, which is easy to miss even when ARIA attributes are present
+
+A widget can have textbook-correct `role`/`aria-*` attributes and still fail if focus is never moved: a modal that sets `role="dialog"` but never calls `.focus()` on an element inside it when opened, or never restores focus to the trigger on close, is not accessible despite "having ARIA." Grep specifically for `.focus()` calls (or their absence) at the widget's open/close or activate/deactivate transitions, independent of the ARIA-attribute check in rule 1.
+
+### 3. Map each finding to the specific APG pattern for that widget type, not a generic "is it accessible" judgment
+
+"Accessible" is not a yes/no property; it is per-interaction-pattern. A datepicker's requirements (grid navigation, `aria-live` announcement of the selected date) are different from a dropdown menu's (`aria-expanded`, `aria-haspopup`, arrow-key/Escape handling) or a tooltip's (`aria-describedby`, hover *and* focus triggering, Escape dismissal). Identify which APG pattern the widget corresponds to before building the parity checklist — do not reuse one pattern's checklist for a structurally different widget.
+
+### 4. Treat "no accessibility behavior found after reading the source" as a real, reportable gap — not a reason to skip the checklist
+
+If the plugin genuinely implements nothing (common for homegrown carousels, custom tooltips, and simple show/hide toggles built directly on top of jQuery with no ARIA/keyboard code at all), report this explicitly as a pre-existing gap the migration inherits, and still produce the APG-pattern-based parity checklist so the replacement component can *close* the gap rather than silently reproduce it. Do not conflate "the legacy version was already inaccessible" with "so the new version doesn't need to be."
+
+## Minimal safe audit progression
+
+1. Identify each interactive widget being migrated and classify it against the closest W3C ARIA APG pattern (dialog, tabs, tablist, menu, menubar, combobox, listbox, slider, tooltip, disclosure, accordion, carousel, etc.).
+2. For each widget, locate the actual plugin/implementation source and grep for ARIA attribute writes, `tabindex` management, and keyboard event handlers (rule 1).
+3. Separately check focus-management calls at the widget's key state transitions (rule 2).
+4. Build a per-widget parity checklist directly from the matched APG pattern's required roles/states/properties/keyboard interactions (rule 3), marking each item as "present in legacy (verified)", "absent in legacy (confirmed gap)", or "inference — plugin source not fully readable, needs runtime confirmation".
+5. Flag any widget where the legacy implementation provides real accessibility behavior that the currently-planned replacement component does not yet account for — this is the actual migration risk this reference exists to catch.
+
+## Verification targets
+
+- Where feasible, confirm the plugin's runtime-injected ARIA/keyboard behavior against the plugin's own official documentation or changelog (version-specific — accessibility support has been added/changed across major versions of common plugins) rather than relying solely on reading one version of vendored source.
+- For focus-trap claims, confirm whether the trap covers `Tab` cycling in both directions (forward from the last focusable element wraps to the first, `Shift+Tab` from the first wraps to the last) — a common incomplete implementation traps only one direction.
+
+## When to push back
+
+Push back if the user asks to:
+
+- skip the accessibility audit for a widget because "the markup has no ARIA attributes so there's nothing to check" — this is exactly the false-negative pattern this reference exists to prevent for runtime-injected behavior,
+- declare a replacement component "equivalent" based on visual/behavioral parity alone, with no APG-pattern-based keyboard/focus/ARIA checklist,
+- treat a confirmed pre-existing accessibility gap in the legacy widget as acceptable to carry forward silently without at least flagging it as a known, inherited gap in the migration output.

package/skills/frontend/microfrontend-boundary-review/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: microfrontend-boundary-review
+description: Reviews micro-frontend/module-federation boundary contracts for shared-dependency versioning safety, runtime isolation, and ownership clarity before adoption or extension of a distributed frontend architecture.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# Micro-Frontend Boundary Review
+
+## Purpose
+
+Gate the adoption or extension of a micro-frontend / module-federation architecture on three things that determine whether it actually reduces coupling or merely relocates it: an explicit shared-dependency version-compatibility contract, a runtime-isolation level matched to each remote's data sensitivity, and unambiguous per-remote ownership with a bounded blast radius. Micro-frontends are frequently adopted to solve an organizational coupling problem (multiple teams shipping one deployable) but, done carelessly, they trade that problem for a worse one: distributed runtime coupling where one team's broken bundle or dependency bump breaks a sibling team's remote in production. This skill exists to make that trade-off explicit before it ships, not to rubber-stamp micro-frontends as a default architecture.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- adopt micro-frontends or module federation for the first time in a project that is currently a single deployable,
+- add a new remote to an existing micro-frontend host (including a third-party-built or externally-owned remote),
+- audit shared-dependency version drift across existing remotes that is causing or risks causing runtime breakage,
+- review the isolation level (iframe vs. same-runtime composition) chosen for a remote against the sensitivity of the data it handles.
+
+Do not use this skill for:
+
+- module/package boundary review within a single deployable application — that is `frontend-platform-architecture-review`,
+- reviewing whether server-side aggregation belongs in a BFF versus client-side composition — that is `frontend-bff-boundary-review`,
+- component-level React architecture (props, composition, state placement) inside one remote or host — that is `react-component-architecture-review`,
+- approving micro-frontends as a default architectural choice; this skill's default posture is to make the team justify the distributed-coupling trade-off, not to assume it is warranted.
+
+## Context7 Documentation Protocol
+
+- Resolve `/reactjs/react.dev` with `resolve-library-id` before evaluating any same-runtime composition pattern (module federation without iframes, build-time composition, or any design where a host and one or more remotes mount into the same page) that puts multiple React roots on one page or that requires the host and a remote to interoperate at runtime.
+- Query the resolved docs for `createRoot` and `useId` behavior before approving that pattern. Official React docs confirm `createRoot` is designed to be called multiple times on one page — "a page that uses 'sprinkles' of React for parts of the page may have as many separate roots as needed" — so multiple independently-mounted roots is a supported pattern, not a hack. Docs also confirm that independent React applications sharing a page must pass a distinct `identifierPrefix` to `createRoot` (or `hydrateRoot`) to prevent `useId`-generated identifier collisions between them; a same-runtime composition with two or more `createRoot` calls and no distinct `identifierPrefix` per root is a concrete, checkable defect, not a style preference.
+- React's official docs do not state a cross-major-version compatibility guarantee for multiple React copies coexisting in one page (e.g., a host on React 18 and a remote on React 19 sharing a runtime). Treat any claim that "different React versions across remotes is safe because each root is independent" as `documentation-based, unconfirmed` — flag it as a required verification item rather than asserting it is safe or unsafe from memory.
+- Where a claim depends on module-federation-tooling behavior specifically (Webpack Module Federation shared-scope negotiation, Vite plugin federation's `shared` config, singleton flags, `strictVersion` behavior), require the proposer to cite that tool's own current documentation. That tooling is outside React/Next.js core and is not assumed covered by the React docs grounding above — do not extend React-docs-grounded claims to cover federation-tool-specific version-negotiation behavior.
+- If Context7 is unavailable, state every runtime-isolation and shared-dependency claim as `documentation-based, unconfirmed` rather than asserting it from memory, and require the user to verify against the installed React version and the federation tool's current docs before treating the boundary as approved.
+
+## Lean operating rules
+
+- First establish the composition mechanism in scope (module federation, iframes, or build-time/server-side composition) — the isolation and versioning risks differ by mechanism, and advice given for one mistakenly applied to another is unreliable.
+- Determine the isolation level required from each remote's data sensitivity before reviewing anything else. A remote that renders or handles data that should not share a CSP/JavaScript-runtime trust boundary with sibling remotes needs iframe isolation or an equivalent mitigation; same-runtime composition is not a neutral default for that remote regardless of how convenient it is.
+- Do not treat "it uses module federation" as evidence of isolation. Module federation and other non-iframe composition share the same JavaScript runtime and the same CSP context across host and remotes — a vulnerability or a broken bundle in one remote can affect the host and every sibling remote sharing that runtime.
+- Require an explicit, documented shared-dependency version-compatibility policy (pinned versions, a defined compatible range, or singleton/strictVersion enforcement in the federation config) before approving adoption or a new remote. Unmanaged, unmonitored version drift across remotes is the most common cause of micro-frontend production incidents and is not acceptable as "we'll handle it if it breaks."
+- Require a bounded blast radius for every remote: an error boundary or equivalent isolation around the remote's mount point so an uncaught error or broken bundle in that remote does not take down the host or sibling remotes, and an independent deployment/rollback path so one remote's release cannot force a host-wide rollback.
+- Require unambiguous, single-team ownership per remote. A remote with shared or unclear ownership has no clear on-call responsibility when it breaks in production, which defeats the organizational-coupling benefit micro-frontends were adopted for in the first place.
+- Do not accept "micro-frontends reduce coupling" as self-evidently true. Ask what coupling moved from build-time (a monorepo/shared-deploy dependency graph, which is visible and tooling-enforced) to runtime (a shared-dependency and shared-CSP-context graph, which is often invisible until it breaks in production).
+- Never execute, build, or run application code, module-federation dev servers, or bundler configs as part of this review; this is a static-review skill (Read/Grep/Glob only) — review the composition config, shared-dependency manifest, and ownership documentation as given.
+- Treat any hardcoded credential, API key, or token found in a remote's config, shared module, or example fixture as a HIGH-severity finding requiring immediate escalation, separate from the boundary-contract verdict.
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step boundary-review procedure (isolation, versioning, ownership, blast radius) and the required output shape.
+- [Shared-runtime security and CSP boundary](references/shared-runtime-security.md) — use only when a remote handles sensitive data and same-runtime (non-iframe) composition is proposed or in place, to ground the CSP trust-boundary collapse risk and isolation mitigations.
+
+## Response minimum
+
+Return, at minimum:
+
+- the composition mechanism in scope (module federation, iframes, build-time/server-side composition) and whether it was confirmed from config or asserted by the user,
+- the isolation-level verdict for each remote in scope, matched against its data sensitivity,
+- the shared-dependency version-compatibility policy status (present/absent, and its mechanism if present),
+- the blast-radius and ownership status per remote (error-boundary/isolation mitigation present, independent deploy path present, owning team named),
+- ranked findings with file:line or config-key evidence where applicable, risk class, and fix,
+- verdict: approve / approve-with-notes / block,
+- evidence level (including whether React-version or federation-tool-version claims were confirmed or left `documentation-based, unconfirmed`) and open questions.

package/skills/frontend/microfrontend-boundary-review/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "microfrontend-boundary-review",
+  "name": "Micro-Frontend Boundary Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews micro-frontend/module-federation boundary contracts for shared-dependency versioning safety, runtime isolation, and ownership clarity before adoption or extension, grounded via Context7 against official React docs for same-runtime multi-root composition.",
+  "source_type": "original",
+  "official_docs": [
+    "https://react.dev/reference/react-dom/client/createRoot",
+    "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy",
+    "https://web.dev/articles/vitals"
+  ],
+  "security_notes": "Micro-frontend boundaries that share a JavaScript runtime (module federation, build-time composition, or any non-iframe composition) collapse the CSP trust boundary between teams' code — a vulnerability, XSS, or broken bundle in one remote can affect the host and sibling remotes sharing that runtime. Require an explicit shared-dependency version-compatibility contract and a documented blast-radius statement (error-boundary isolation, independent deploy/rollback) for any non-iframe-isolated micro-frontend adoption, and require iframe isolation or an equivalent mitigation for any remote handling data that should not share a trust boundary with lower-trust remotes. Static-review-only skill: it reads and greps composition config and does not execute, build, or run application code, dev servers, or bundler configs. Treat any hardcoded credential, API key, or token found in a remote's config or example fixture as a HIGH-severity finding requiring immediate escalation.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/microfrontend-boundary-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/microfrontend-boundary-review/references/shared-runtime-security.md

@@ -0,0 +1,50 @@
+# Shared-runtime security and CSP boundary
+
+Use this reference only when a remote in scope handles sensitive data and same-runtime (non-iframe) composition is proposed or already in place. It grounds the CSP trust-boundary collapse risk that makes "we used module federation" an insufficient answer to "is this isolated."
+
+## What people get wrong
+
+The naive story is:
+
+> Module federation loads remote code into my app via a script tag, same as any other bundle-splitting technique. That's just how modern frontend works — it's not a security boundary question.
+
+Wrong. A `<script>`-loaded remote, whether fetched via module federation, dynamic `import()`, or any other non-iframe mechanism, executes in the same JavaScript realm as the host: same `window`, same DOM, same Content-Security-Policy context, same cookies and storage the host can reach. There is no process boundary and no origin boundary unless one is deliberately introduced. "It's just code splitting" is true from a bundler's perspective and false from a trust-boundary perspective — those are different questions with different answers.
+
+## Officially grounded shape
+
+- CSP (per MDN) is enforced per browsing context / document, not per script origin within that document. A single CSP header applies to the entire page — host and every same-runtime remote share it. A remote that needs a looser policy (e.g., to run its own inline styles or connect to its own API) cannot get one without loosening the policy for the host and every sibling remote, unless that remote is isolated into its own document (an iframe with its own CSP).
+- An iframe, by contrast, is a separate browsing context with its own document and can carry its own CSP (via the iframe's own response headers, or constrained further by the host's `Content-Security-Policy: frame-src`/`child-src` and the iframe's `sandbox` attribute). This is the mechanism that actually creates an enforceable boundary between host and remote, not module federation's build-time module resolution.
+- React's official docs confirm `createRoot` supports mounting multiple independent applications into one page (see `references/../SKILL.md` Context7 Documentation Protocol), which is the mechanism most same-runtime micro-frontend compositions use — this confirms the *mounting* pattern is supported, but says nothing about *security isolation* between those roots, because there is none by default: all roots share one JS realm.
+
+## Non-negotiable design rules
+
+1. **Isolation level is a data-sensitivity decision, not a tooling decision.** Do not let the choice of module federation vs. iframes be driven by developer convenience or performance preference alone when a remote handles data (payment details, PII, credentials, admin actions) that should not be reachable by a compromised or buggy sibling remote. Convenience does not override trust-boundary requirements.
+
+2. **A compromised or buggy same-runtime remote can read/write anything the host can.** This includes DOM access to sibling remotes' rendered output, cookies and localStorage/sessionStorage the host has access to, and any global state or event bus shared across the composition. Treat a same-runtime remote as having the same privilege as the host itself, not a scoped subset of it.
+
+3. **Third-party-owned or externally-built remotes are a stronger case for iframe isolation**, independent of data sensitivity, because the supply-chain trust level of the remote's build pipeline is not controlled by the host team. A remote built and deployed by a team outside the organization's own release process should default to iframe isolation unless there is a specific, documented reason and compensating control (e.g., contractual code-review gate, pinned immutable artifact, subresource integrity) to trust it in the shared runtime.
+
+4. **Shared-dependency version drift is itself a security surface**, not just a stability one. An outdated shared dependency pulled in by version-range negotiation (rather than pinning) can reintroduce a patched vulnerability across the entire composition, and the host team may have no visibility into which remote's dependency requirement caused the downgrade.
+
+## High-risk assumptions to kill
+
+- "Module federation isolates the remote because it's a separate bundle." — False; bundle separation is a build-time concept, not a runtime trust boundary.
+- "The remote only touches its own DOM subtree, so it can't affect the rest of the page." — False by default; nothing prevents a same-runtime remote's script from reaching outside its mount point unless the host specifically constrains it (and few do).
+- "We trust the other team, so isolation doesn't matter." — Trust in a team does not substitute for isolation against a supply-chain compromise of that team's dependencies or build pipeline.
+- "CSP is already strict, so we're covered." — A strict host-level CSP still applies uniformly to every same-runtime remote; it does not give any one remote a tighter or differently-scoped policy than the rest of the page.
+
+## Safe verification targets
+
+- The response headers actually served for the host document — confirm the CSP header text, not a policy described in a design doc.
+- Whether any remote requiring isolation is served inside an `<iframe>` with its own `sandbox` attribute and (where relevant) its own CSP header, versus mounted via same-runtime `createRoot`/module federation.
+- The federation config's `shared` block or equivalent, to confirm whether shared dependencies are pinned/singleton-enforced or resolved via an unpinned version range.
+
+## When to push back
+
+Push back if the user asks for:
+
+- same-runtime composition for a remote handling payment, auth, or other sensitive data with no isolation mitigation and no documented compensating control,
+- trusting a third-party-owned remote in the shared runtime solely because "we trust that vendor," with no supply-chain control (pinning, integrity checks, review gate) backing that trust,
+- treating an unpinned shared-dependency version range as acceptable because "it hasn't broken yet."
+
+Those are not pragmatic trade-offs. They are unreviewed risk acceptance dressed up as an architecture decision.

package/skills/frontend/microfrontend-boundary-review/references/workflow-and-output.md

@@ -0,0 +1,45 @@
+# Review workflow and findings contract
+
+Use this reference for the step-by-step boundary-review procedure and the required output shape for any micro-frontend adoption review, new-remote addition, or existing-composition audit.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "We're using module federation, so the frontend is already decoupled — this review is a formality."
+
+That is backwards. Module federation (and most non-iframe composition mechanisms) decouple the *build*, not the *runtime*. Host and remotes still share one JavaScript execution context, one CSP context, and — unless explicitly pinned or negotiated — a dependency graph that can silently drift out of compatibility. The review exists precisely because "we already use the right tooling" is not the same claim as "the boundary is safe."
+
+## Step-by-step workflow
+
+1. **Classify the composition mechanism.** Determine whether the architecture uses module federation (Webpack Module Federation, Vite plugin federation, or similar), iframe-based composition, or build-time/server-side composition (e.g., server-side includes, build-time module stitching). Do not proceed with mechanism-specific advice until this is confirmed from config, not assumed from the user's description alone.
+
+2. **Determine the isolation level required per remote.** For each remote in scope, ask: does it render or handle data that should not be visible to, or influenced by, a bug or compromise in a sibling remote? If yes, same-runtime composition is disqualified unless a documented, specific mitigation is in place (e.g., a dedicated CSP frame-ancestors/sandboxed iframe for that one remote, or a Trusted Types policy scoped to it).
+
+3. **Review the shared-dependency contract.** Locate the federation config's `shared` block (or equivalent for build-time composition) and check for: pinned or ranged version requirements, `singleton`/`strictVersion`-style enforcement (tool-specific — verify against that tool's current docs, not assumed from React docs), and whether version mismatches fail the build/fail loudly at runtime or fail silently (multiple copies of a library loaded, or an incompatible version silently used).
+
+4. **Confirm ownership is unambiguous.** Every remote must map to exactly one owning team with clear on-call responsibility. A remote with co-ownership, no documented owner, or an owner that is "whoever last touched it" is a blocking finding, not a note.
+
+5. **Assess blast radius.** For each remote, determine what happens to the host and sibling remotes if this remote throws an uncaught error, fails to load, or ships a broken bundle. Look for an error boundary (or equivalent isolation mechanism) around each remote's mount point, and confirm each remote has an independent deployment and rollback path that does not require a host-wide release.
+
+6. **Check same-runtime multi-root hygiene, if applicable.** If the composition mounts multiple independent applications into one page (e.g., multiple `createRoot` calls, one per remote), confirm each root passes a distinct `identifierPrefix` to prevent `useId`-generated identifier collisions across independently-owned code — this is a concrete, checkable defect per official React docs, not a stylistic nit.
+
+7. **Issue a verdict** using the response-minimum contract below.
+
+## Required output shape
+
+Every response to a micro-frontend boundary review must include:
+
+- **Composition mechanism** — module federation / iframes / build-time-server-side, and whether this was confirmed from config or asserted by the user.
+- **Isolation verdict per remote** — matched explicitly against that remote's data sensitivity; state which remotes require iframe-or-equivalent isolation and whether that mitigation exists.
+- **Shared-dependency policy status** — present or absent; if present, its mechanism (pinned versions, `singleton`, `strictVersion`, or equivalent) and whether mismatches fail loudly or silently.
+- **Blast-radius and ownership status per remote** — error-boundary/isolation mitigation present, independent deploy/rollback path present, owning team named.
+- **Ranked findings** — file:line or config-key evidence where applicable, risk class (isolation gap, versioning gap, ownership gap, blast-radius gap), and a concrete fix.
+- **Verdict** — approve / approve-with-notes / block.
+- **Evidence level** — `live evidence` (read from actual config/source), `user-provided evidence` (asserted by the user without config to confirm), `documentation-based` (React/CSP/tooling docs grounding a claim), or `documentation-based, unconfirmed` (a claim the official docs do not explicitly confirm, e.g. cross-major-version React compatibility across remotes) — plus open questions the proposer must answer before the boundary can be considered fully reviewed.
+
+## Verification targets
+
+- The federation config's `shared` block (or build-time composition manifest) — the source of truth for the version-compatibility policy, not the proposer's verbal description of it.
+- The mount-point code for each remote — to confirm an error boundary or equivalent isolation wraps it, not just that one exists "somewhere."
+- The deployment pipeline configuration — to confirm each remote's independent deploy/rollback path actually exists as a distinct pipeline stage or repository, not merely as an intention.

package/skills/frontend/monorepo-package-governance-review/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: monorepo-package-governance-review
+description: Reviews monorepo task-graph configuration (Turborepo tasks/caching, Nx task pipelines) alongside dependency and lockfile governance (pnpm catalogs, npm overrides, lifecycle-script risk) to prevent false-green CI from stale cache reuse and unpinned supply-chain exposure.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.2.0"
+  updated: "2026-07-03"
+  category: platform
+---
+
+# Monorepo & Package Governance Review
+
+## Purpose
+
+Monorepo tooling and dependency governance fail together more often than separately: a missing task-graph edge lets a stale build pass CI, and an unpinned dependency range lets that same task silently resolve a different, possibly compromised, package version next time. This skill reviews both the task graph (Turborepo/Nx) and the dependency/lockfile layer (pnpm catalogs, npm overrides, lifecycle scripts) as one governance surface, without stuffing bundler internals, framework-specific build guidance, or CI-vendor setup into every prompt.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review `turbo.json` (`tasks`, `dependsOn`, `inputs`, `outputs`, `env`) or `nx.json` (`targetDefaults`, `namedInputs`) task-graph configuration,
+- diagnose a false-green CI result where a task passed despite a real upstream code change (stale cache reuse),
+- review `package.json`/lockfile version-pin policy, pnpm `catalog`/`catalogs`, or npm `overrides`/`resolutions`,
+- audit lifecycle scripts (`postinstall`/`preinstall`/`prepare`) introduced by a new or bumped dependency,
+- consolidate duplicate/drifted dependency versions across monorepo packages,
+- review remote-cache (Turborepo Remote Cache / Nx Cloud) token handling in CI config,
+- audit `.npmrc` scope-to-registry mappings for scoped internal packages (dependency-confusion exposure), verify `package-lock.json` is committed and CI enforces a frozen install (`npm ci`, not `npm install`), or review lifecycle-script (`postinstall`/`preinstall`/`prepare`) allowlisting for a new dependency.
+
+## Lean operating rules
+
+- Classify the monorepo tool in scope first (Turborepo vs Nx vs plain npm/pnpm workspaces) from actual config files present (`turbo.json`, `nx.json`, `pnpm-workspace.yaml`) — do not assume tooling from the user's phrasing alone.
+- Trace every cross-package build/test task dependency to its actual `dependsOn` (Turborepo) or `targetDefaults`/`dependsOn` (Nx) edge; a task that consumes another package's build output without a graph edge is a false-green risk, not a style nit.
+- Check that cache `inputs` (Nx `namedInputs`) and `env`/`globalEnv` (Turborepo) include every file and environment variable that actually affects a task's output; an incomplete cache key is a correctness bug that manifests as a stale pass, not merely a performance issue.
+- Note that Turborepo's legacy `pipeline` key was renamed to `tasks`; flag `pipeline` usage as needing a version check, not silent modernization, since the correct key depends on the installed Turborepo major version.
+- Treat any lockfile change unaccompanied by a matching `package.json`/`pnpm-workspace.yaml` change (or vice versa) as suspicious and requiring explanation before approval.
+- Require pinning or `catalog:`/npm `overrides` consolidation for security-sensitive or high-blast-radius dependencies; do not blanket-require exact pins if the team runs a working Renovate/Dependabot auto-merge policy with CI gating — ask before assuming the policy is absent.
+- Flag any new dependency's `postinstall`/`preinstall`/`prepare` script by quoting its actual script content from `package.json`, not by assuming intent from the package name alone.
+- Verify current pnpm `catalog:`/`catalogs:` syntax and Turborepo/Nx task-config key names against Context7-sourced docs before recommending a diff, since these keys and defaults have changed across major versions (see Context7 Documentation Protocol below).
+- Load only the reference needed for the component in scope; do not dump both the task-graph and dependency-governance reference into a single-focus review.
+
+## Context7 Documentation Protocol
+
+Before making any version-specific claim about Turborepo (`tasks` vs legacy `pipeline`, `dependsOn` semantics, `inputs`/`outputs`/`env`/`globalEnv` behavior, Remote Cache auth), Nx (`targetDefaults`, `namedInputs`, `dependsOn`, `nx.json` vs per-project `project.json`/`package.json` `nx` block), pnpm (`catalog`/`catalogs` syntax in `pnpm-workspace.yaml`, the `catalog:` protocol in `overrides`), or npm registry/supply-chain behavior (`.npmrc` scope-to-registry mapping, `npm ci` vs `npm install` frozen-install semantics, `allowScripts`/`npm approve-scripts` lifecycle-script gating):
+
+1. Call `mcp__Context7__resolve-library-id` for the library in scope (`Turborepo`, `Nx`, `pnpm`, or `npm`) if not already resolved in this session.
+2. Call `mcp__Context7__query-docs` with a specific query naming the exact config key or behavior in question (for example: "turbo.json tasks dependsOn env cache hash", "nx.json targetDefaults namedInputs", "pnpm-workspace.yaml catalog catalogs syntax", "npmrc scope registry mapping allowScripts npm ci").
+3. Prefer the result over training-data recall — config key names and defaults have changed across major versions of all three tools.
+4. If Context7 is unavailable or returns no relevant result, state the claim as `documentation-based (unverified this session)` and recommend the user confirm against the installed tool version's own docs before applying any diff.
+5. Never invent a config key, CLI flag, or default value that Context7 did not return or that is not directly visible in the repo's own config file.
+
+## References
+
+Load these only when needed:
+
+- [Task-graph review](references/task-graph-review.md) — use for `turbo.json`/`nx.json` false-green diagnosis: missing `dependsOn` edges, incomplete cache `inputs`/`env`, and legacy `pipeline` vs `tasks` drift.
+- [Dependency and lockfile governance](references/dependency-lockfile-governance.md) — use for pnpm `catalog`/`catalogs`, npm `overrides`, lockfile/package.json mismatch, and lifecycle-script (`postinstall`) risk review.
+- [npm supply-chain governance](references/npm-supply-chain-governance.md) — use for dependency-confusion review of `.npmrc` scope-to-registry mappings, unscoped registry auth tokens, `package-lock.json` commitment/frozen-install (`npm ci`) enforcement, and `allowScripts` lifecycle-script gating for new/bumped dependencies.
+
+## Response minimum
+
+Return, at minimum:
+
+- whether the finding is task-graph (false-green risk), dependency-version (supply-chain/reproducibility risk), or both,
+- exact missing edge / cache-key gap / unpinned range with file and line citation,
+- evidence level (`live repo evidence`, `documentation-based`, or `inference`) and the Turborepo/Nx/pnpm version the guidance targets,
+- proposed config diff (not applied — this skill is static-review-only),
+- security caveat on any lifecycle script or committed token found, and a rollback/verification note (for example, which command to run locally to confirm the cache-key fix produces a miss on the affected change).

package/skills/frontend/monorepo-package-governance-review/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "monorepo-package-governance-review",
+  "name": "Monorepo & Package Governance Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews monorepo task-graph configuration (Turborepo/Nx) and dependency/version governance (pnpm catalogs, npm overrides, lockfile integrity) together to stop false-green CI cache reuse and unpinned supply-chain exposure, with config-key claims grounded in Context7-sourced docs and progressive reference loading. Also covers npm dependency-confusion review: .npmrc scope-to-registry mapping, package-lock.json commitment/frozen-install (npm ci) enforcement, and allowScripts lifecycle-script gating.",
+  "source_type": "original",
+  "official_docs": [
+    "https://turborepo.com/docs/crafting-your-repository/configuring-tasks",
+    "https://turborepo.com/docs/crafting-your-repository/caching",
+    "https://nx.dev/concepts/task-pipeline-configuration",
+    "https://pnpm.io/catalogs",
+    "https://pnpm.io/pnpm-workspace_yaml",
+    "https://github.com/npm/cli/blob/latest/docs/lib/content/using-npm/scope.md",
+    "https://github.com/npm/cli/blob/latest/docs/lib/content/configuring-npm/npmrc.md",
+    "https://github.com/npm/cli/blob/latest/docs/lib/content/commands/npm-ci.md",
+    "https://github.com/npm/cli/blob/latest/docs/lib/content/commands/npm-approve-scripts.md"
+  ],
+  "security_notes": "Static-review-only skill: reads and greps turbo.json, nx.json, package.json, pnpm-workspace.yaml, .npmrc, and lockfiles but never runs install, build, or CI commands. Remote-cache and registry auth tokens must be CI-scoped secrets, never committed to turbo.json/nx.json/.npmrc; any token-shaped literal found in a config file is an automatic blocking finding, and any .npmrc credential key (_auth/_authToken/_password/etc.) not scoped to a specific registry host/path is a blocking finding regardless of the token's live validity. Any dependency lifecycle script (postinstall/preinstall/prepare) introduced in the same PR as a workspace-topology change warrants extra scrutiny and must be quoted verbatim in the finding, not summarized from the package name; cross-reference it against the root package.json's allowScripts field. A scoped package (@scope/name) referenced in package.json with no matching @scope:registry mapping in .npmrc is a dependency-confusion finding.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/monorepo-package-governance-review",
+  "author": "github: Raishin",
+  "version": "0.2.0"
+}

package/skills/frontend/monorepo-package-governance-review/references/dependency-lockfile-governance.md

@@ -0,0 +1,82 @@
+# Dependency and Lockfile Governance
+
+Use this reference for reviewing dependency version policy, pnpm catalogs, npm overrides, lockfile/manifest consistency, and lifecycle-script risk in a monorepo workspace.
+
+> Version note: pnpm `catalog`/`catalogs` syntax and the `catalog:` protocol are documented at `pnpm.io/catalogs` and `pnpm.io/pnpm-workspace_yaml`. Confirm the installed pnpm major version supports catalogs (a relatively recent feature) via Context7 before recommending a migration to it.
+
+## What people get wrong
+
+The naive story is:
+
+> "The lockfile is just an implementation detail; reviewing `package.json` is enough."
+
+Wrong. A `package.json` range like `^4.2.0` and a lockfile pinned to `4.2.0` can silently diverge from what actually gets installed the next time `install` runs without `--frozen-lockfile` (or the pnpm/npm equivalent). Dependency governance review has at least three separate concerns, and collapsing them into "check package.json" misses two of the three:
+
+1. **declared range** — what `package.json` (or a pnpm catalog entry) says is acceptable,
+2. **resolved version** — what the lockfile actually pins right now,
+3. **install-time behavior** — whether CI enforces the lockfile (frozen install) or silently re-resolves and drifts.
+
+## Officially grounded shape
+
+From pnpm docs (`catalogs`, `pnpm-workspace_yaml`, `settings`):
+
+- `pnpm-workspace.yaml` top-level `catalog:` defines a default catalog of shared dependency versions, referenced in any package's `package.json` via the `catalog:` protocol (or `catalog:default` explicitly).
+- `catalogs:` (plural) defines named catalogs (e.g., `react17`, `react18`) for cases where different packages in the workspace intentionally need different major versions of the same dependency during a migration.
+- The `catalog:` protocol can also be used inside `pnpm-workspace.yaml`'s own `overrides` block (`overrides: { foo: "catalog:" }`) to force a single resolved version workspace-wide while keeping the source of truth in one catalog entry.
+- Catalogs solve version **drift** (same dependency, different ranges in different packages) but do not by themselves solve version **pinning** (exact vs range) — those are separate governance questions.
+
+npm's dependency-governance primitives (`overrides` in `package.json`, `resolutions` in Yarn) serve a similar drift-consolidation role but operate differently: `overrides` forces a resolved version across the entire tree regardless of what nested dependencies request, which can mask a legitimate need for two different major versions if applied too broadly.
+
+## Non-negotiable design rules
+
+### 1. Lockfile changes must be explainable by a manifest change
+
+If a lockfile diff shows resolved-version changes with no corresponding `package.json`/`pnpm-workspace.yaml` diff, treat that as suspicious until explained (could be a legitimate transitive-dependency update from a fresh `install`, or could indicate an out-of-band lockfile edit or a compromised registry response). Ask for the `install` command/log that produced the diff before approving.
+
+### 2. Catalog/override consolidation is a security control, not just tidiness
+
+Multiple packages independently specifying loose ranges (`^4.0.0`) for the same security-sensitive dependency means each package can independently resolve to a different patch/minor version over time, widening the set of versions that must be trusted. Consolidating via a pnpm catalog entry or npm `overrides` forces one resolved version, shrinking the audit surface — recommend this specifically for auth, crypto, or serialization libraries, not indiscriminately for every dependency.
+
+### 3. Pinning policy depends on the team's automation, not a blanket rule
+
+Do not require exact-version pins (`4.2.0` instead of `^4.2.0`) unless asked, unless the dependency is security-sensitive, or unless there is no automated update+CI-gate pipeline (Renovate/Dependabot with required status checks) in place. A team with working automated updates and a frozen-lockfile CI gate already has reproducibility; blanket exact-pinning there adds churn without adding safety. Ask about the update-automation setup before recommending a pinning policy change.
+
+### 4. Lifecycle scripts are quoted, not summarized
+
+When a new or bumped dependency introduces a `postinstall`, `preinstall`, or `prepare` script, quote the script's actual content from the dependency's `package.json` (or lockfile-recorded script) in the finding. Do not infer safety or danger from the package name or its stated purpose — a script literally reading `node scripts/postinstall.js` requires opening that file, not accepting the name as self-explanatory.
+
+### 5. Frozen installs are the enforcement mechanism — verify CI actually uses one
+
+A correct lockfile is meaningless if CI runs a non-frozen install (allowing silent re-resolution). Check the CI workflow for the frozen-install flag appropriate to the package manager (e.g., pnpm's `--frozen-lockfile`, npm's `ci` command) before concluding that lockfile governance is actually enforced end-to-end.
+
+## Minimal safe review flow
+
+1. Identify the package manager and workspace layout (`pnpm-workspace.yaml`, npm/yarn `workspaces` field in root `package.json`).
+2. For the dependency/package in scope, compare the declared range(s) across every package that references it — flag drift (same dependency, different ranges, no catalog/override tying them together).
+3. Cross-check the lockfile's resolved version(s) against declared ranges; flag any resolved version outside a declared range (should not normally happen, but indicates a manifest/lockfile edit order-of-operations problem) and any case with multiple distinct resolved versions for what should be one consolidated dependency.
+4. For any new/bumped dependency in the diff, check its `package.json` for `postinstall`/`preinstall`/`prepare` and quote the script content verbatim if present.
+5. Check the CI workflow for a frozen/`ci`-style install command; flag if absent.
+6. Report findings with exact file:line citations; propose the catalog/override/pin diff without applying it.
+
+## Adversarial checklist
+
+Before recommending a dependency-governance change, answer these:
+
+- Does the lockfile diff have a corresponding manifest diff, or is it unexplained?
+- For the dependency being consolidated, is there a legitimate reason two packages need different major versions (active migration), or is the split accidental drift?
+- Does CI actually enforce the lockfile with a frozen-install flag, or can a fresh `install` silently re-resolve?
+- If a lifecycle script is present, have I read its actual content, not just its filename?
+- Is the pinning policy I'm recommending consistent with whether this team already runs automated dependency updates with CI gating?
+
+If you cannot answer these from repo evidence, say so rather than issuing a blanket pinning recommendation.
+
+## When to push back
+
+Push back if the user asks to:
+
+- "just pin everything to exact versions" without checking whether an update-automation + CI-gate pipeline already provides reproducibility — this trades update velocity for a pinning policy that may not add real safety,
+- consolidate every dependency into one catalog entry regardless of legitimate multi-version migration needs (e.g., forcibly unifying `react17`/`react18` catalogs mid-migration),
+- accept a lockfile diff with no explainable manifest change "because CI passed" — a passing CI run does not prove the lockfile change was legitimate, only that the resolved versions installed successfully,
+- ignore a `postinstall` script because "it's a well-known package" — package reputation does not substitute for reading the actual script content in the version being introduced.
+
+Those are not shortcuts. They trade a diagnosable supply-chain question for an assumption that will not hold under a compromised-dependency scenario.