mustflow 2.39.1 → 2.58.1

package/templates/default/locales/en/.mustflow/skills/file-upload-security-review/SKILL.md

@@ -0,0 +1,305 @@
+---
+mustflow_doc: skill.file-upload-security-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: file-upload-security-review
+description: Apply this skill when code is created, changed, reviewed, or reported and file upload, import, attachment, direct-to-storage upload, remote file fetch, archive extraction, thumbnailing, preview generation, image resizing, document conversion, virus scanning, CDR, file metadata, storage keys, public file URLs, signed upload or download URLs, CDN delivery, file download, uploaded filename display, or upload-related tests need security review across the full file lifecycle.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.file-upload-security-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - test_audit
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# File Upload Security Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review file upload security as a full lifecycle, not as an extension or MIME-type checklist.
+
+The review question is not "does the upload route block `.exe`?" It is "what final bytes, filename,
+storage key, parser, visibility state, authorization check, and response headers can this uploaded
+file reach after it enters the system?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code review, implementation, refactor, docs, tests, or reports touch file uploads, imports,
+  attachments, avatars, media libraries, document intake, CSV import or export, remote URL import,
+  direct-to-object-storage uploads, signed upload URLs, signed download URLs, file downloads,
+  thumbnails, previews, image resizing, metadata extraction, OCR, archive extraction, document
+  conversion, antivirus scanning, CDR, storage key generation, CDN delivery, file cleanup, or file
+  visibility states.
+- A request, form, client state, queue payload, webhook, storage callback, or object metadata
+  supplies a filename, extension, MIME type, content type, path, folder, key, bucket, URL, callback
+  URL, content disposition, size, checksum, tenant id, project id, upload id, or visibility flag.
+- A review needs security coverage for dangerous file types, path traversal, web-root execution,
+  parser exploits, SVG or HTML rendering, PDF or Office active content, archive extraction, CSV
+  formula injection, direct-to-storage race conditions, presigned URL policy, storage overwrite,
+  download authorization, response headers, filename injection, resource exhaustion, or upload
+  denial-case tests.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only general source-to-sink security review beyond files; use `security-flow-review`.
+- The task primarily changes API authorization, route guards, role models, or tenant policy; use
+  `api-access-control-review` or `auth-permission-change` first, then this skill for file-specific
+  surfaces.
+- The task primarily models upload states, retries, or processing lifecycle transitions; use
+  `state-machine-pattern` first, then this skill for security-specific file handling.
+- The task primarily changes file metadata persistence, storage/database consistency, or cleanup
+  rules; use `database-change-safety` or `adapter-boundary` first when those are the owning concern.
+- The task asks for live exploit traffic, malware collection, credentialed cloud testing, or unsafe
+  payload corpus generation. Stay within defensive local code review, safe fixtures, and configured
+  tests.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- User goal, current diff or target files, upload surface, and the file security claim being
+  reviewed.
+- Upload entrypoint ledger: routes, controllers, forms, mobile clients, SDK calls, GraphQL
+  mutations, direct-to-storage URL issuers, storage callbacks, remote URL importers, batch imports,
+  admin tools, and test helpers that can create or attach files.
+- File identity ledger: original filename, normalized filename, final storage key, bucket or root,
+  database record id, tenant or owner, checksum, size, content type, detected type, extension,
+  visibility, status, and cleanup owner.
+- Validation ledger: extension allowlist, decoding and normalization, content-type trust, signature
+  checks, parser-based validation, image rewriting, metadata stripping, antivirus, CDR, size limits,
+  count limits, quota, rate limits, and failure behavior.
+- Processing ledger: thumbnailing, preview, image resize, OCR, PDF parsing, Office conversion,
+  archive extraction, CSV handling, media transcoding, scanner execution, queue jobs, retries,
+  sandboxing, timeout, memory, CPU, network, and privilege limits.
+- Serving ledger: download authorization, signed URLs, CDN cache, response `Content-Type`,
+  `Content-Disposition`, `X-Content-Type-Options`, CSP or origin isolation, filename display, logs,
+  admin preview, email attachments, and public/private transition.
+- Existing tests, abuse cases, security docs, storage policy docs, configured command intents, and
+  any unavailable cloud or scanner evidence.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the
+  current scope.
+- Required inputs are available, or missing filename, key, parser, visibility, authorization,
+  storage, scanner, or serving evidence can be reported without guessing.
+- Treat client-provided filename, extension, MIME type, path, bucket, key, URL, size, checksum,
+  tenant, owner, and visibility as untrusted until server-side evidence proves otherwise.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten server-side file type allowlists, decoded and normalized filename checks, generated
+  storage keys, path containment checks, overwrite protection, upload size and count limits, quota
+  checks, quarantine states, scanner gates, parser sandboxing, archive extraction guards, CSV formula
+  neutralization, metadata stripping, image rewriting, signed URL constraints, download
+  authorization, response headers, filename encoding, audit logs, cleanup rules, and focused
+  denial-case tests.
+- Update storage docs, security docs, API examples, role matrices, fixtures, template surfaces, and
+  package tests that describe the same file lifecycle contract.
+- Keep changes scoped to file upload, file processing, and file serving boundaries.
+- Do not add broad malware scanners, live external probes, dependency installs, production storage
+  operations, offensive payload collections, or unrelated hardening work under this skill.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Draw the file lifecycle before judging the first check.
+   - Name each step from upload entrypoint to final serving path: receive, normalize, validate,
+     store, record metadata, scan, transform, promote, preview, download, delete, and cleanup.
+   - Include admin preview, email attachment, export, CDN, search index, and worker paths when they
+     can read the uploaded bytes.
+2. Treat frontend restrictions as usability only.
+   - `<input accept>`, client-side size checks, mobile picker filters, and JavaScript extension
+     checks do not prove security.
+   - Require equivalent server-side validation or report the boundary gap.
+3. Decode and normalize before extension checks.
+   - Check URL encoding, repeated decoding, case, trailing dots or spaces, Unicode confusables,
+     null-like separators, double extensions, and platform-specific separators before extension
+     allowlist decisions.
+4. Prefer allowlists over blocklists.
+   - Business-required file types should be explicit.
+   - Blocklists for `.php`, `.jsp`, `.asp`, `.html`, `.svg`, config files, legacy plugin types, or
+     executable server extensions are not enough by themselves.
+5. Validate the final storage name and key, not only the original filename.
+   - Confirm the server generates the stored basename, object key, upload id, and path.
+   - Treat `destination`, `folder`, `key`, `path`, `filename`, `bucket`, and callback-provided
+     storage locations as attacker-controlled unless derived on the server.
+6. Prove path containment after normalization and symlink resolution.
+   - `path.join(uploadDir, userName)` is not enough.
+   - Check real path containment, absolute paths, drive letters, backslashes, `..`, symlinks,
+     hardlinks, case-insensitive filesystems, and reserved names when local files are used.
+7. Bound filenames and storage keys.
+   - Check filename length, full path length, database column length, object-storage key length, log
+     field length, CDN cache-key length, and error behavior for oversized or malformed names.
+8. Prevent overwrite and key guessing.
+   - Check duplicate names, fixed keys such as `avatar.png`, public key predictability, tenant key
+     collisions, and presigned upload reuse.
+   - Existing object replacement should require an explicit server-side policy and authorization.
+9. Keep uploaded bytes outside executable web roots.
+   - Prefer private object storage or a non-executable file root served through an authorized
+     application handler.
+   - Check web server handlers for PHP, CGI, ASP.NET, JSP, SSI, `.htaccess`, `web.config`, and
+     similar config-file replacement paths.
+10. Do not trust request MIME labels.
+    - `Content-Type`, `file.mimetype`, `$_FILES['type']`, and client metadata are claims, not
+      evidence.
+    - Compare them with detected type only as a signal, never as the only security decision.
+11. Treat magic bytes as necessary but not sufficient.
+    - Polyglot files, metadata payloads, trailing content, and container formats can pass simple
+      signature checks while still reaching dangerous parsers.
+12. Re-encode images when possible.
+    - Decode and write a new image instead of storing user bytes directly when the product only
+      needs raster images.
+    - Strip EXIF, comments, thumbnails, ICC surprises, and other metadata unless product policy
+      intentionally preserves them.
+13. Treat SVG and HTML as active content.
+    - Do not group SVG with ordinary raster images.
+    - If SVG is allowed, require sanitization or rasterization, separate origin or strict CSP,
+      attachment disposition, external reference controls, and download/header review.
+14. Treat PDF and Office documents as active document bundles.
+    - Check macros, embedded objects, JavaScript, external links, parser vulnerabilities, preview
+      isolation, antivirus or CDR, and whether downloads are safer than inline rendering.
+15. Review archive extraction as the main feature.
+    - For ZIP, tar, and nested archives, validate every entry path after normalization and prove it
+      stays inside the extraction root.
+    - Bound extracted file count, total uncompressed bytes, compression ratio, nesting depth,
+      symlinks, hardlinks, absolute paths, duplicate entries, and processing time.
+16. Review CSV import and export for formula injection.
+    - If user-supplied cells may later be opened in spreadsheets, handle cells beginning with `=`,
+      `+`, `-`, `@`, tabs, carriage returns, line feeds, separators, quotes, and confusable
+      variants according to local policy.
+17. Review remote URL import as SSRF plus upload.
+    - Check scheme allowlists, redirect chains, DNS rebinding, localhost, private networks,
+      link-local metadata endpoints, non-HTTP schemes, credential forwarding, response size,
+      timeout, and final file validation.
+18. Keep scanner and conversion work behind a publication gate.
+    - A file that is pending scan, failed scan, pending conversion, or failed conversion should not
+      be public, previewable, downloadable, indexed, or emailed unless policy explicitly allows it.
+19. Sandbox file parsers and scanners.
+    - ImageMagick, ffmpeg, LibreOffice, PDF parsers, OCR tools, unzip, antivirus, and CDR engines
+      need low privilege, no unnecessary network, timeouts, memory and CPU limits, temporary
+      directory isolation, and controlled input paths.
+20. Validate direct-to-storage uploads in two phases.
+    - Before issuing a signed upload URL, authorize the target resource and fix method, bucket, key,
+      prefix, content type policy, checksum, size range, overwrite policy, and expiration.
+    - After upload completion, verify actual object metadata before promoting it out of quarantine.
+21. Treat presigned URLs as delegated authority.
+    - Check method, bucket, key, prefix, expiry, reuse, checksum, content-length range, content type,
+      ACL or public-read flags, revocation behavior, CDN caching, and whether the creator's
+      privileges are too broad.
+22. Enforce tenant boundaries in storage keys and metadata.
+    - Server-generated keys should include trusted tenant, organization, project, or resource
+      context plus a random id when multi-tenant isolation matters.
+    - Reads, writes, deletes, overwrites, cleanup, and promotion must use the same boundary.
+23. Recheck authorization at download and preview time.
+    - Upload permission is not download permission.
+    - Check owner, tenant, project membership, billing or entitlement state, deleted state, scanner
+      state, visibility, share links, admin scope, and service-account scope before serving bytes.
+24. Set response headers deliberately.
+    - Use safe `Content-Type`; default ambiguous private downloads to `application/octet-stream`.
+    - Use `Content-Disposition: attachment` when inline rendering is not required.
+    - Add `X-Content-Type-Options: nosniff` and review CSP, origin isolation, and CDN header
+      preservation where browser execution risk exists.
+25. Treat filename display as an injection surface.
+    - Escape original filenames in HTML, email, admin tables, JSON-in-script, logs, and support
+      views.
+    - For `Content-Disposition`, remove CR/LF and encode filenames safely for header context.
+26. Apply resource limits at every layer.
+    - Bound request body size, per-file size, file count, concurrent uploads, chunk count, multipart
+      sessions, user quota, tenant quota, daily quota, extracted size, transformed size, preview
+      time, and retry volume.
+27. Revalidate chunked and multipart uploads at assembly time.
+    - Check final file size, content type, signature, chunk order, chunk count, checksum, session
+      expiration, stale partial cleanup, and final key ownership after assembly.
+28. Review upload endpoint auth, CSRF, and rate limits.
+    - Browser-cookie upload endpoints need CSRF posture.
+    - Import, admin upload, remote fetch, and chunk completion endpoints need authentication,
+      authorization, anti-automation controls, and audit logs.
+29. Check storage cleanup without breaking authorization.
+    - Find orphaned objects, database rows without objects, failed conversions, stale quarantine,
+      abandoned multipart uploads, deleted records waiting for physical removal, and public CDN
+      cache invalidation.
+30. Test denial cases from the attacker's path.
+    - Cover disallowed type, spoofed MIME, renamed extension, encoded extension, double extension,
+      oversize body, quota exceeded, path traversal, archive escape, zip bomb, SVG active content,
+      CSV formula, unauthorized upload target, unauthorized download, pending-scan download,
+      presigned overwrite, stale multipart session, and remote URL SSRF where relevant.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The file lifecycle names entrypoints, final filename or key, storage root or bucket, metadata
+  record, validation gates, processing tools, visibility state, serving path, and cleanup owner.
+- Client-provided filenames, MIME labels, paths, keys, URLs, sizes, checksums, tenants, owners, and
+  visibility flags are either ignored, verified, or explicitly reported as risky.
+- File type validation is tied to normalized final names and actual bytes, not only extension or
+  request headers.
+- Upload, processing, promotion, preview, download, CDN, email, admin, and cleanup paths are checked
+  or explicitly scoped out.
+- Denial-case tests or missing evidence are named from the attacker-controlled file lifecycle.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `test_audit`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured tests that prove file lifecycle denial behavior: disallowed type,
+spoofed MIME, normalized extension bypass, path traversal, archive escape, resource limit,
+unauthorized upload target, unauthorized download, pending-scan access, presigned policy, and remote
+URL rejection.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If filename, key, storage, parser, scanner, visibility, tenant, authorization, or response-header
+  evidence is missing, report the gap instead of claiming the upload path is safe.
+- If the fix requires broad auth model changes, use `auth-permission-change` or
+  `api-access-control-review` before editing that scope.
+- If a sensitive filename, URL, token, storage key, signed URL, user content, or malware-like sample
+  appears in logs, diffs, fixtures, screenshots, command output, or final reports, stop repeating it
+  and use `secret-exposure-response` when it may be sensitive.
+- If a command fails, use `failure-triage` before further edits.
+- If verification would require live storage credentials, production files, malware samples, or
+  unsafe network probes, skip that path and report the remaining risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- File upload security reviewed
+- Upload entrypoints, file identity, storage, validation, processing, serving, and cleanup map
+- Filename, type, path, overwrite, web-root, parser, archive, CSV, remote URL, scanner, signed URL,
+  tenant, authorization, header, and resource-limit findings
+- Fixes made or recommendation
+- Denial tests, fixtures, or invariant evidence
+- Command intents run
+- Skipped checks and reasons
+- Remaining file-upload security risk

