mustflow 2.38.0 → 2.58.0

package/templates/default/locales/en/.mustflow/skills/api-request-performance-review/SKILL.md

@@ -0,0 +1,189 @@
+---
+mustflow_doc: skill.api-request-performance-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: api-request-performance-review
+description: Apply this skill when API endpoints, handlers, controllers, resolvers, serializers, mappers, service methods, or route-level request paths are created, changed, reviewed, or reported and the main latency risk is repeated work inside one request, including per-request I/O counts, DB or ORM fan-out, Redis fan-out, external API calls, transaction scope, pool acquire wait, cache miss paths, serialization, response size, request-path CPU work, or missing trace evidence.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.api-request-performance-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# API Request Performance Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review API latency as repeated work inside one request, not as a search for an ugly slow function.
+
+The core question is: "For one request, how many times do we repeat the same I/O, data fetch, serialization, lock wait, transaction wait, or CPU-heavy operation before sending the response?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- An API endpoint, handler, controller, route, resolver, serializer, mapper, service method, middleware, webhook receiver, backend-for-frontend path, admin API, or request-scoped worker path is created, changed, reviewed, or reported.
+- The likely risk is per-request I/O, DB query count, ORM lazy loading, Redis fan-out, external API calls, filesystem reads, transaction scope, pool acquire wait, cache miss behavior, JSON serialization, response bytes, DTO mapping, compression, crypto, image/file processing, or missing spans.
+- Code or docs claim an API path is fast, paginated, cached, batched, preloaded, streaming, bounded, safe at p95 or p99, or protected by instrumentation.
+- A route-level performance finding needs a request cost ledger before a broader performance-budget, load-test, database-plan, or profiling project.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a general hot-path review without an API request boundary; use `hot-path-performance-review`.
+- The task is only database query shape, migration safety, or engine-specific query tuning with no route-level request path; use `database-query-bottleneck-review` or the matching database skill.
+- The task is primarily cache correctness, stale data spread, permission leakage, or invalidation order; use `cache-integrity-review`.
+- The task is primarily reliability, retry, timeout, queue, health-check, or operational failure handling rather than per-request latency; use `backend-reliability-change`.
+- The task is a full measurement, benchmark, production profiling, load-test, service-level objective, or p95/p99 performance-budget project; use `performance-budget-check` as the main route.
+- The route-level request path is slow mainly because of LLM response latency, time to first token, first useful output, streaming, LLM round trips, tool-call wait, prompt-cache latency, model routing speed, realtime continuation, priority tier, or predicted-output behavior; use `llm-response-latency-review`.
+- The API path is explicitly tiny, hard-capped, offline-only, or manual-only and the bounded request size is documented.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Request path: endpoint, route, handler, controller, resolver, serializer, mapper, middleware, service method, response builder, and downstream calls under review.
+- Request cost ledger inputs: route span, DB query count, Redis call count, external API call count, filesystem or object-storage calls, payload size, response bytes, JSON serialization time, DTO mapping time, cache hit or miss, queue time, pool acquire wait, transaction duration, lock wait, and request-path CPU work when available.
+- Data shape: request parameters, page size, relation counts, tenant or user scope, expected result size, maximum payload, large JSON/TEXT/BLOB fields, and response projection.
+- ORM behavior: lazy loading, eager loading, generated SQL, relation access in serializers or templates, Django `select_related` and `prefetch_related`, Rails `includes`, `preload`, `eager_load`, and `strict_loading`, or equivalent framework behavior.
+- Database evidence when available: `SELECT *`, app-side filtering or sorting, deep `OFFSET`, `COUNT(*)`, index fit for `WHERE` plus `ORDER BY` plus `LIMIT`, `EXPLAIN`, estimated rows, actual rows, join cardinality, and selectivity.
+- Cache and Redis evidence: request-scope cache, key dimensions, cache miss path, `MGET`, pipeline behavior, Redis round trips, Redis Slow Log limitations, hot keys, fallback behavior, and stampede controls.
+- Correctness boundaries: authorization, tenant isolation, ordering, duplicates, pagination stability, consistency, idempotency, timeout, cancellation, partial failure, stale data, and response contract.
+- Relevant command-intent contract entries for build, tests, 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 route, query-count, trace, cache, or payload evidence can be reported without guessing.
+- If database query shape is changed, also apply the matching database skill.
+- If cache correctness or invalidation behavior changes, also apply `cache-integrity-review`.
+- If retry, timeout, queue, health, idempotency, or external-service failure behavior changes, also apply `backend-reliability-change`.
+- If authorization, tenant scope, personal data, logs, telemetry, or cache keys affect the API path, also apply the relevant security or privacy skill.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Narrow projection, remove route-level overfetching, batch per-item database or Redis calls, replace repeated external calls with bounded aggregation, add request-scope memoization, move app-side filtering or sorting into the right data layer, shorten transactions, and add bounded concurrency where semantics are clear.
+- Add or tighten route-level observability for route span timing, DB query count, pool acquire wait, Redis count, cache hit or miss, external latency, response bytes, JSON serialization time, queue time, and request-path CPU work when local patterns support it.
+- Add focused tests or fixtures for query count, lazy-loading prevention, pagination stability, response projection, authorization scope, cache key dimensions, timeout behavior, serialization shape, or error boundaries when repository patterns support them.
+- Do not add speculative caches, unbounded eager loading, unbounded concurrency, broad denormalization, new infrastructure, raw load tests, or profiling hooks without evidence and ownership of invalidation, backpressure, and failure behavior.
+- Do not trade correctness, authorization, tenant isolation, response contract, idempotency, ordering, or partial-failure behavior for a faster-looking request path.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Name the API request boundary first. Include the route, handler, controller, resolver, serializer, mapper, service method, response builder, and downstream calls that run before the response is committed.
+2. Build a Request cost ledger. Record DB query count, Redis round trips, external API calls, filesystem or object-storage calls, cache hit or miss, payload size, response bytes, JSON serialization time, DTO mapping time, pool acquire wait, transaction duration, lock wait, queue time, and request-path CPU work. Mark unavailable values as missing evidence rather than inventing them.
+3. Count repeated I/O before reading abstraction names.
+   - A loop, mapper, serializer, resolver, template, or DTO builder that calls DB, Redis, HTTP, RPC, filesystem, object storage, provider SDK, queue, logger, metrics, crypto, compression, or image processing is the first suspect.
+   - Sequential `await` inside a loop is still serial request latency unless the operations are order-dependent.
+   - Unbounded fan-out is not a fix. Use bounded concurrency only when the downstream resource and failure behavior are understood.
+4. Inspect ORM serializer and mapper paths.
+   - Property reads such as `user.team.name`, `order.items`, `post.comments`, or equivalent relation access can be hidden queries.
+   - In Django, choose `select_related` for single-valued relations and `prefetch_related` for multi-valued relations when the route actually needs them.
+   - In Rails, compare `includes`, `preload`, `eager_load`, and `strict_loading`; use strict loading or query-count tests where local patterns support them.
+   - Treat eager loading too much as a separate bug. It can replace N+1 with row explosion, duplicate parents, memory bloat, or huge response mapping.
+5. Check query projection and response projection together.
+   - Flag `SELECT *`, full entity hydration, unbounded DTOs, and list endpoints that fetch large JSON, TEXT, BLOB, image, metadata, audit, or internal columns.
+   - Fetch detail fields only after narrowing the row set when the route returns a list, feed, search result, or admin table.
+6. Push filtering, sorting, grouping, and distinct work to the right layer.
+   - App-side filtering after loading many rows usually hides a database or cache misuse.
+   - App-side sorting, grouping, or `distinct` after join fan-out can turn a small response into a large server memory job.
+   - Preserve authorization, tenant scope, null semantics, duplicates, and stable ordering when moving work.
+7. Review pagination and counts as latency surfaces.
+   - Deep `OFFSET` pages usually make the database count and discard earlier rows.
+   - Prefer keyset or cursor pagination with stable tie-breakers when arbitrary page jumps are not a product requirement.
+   - Expensive `COUNT(*)` for every request needs a product reason, approximate or cached count policy, or deferred count behavior.
+8. Match indexes to the whole request query.
+   - Check `WHERE`, `ORDER BY`, and `LIMIT` together instead of asking only whether one predicate has an index.
+   - Functions around columns, implicit casts, `LOWER(email)`, `DATE(created_at)`, timezone conversion, `%keyword%`, low-selectivity predicates, and mismatched sort order can defeat useful index access.
+   - When plan evidence exists, compare `EXPLAIN` estimated rows with actual rows, join cardinality, loops, rows examined, rows returned, buffers, temp files, sort method, and lock or pool wait.
+9. Keep external calls out of transactions.
+   - Do not hold a DB transaction while waiting for an external API, file upload, object storage, Redis fallback, image processing, logging sink, or user-controlled operation.
+   - Move external effects after commit with an outbox, job, reconciliation record, or idempotent follow-up only when the repository already owns that pattern.
+10. Separate database execution time from pool acquire wait.
+    - A query can look fast while the request waits for a saturated connection pool.
+    - Review pool acquire time, pool size, transaction duration, connection leaks, per-request client creation, and slow downstream calls holding connections.
+11. Check Redis as a network service, not as free memory.
+    - Redis calls inside loops are request latency. Prefer `MGET`, pipelining, batching, or request-scope cache when semantics allow.
+    - Redis Slow Log does not include client round-trip time, connection wait, serialization, or application loop overhead.
+    - Review cache miss path, fallback DB pressure, stampede control, hot keys, and key cardinality before calling the cache safe.
+12. Review cache key scope and miss behavior.
+    - A key that is too narrow can leak or serve wrong data; a key that is too wide can explode cardinality and never hit.
+    - Count what happens on miss: DB calls, external calls, serialization, lock or singleflight behavior, early refresh, negative caching, stale serve, and timeout.
+13. Count JSON, DTO, and response building costs.
+    - Repeated JSON parse/stringify, broad DTO-to-DTO mapping, deep clone, object spread over large arrays, and whole-object logging can dominate route CPU.
+    - Large response bytes increase server serialization, compression, network transfer, browser parse, and client cache pressure.
+14. Check request-path CPU before offloading blame to the database.
+    - Compression, crypto, hashing, image resize, PDF or spreadsheet generation, diffing, regex, report rendering, and large locale formatting can block the request.
+    - For Node, look for event-loop blocking and flame graph evidence when available. For Go, use pprof evidence when available. For MongoDB, inspect `explain()` evidence when the route depends on MongoDB query shape.
+15. Treat observability as part of the fix when evidence is missing.
+    - Add OpenTelemetry or existing tracing spans only through local patterns.
+    - Prefer route span, DB query count, Redis count, external-call count, pool acquire wait, cache hit or miss, external latency, response bytes, JSON serialization time, queue time, timeout count, and error category over vague "seems slow" comments.
+16. Rank fixes by request payoff.
+    - Usually fix per-item DB or Redis calls, ORM lazy loading, app-side filtering after overfetch, deep offset pagination, expensive counts, external calls inside transactions, pool waits, unbounded fan-out, huge responses, and missing spans before micro-optimizing helper code.
+17. Label evidence honestly.
+    - Static review can identify likely API latency risks but cannot prove speedup.
+    - A trace from a tiny fixture, warm local cache, or empty database is not representative production evidence.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The API request boundary and Request cost ledger are explicit.
+- DB query count, Redis call count, external API call count, cache hit or miss behavior, response bytes, serialization cost, transaction scope, pool acquire wait, and request-path CPU work are fixed, bounded, instrumented, or reported.
+- ORM lazy loading, eager-loading overfetch, `SELECT *`, app-side filtering or sorting, deep `OFFSET`, expensive `COUNT(*)`, index mismatch, external call inside transaction, Redis loop, and cache miss amplification are checked where relevant.
+- Correctness, authorization, tenant isolation, idempotency, ordering, pagination stability, partial failure, cancellation, timeout, and stale-data behavior remain intact or are reported as tradeoffs.
+- API performance claims are backed by configured evidence, trace evidence, plan evidence, or labeled as static review risk.
+
+<!-- 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 API request path. Do not infer raw server, load-test, benchmark, profiler, database shell, Redis shell, browser, or package-manager commands outside the command contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If route-level traces, query counts, payload size, cache behavior, or pool wait evidence are missing, report static risk instead of claiming measured latency.
+- If the safe fix requires engine-specific database features, use the matching database skill before editing those surfaces.
+- If the safe fix requires production traces, load tests, flame graphs, pprof captures, MongoDB `explain()` from live data, Redis Slow Log access, provider dashboards, or unconfigured commands, report the manual evidence boundary instead of running raw commands.
+- If optimization conflicts with correctness, authorization, tenant isolation, idempotency, ordering, partial failure, or the response contract, keep correctness and report the tradeoff.
+- If a configured test, build, docs, release, or mustflow command fails, preserve the failing intent and output tail, then fix only the behavior or contract exercised by the failure.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- API request path reviewed
+- Request cost ledger: route span, DB query count, Redis count, external API calls, filesystem or object-storage calls, payload size, response bytes, JSON serialization time, DTO mapping time, cache hit or miss, queue time, pool acquire wait, transaction duration, lock wait, and request-path CPU work
+- ORM lazy loading, eager loading, projection, pagination, count, index fit, app-side filtering or sorting, transaction, pool, Redis, cache miss, serialization, response size, CPU-heavy request work, and observability findings
+- API request performance change made or recommended
+- Evidence level: measured trace, configured-test evidence, plan evidence, static review risk, manual-only, missing, or not applicable
+- Command intents run
+- Skipped measurements and reasons
+- Remaining API request performance risk

