mustflow 2.39.1 → 2.58.0

package/templates/default/locales/en/.mustflow/skills/low-end-device-support-review/SKILL.md

@@ -0,0 +1,340 @@
+---
+mustflow_doc: skill.low-end-device-support-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: low-end-device-support-review
+description: Apply this skill when Android Go, low-RAM Android, older iOS, React Native, Flutter, Tauri mobile, Electron, desktop app shell, or other constrained-device support needs review for low-end target devices, runtime memory class, `isLowRamDevice()`, `getMemoryClass()`, cold-start frequency, peak memory, low memory killer, iOS dirty memory, memory warnings, `onTrimMemory()`, image decode sizes, GIF or Lottie cost, list virtualization, Compose recomposition, SwiftUI body work, main-thread work, frozen frames, blur, shadow, gradient, glass effects, SDK diet, remote config defaults, network fan-out, disk writes, cache limits, DB paging and indexes, background work, polling, sensors, permissions, bottom-percentile device measurement, and product-level p90 budgets.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.low-end-device-support-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Low-End Device Support Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review low-end device support as a capability budget across CPU, GPU, RAM, storage, network,
+startup, rendering, SDKs, and background work.
+
+The review question is not "which single algorithm is slow?" It is "does the app try to wake too
+many SDKs, decode too many pixels, make too many requests, open too much data, animate too much UI,
+and keep too much cache at the same time for the weakest supported device?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Android Go, low-RAM Android, older iOS, React Native, Flutter, Tauri mobile, Electron, desktop app
+  shell, TV, embedded, kiosk, or other constrained-device code is created, changed, reviewed, or
+  reported with low-end, low RAM, weak CPU, weak GPU, small storage, slow disk, slow network,
+  out-of-memory, low memory killer, LMK, ANR, hangs, frozen frames, dropped frames, slow startup,
+  heavy first screen, image decode, GIF, Lottie, cache, database, SDK, polling, sensor, or
+  background-work risk.
+- Code or product policy touches `isLowRamDevice()`, `getMemoryClass()`, Android Go behavior,
+  memory class, low-end mode, cache sizing, image sizing, animation reduction, prefetch width,
+  request fan-out, list batch size, feature degradation, remote config defaults, SDK auto-init, or
+  bottom-percentile device budgets.
+- A final report claims low-end safe, Android Go safe, older-device safe, memory efficient,
+  lightweight, responsive, low RAM compatible, production performance ready, or measured on weak
+  devices.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only launch critical-path review from icon tap to first frame or fully usable state;
+  use `app-startup-performance-review`.
+- The task is only battery, wakeup, mobile radio, background scheduling, GPS, sensors, or Low Power
+  Mode behavior; use `mobile-energy-efficiency-review`.
+- The task is only browser per-frame work, INP, scroll jank, style, layout, paint, compositing, or
+  DOM cost; use `frame-render-performance-review`.
+- The task is only backend latency, service throughput, data-structure cost, N+1 access,
+  allocation churn, or broad hot-path budgeting without a constrained-device surface; use
+  `performance-budget-check` or a narrower performance skill.
+- The task is only responsive layout, hostile content, keyboard, safe area, overflow, i18n, or
+  visual resilience without runtime capability limits; use `frontend-stress-layout-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Target-device ledger: supported platforms, lowest comfort baseline, lowest support baseline,
+  OS versions, memory class, RAM, storage, CPU/GPU class, screen density, network assumptions, and
+  whether the target is Android Go, low-RAM Android, older iOS, emulator, simulator, or physical
+  device.
+- Measurement ledger: release or profile build evidence from bottom 10% devices, Android Vitals,
+  crash, ANR, startup, slow rendering, frozen frame, LMK, wake lock, Perfetto, Macrobenchmark, iOS
+  Organizer, Instruments, MetricKit, device traces, or an explicit static-only boundary.
+- Product budget ledger: home first frame p90, fully usable p90, screen peak memory, image memory
+  limit, cache limit, request fan-out, concurrency width, dropped-frame or frozen-frame target,
+  background work count, SDK initialization timing, and feature degradation policy.
+- Startup and first-screen ledger: cold-start frequency, TTID, TTFD, local cache, skeleton, local
+  defaults, remote config, ContentProvider auto-init, AndroidX App Startup, Baseline Profile,
+  Startup Profile, R8, first-screen API fan-out, first-screen image decode, first-screen list size,
+  and post-first-frame work.
+- Memory-pressure ledger: peak memory, average memory, Android LMK, zRAM, iOS dirty memory,
+  `onTrimMemory()`, iOS memory warning, image cache, screen cache, hidden tabs, search results,
+  temporary models, and cleanup behavior.
+- Rendering and list ledger: main-thread work, frozen frames over 700ms, 16ms frame budget,
+  transform, opacity, rotation, layout-property animations, blur, shadow, gradient, glass effects,
+  list virtualization, stable keys, lazy layout, Compose `remember`, `derivedStateOf`, delayed state
+  reads, SwiftUI `body`, and offscreen work.
+- Data, network, and disk ledger: thumbnail versus original image sizing, GIF or video or Lottie
+  choice, API field selection, first-screen API fan-out, DB query shape, indexes, sort, paging,
+  selected columns, SQLite WAL, transactions, JSON, plist, XML, cache bounds, LRU policy, and batch
+  disk writes.
+- SDK and background ledger: first-run essential SDKs, after-first-screen SDKs, feature-entry SDKs,
+  analytics, ads, CRM, chat, session replay, A/B tests, crash reporting, remote config, payments,
+  maps, push token, auto screen tracking, WorkManager, polling, wake locks, sensors, location, and
+  permission start or stop ownership.
+- Existing tests, profiler traces, telemetry, build outputs, package surfaces, synchronized docs or
+  templates, and configured command-intent 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 low-end evidence is available from current files, diffs, docs, configured outputs,
+  user-provided evidence, or can be reported as missing without guessing.
+- Review release or profile behavior on weak physical devices when making performance claims. Treat
+  debug builds, simulators, emulators, hot reload, flagship-only testing, and warm developer caches
+  as weak evidence unless the task explicitly scopes them.
+- If the change touches auth, privacy, payments, migrations, storage, permissions, telemetry,
+  background services, or third-party SDK behavior, also use the narrower matching skill when its
+  trigger is present.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten runtime capability detection, low-end mode switches, target-device budgets, cache
+  bounds, image decode sizing, first-screen local defaults, skeleton or cached data paths, SDK
+  deferral, remote config fallback, API field reduction, request fan-out limits, screen-level
+  concurrency queues, list virtualization, animation reduction, memory-warning cleanup, disk-write
+  batching, database paging and indexes, background-work constraints, polling removal, sensor stop
+  paths, low-end telemetry, and focused tests.
+- Stage SDKs into first-run essential, after-first-screen, and feature-entry groups when repository
+  evidence supports the change.
+- Reduce decorative blur, shadow, gradient, glass, GIF, complex Lottie, offscreen animation,
+  oversized thumbnails, unbounded cache, eager prefetch, and hidden-tab retention when they harm
+  the target device budget.
+- Do not fake low-end support by only adding a model blacklist, longer splash hold, spinner, reduced
+  marketing copy, or generic "optimize later" comment.
+- Do not remove correctness, safety, auth, privacy, crash diagnostics, accessibility, required
+  migration integrity, or user-critical behavior merely to fit a low-end budget.
+- Do not start raw Android Studio, Xcode, emulator, device lab, profiler, dashboard, dev-server,
+  package-manager, or telemetry workflows outside the configured command contract.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the low-end product contract before tuning.
+   - Name the comfort baseline and support baseline separately.
+   - Define p90 home first frame, p90 fully usable state, screen peak memory, image memory limit,
+     cache limit, dropped-frame or frozen-frame threshold, background work count, API fan-out, and
+     SDK initialization timing.
+   - If budgets do not exist, report that low-end support is policy-incomplete instead of treating
+     isolated micro-optimizations as a complete answer.
+2. Check measurement quality.
+   - Prefer release or profile builds on bottom 10% physical devices.
+   - Use Android Vitals, LMK reports, ANR, frozen frames, startup, wake locks, Perfetto,
+     Macrobenchmark, iOS Organizer, Instruments, and MetricKit only when configured or supplied.
+   - Label static-only review clearly when device, profiler, release-build, or field evidence is
+     missing.
+3. Detect capability at runtime.
+   - Use platform capability signals such as `isLowRamDevice()` and `getMemoryClass()` where
+     available.
+   - Avoid model-name blacklists as the primary decision because vendor, region, carrier, and
+     custom builds drift.
+   - Tie capability to concrete limits: image resolution, cache size, animation, prefetch count,
+     concurrency width, list batch size, and feature entry.
+4. Treat cold start as common on low-end devices.
+   - Low-end users often hit cold start more often because the OS kills background processes.
+   - Separate TTID from TTFD and first frame from useful state.
+   - Route startup-only launch work to `app-startup-performance-review` while keeping low-end
+     capability budgets here.
+5. Keep process entry small.
+   - Keep `Application.onCreate()`, `AppDelegate`, first Activity, and first ViewController limited
+     to process-critical work.
+   - Defer analytics, ad SDKs, remote config refresh, push token, payments, maps, chat, A/B tests,
+     database open, cache cleanup, and prefetch until after first frame or feature entry unless
+     product safety requires them.
+6. Audit hidden Android startup.
+   - Check ContentProvider auto-init and AndroidX App Startup ownership before assuming visible
+     application code controls launch.
+   - Disable or defer auto-init when the SDK supports it and first screen does not require it.
+7. Keep remote config local-first.
+   - Provide local defaults for feature flags and low-end limits.
+   - Let server values update after the first usable state when product semantics allow it.
+   - Report any experiment, kill switch, or remote config that blocks first screen without a local
+     fallback.
+8. Protect the main thread.
+   - Treat main-thread UI work as scarce. Move image decode, JSON parsing, DB open, decompression,
+     recommendation computation, cache cleanup, and network waits off the immediate UI path.
+   - Fix frozen frames over 700ms before spending effort on tiny 16ms frame optimizations.
+   - Keep 16ms frame budgets and input responsiveness visible as constraints, not as proof without
+     trace evidence.
+9. Reduce expensive pixels.
+   - Prefer transform, opacity, and rotation for animation.
+   - Avoid per-frame width, height, margin, padding, constraint, or layout-property changes.
+   - Limit repeated blur, shadow, gradient, glass, translucent layer, and complex effect use,
+     especially inside list cells.
+10. Watch peak memory, not only averages.
+    - Review screen transitions, image-heavy screens, search, maps, media, hidden tabs, and cached
+      results for peak memory spikes.
+    - On Android, account for LMK and zRAM pressure. On iOS, account for dirty memory.
+    - Do not approve "average memory is fine" when one screen can spike over the device budget.
+11. Make memory pressure handlers real.
+    - Use `onTrimMemory()` and iOS memory warning paths to release image cache, screen cache, search
+      results, temporary models, hidden-tab data, decoded bitmaps, and stale prefetch.
+    - Test or report the missing test boundary for these cleanup paths.
+12. Cap concurrency by screen.
+    - Avoid running image decode, JSON parsing, DB queries, decompression, recommendation compute,
+      and prefetch all at once.
+    - Use screen-level or feature-level queues with cancellation, backpressure, timeout, and owner
+      visibility.
+13. Decode images to display size.
+    - Never decode original images for thumbnails.
+    - Treat large `ARGB_8888` images as memory events; a 4048x3036 image can be about 48MB when
+      fully decoded.
+    - Use thumbnail URLs, server transforms, downsampling, hardware bitmap policy, and low-end image
+      quality limits where the platform and project support them.
+14. Degrade animated media.
+    - Treat GIF as disabled or heavily restricted in low-end mode unless it is core user content.
+    - Prefer small video or static fallback where product semantics allow it.
+    - Keep Lottie simple; complex vector animation can become CPU work even when it looks light.
+15. Keep lists visible-only.
+    - Use lazy layout or virtualization, stable keys, bounded buffers, and paging.
+    - Avoid pre-rendering offscreen cells, measuring every cell repeatedly, decoding every image
+      eagerly, or changing keys across updates.
+16. Keep declarative UI bodies cheap.
+    - In Compose, use `remember`, `derivedStateOf`, stable models, and delayed state reads to avoid
+      recomputing sort, filter, date, permission, and price work during composition.
+    - In SwiftUI, keep `body` dumb; move formatters, image resizing, sorting, filtering, and state
+      combination into a view model or preparation layer.
+17. Bound caches.
+    - Set smaller RAM cache limits for low-end mode and define eviction behavior.
+    - Prefer LRU or project-standard bounded eviction over unbounded maps.
+    - Release screen-local caches on screen exit when the next screen needs memory more than the
+      previous screen needs instant restore.
+18. Shape database work for scroll.
+    - Review index fit, sort order, paging, selected columns, and query count for home feeds, chats,
+      notifications, and other frequently opened lists.
+    - Use SQLite WAL and transactions where the repository already supports them and the write path
+      needs batching.
+    - Do not overfetch full records just to render thumbnails or list rows.
+19. Batch disk writes.
+    - Avoid rewriting a large JSON, plist, or XML file for a tiny value change.
+    - Coalesce autosave, scroll position, telemetry, cache metadata, and preferences writes.
+    - Prefer partial updates, append or merge strategies, or a database when frequent small updates
+      outgrow a single serialized blob.
+20. Reduce first-screen network fan-out.
+    - Fetch only the fields and thumbnails needed for orientation and first action.
+    - Defer detailed data until screen entry.
+    - Avoid many parallel first-screen APIs that create CPU, memory, radio, TLS, JSON, and retry
+      pressure at once.
+21. Respect mobile background and sensor cost.
+    - Use system-batched work such as WorkManager when durable background work can wait.
+    - Avoid wake locks, polling, and exact periodic refresh by default.
+    - Start GPS, camera, microphone, Bluetooth, Wi-Fi scan, and other sensors only for explicit
+      visible value, use coarse location where enough, and stop when the screen or task ends.
+22. Put the app on an SDK diet.
+    - Classify SDKs as first-run essential, after-first-screen, or feature-entry only.
+    - Review analytics, ads, CRM, chat, session replay, A/B testing, crash reporting, remote config,
+      payments, maps, and push setup.
+    - Disable auto screen tracking, unused event collection, eager modules, and hidden auto-init
+      where product and SDK policy allow it.
+23. Define low-end degradation as a product behavior.
+    - Name which image resolution, cache size, animation, prefetch, list batch size, background
+      work, SDK timing, recommendation, ML, or ornamental effect changes under low-end mode.
+    - Keep user-critical safety, accessibility, auth, privacy, payment, and data-integrity paths
+      explicit.
+24. Verify or report the gap.
+    - Use configured tests, builds, docs checks, release checks, and mustflow checks for changed
+      repository surfaces.
+    - Use device, profiler, platform dashboard, and field telemetry evidence only when configured or
+      supplied.
+    - Report missing bottom-percentile device evidence, release-build traces, low-memory simulation,
+      memory-warning tests, startup traces, list-scroll traces, or field telemetry instead of
+      claiming measured low-end improvement.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Target-device baseline, capability detection, low-end mode, p90 budgets, startup and first-screen
+  boundary, memory pressure, peak memory, main-thread work, frozen frames, image decode, animated
+  media, list virtualization, Compose or SwiftUI work, cache limits, DB shape, disk writes, network
+  fan-out, background work, polling, sensors, SDK staging, degradation policy, and evidence level
+  are explicit.
+- Model blacklist shortcuts, splash masking, local-default gaps, hidden ContentProvider auto-init,
+  eager SDK setup, remote-config blocking, first-screen API fan-out, main-thread decode or parsing,
+  frozen frames, layout-property animation, repeated blur or shadow, peak memory spikes, no-op
+  memory warnings, unbounded caches, original-size thumbnails, GIF decoration, unstable list keys,
+  heavy Compose or SwiftUI body work, overfetching DB queries, giant JSON rewrites, polling, sensors
+  left on, and first-run SDK bloat are fixed or reported.
+- Low-end support claims are backed by configured tests, device or telemetry evidence, static review
+  evidence, or labeled as manual-only or missing.
+
+<!-- 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`
+
+Prefer the narrowest configured test, build, docs, release, or mustflow intent that covers the
+changed low-end support surface and synchronized template surfaces. Do not infer raw Android
+Studio, Xcode, emulator, device, profiler, platform dashboard, package-manager, benchmark,
+telemetry, or dev-server commands outside the command contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a configured command fails, preserve the failing intent, failing assertion or output tail, and
+  the low-end invariant it exercised before editing again.
+- If target-device baselines or budgets are missing, report that low-end support cannot be fully
+  judged yet instead of adding isolated optimizations.
+- If release-build, weak-device, profiler, memory-warning, platform-dashboard, or production
+  telemetry evidence is missing, complete available static and configured-test evidence and report
+  the missing measurement boundary.
+- If safe repair requires product requirement changes, native permission policy, third-party SDK
+  dashboard changes, device lab testing, production telemetry, or platform-specific implementation
+  outside the current scope, report the boundary instead of inventing commands.
+- If low-end performance conflicts with security, privacy, payment correctness, migration
+  integrity, crash reporting, accessibility, or user trust, keep the safer behavior and report the
+  tradeoff.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Low-end device support boundary reviewed
+- Target-device baseline, budgets, capability detection, startup, memory, rendering, list, data,
+  network, disk, background, sensor, SDK, degradation, and evidence findings
+- Low-end support fixes made or recommended
+- Evidence level: measured, configured-test evidence, static low-end risk, manual-only, missing, or
+  not applicable
+- Command intents run
+- Skipped low-end diagnostics and reasons
+- Remaining low-end device support risk