package/templates/default/locales/en/.mustflow/skills/frame-render-performance-review/SKILL.md

@@ -0,0 +1,159 @@
+---
+mustflow_doc: skill.frame-render-performance-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: frame-render-performance-review
+description: Apply this skill when browser rendering performance, per-frame work, INP, animation smoothness, scroll responsiveness, style recalculation, layout, forced synchronous layout, layout thrashing, paint, compositing, DOM size, CSS selector cost, global class toggles, CSS custom property churn, containment, content-visibility, virtualization, image or media geometry, IntersectionObserver, passive listeners, overscroll behavior, requestAnimationFrame, long tasks, web workers, OffscreenCanvas, ResizeObserver, runtime CSS injection, React memo, context rerenders, deferred rendering, transitions, hydration cost, DevTools rendering traces, or interaction-to-next-paint flame analysis need review.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.frame-render-performance-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Frame Render Performance Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review browser rendering performance by reducing the work needed for each frame and interaction: JavaScript, style recalculation, layout, paint, compositing, and the next paint after user input.
+
+The review question is not "did we add `useMemo`?" It is "what work does the browser have to redo before the next frame, and can the changed code reduce the affected DOM, style, layout, paint, or main-thread scope?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A frontend change affects animation, scrolling, drag, resize, pointer movement, keyboard input, search input, list rendering, charts, maps, canvas, virtualized lists, hydration, or any interaction whose next paint can lag.
+- Code touches DOM reads and writes, `offset*`, `client*`, `scroll*`, `getBoundingClientRect()`, computed styles, inline styles, class toggles, CSS variables, runtime CSS injection, layout-affecting CSS properties, `will-change`, `contain`, `content-visibility`, `contain-intrinsic-size`, `aspect-ratio`, or media dimensions.
+- Code touches scroll listeners, wheel or touch handlers, passive event listener options, `IntersectionObserver`, `ResizeObserver`, `requestAnimationFrame`, timers, long tasks, `scheduler.yield`, web workers, `OffscreenCanvas`, or canvas/chart redraw loops.
+- Code touches React render boundaries, `memo`, `useMemo`, `useCallback`, context providers, `useDeferredValue`, `useTransition`, hydration, lazy islands, or framework-specific rerender behavior with user-perceived responsiveness risk.
+- A review or final report claims smoother rendering, fewer layout shifts, better INP, less jank, faster animation, lower main-thread cost, smaller DOM cost, or improved DevTools rendering traces.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is about first discovery of LCP resources, critical CSS, font loading, first-view data, TTFB, CDN caching, resource hints, or first-render delivery rather than per-frame work; use `web-render-performance-review`.
+- The task is about initial JavaScript bytes, tree-shaking, shared vendor chunks, package imports, polyfills, or bundler pruning rather than runtime frame cost; use `client-bundle-pruning-review`.
+- The task is broad performance budgeting, backend latency, throughput, or p95/p99 service behavior without browser frame impact; use `performance-budget-check`.
+- The task is only visual polish or accessibility with no frame, INP, style, layout, paint, or main-thread performance risk; use `ui-quality-gate`, `css-code-change`, or `html-code-change`.
+- The needed proof requires an unconfigured browser trace, DevTools session, Lighthouse run, RUM report, dev server, profiler, or package-manager script. Report the missing measurement boundary instead of inventing raw commands.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Interaction and frame ledger: affected interaction, route, viewport, target frame rate, user-visible symptom, expected INP or next-paint boundary, and whether the path runs during startup, scroll, input, animation, resize, or idle.
+- DOM and layout ledger: node count, tree depth, affected subtree, list size, virtualization boundary, layout containment, geometry reads, geometry writes, reserved media slots, and layout-shift evidence.
+- Style and CSS ledger: class or attribute toggles, selector complexity, global state classes, CSS custom property scope, runtime style injection, CSS animations, transitions, `will-change`, `contain`, `content-visibility`, and stacking or containing block side effects.
+- Paint and compositing ledger: animated properties, repaint area, layer promotion, transform and opacity usage, canvas or SVG drawing, image/video/ad slots, shadows, filters, clipping, and expensive visual effects.
+- Event and scheduling ledger: scroll, wheel, touch, pointer, resize, observer, timer, `requestAnimationFrame`, long task, worker, `OffscreenCanvas`, `scheduler.yield`, debounce, throttle, and cancellation behavior.
+- Framework render ledger: component rerender scope, React props stability, context value changes, memo boundaries, deferred updates, transitions, hydration scope, island or partial hydration strategy, and stale async result handling.
+- Evidence ledger: DevTools Rendering or Performance panel findings, paint flashing, layout shift regions, Selector Stats, long task output, INP flame, RUM, trace, screenshot, configured tests, or missing evidence.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- Required inputs are available from current files, diffs, docs, configured outputs, user-provided evidence, or can be reported as missing without guessing.
+- If changes touch actual HTML, CSS, framework code, canvas, media assets, accessibility, security-sensitive embeds, or package metadata, also use the matching narrower skill.
+- If browser API or framework behavior is version-sensitive, verify against project dependencies or current official documentation before durable docs or code comments rely on it.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Separate DOM reads and writes, batch layout-affecting writes, move animations to transform or opacity, narrow or remove `will-change`, add safe containment, add `content-visibility` with intrinsic size, virtualize large lists, simplify selectors, narrow global class and CSS variable scope, reserve media geometry, replace JS scroll geometry polling with observers, add passive listeners where scroll is not cancelled, use CSS overscroll behavior, move visual updates into `requestAnimationFrame`, split long tasks, move DOM-free heavy work to workers, use `OffscreenCanvas` where supported, use `ResizeObserver`, reduce runtime CSS injection, narrow rerender scope, stabilize props and context values, defer expensive results, narrow hydration, add focused tests, and update directly synchronized docs or templates.
+- Add instrumentation, trace notes, or budget assertions only when the repository already has a pattern or configured command intent.
+- Keep edits local to the affected frame, interaction, component subtree, CSS scope, or scheduling path. Do not migrate frameworks, replace rendering engines, introduce virtualization libraries, add worker infrastructure, or start browser measurement workflows without explicit scope and command-contract support.
+- Do not break accessibility, keyboard behavior, scroll intent, reduced motion, focus management, layout stability, media semantics, localization, authorization, privacy, or correctness merely to reduce frame work.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the bottleneck before optimizing. Separate JavaScript long task, style recalculation, layout, paint, compositing, hydration, or framework rerender risk. If no trace exists, label the finding as static frame-risk evidence.
+2. Keep DOM reads and writes separate. Collect geometry reads such as `offsetHeight`, `scrollTop`, `getBoundingClientRect()`, and computed style first, then batch writes in a later phase or frame to avoid forced synchronous layout.
+3. Look for layout thrashing inside loops, scroll handlers, resize handlers, animation steps, pointer moves, and render effects. Repeated read/write/read cycles are higher risk than a single geometry read.
+4. Animate composite-friendly properties first. Prefer `transform` and `opacity` for movement and fade. Treat `width`, `height`, `top`, `left`, `margin`, layout-affecting grid values, and expensive filters as layout or paint suspects.
+5. Use `will-change` only as a temporary hint. Add it shortly before real animation when evidence supports it, and remove it afterward. Do not leave broad `will-change` on static elements.
+6. Add containment to independent widgets when safe. Cards, panels, messages, and dashboard tiles can use `contain` to limit layout and paint scope, but check containing block, stacking context, overflow, `position: fixed`, `absolute`, and z-index behavior.
+7. Use `content-visibility: auto` for large below-fold sections. Pair it with `contain-intrinsic-size` or stable placeholders so skipped rendering does not create scroll jumps.
+8. Stop offscreen work, not only offscreen rendering. For skipped or hidden charts, maps, canvas, or media widgets, pause redraws, resize loops, observers, polling, and expensive updates while the widget is not visible.
+9. Virtualize long lists. Large tables, chat logs, feeds, option lists, and grids should keep only the visible window plus buffer in the DOM when item count can grow.
+10. Reduce DOM depth and breadth where it affects a hot render path. Deep wrapper chains and wide repeated structures increase style and layout propagation even when no single node looks expensive.
+11. Simplify selectors on hot or broad subtrees. Prefer simple class selectors over selectors that depend on deep descendants, complex siblings, expensive pseudo-classes, or global ancestor state.
+12. Avoid broad global class toggles. `body` or `html` state changes force wide style invalidation. Use the narrowest subtree root unless the state is truly global, such as theme.
+13. Scope frequently changing CSS variables close to the affected subtree. Avoid changing `:root` custom properties on pointer move, scroll, drag, or animation. Use non-inheriting registered properties when project support and browser targets allow it.
+14. Reserve media, ad, and embed geometry. Use width, height, `aspect-ratio`, or stable placeholders so image, video, iframe, and ad loads do not trigger layout shifts and repeated paint.
+15. Keep LCP media and first-render discovery concerns routed to `web-render-performance-review`. In this skill, focus on whether loaded media shifts layout, repaints broad regions, or forces per-frame work.
+16. Prefer native lazy loading for below-fold images and iframes when it covers the case. Avoid JS lazy loaders that add scroll handlers, observers, state churn, and rerenders without a project reason.
+17. Use `IntersectionObserver` for visibility and infinite-scroll triggers. Do not calculate viewport intersection manually on every scroll event unless a browser limitation forces it.
+18. Use passive wheel, touch, and scroll listeners when the handler does not call `preventDefault()`. Do not mark listeners passive when the gesture intentionally cancels scrolling.
+19. Use CSS `overscroll-behavior` before JavaScript scroll blocking for modals, drawers, and nested scroll containers. Keep JS scroll locks as the narrow fallback for focus and body-lock requirements.
+20. Schedule visual writes with `requestAnimationFrame`. Do not use fixed `setTimeout(..., 16)` as a frame clock. Use the animation timestamp so high-refresh displays do not speed up motion.
+21. Split long tasks. Work longer than one frame or around 50ms should yield between chunks, show urgent UI first, and move non-urgent analytics, cache cleanup, validation, or transformation out of the immediate interaction path.
+22. Move DOM-free heavy computation off the main thread when the boundary cost is worth it. Filtering, sorting, diffing, crypto, markdown parsing, image preprocessing, and search indexing can move to a worker when data transfer and cancellation are defined.
+23. Consider `OffscreenCanvas` for heavy canvas rendering when browser targets and architecture support it. Charts, whiteboards, maps, and image editors should not block input and paint if a worker boundary is practical.
+24. Use `ResizeObserver` for element size changes. Avoid window resize handlers that read every card and write layout back in the same pass.
+25. Avoid runtime CSS rule churn. Do not inject new style tags or rules during click, hover, drag, pointer move, or repeated list rendering. Use static classes and narrow CSS variables where dynamic values are needed.
+26. Treat React `memo` as a rerender scope tool, not a cure. It fails when props are fresh objects, arrays, or functions each render. Prefer smaller component boundaries and stable primitive props.
+27. Split React context by change frequency and audience. A fresh provider object rerenders all consumers of that context; do not put theme, auth, permissions, feature flags, and editor state into one object unless they change together.
+28. Keep input updates urgent and heavy results deferred. Use deferred rendering or transitions for large filtered lists, charts, panels, or route changes when immediate input feedback matters more than full result freshness.
+29. Narrow hydration. SSR can still hurt INP when the client hydrates too much at once. Hydrate only interactive islands early and defer low-priority regions by visibility, idle time, or route intent when the framework supports it.
+30. Verify with the right evidence. Prefer DevTools Performance, paint flashing, layout shift regions, Selector Stats, long tasks, and INP flame evidence when configured or provided. If unavailable, report static risks and skipped measurement reasons.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The affected interaction, frame phase, DOM scope, style scope, layout reads/writes, paint or compositing cost, scheduling path, and framework render boundary are explicit where relevant.
+- Forced synchronous layout, layout thrashing, layout-affecting animations, stale `will-change`, missing containment, unsafe `content-visibility`, offscreen background work, oversized DOM, complex selectors, broad global class toggles, root CSS variable churn, unreserved media geometry, JS scroll polling, non-passive listeners, JS scroll blocking, timer-based animation, long tasks, main-thread heavy computation, canvas main-thread cost, resize measurement loops, runtime CSS injection, ineffective memo, broad context rerenders, urgent heavy results, and full hydration cost are fixed or reported.
+- Rendering performance claims are backed by current configured evidence or labeled as static frame-risk, manual-only measurement, or missing evidence.
+- Accessibility, focus, scroll intent, reduced motion, layout stability, privacy, and framework semantics remain intact or are reported as tradeoffs.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Use the narrowest configured test, build, docs, release, or mustflow intent that covers the changed rendering path. Use DevTools, browser traces, Lighthouse, RUM, dev servers, or profiler workflows only when they are configured one-shot intents or explicitly approved by the user.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the affected frame phase is unknown, report the unknown before adding memoization, observers, workers, containment, or virtualization.
+- If a configured test or build fails, preserve the failing intent and output tail, then fix only the rendering, CSS, framework, or scheduling boundary exercised by the failure.
+- If the fix needs unconfigured browser measurement, dev servers, worker infrastructure, virtualization dependencies, framework upgrades, or profiler tooling, stop and report the missing product or command-contract decision.
+- If frame performance conflicts with accessibility, scroll intent, focus management, reduced motion, layout stability, or correctness, keep the safer behavior and report the tradeoff.
+- If verification fails after a frame-rendering change, use `failure-triage` before broadening the fix.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Frame rendering surface reviewed
+- Interaction, frame phase, DOM/style/layout/paint/compositing/scheduling/framework ledgers
+- Findings or fixes
+- Evidence level: measured, configured-test evidence, static frame-risk, manual-only, missing, or not applicable
+- Command intents run
+- Skipped browser or rendering measurements and reasons
+- Remaining frame-render performance risk