package/templates/default/locales/en/.mustflow/skills/app-startup-performance-review/SKILL.md

@@ -0,0 +1,309 @@
+---
+mustflow_doc: skill.app-startup-performance-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: app-startup-performance-review
+description: Apply this skill when Android, iOS, React Native, Flutter, Tauri mobile, desktop app shell, Electron, or other installed app code needs startup performance review from icon tap or process launch to first frame and fully usable state, including cold, warm, or hot start, Android TTID and TTFD, `reportFullyDrawn()`, Android Vitals startup thresholds, Xcode Organizer, Instruments App Launch or Time Profiler, `Application.onCreate()`, `AppDelegate`, ContentProvider auto-init, AndroidX App Startup, DI graph creation, SDK initialization, static initializers, main-thread disk or network work, cache snapshots, launch migrations, first-screen layout, launch assets, custom fonts, R8, Baseline Profile, Startup Profile, Macrobenchmark, Perfetto, Hermes, JavaScript or Dart import graphs, deferred components, shader warmup, on-demand modules, splash holds, auth or config gates, and post-first-frame work queues.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.app-startup-performance-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# App Startup Performance Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review installed app startup as a launch critical path from icon tap or process start to first frame
+and fully usable state, not as a splash-screen masking problem.
+
+The review question is not "does the splash look smooth?" It is "what code, I/O, SDK, dependency
+graph, asset, first-screen, auth, or config gate blocks the user before the app can draw and before
+the first useful action works?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Android, iOS, React Native, Flutter, Tauri mobile, Electron, desktop app shell, or packaged app
+  code is created, changed, reviewed, or reported with startup, launch, splash, first frame, first
+  screen, time-to-interactive, time-to-full-display, cold start, warm start, hot start, blank screen,
+  slow app open, initial route, auth bootstrap, config bootstrap, SDK initialization, or app shell
+  performance risk.
+- Code touches `Application.onCreate()`, `AppDelegate`, Android ContentProvider auto-init, AndroidX
+  App Startup initializers, dependency injection graph creation, service locators, SDK setup, crash
+  reporting, analytics, remote config, feature flags, A/B experiments, ad SDKs, database open,
+  migrations, cache cleanup, thumbnail generation, log compression, static initializers, top-level
+  imports, global constants, first-screen assets, custom fonts, launch resources, route bootstrap,
+  React Native bundles, Flutter first frame, Tauri or Electron preload, or on-demand modules.
+- A final report claims startup is faster, startup-safe, splash-safe, fully drawn, release-ready,
+  app-store quality, Play quality, low-end-device safe, or measured by Android Vitals, TTID, TTFD,
+  `reportFullyDrawn()`, Xcode Organizer, Instruments, Macrobenchmark, Perfetto, or similar evidence.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is purely web page first render, Core Web Vitals, LCP, browser TTFB, route prefetch, or
+  web hydration outside an installed app shell; use `web-render-performance-review`.
+- The task is per-frame browser jank, INP, scroll, animation, style, layout, paint, compositing, or
+  interaction rendering after startup; use `frame-render-performance-review`.
+- The task is mobile battery, background wakeups, radio, GPS, sensors, Low Power Mode, Battery
+  Saver, or energy diagnostics without launch critical-path impact; use `mobile-energy-efficiency-review`.
+- The task is broad runtime performance, backend latency, database throughput, memory, allocation,
+  queueing, or generic hot-path work with no app startup boundary; use `performance-budget-check`.
+- The operation only changes splash branding, colors, copy, or artwork with no launch timing,
+  startup task, first-screen, asset, or fully usable state claim.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Startup scope ledger: platform, app type, target release build, device class, OS version, startup
+  type, entry route, first frame definition, fully usable state definition, and whether the path is
+  cold start, warm start, hot start, or process resume.
+- Measurement ledger: Android Vitals, TTID, TTFD, `reportFullyDrawn()` timing, Macrobenchmark,
+  Perfetto, Startup Profile, Baseline Profile, Xcode Organizer, Instruments App Launch, Time
+  Profiler, release/profile device evidence, low-end physical device evidence, or an explicit
+  static-only boundary.
+- Launch critical-path ledger: process entry, app delegate or application class, ContentProvider
+  auto-init, AndroidX App Startup initializers, dependency graph creation, SDK initialization,
+  static initializers, top-level imports, app shell bootstrap, first route, first view controller or
+  activity, and first navigation decision.
+- Main-thread blocking ledger: synchronous disk reads, network calls, JSON parsing, database open,
+  SQLite access, SharedPreferences, DataStore, UserDefaults, Keychain, secure storage, file scans,
+  font loading, image decode, shader work, and strict-mode or profiler evidence.
+- First usable state ledger: cached snapshot, local token, local config, remote config gate, feature
+  flag gate, server validation, kill switch, offline behavior, first CTA availability, and
+  post-first-frame refresh policy.
+- First-screen render ledger: shell complexity, list size, nested scroll, custom chart, map, video,
+  Lottie, blur, shadow, SVG, oversized launch resources, custom fonts, synchronous layout work,
+  cached summary, and placeholder stability.
+- Deferred work ledger: analytics, crash SDK, ad SDK, remote config refresh, feature experiments,
+  migrations, cache cleanup, thumbnail regeneration, log compression, prefetch, warmup, telemetry,
+  and idle or screen-entry queue ownership.
+- Platform optimization ledger: Android R8, shrink or optimize settings, keep-rule side effects,
+  Baseline Profile, Startup Profile, Macrobenchmark CI, Perfetto traces, AndroidX App Startup,
+  on-demand modules, iOS dynamic frameworks, mergeable libraries, Objective-C `+load`, C++ static
+  constructors, React Native Hermes, lazy loading, inline require, import graph, Flutter deferred
+  components, shader warmup tradeoff, and Tauri or Electron preload cost.
+- Existing tests, startup budgets, 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 startup evidence is available from current files, diffs, docs, configured outputs, user
+  evidence, or can be reported as missing without guessing.
+- Review release or profile behavior, not only debug builds, simulators, emulators, hot-reload
+  sessions, flagship devices, or local developer machines.
+- If code touches auth, permissions, privacy, payments, migrations, storage, push, analytics, or
+  third-party SDKs, also use the matching narrower security, data, migration, telemetry, or
+  dependency skill when its trigger is present.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Move noncritical SDK initialization, analytics, remote config, feature experiments, ad SDKs,
+  cache cleanup, log compression, prefetch, migrations, heavy parsing, and thumbnail work from
+  pre-first-frame startup into post-first-frame, idle, background-safe, or screen-entry queues.
+- Replace eager dependency graph construction, top-level imports, static initializers, app-wide
+  service locator setup, and auto-initialized providers with lazy, scoped, or explicit startup
+  owners when the repository evidence supports the change.
+- Add or tighten startup budgets, measurement hooks, `reportFullyDrawn()` placement, first usable
+  state tests, lazy-init tests, macrobenchmark-style harness integration, profiler notes, and
+  synchronized docs or templates when the repository already has a pattern or configured intent.
+- Simplify first-screen render work, use cached snapshots, defer server validation, limit remote
+  config gates, reduce first-screen asset and font cost, and split on-demand modules when in scope.
+- Do not hide slow startup behind a longer splash hold, fake `reportFullyDrawn()` early, remove
+  necessary safety gates, skip required migrations unsafely, or trade correctness, auth, privacy,
+  data integrity, crash diagnostics, accessibility, or user trust for a faster-looking first paint.
+- Do not start raw Android Studio, Xcode, emulator, device, profiler, browser, package-manager,
+  benchmark, or dev-server workflows outside the configured command contract.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the startup target before tuning.
+   - Name cold start, warm start, hot start, process resume, or first route transition.
+   - Name the user-visible first frame and the fully usable state separately.
+   - For Android, distinguish TTID from TTFD and require `reportFullyDrawn()` to mark real usable
+     completion, not an early metric shortcut.
+   - For iOS, distinguish launch display, first screen readiness, and post-launch work visible in
+     Xcode Organizer or Instruments.
+2. Check measurement quality.
+   - Prefer release or profile builds on a low-end physical device for startup claims.
+   - Treat debug builds, simulators, emulators, hot reload, warm dev caches, and flagship-only
+     evidence as weak or non-representative.
+   - Use Android Vitals cold, warm, and hot startup thresholds, Macrobenchmark, Perfetto, Startup
+     Profile, Baseline Profile, Xcode Organizer, Instruments App Launch, and Time Profiler only
+     when they are configured or provided. Otherwise label the result as static startup risk.
+3. Draw the launch critical path.
+   - List every owner that runs before the first frame: OS entry, `Application.onCreate()`,
+     `AppDelegate`, ContentProvider auto-init, AndroidX App Startup, dependency injection, SDK
+     setup, static initializers, top-level imports, first route, first activity or view controller,
+     first database open, and first network decision.
+   - Mark whether each item is required for first pixels, required for first useful action, or
+     deferrable.
+4. Empty the application delegate or application class.
+   - Do not treat `Application.onCreate()` or `AppDelegate` as a warehouse for analytics, crash SDKs,
+     remote config, feature flags, A/B experiments, ad SDKs, database open, dependency graph build,
+     cache warmup, and one-time cleanup.
+   - Keep only the minimum process safety and routing prerequisites there.
+5. Audit auto-init.
+   - On Android, search ContentProvider and AndroidX App Startup initialization paths before blaming
+     visible application code.
+   - Disable or defer third-party auto-init when the SDK supports it and startup does not need it.
+   - Keep a single explicit startup owner so SDK order and failure behavior are reviewable.
+6. Shrink dependency graph creation.
+   - Do not build the whole DI container, service locator, repository graph, database stack, or SDK
+     registry before first frame when the first screen needs only a small subset.
+   - Prefer lazy providers, route-scoped owners, and first-use construction with clear failure paths.
+7. Hunt static initializer cost.
+   - Check Kotlin `object` and companion object initialization, Java static blocks, Swift global
+     constants, Objective-C `+load`, C++ static constructors, module-level JavaScript or Dart
+     code, and Electron or Tauri preload side effects.
+   - Move heavy parsing, disk reads, regex compilation, crypto setup, SDK access, and service
+     creation out of static startup paths.
+8. Remove main-thread disk and network before first frame.
+   - Treat SharedPreferences, DataStore, UserDefaults, Keychain, secure storage, SQLite, JSON files,
+     file scans, cache index reads, network fetches, DNS, TLS, and remote config calls as startup
+     blockers until proven asynchronous and non-blocking.
+   - Use platform strict-mode, profiler, or trace evidence when available; otherwise report static
+     risk instead of claiming the path is clean.
+9. Make first usable state mostly local.
+   - Draw the first screen from a small cache snapshot, local token, and last-known safe config when
+     product semantics allow it.
+   - Defer server validation, full remote config refresh, feature experiment fetches, personalization,
+     and secondary data until after first frame or screen entry.
+   - Keep only a minimal synchronous kill switch or safety gate when the product truly needs it.
+10. Keep migrations and maintenance off launch.
+    - Do not run large database migrations, cache cleanup, thumbnail regeneration, log compression,
+      full-text index rebuilds, media scans, or telemetry flushes before first frame.
+    - Split required compatibility checks from heavy maintenance; schedule heavy work after first
+      usable state with cancellation, retry, and failure visibility.
+11. Make the first screen cheap.
+    - Prefer a lightweight shell, primary CTA, cached summary, stable placeholders, and enough
+      content for orientation.
+    - Defer nested scroll containers, custom charts, maps, video, Lottie, shadows, blur, SVG-heavy
+      illustrations, huge lists, and complex text measurement until after startup unless they are
+      the core first task.
+12. Keep launch assets and fonts small.
+    - Use appropriately sized launch resources, not full-resolution marketing artwork.
+    - Limit first-screen custom font families, weights, and icon fonts; use system or fallback fonts
+      when the first usable state matters more than brand polish.
+    - Avoid startup JSON parsing or asset manifest scans that exist only to select decoration.
+13. Apply Android startup tooling deliberately.
+    - Check R8 optimize and shrink behavior, keep-rule bloat, class loading, Baseline Profile,
+      Startup Profile, Macrobenchmark coverage, Perfetto trace boundaries, and AndroidX App Startup
+      ownership.
+    - Use on-demand modules for large optional features when the module split is already supported
+      or explicitly in scope.
+14. Apply iOS startup tooling deliberately.
+    - Review third-party framework count, dynamic framework loading, mergeable library options,
+      Objective-C `+load`, C++ static constructors, global Swift initialization, and app delegate
+      work.
+    - Use Xcode Organizer, Instruments App Launch, and Time Profiler evidence when available.
+15. Apply hybrid framework startup rules.
+    - React Native: check Hermes, startup bundle size, lazy loading, `inline require`, import graph,
+      top-level side effects, native module eager init, and whether one heavy import pulls in a
+      screen that the first route does not need.
+    - Flutter: check release or profile startup on device, deferred components, shader warmup as a
+      tradeoff, synchronous plugin setup, isolate startup, and first-frame work.
+    - Electron or Tauri: check preload script cost, window creation, sync filesystem access, eager
+      native plugin load, and first window route imports.
+16. Split work by launch phase.
+    - Put only process-critical prerequisites before first frame.
+    - Put visible first-screen requirements before fully usable state.
+    - Put analytics, remote config refresh, prefetch, optional SDKs, cleanup, and warmup after first
+      frame, idle, background-safe scheduling, or screen entry.
+    - Give each deferred bucket an owner, cancellation rule, timeout, retry policy, and observability.
+17. Verify or label the evidence.
+    - Use configured tests, builds, docs checks, release checks, and mustflow checks for repository
+      surfaces changed by the review.
+    - Use platform traces, Macrobenchmark, Perfetto, Android Vitals, Xcode Organizer, and
+      Instruments only when they are configured or supplied.
+    - Report missing device, profiler, release-build, low-end-device, production telemetry, or
+      benchmark evidence instead of claiming measured startup improvement.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Startup type, first frame, fully usable state, measurement quality, release/profile device
+  boundary, launch critical path, app delegate or application class work, auto-init, dependency
+  graph, static initializers, main-thread I/O, first-screen data source, auth and config gates,
+  maintenance work, first-screen render complexity, assets, fonts, platform optimizations, hybrid
+  framework import graph, deferred queue ownership, and verification evidence are explicit.
+- Splash masking, early `reportFullyDrawn()` metric gaming, debug-only measurement, simulator-only
+  claims, flagship-only claims, app delegate warehouses, ContentProvider surprise init, eager DI
+  graph construction, SDK auto-init, static initializer cost, main-thread disk or network, network
+  first-screen dependency, launch migrations, cache cleanup, heavy first screen, oversized launch
+  assets, font bloat, React Native top-level import bloat, Flutter shader surprise, and unowned
+  deferred work are fixed or reported.
+- Startup performance claims are backed by configured tests, platform diagnostic 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 startup surface and synchronized template surfaces. Do not infer raw Android Studio, Xcode,
+emulator, physical device, profiler, platform dashboard, package-manager, benchmark, 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 startup invariant it exercised before editing again.
+- If first frame or fully usable state cannot be defined, report that startup performance is not
+  reviewable yet instead of adding generic lazy loading.
+- If release-build, device, profiler, or production telemetry evidence is missing, complete
+  available static and configured-test evidence and report the missing measurement boundary.
+- If safe repair requires product changes to auth, config, SDK policy, migration design, native
+  module ownership, release profiling, platform entitlements, or third-party SDK settings outside
+  scope, report the boundary instead of inventing commands.
+- If startup speed conflicts with security, privacy, data migration integrity, crash reporting,
+  accessibility, or user trust, keep the safer behavior and report the startup tradeoff.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- App startup boundary reviewed
+- Startup type, first frame, fully usable state, measurement quality, and evidence level
+- Launch critical path, auto-init, dependency graph, static initializer, main-thread I/O, first data,
+  auth/config gate, maintenance, first-screen render, asset/font, platform tooling, hybrid framework,
+  and deferred-work findings
+- Startup fixes made or recommended
+- Evidence level: measured, configured-test evidence, static startup risk, manual-only, missing, or
+  not applicable
+- Command intents run
+- Skipped startup diagnostics and reasons
+- Remaining app-startup performance risk