mustflow 2.38.0 → 2.58.0

package/templates/default/locales/en/.mustflow/skills/desktop-background-process-stability-review/SKILL.md

@@ -0,0 +1,318 @@
+---
+mustflow_doc: skill.desktop-background-process-stability-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: desktop-background-process-stability-review
+description: Apply this skill when Windows services, macOS LaunchDaemon or LaunchAgent jobs, Linux systemd units, Electron main or utility processes, WebView helpers, tray apps, sync workers, local daemons, auto-start helpers, updaters, desktop background jobs, or cross-session desktop processes need stability review for crash recovery, durable checkpoints, single-instance and data-directory locks, OS supervisor configuration, restart backoff, health checks, heartbeats, leases, idempotent jobs, atomic file writes, shutdown and preshutdown handling, exit-code semantics, UI and worker process separation, service Session 0 isolation, launchd daemon versus agent choice, systemd restart limits, sleep/resume, monotonic time, IPC authorization, environment and working-directory determinism, least privilege, startup logging, crash reporting, update safety, lifecycle tests, and safe mode.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.desktop-background-process-stability-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Desktop Background Process Stability Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review desktop background processes as recoverable local systems, not immortal processes.
+
+The review question is not "how do we keep this process alive forever?" It is "when this service,
+agent, helper, worker, tray process, or sync daemon dies, restarts, races another instance, loses
+network, resumes from sleep, or updates mid-job, what durable evidence prevents data loss,
+duplicate side effects, privilege confusion, or silent stuck work?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Windows services, service helpers, SCM failure actions, preshutdown handlers, service SIDs,
+  Session 0 boundaries, scheduled tasks, tray apps, auto-start entries, or user-session helpers are
+  created, changed, reviewed, or reported.
+- macOS LaunchDaemons, LaunchAgents, login items, app helpers, background items, agent versus daemon
+  placement, launchd restart behavior, per-user state, or fork/daemonize behavior is involved.
+- Linux desktop services, systemd user units, system units, restart policies, start-rate limits,
+  working directories, sandboxing, or service environment are involved.
+- Electron, Tauri, WebView, native desktop, .NET, JVM, Python, Rust, C++, Go, Node, or shell-backed
+  apps run main-process, utility-process, child-process, updater, sync, indexing, notification,
+  tray, plugin, or background work outside the visible UI lifecycle.
+- Code touches durable checkpoints, local queues, job leases, single-instance locks, data-directory
+  locks, IPC, crash reporting, heartbeat records, sleep/resume handling, network reachability,
+  monotonic timers, atomic settings writes, exit codes, update drain, rollback, or safe mode.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only installed app startup from process launch to first frame or fully usable state;
+  use `app-startup-performance-review`.
+- The task is only memory residency, renderer count, hidden windows, decoded media, caches, or
+  after-close memory; use `desktop-memory-footprint-review`.
+- The task is only queue acknowledgement, offsets, DLQ, prefetch, redelivery, or broker semantics;
+  use `queue-processing-integrity-review`.
+- The task is only duplicate external requests or business-command replay; use
+  `idempotency-integrity-review`.
+- The task is only generic failure handling that can make the system falsely report success; use
+  `failure-integrity-review`.
+- The task is only backend or server deployment rollout, probes, canaries, or rollback; use
+  `deployment-rollout-safety-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Process ledger: process role, platform, supervisor, user session, privilege level, data directory,
+  account or profile scope, autostart path, UI relationship, updater relationship, and shutdown
+  owner.
+- Recovery ledger: durable checkpoint, last safe offset, job table, local queue, lease fields,
+  startup recovery flow, stale-lock cleanup, partial-write handling, and corruption response.
+- Instance ledger: app single-instance lock, user-session lock, data-directory lock, account lock,
+  updater/helper lock, lock acquisition timing, stale lock detection, and cross-elevation or
+  cross-session behavior.
+- Supervisor ledger: Windows SCM, scheduled task, launchd daemon or agent, systemd user or system
+  unit, restart policy, backoff, start-rate limit, manual stop behavior, safe mode trigger, and
+  environment or working-directory contract.
+- Health ledger: PID check, event-loop progress, IPC response, database or file lock check, queue
+  progress, heartbeat fields, last progress time, current job id, processed offset, last success,
+  last error code, and stuck-work classification.
+- Lifecycle ledger: normal stop, crash, kill, logout, shutdown, preshutdown, sleep, resume, network
+  loss, VPN change, disk full, permission loss, clock jump, antivirus file lock, update, rollback,
+  and first-start-after-update behavior.
+- Security ledger: IPC ACL, local token, origin or caller verification, schema version, request size
+  limit, request timeout, least privilege, writable paths, service SID, sandboxing, secret storage,
+  and crash/log redaction.
+- Existing tests, telemetry, crash reports, logs, package or installer 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 process, supervisor, recovery, and lifecycle evidence is available from current files,
+  diffs, docs, configured outputs, user-provided evidence, or can be reported as missing without
+  guessing.
+- Treat OS documentation, installer manifests, service plist or unit files, registry entries,
+  autostart entries, and package scripts as contract surfaces when the change depends on them.
+- If the change touches money, privacy, security, migrations, queue semantics, file corruption, or
+  cloud sync, also use the narrower matching skill when its trigger is present.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten durable checkpoints, local job states, leases, startup recovery, stale-lock cleanup,
+  single-instance locks, data-directory locks, idempotency keys, atomic file writes, fsync/rename
+  write paths, exit-code classification, health probes, progress heartbeats, restart backoff,
+  safe-mode thresholds, lifecycle handlers, sleep/resume recovery, IPC authorization, explicit
+  environment setup, least-privilege configuration, early logging, crash reporter metadata, and
+  focused lifecycle tests.
+- Separate UI process lifecycle from worker process lifecycle when the visible app, tray app,
+  renderer, helper, or worker currently owns unrelated shutdown or recovery behavior.
+- Prefer OS supervisors such as Windows SCM, launchd, and systemd over hand-rolled infinite monitor
+  loops when the platform already owns restart and lifecycle policy.
+- Do not add a watchdog, autostart entry, restart policy, or hidden process solely to hide crashes.
+- Do not rely on shutdown hooks as the primary persistence path.
+- Do not broaden privileges, writable paths, IPC trust, or background execution scope to make
+  recovery easier.
+- Do not start raw services, background processes, profilers, OS lifecycle tests, login item changes,
+  installer changes, or system configuration outside the configured command contract.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the process boundary.
+   - Name each background process, helper, renderer, service, agent, updater, tray app, and worker.
+   - Record the owner of data, UI, IPC, update, crash reporting, and shutdown for each role.
+   - Reject "the app is running" as a sufficient invariant when visible UI and background work have
+     different lifecycles.
+2. Treat process death as normal.
+   - Identify what state is safe after crash, kill, logout, shutdown, update, or power loss.
+   - Move essential progress from memory-only state into durable checkpoints, local job records,
+     append-only logs, or recoverable files.
+   - Report any path whose only recovery story is "the process should not die."
+3. Make startup recovery explicit.
+   - On process start, recover leased jobs, stale locks, partial files, local queues, pending sync
+     records, interrupted migrations, and previous crash metadata before accepting new work.
+   - Keep recovery bounded and observable; a restart that immediately re-enters the same corrupted
+     state is a crash loop, not resilience.
+4. Separate process single-instance from resource ownership.
+   - Acquire app or process single-instance locks before opening databases, queues, files, IPC
+     sockets, network sessions, or updater resources.
+   - Also review locks by data directory, profile id, account id, device id, and privilege/session
+     boundary.
+   - Do not assume one desktop session, one elevation level, or one helper binary means one writer.
+5. Model jobs with leases and terminal states.
+   - Prefer `pending`, `leased`, `done`, and `failed` or equivalent explicit states over one
+     "processing" boolean.
+   - Include `job_id`, `dedupe_key`, `attempt`, `lease_until`, `completed_at`, and failure reason
+     when repeated work or restart recovery can happen.
+   - Recover expired leases and keep in-flight side effects idempotent.
+6. Make writes crash-safe.
+   - For settings, checkpoints, queues, indexes, tokens, and manifests, prefer write-temp,
+     flush, fsync, and atomic rename or the repository's equivalent safe-write helper.
+   - Ensure a crash leaves either the old version or the new version, not a half-written JSON, TOML,
+     database, index, or checkpoint.
+7. Persist during normal operation.
+   - Treat shutdown hooks, preshutdown callbacks, signal handlers, and app quit events as best-effort
+     cleanup, not the only moment progress is saved.
+   - Keep long cleanup out of direct service control handlers unless the platform contract supports
+     reporting progress safely.
+8. Use the OS supervisor deliberately.
+   - For Windows, review SCM failure actions, delayed auto-start, service SID, preshutdown, and
+     Session 0 isolation.
+   - For macOS, choose LaunchDaemon for system-wide work and LaunchAgent for per-user work, and do
+     not daemonize under launchd.
+   - For Linux, review systemd user versus system units, restart policy, start-rate limits, working
+     directory, environment, and sandboxing.
+9. Add restart discipline.
+   - Automatic restart needs backoff, max attempts, failure classification, and safe mode.
+   - Preserve a user-intentional stop separately from crash recovery so scheduled restarts do not
+     surprise users after they explicitly stopped the background process.
+   - Detect crash loops and stop consuming CPU, battery, network, and trust.
+10. Replace PID checks with progress checks.
+    - A live PID only proves a process exists.
+    - Prefer health that proves event-loop turns, IPC responses, local storage access, queue progress,
+      last successful sync, last progress time, and bounded latency.
+    - Separate alive, ready, progressing, degraded, and blocked states when the UI or supervisor uses
+      the result.
+11. Make heartbeats useful.
+    - Heartbeats should include progress evidence, such as `last_progress_at`, `current_job_id`,
+      `processed_offset`, `last_successful_sync_at`, `last_error_code`, process start id, build
+      version, and attempt.
+    - Avoid `last_seen_at` alone when a tight loop, deadlock, or stuck queue can keep updating it.
+12. Keep UI and background lifecycle separate.
+    - Closing a window, hiding a tray icon, renderer crash, UI reload, or WebView crash should not
+      silently kill durable background work unless that is the explicit product contract.
+    - A worker crash should be visible to the UI as degraded or recovering, not hidden behind stale
+      status text.
+13. Respect desktop platform boundaries.
+    - Do not show UI directly from a Windows service running in Session 0; communicate with a
+      user-session process through authorized IPC.
+    - Do not put per-user macOS camera, clipboard, notification, home-directory, or UI-like work into
+      a system daemon when a LaunchAgent is the proper boundary.
+    - Do not solve network availability through boot ordering alone.
+14. Treat sleep and resume as first-class failures.
+    - On resume, suspect sockets, DNS, VPN, file handles, timers, leases, auth sessions, and
+      reachability.
+    - Revalidate network and storage before resuming queued work.
+    - Keep stale in-memory timers from making lease or timeout decisions after a long sleep.
+15. Use monotonic time for durations.
+    - Measure timeouts, lease intervals, heartbeat gaps, retry delay, and crash-loop windows with a
+      monotonic clock or equivalent elapsed-time source.
+    - Use wall-clock timestamps only for user-visible time and audit records that need calendar time.
+16. Harden IPC.
+    - Treat localhost ports, named pipes, Unix sockets, custom protocols, shared memory, and
+      renderer-to-main messages as local attack surfaces.
+    - Add ACLs, caller tokens, origin checks, message schema versions, request size limits, per-request
+      timeouts, and safe error handling where applicable.
+17. Make environment deterministic.
+    - Use absolute executable paths, explicit working directories, explicit data directories, and
+      bounded environment variables.
+    - Do not depend on a shell PATH, current directory, inherited locale, inherited HOME, or interactive
+      user environment unless the contract states that requirement.
+18. Reduce privilege and write scope.
+    - Run background work with the least privilege that can do the job.
+    - Limit writable directories to data, logs, crash dumps, and update staging paths that are actually
+      needed.
+    - Keep elevated helpers small, IPC-gated, audited, and unable to execute arbitrary UI commands.
+19. Capture earliest failure evidence.
+    - Initialize crash reporting and stdout or stderr capture before creating renderers, workers, IPC,
+      or long startup work.
+    - Include app version, channel, OS, architecture, process role, process start id, job id, safe
+      account hash, feature flags, exit reason, and supervisor restart reason when the repository has
+      safe observability patterns.
+    - Redact secrets, tokens, paths, raw account identifiers, and user content.
+20. Make updates restart-safe.
+    - Before updating, drain or shorten leases, persist checkpoints, pause risky queue consumers, and
+      keep rollback or previous-version compatibility evidence.
+    - Make migrations and helper registration re-entrant.
+    - Do not delete the old executable, helper, service definition, or data compatibility path before
+      the new version proves healthy.
+21. Add real lifecycle tests or explicit manual gaps.
+    - Prefer tests or probes for double start, stale lock, expired lease recovery, atomic write crash
+      boundary, IPC denial, user stop versus crash restart, sleep/resume handling, update interruption,
+      corrupted local file, disk full, permission denial, and safe-mode entry.
+    - If OS-level lifecycle tests are not configured intents, report them as manual-only evidence gaps.
+22. Define safe mode.
+    - After repeated crashes or startup failures, disable risky plugins, queue consumption, sync loops,
+      GPU-heavy features, recent migrations, or aggressive background work.
+    - Keep enough diagnostics for repair, and avoid a crash loop that consumes CPU, battery, network,
+      or user trust.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Process roles, durable state, startup recovery, instance locks, supervisor policy, restart backoff,
+  health checks, progress heartbeats, job leases, atomic writes, shutdown behavior, exit-code
+  semantics, UI and worker lifecycle, platform boundaries, sleep/resume, monotonic time, IPC,
+  environment, privilege, logging, crash reporting, update safety, lifecycle tests, and safe mode are
+  explicit.
+- Memory-only state, late single-instance locks, PID-only health checks, `last_seen_at`-only
+  heartbeats, one "processing" boolean, non-atomic local files, shutdown-only persistence, hand-rolled
+  monitor loops, unbounded restart loops, user-stop/restart confusion, service UI from Session 0,
+  daemon/agent mismatch, daemonizing under launchd, boot-order network assumptions, wall-clock lease
+  timers, trusted local IPC, inherited PATH or working directory dependence, overprivileged helpers,
+  missing early logs, uninitialized crash reporter gaps, one-shot migrations, and no-op safe mode are
+  fixed or reported.
+- Desktop background stability claims are backed by configured tests, static-review evidence,
+  telemetry or crash 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 process, supervisor, template, installer, IPC, file-write, queue, or lifecycle surface. Do
+not infer raw service starts, launchd loads, systemd starts, installer changes, login item edits,
+sleep/resume automation, crash reporter dashboards, or OS lifecycle harnesses 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 lifecycle invariant it exercised before editing again.
+- If only static evidence is available, report that OS-supervisor, sleep/resume, update, and
+  crash-loop behavior still need manual or platform harness validation.
+- If safe repair requires installer changes, service registration changes, updater design, privilege
+  changes, OS lifecycle harnesses, migration policy, or product decisions outside scope, report that
+  boundary instead of inventing commands.
+- If process stability conflicts with data safety, user intent, security, privacy, least privilege,
+  update rollback, or battery life, keep the safer behavior and report the tradeoff.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Desktop background process stability boundary reviewed
+- Process, recovery, instance-lock, supervisor, restart, health, heartbeat, lease, atomic-write,
+  shutdown, platform, power, time, IPC, environment, privilege, logging, crash, update, lifecycle-test,
+  and safe-mode findings
+- Stability fixes made or recommended
+- Evidence level: configured-test evidence, static desktop-process risk, telemetry/crash evidence,
+  manual-only, missing, or not applicable
+- Command intents run
+- Skipped desktop lifecycle diagnostics and reasons
+- Remaining desktop background process stability risk

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

@@ -0,0 +1,318 @@
+---
+mustflow_doc: skill.desktop-memory-footprint-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: desktop-memory-footprint-review
+description: Apply this skill when Windows, macOS, Linux, Electron, WebView, WPF, WinUI, Win32, Qt, Java Swing or JavaFX, .NET, JVM, Rust, C++, Python, or other desktop app code needs memory-footprint review for working set versus private memory, RSS, dirty pages, live set, peak and after-close memory, UI and data virtualization, renderer and window count, module loading, image decode size, OS-discardable caches, memory-mapped files, `madvise`, `EmptyWorkingSet`, .NET LOH and `ArrayPool<T>`, WPF visual trees, GDI or USER handles, detached DOM nodes, hidden windows or tabs, string deduplication, large buffer capacity, struct padding, object graph shape, undo history, inactive views, low-memory signals, and scenario-level memory budgets.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.desktop-memory-footprint-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Desktop Memory Footprint Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review desktop app memory as a scenario-level footprint problem across UI objects, data residency,
+native handles, renderer processes, decoded media, caches, mapped files, heap live sets, and
+after-close cleanup.
+
+The review question is not "can GC run more often?" It is "which screens, files, windows, renderers,
+decoded assets, caches, handles, buffers, strings, and history entries remain resident, private,
+dirty, or expensive after the user no longer needs them?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Windows, macOS, Linux, Electron, WebView, WPF, WinUI, Win32, Qt, Java Swing, JavaFX, .NET, JVM,
+  Rust, C++, Python, or other desktop app code is created, changed, reviewed, or reported with
+  memory use, working set, RSS, private bytes, dirty memory, live set, heap growth, GPU memory,
+  native handles, renderer process, hidden window, tab, large file, image, cache, undo history, or
+  after-close memory risk.
+- Code touches large lists, tables, trees, CSV or log viewers, binary viewers, image viewers, note
+  apps, chat apps, design tools, document editors, preview panes, hidden tabs, background windows,
+  file loading, memory maps, caches, pooled buffers, strings, object models, visual templates,
+  event listeners, WebViews, Electron `BrowserWindow`, preload scripts, `require()` graphs, native
+  GDI or USER objects, or low-memory handling.
+- A final report claims a desktop path is memory optimized, leak-free, lightweight, safe for large
+  files, safe for long-running sessions, safe after closing tabs or windows, or validated by Task
+  Manager, Activity Monitor, Chrome DevTools, JFR, dotnet counters, heap snapshots, or platform
+  memory tools.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is only about retained-reference leaks, setup and cleanup symmetry, listeners, timers,
+  streams, workers, or native handle release ownership; use `memory-lifetime-review`.
+- The task is only about generic hot-path latency, throughput, allocation churn, GC pressure, or
+  cost multipliers with no desktop app memory surface; use `performance-budget-check`.
+- The task is only installed app startup from process launch to first frame or fully usable state;
+  use `app-startup-performance-review`.
+- The task is only low-end or constrained-device policy across mobile or installed app capability
+  budgets; use `low-end-device-support-review`.
+- The task is only browser page rendering, INP, DOM frame work, CSS layout, paint, or compositing;
+  use `frame-render-performance-review`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Scenario ledger: app type, platform, runtime, process model, target device class, user scenario,
+  baseline state, peak state, steady state, after-close state, and what user action should release
+  memory.
+- Measurement ledger: working set, RSS, private bytes, dirty memory, live set after full collection,
+  heap snapshot, allocation sampling, detached DOM evidence, renderer memory, native handle count,
+  GPU texture memory, page faults, memory pressure event, or an explicit static-only boundary.
+- UI residency ledger: list, table, tree, virtualized control, data model, visual tree, template,
+  row container recycling, offscreen view, hidden tab, hidden window, preview pane, WebView,
+  renderer process, iframe, DOM node, event listener, and teardown behavior.
+- Data residency ledger: full file load, streaming parser, memory-mapped file, mapped window,
+  `madvise` or OS-discardable range, parsed row model, sort index, filter index, search index,
+  undo history, diff model, document snapshot, and after-close release point.
+- Cache ledger: cache owner, cache item cost, total cost limit, count limit, eviction, weak or
+  discardable behavior, decoded image bytes, GPU texture size, parsed object cost, font or renderer
+  cache, and low-memory response.
+- Runtime ledger: Electron `BrowserWindow`, preload and `require()` graph, WPF virtualization,
+  WPF visual tree, Qt `canFetchMore()` and `fetchMore()` or lazy model loading, .NET LOH,
+  `ArrayPool<T>`, GDI or USER
+  handles, JVM live set, Java string deduplication, Rust or C++ buffer capacity, struct padding,
+  and native resource 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 memory evidence is available from current files, diffs, docs, configured outputs,
+  user-provided evidence, or can be reported as missing without guessing.
+- Treat Task Manager working set, Activity Monitor, RSS, and one-off heap-used snapshots as partial
+  evidence. Do not equate lower resident pages with lower owned memory without private, dirty, live
+  set, after-close, or retainer evidence.
+- If the change touches privacy, security, payment, persistence, migrations, crash reporting,
+  telemetry, or data recovery, also use the narrower matching skill when its trigger is present.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten UI virtualization, data virtualization, container recycling, lazy model fetch,
+  renderer or window disposal, feature-entry module loading, image downsampling, cache cost limits,
+  discardable cache behavior, streaming or memory-mapped file access, mapped-range release hints,
+  low-memory handlers, after-close cleanup, undo compaction, object-shape flattening, string or
+  symbol tables, pooled-buffer scope, native handle release, and focused tests.
+- Replace full UI object creation, full file reads, eager renderer creation, hidden window retention,
+  original-size bitmap retention, unbounded dictionaries, per-item visual templates, whole-document
+  undo snapshots, and long-lived large buffer capacity when the repository evidence supports it.
+- Do not call working-set trimming APIs such as `EmptyWorkingSet` merely to make Task Manager look
+  better.
+- Do not add a "clear cache" button as the primary memory policy when the app can release memory
+  automatically by scenario, pressure, close, or eviction.
+- Do not trade correctness, user data recovery, undo semantics, accessibility, security, privacy,
+  crash diagnostics, or platform lifecycle safety for lower memory numbers.
+- Do not start raw profilers, device tools, dashboards, browser sessions, app launches, or
+  platform-specific measurement workflows outside the configured command contract.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define scenario budgets before optimizing.
+   - Prefer scenario budgets such as first launch, empty document, open small file, open large file,
+     scroll many rows, preview many images, open many tabs, close all tabs, and idle after close.
+   - Track peak, steady-state, and after-close memory separately.
+   - If no budget exists, report the missing product memory contract instead of claiming complete
+     optimization from a small cleanup.
+2. Choose the right memory number.
+   - Distinguish working set or RSS from private committed memory, dirty pages, live heap after full
+     collection, mapped file pages, GPU resources, renderer processes, and native handles.
+   - Treat page faults and memory mapping as reasons resident memory may move without ownership
+     changing.
+   - Reject "working set went down" as proof when the change only forces paging and the next user
+     interaction faults pages back in.
+3. Separate UI virtualization from data virtualization.
+   - UI virtualization reduces visible containers and visual objects.
+   - Data virtualization reduces resident source rows, parsed objects, sort indexes, and filter
+     indexes.
+   - A million-row view that keeps a million parsed rows in memory is not fixed by virtualizing
+     only row controls.
+4. Virtualize lists, tables, and trees.
+   - Ensure large views create only visible containers plus a bounded buffer.
+   - Enable container recycling where the framework supports it.
+   - Avoid per-row buttons, text objects, checkboxes, handlers, and layout objects for offscreen
+     rows.
+5. Count expanded visual objects.
+   - In WPF, WinUI, Qt, JavaFX, WebView, or custom UI frameworks, inspect expanded templates and
+     repeated visual trees, not only component count.
+   - A single friendly-looking template multiplied by thousands of rows can create the real memory
+     footprint.
+6. Control Electron and WebView process count.
+   - Treat each `BrowserWindow`, WebView, iframe, preload script, and renderer as a memory owner.
+   - Prefer stateful navigation or view reuse only when it does not keep hidden DOM, JS heap, GPU
+     textures, and renderer caches alive.
+   - Destroy closed windows when fast reopen can be served by persisted state rather than a hidden
+     renderer.
+7. Defer desktop modules by journey.
+   - Do not load PDF engines, spell checkers, AI models, export libraries, ZIP libraries, markdown
+     renderers, plugin hosts, or full font and theme packs at app start when a feature entry can
+     load them.
+   - In Electron and Node-like runtimes, inspect preload and `require()` graphs for modules that
+     survive only because startup imported them.
+8. Decode media to displayed size.
+   - Judge images by decoded pixel bytes, not file size.
+   - Downsample large images for thumbnails, previews, chat cells, notes, and document sidebars.
+   - Bound decoded bitmap caches and GPU texture caches by cost, not only item count.
+9. Make caches discardable by cost.
+   - Store only rebuildable values in memory caches.
+   - Use byte, texture, DOM node, parsed-object, or renderer cost when deciding eviction.
+   - Prefer OS-discardable, weak, pressure-aware, or cost-limited caches where the platform supports
+     them, such as `NSCache` with `countLimit` and `totalCostLimit`.
+   - Avoid global `Map`, `Dictionary`, or static cache structures that never evict.
+10. Stream or map large files.
+    - Avoid full `readAll`, `read()`, `ReadAllBytes`, `json.load`, or equivalent APIs on growing
+      logs, CSVs, database dumps, binary files, and media.
+    - Prefer streaming, chunked parsing, paging, or memory-mapped files with bounded windows.
+    - For mapped files, remember that address-space visibility is not the same as resident physical
+      RAM.
+11. Release mapped or inactive ranges deliberately.
+    - Where supported, use OS hints such as `madvise`-style discard for ranges the app can reread.
+    - Keep this as a paging and residency tool, not as a substitute for shrinking live object graphs.
+12. Handle .NET large objects carefully.
+    - Treat arrays near or above the 85,000 byte LOH threshold as Gen 2 and fragmentation risks.
+    - Use `ArrayPool<T>` for short-lived buffers only when ownership is tight and return timing is
+      provable.
+    - Do not return pooled buffers while another async operation, native API, or consumer may still
+      use them.
+13. Keep native handles in the memory review.
+    - Track GDI, USER, bitmap, brush, font, pen, region, cursor, icon, file, socket, and OS handle
+      counts where applicable.
+    - Pair native create and destroy functions and test repeated open, draw, print, capture, tray,
+      and close paths.
+14. Find detached UI trees.
+    - For Electron, WebView, browser-based UI, and hybrid apps, inspect detached DOM nodes, event
+      listeners, console-retained objects, devtools artifacts, and JS references from stores,
+      callbacks, promises, and logs.
+    - Separate measurement artifacts from app leaks when DevTools or a console binding retains the
+      object.
+15. Shrink duplicate strings and symbols.
+    - Repeated JSON field names, log levels, file paths, status strings, tags, categories, and table
+      cell text can dominate live heap.
+    - Use enums, symbol ids, intern tables, shared dictionaries, or JVM string deduplication where
+      the runtime and workload justify it.
+16. Watch live set after cleanup.
+    - For JVM and similar runtimes, inspect live set after old or full collection across repeated
+      open, close, search, tab, and file workflows.
+    - A staircase increase after every close is a leak or retention problem even when current heap
+      use looks temporarily low.
+17. Shrink large buffer capacity explicitly.
+    - In Rust, C++, and similar runtimes, `clear()` usually preserves capacity.
+    - After one-time large operations, use an explicit shrink, replacement, or bounded reusable
+      buffer policy when retaining capacity hurts later scenarios.
+18. Reduce padding and pointer forests in bulk models.
+    - For millions of rows, render nodes, cells, or document spans, review struct field order,
+      alignment padding, object headers, boxed metadata, and pointer-heavy object graphs.
+    - Prefer columnar arrays, struct-of-arrays, shared style tables, integer ids, compact enums, and
+      pooled strings where the product model supports it.
+19. Store history as deltas.
+    - Avoid undo stacks made of full document snapshots.
+    - Prefer operation logs, field-level patches, tile diffs, rope or piece-table structures, and
+      bounded checkpoints when the product needs undo or diff.
+20. Degrade inactive views.
+    - When tabs, documents, previews, canvases, images, search results, WebViews, and GPU textures
+      become inactive, release or downgrade backing stores by tier.
+    - Keep enough state to restore the view, not necessarily the whole rendered surface.
+21. Make low-memory handling real.
+    - On memory pressure, release thumbnail caches, decoded images, inactive document caches,
+      hidden WebViews, search index caches, parsed previews, GPU textures, and large temporary
+      buffers in a defined order.
+    - Log or expose bounded reason and outcome evidence where the repository already has a safe
+      observability pattern.
+22. Prove after-close behavior.
+    - Repeat open, load, scroll, search, preview, close, reopen, and idle transitions.
+    - Prefer tests or probes that assert row container count, model page count, cache total cost,
+      native handle count, renderer count, hidden window count, pool checkout count, undo memory
+      budget, or after-close state.
+    - If heap snapshots, allocation sampling, JFR, dotnet counters, Instruments, Windows tools,
+      Chrome DevTools, or platform profilers are not configured intents, report them as manual-only
+      evidence gaps.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Scenario budget, measurement metric, UI virtualization, data virtualization, visual tree count,
+  renderer or window count, module loading, decoded media, cache cost, mapped files, inactive
+  ranges, LOH or pooled buffers, native handles, detached UI trees, duplicate strings, live set,
+  buffer capacity, object graph shape, undo strategy, inactive views, low-memory handling, and
+  after-close behavior are explicit.
+- Full UI object creation, UI-only virtualization, hidden renderer retention, eager feature modules,
+  original-size thumbnails, item-count-only caches, full file reads, mapped ranges held forever,
+  working-set trimming theater, unsafe pooled buffer return, GDI or USER handle leaks, detached DOM
+  retention, console measurement artifacts, duplicate strings, live-set staircases, cleared-but-huge
+  buffers, padded bulk structs, pointer-heavy row models, whole-document undo snapshots, inactive
+  tabs kept fully rendered, and no-op low-memory handlers are fixed or reported.
+- Desktop memory claims are backed by configured tests, profiler 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 desktop memory surface and synchronized template surfaces. Do not infer raw heap snapshots,
+JFR, dotnet counters, Chrome DevTools, Windows Performance tools, Instruments, Activity Monitor,
+Task Manager, app launchers, or platform profilers 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 memory invariant it exercised before editing again.
+- If the metric is only working set, RSS, or a single live heap value, report the evidence boundary
+  before claiming memory was reduced.
+- If scenario budgets are missing, report that desktop memory fitness cannot be fully judged yet
+  instead of treating isolated GC, cache, or object-count changes as complete.
+- If safe repair requires product changes to undo semantics, document recovery, renderer
+  architecture, plugin policy, native resource ownership, profiler setup, or OS-specific behavior
+  outside scope, report the boundary instead of inventing commands.
+- If memory reduction conflicts with correctness, persistence, undo, accessibility, crash
+  diagnostics, privacy, security, or user trust, keep the safer behavior and report the tradeoff.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Desktop memory footprint boundary reviewed
+- Scenario budget, measurement metric, UI/data virtualization, renderer/window, module loading,
+  media, cache, file, runtime, native handle, UI retention, string, data model, history, inactive
+  view, memory-pressure, and after-close findings
+- Desktop memory fixes made or recommended
+- Evidence level: measured, configured-test evidence, static desktop-memory risk, manual-only,
+  missing, or not applicable
+- Command intents run
+- Skipped desktop memory diagnostics and reasons
+- Remaining desktop memory footprint risk