package/templates/default/locales/en/.mustflow/skills/memory-lifetime-review/SKILL.md

@@ -0,0 +1,169 @@
+---
+mustflow_doc: skill.memory-lifetime-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: memory-lifetime-review
+description: Apply this skill when code is created, changed, reviewed, or reported and object lifetime, retained references, cleanup symmetry, event listeners, timers, subscriptions, goroutines, threads, workers, streams, native handles, caches, queues, or memory/resource leak risk may matter.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.memory-lifetime-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Memory Lifetime Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Find memory and resource leaks by tracing what still retains a value, handle, task, listener, or buffer after the useful work is done.
+
+The question is not only "where was it allocated?" The stronger review question is "which longer-lived owner can still reach it?" In garbage-collected languages, an unused object remains alive when a live object still references it. In non-GC or native-resource paths, the same shape appears as a missing close, cancel, release, unsubscribe, shutdown, or ownership-transfer rule.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code creates, changes, reviews, or reports event listeners, observers, subscriptions, intervals, timeouts, animation frames, effects, ref callbacks, registries, caches, maps, queues, pools, workers, threads, goroutines, futures, tasks, streams, sockets, files, database cursors, image or GPU handles, native handles, or external client sessions.
+- A long-lived object such as a singleton, static field, module cache, process-level registry, service, worker, ViewModel, global store, connection pool, scheduler, or background task can retain a request, response, user session, DOM node, UI component, Activity, Fragment, context, socket, buffer, payload, or closure.
+- Code adds lifecycle setup such as `new`, `open`, `connect`, `subscribe`, `observe`, `addEventListener`, `setInterval`, `setTimeout`, `context.WithCancel`, `ThreadLocal.set`, `malloc`, `retain`, `shared_ptr`, `Rc`, task spawning, stream creation, or cache insertion.
+- Code uses closures, callbacks, lambdas, async work, promises, channels, effects, refs, logging queues, metrics queues, debug arrays, maps, or registries that may capture or store large or short-lived objects.
+- A review or final report claims that a path is leak-free, bounded, cleaned up, disposable, safe for repeated mount/unmount, safe for long-running processes, safe under retries, or safe for repeated requests.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only about CPU time, latency, query count, bundle size, or payload size with no retained-reference, cleanup, or resource-lifetime risk; use `performance-budget-check`.
+- The task is only ordinary ownership or borrowing inside one language-specific change and the matching language skill fully covers the risk; use this skill only if the retention or cleanup boundary crosses callbacks, async tasks, process lifetime, UI lifecycle, native handles, or shared registries.
+- The task is only database schema, migration, authorization, or API contract work with no long-lived process, stream, queue, cache, or resource handle; use the more specific skill.
+- The only evidence is a vague worry about memory without code paths, retained owners, repeated lifecycle actions, or resource handles to inspect.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Lifetime surface: UI mount/unmount, request/response, job, worker, stream, queue, cache, pool, process, test runner, CLI command, background task, native resource, or application shutdown.
+- Setup sites: allocation, registration, subscription, listener attachment, timer creation, task spawn, context creation, handle open, cache insert, registry add, ref storage, or ownership transfer.
+- Cleanup sites: remove, abort, cancel, close, clear, unsubscribe, dispose, release, terminate, join, shutdown, delete, weak ownership, eviction, TTL expiry, bounded queue drop, stream return, or final response cleanup.
+- Retainer graph: the longer-lived owner, the shorter-lived object, the reference path between them, and the expected point where that reference should be severed.
+- Repetition path: repeated requests, screen open/close, route changes, tab switches, reconnects, retries, scheduled runs, test cases, or long-running sessions that can accumulate retained state.
+- Error and success paths: normal completion, early return, partial read, cancellation, timeout, retry, exception, unmount, shutdown, and dependency failure behavior.
+- Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
+
+<!-- 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 inputs can be reported without guessing.
+- If authorization, secrets, personal data, telemetry, or audit records are retained, also use `security-privacy-review`.
+- If queue, cache, retry, worker, health, or operational behavior changes, also use `backend-reliability-change`.
+- If user-perceived latency, throughput, allocation churn, GC pressure, or memory budget is claimed, also use `performance-budget-check`.
+- If UI lifecycle, rendering, or browser behavior changes, also use the matching UI or framework skill.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten teardown, cancellation, ownership, weak-reference, eviction, queue-bound, stream-close, worker-shutdown, and lifecycle-symmetry code tied to the task.
+- Refactor setup and cleanup into a shared lifecycle boundary when it prevents duplicate registration or forgotten teardown.
+- Add focused tests, fixtures, probes, or docs that prove cleanup symmetry, bounded retention, repeated lifecycle behavior, or native-resource disposal when repository evidence supports them.
+- Do not hide leak warnings by raising listener limits, disabling strict lifecycle checks, adding finalizers as primary cleanup, or weakening tests.
+- Do not use weak references as a design cover-up when the real owner and cleanup point should be explicit.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the lifetime boundary. State which object or resource should die at request end, unmount, stream close, job completion, retry cancellation, test end, worker shutdown, or process exit.
+2. Build a retainer ledger.
+   - For each setup site, record the long-lived owner, the short-lived object or resource, the reference path, and the intended cleanup owner.
+   - Treat singletons, static maps, module-level arrays, registries, caches, listeners, stores, workers, ViewModels, thread pools, goroutines, and scheduler state as long-lived until proven otherwise.
+   - Treat requests, responses, DOM nodes, UI components, Activity or Fragment instances, contexts, buffers, payloads, streams, sockets, cursors, and per-job state as short-lived unless the product explicitly says they are durable.
+3. Check setup and cleanup symmetry in the same change.
+   - `addEventListener` needs a stable removal path or an `AbortSignal` tied to teardown.
+   - `setInterval`, repeated `setTimeout`, animation frames, schedulers, and cron-like loops need clear, cancel, shutdown, or bounded end behavior.
+   - `subscribe`, `observe`, websocket, EventSource, stream, file, DB cursor, socket, and provider client handles need unsubscribe, close, dispose, or abort behavior.
+   - `context.WithCancel`, `WithTimeout`, or `WithDeadline` needs cancel on all paths that stop needing the child context.
+   - `ThreadLocal.set` in pooled threads needs a `remove` path in a finally-like boundary.
+4. Review normal repeated paths before rare error paths. Screen open/close loops, route changes, tab switches, request loops, reconnect loops, scheduled jobs, queue redeliveries, and test reruns often expose leaks better than exceptional returns.
+5. Inspect closure capture.
+   - A small callback may retain `this`, request, response, context, session, view, DOM event, buffer, large array, database row, or provider payload.
+   - If the callback is stored in a long-lived emitter, timer, queue, cache, worker, or registry, shrink captures to stable identifiers or copied scalar values.
+6. Check anonymous or unstable listener identities. A listener added with a fresh anonymous function in a loop or mount path usually cannot be removed by function identity. Prefer a stable callback reference or a scoped abort controller when the platform supports it.
+7. Treat timeout wrappers as incomplete cancellation. `Promise.race` or equivalent timeout selection does not stop the losing work by itself. Verify that fetches, DB calls, streams, workers, goroutines, futures, or background tasks receive a real abort, cancel, close, or done signal.
+8. Check streams and async iterators. Early break, partial read, error, or return paths must close, cancel, drain, or otherwise release upstream sockets, file descriptors, buffers, goroutines, and listeners.
+9. Bound caches, registries, debug stores, logs, and queues.
+   - Caches need max entries or bytes, TTL, eviction, key cardinality review, authorization dimensions, and stale behavior.
+   - Debug arrays such as recent requests, events, responses, payloads, traces, or errors need a cap and should store small copied facts rather than live large objects.
+   - Logs, metrics, traces, and dead-letter queues should not retain raw requests, responses, DOM events, exception graphs, payload bodies, tokens, or personal data.
+   - Producer-consumer queues need a capacity, drop or backpressure policy, timeout, and consumer shutdown path.
+10. Check language and runtime traps where applicable.
+    - JavaScript and TypeScript: `addEventListener`, EventEmitter listeners, `setMaxListeners`, timers, intervals, unresolved promises, `AbortSignal`, React effects, ref arrays, module caches, maps, and logging queues.
+    - React and similar UI runtimes: effects that touch the outside world need cleanup that reverses setup; ref callbacks and registries must remove old nodes and survive strict double-invocation checks.
+    - Android: ViewModel or application-scope objects must not retain Activity, Fragment, View, lifecycle owner, or short-lived context; use lifecycle cleanup such as `onCleared` where appropriate.
+    - Java and Kotlin: thread pools plus `ThreadLocal`, static caches, listener registries, executors, cursors, streams, and closeable resources need explicit release.
+    - Go: goroutines must exit on their own, channels need a done or cancellation path when downstream stops early, contexts need cancel, and finalizers are not primary cleanup.
+    - C and C++: ownership transfer must be explicit across raw pointers, containers, callbacks, and failure paths; `shared_ptr` cycles need `weak_ptr` or a different ownership shape.
+    - Rust: `Rc`, `Arc`, `RefCell`, task handles, channels, and cycles can leak even when memory safety is preserved; use weak ownership or explicit shutdown when ownership is not truly shared.
+    - Python: weak references are useful for caches and observer maps, but not as a substitute for a clear lifetime owner; check global dicts, LRU caches, callbacks, generators, files, and async tasks.
+11. Reject finalizers as the main plan. Finalizers, destructors, drop hooks, or weak callbacks can be last-resort diagnostics or safety nets, but the review should still identify deterministic cleanup for resources and reference removal.
+12. Add a repeated-lifecycle proof when feasible. Prefer a focused test or probe that repeats the risky lifecycle, then asserts listener count, registry size, cache size, goroutine/task completion, handle closure, queue depth, or retained object count. If heap snapshots, leak profilers, sanitizer runs, or platform-specific diagnostics are not configured intents, report them as manual evidence gaps instead of running raw commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every setup site has a cleanup owner, cleanup trigger, and repeated-path behavior, or the missing evidence is reported.
+- Long-lived owners no longer retain short-lived objects beyond their intended lifecycle, or the remaining retention is intentional and bounded.
+- Caches, queues, registries, debug stores, and logging or telemetry buffers have capacity, eviction, truncation, or copied-value boundaries where they can grow.
+- Async, stream, worker, goroutine, thread, and native-resource paths have deterministic cancellation, close, shutdown, or release behavior where the platform supports it.
+- Tests or configured verification cover the highest-risk repeated lifecycle when feasible.
+
+<!-- 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 proves the changed lifetime surface. Do not infer raw heap snapshot, profiler, sanitizer, browser, device, server, database, or load-test commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If a configured test or build fails, preserve the failing intent and output tail, then fix the lifecycle boundary that the failure exercised before broad refactors.
+- If no cleanup owner can be identified, stop and report the retainer path and missing lifecycle decision instead of hiding it behind weak references or comments.
+- If setup and cleanup live in separate owners, make the ownership transfer explicit or report the split as a residual leak risk.
+- If repeated-lifecycle proof requires unconfigured heap, profiler, sanitizer, browser, device, or load-test access, report the missing manual evidence and complete the configured checks that are available.
+- If leak reduction conflicts with product semantics, authorization, durability, observability, or retry behavior, use the relevant stronger skill and report the tradeoff.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Lifetime boundary reviewed
+- Setup sites and cleanup owners
+- Retainer paths found or ruled out
+- Long-lived owners and short-lived objects checked
+- Timers, listeners, subscriptions, streams, workers, goroutines, threads, native handles, caches, queues, registries, closures, and logs checked where relevant
+- Cleanup symmetry changes made or recommended
+- Repeated-lifecycle proof: configured, manual-only, missing, or not applicable
+- Command intents run
+- Skipped diagnostics and reasons
+- Remaining memory or resource lifetime risk