mustflow 2.103.3 → 2.103.12

package/templates/default/locales/en/.mustflow/skills/api-contract-change/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.api-contract-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: api-contract-change
-description: Apply this skill when HTTP, REST, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, API schemas, generated clients, SDKs, status codes, headers, content negotiation, cache headers, error envelopes, pagination, filtering, sorting, search, or public API examples are created or changed.
+description: Apply this skill when HTTP, REST, HTTP QUERY, Accept-Query, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, API schemas, generated clients, SDKs, status codes, headers, content negotiation, cache headers, error envelopes, pagination, filtering, sorting, search, or public API examples are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -29,7 +29,7 @@ metadata:
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Treat an API change as a contract change, not as a route or controller edit. The contract includes request schema, response schema, status code, headers, content negotiation, cache semantics, error shape, auth and permission behavior, pagination, filtering, sorting, search semantics, generated clients, SDKs, mocks, fixtures, examples, and documentation.
+Treat an API change as a contract change, not as a route or controller edit. The contract includes request method semantics, request schema, response schema, status code, headers, content negotiation, cache semantics, error shape, auth and permission behavior, pagination, filtering, sorting, search semantics, generated clients, SDKs, mocks, fixtures, examples, and documentation.
 
 The goal is to keep runtime behavior, type contracts, generated artifacts, callers, tests, and docs aligned.
 
@@ -37,6 +37,7 @@ The goal is to keep runtime behavior, type contracts, generated artifacts, calle
 ## Use When
 
 - HTTP, REST, RPC, GraphQL, tRPC, Hono RPC, Elysia Eden, gRPC, protobuf, OpenAPI, AsyncAPI, webhook, callback, public endpoint, internal endpoint, generated client, SDK, schema, mock, fixture, or API docs behavior changes.
+- HTTP method choices change, including GET, POST, PUT, PATCH, DELETE, safe/idempotent operations, request-body semantics, HTTP QUERY, or Accept-Query support.
 - Request body, query parameters, path parameters, headers, cookies, response body, content negotiation, content coding, status codes, redirects, caching headers, rate-limit headers, error envelopes, validation errors, auth errors, or permission errors change.
 - SSE, streaming response, WebTransport handshake, WebSocket fallback, compression negotiation, or delivery headers become part of the API behavior that callers rely on.
 - Pagination, filtering, sorting, search, includes, field selection, sparse fields, expansions, cursor shape, or total-count semantics change.
@@ -54,7 +55,8 @@ The goal is to keep runtime behavior, type contracts, generated artifacts, calle
 ## Required Inputs
 
 - Changed route, controller, resolver, handler, schema, validator, generated client, SDK, tests, fixtures, mocks, and docs.
-- Current request and response schema, status code map, headers, content negotiation, content coding, error envelope, auth and permission behavior, rate-limit behavior, cache behavior, streaming or reconnect behavior, pagination/filter/sort/search contract, and deprecation/versioning policy.
+- Current method semantics, request and response schema, status code map, headers, content negotiation, content coding, error envelope, auth and permission behavior, rate-limit behavior, cache behavior, streaming or reconnect behavior, pagination/filter/sort/search contract, and deprecation/versioning policy.
+- For body-bearing read operations, current GET, POST, and QUERY tradeoffs; request body media type; Accept-Query or Allow discovery; cache-key construction; client, proxy, CDN, browser, and server framework support; fallback behavior; and canonical GET URI strategy when present.
 - OpenAPI, GraphQL schema, tRPC router, Hono app type, Elysia Eden type surface, protobuf files, generated clients, SDK examples, frontend callers, mobile callers, integration tests, docs examples, and mock servers when present.
 - Current public consumers, backwards-compatibility expectations, supported client versions, and migration or deprecation policy.
 - Configured verification intents.
@@ -82,13 +84,13 @@ The goal is to keep runtime behavior, type contracts, generated artifacts, calle
 
 1. Name the contract source of truth: OpenAPI, GraphQL schema, route validator, tRPC router, Hono `AppType`, Elysia app/Eden surface, protobuf definition, hand-written SDK type, or docs-backed public contract.
 2. Build a contract ledger for each changed endpoint or operation:
-   - method or operation name;
+   - method or operation name, including safe, idempotent, cacheable, and request-body semantics;
    - path or field name;
    - request path, query, header, cookie, and body shape;
    - auth and permission requirement;
    - response success status and body;
    - error status and body;
-   - relevant headers, content negotiation, content coding, and cache variance;
+   - relevant headers, content negotiation, content coding, cache variance, and request-content cache-key inputs;
    - pagination, filtering, sorting, and search semantics;
    - generated clients, SDK functions, mocks, fixtures, examples, and docs.
 3. Classify each change:
@@ -98,6 +100,7 @@ The goal is to keep runtime behavior, type contracts, generated artifacts, calle
    - response field removed, renamed, narrowed, widened, or made nullable;
    - status code changed;
    - header added, removed, or changed;
+   - method semantics changed, including safe/idempotent behavior or body-bearing read behavior;
    - content coding, compression negotiation, streaming, reconnect, or cache-variance behavior changed;
    - error code or envelope changed;
    - pagination cursor or total semantics changed;
@@ -113,6 +116,9 @@ The goal is to keep runtime behavior, type contracts, generated artifacts, calle
 ## API Style Policy
 
 - REST and HTTP APIs must keep method semantics, status code meanings, headers, content type, content coding, cache behavior, redirects, streaming behavior, and error envelope stable.
+- HTTP QUERY is for safe and idempotent read operations whose query input does not fit the URI cleanly. It is not a default replacement for GET or POST: keep GET for simple, shareable, bookmarkable, and widely cached URLs; avoid GET request bodies as portable API contracts; and call POST-as-search a semantic or compatibility fallback when QUERY support is unavailable.
+- A QUERY contract must define the query request media type with Content-Type, supported query formats with Accept-Query when advertised, Allow or fallback behavior for unsupported clients and intermediaries, CORS preflight expectations for browser callers, and whether Content-Location, Location, or 303 See Other lets callers repeat the operation with GET.
+- QUERY caching must include request content and relevant metadata in the cache key. Any cache-key normalization must match resource semantics; do not normalize the body only for convenience if that can merge distinct queries.
 - OpenAPI changes must include every status/body/header variant that callers rely on. A schema-only success response is not enough when errors are part of the contract.
 - GraphQL must not be forced into a REST envelope. Preserve GraphQL `data`, `errors`, `extensions`, partial response, nullability, and resolver error propagation semantics.
 - GraphQL nullable-to-non-null and non-null-to-null changes are contract changes. Nullability can change whether partial data survives an error.
@@ -131,7 +137,7 @@ The goal is to keep runtime behavior, type contracts, generated artifacts, calle
 - Pagination must define cursor opacity, sort stability, page size limits, `next` and `previous` meaning, empty page behavior, total-count semantics, and whether filters affect counts.
 - Filtering and sorting must define allowed fields, default sort, null ordering, case sensitivity, timezone or locale behavior, invalid filter behavior, and whether unknown fields are rejected or ignored.
 - Search must define query normalization, tokenization, ranking stability expectations, highlight fields, typo tolerance, permissions, and private-data exclusion.
-- Headers such as content-type, content-encoding, vary, cache-control, etag, location, retry-after, rate-limit, pagination links, content-disposition, and deprecation headers are contract surfaces.
+- Headers such as content-type, accept-query, content-encoding, vary, cache-control, etag, location, content-location, retry-after, rate-limit, pagination links, content-disposition, and deprecation headers are contract surfaces.
 
 ## Dependent Surface Checklist
 
@@ -147,6 +153,7 @@ Check every relevant surface before finalizing:
 - API docs, README snippets, changelog, migration notes, deprecation notices, role matrix, and status-code docs;
 - auth and permission checks;
 - rate limits, cache keys, cache headers, search indexes, pagination cursors, and background jobs;
+- QUERY support, Accept-Query discovery, request-body cache-key logic, CORS preflight behavior, unsupported-method fallback, and GET-equivalent Location or Content-Location paths when body-bearing read operations are caller-visible;
 - streaming delivery, SSE event ids, reconnect behavior, proxy or CDN delivery settings, content-coding variants, and fallback clients when they are caller-visible;
 - observability dashboards, audit logs, analytics events, and alerting that parse status or error codes.
 
@@ -157,6 +164,8 @@ Check every relevant surface before finalizing:
 - Treating TypeScript inference as proof that runtime JSON is compatible.
 - Changing status codes without updating callers, docs, tests, and audit expectations.
 - Changing content encoding, streaming flush, reconnect, cache variance, or fallback behavior without updating callers, docs, tests, and delivery verification.
+- Treating GET request bodies as portable API contracts.
+- Switching complex read-only searches to QUERY without client/server/proxy/CDN support evidence, fallback behavior, Content-Type and Accept-Query policy, and request-content cache-key rules.
 - Treating generated clients as disposable when they are the public API.
 - Mixing GraphQL partial-response semantics with REST success/error envelopes.
 - Adding required request fields in a minor-compatible change without a default or compatibility path.
@@ -171,7 +180,7 @@ Check every relevant surface before finalizing:
 ## Postconditions
 
 - The API contract source of truth is known.
-- Request, response, status, header, content negotiation, cache, error, auth, permission, pagination, filtering, sorting, and search impacts are classified.
+- Request method semantics, response, status, header, content negotiation, cache, error, auth, permission, pagination, filtering, sorting, and search impacts are classified.
 - Breaking or compatibility-sensitive changes are named.
 - Generated clients, mocks, fixtures, tests, docs, and examples are synchronized or explicitly reported as skipped.
 - Framework-specific protocol semantics are preserved.
@@ -209,7 +218,7 @@ Prefer the narrowest configured checks that exercise the changed contract from a
 - API style and contract source of truth
 - Changed operations or endpoints
 - Compatibility classification
-- Request, response, status, header, content negotiation, cache, error, auth, permission, pagination, filter, sort, and search notes
+- Request method semantics, response, status, header, content negotiation, cache, error, auth, permission, pagination, filter, sort, search, and QUERY support notes when relevant
 - Generated client, SDK, mock, fixture, docs, and caller surfaces synchronized
 - Files changed
 - Command intents run

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.api-request-performance-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: api-request-performance-review
@@ -58,8 +58,8 @@ The core question is: "For one request, how many times do we repeat the same I/O
 - 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.
+- ORM behavior: lazy loading, eager loading, generated SQL, relation access in serializers or templates, `include` versus explicit `select`, relation load strategy, Django `select_related` and `prefetch_related`, Rails `includes`, `preload`, `eager_load`, and `strict_loading`, or equivalent framework behavior.
+- Database evidence when available: actual SQL, query count, repeated `SELECT ... WHERE id = ?`, `SELECT *`, app-side filtering or sorting, deep `OFFSET`, `COUNT(*)`, index fit for `WHERE` plus `ORDER BY` plus `LIMIT`, `EXPLAIN`, scan type, sort method, 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.
@@ -98,6 +98,8 @@ The core question is: "For one request, how many times do we repeat the same I/O
    - 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.
+   - For Prisma-style APIs, do not trust `include` as a performance proof. Compare actual SQL, query count, selected columns, relation load strategy, and response shape.
+   - Treat repeated `count`, `exists`, `sum`, `latest`, or `first` queries in list serialization as N+1 candidates; prefer grouped aggregation, batched lookup, or database-side projection when semantics match.
 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.
@@ -111,7 +113,10 @@ The core question is: "For one request, how many times do we repeat the same I/O
    - 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.
+   - Prefer query-shaped index review over column-name index decoration: composite indexes often need equality predicates first, range or ordering columns next, and stable tie-breakers for pagination.
+   - 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. Expression indexes, range predicates, or search-specific indexes may be needed when the database owns that capability.
+   - For soft-delete, tenant, status, or visibility predicates that appear on nearly every request, review partial or filtered indexes where the database supports them.
+   - For list projections, check whether a covering or index-only access path is possible before fetching large JSON, TEXT, BLOB, HTML, metadata, or audit columns.
    - 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.
@@ -140,13 +145,14 @@ The core question is: "For one request, how many times do we repeat the same I/O
 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.
+    - If actual SQL, query-count, or query-plan evidence is missing, say so instead of treating tidy ORM code as proof of efficient database behavior.
 
 <!-- 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.
+- ORM lazy loading, eager-loading overfetch, repeated count or aggregate queries, actual SQL and query count, `SELECT *`, app-side filtering or sorting, deep `OFFSET`, expensive `COUNT(*)`, index mismatch, composite/partial/expression/covering index fit, 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.
 
@@ -181,7 +187,7 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 
 - 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
+- ORM lazy loading, eager loading, actual SQL, query count, 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

package/templates/default/locales/en/.mustflow/skills/completion-evidence-gate/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.completion-evidence-gate
 locale: en
 canonical: true
-revision: 4
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: completion-evidence-gate
@@ -43,6 +43,8 @@ missing, blocked, failed, stale, or only partially relevant.
 
 - A task is ready for final reporting after files were created, modified, deleted, or intentionally left unchanged.
 - The user asks whether work is complete, safe to merge, ready to commit, verified, released, installed, or done.
+- A non-trivial task, commit, push, release preparation, deploy preparation, verification run, or
+  paused implementation is being reported and at least one concrete next action remains.
 - A change touched more than one surface, such as source, tests, schemas, templates, workflow files, package metadata, documentation, or generated output.
 - Verification was skipped, failed, manual-only, unavailable, or chosen from multiple plausible command intents.
 - A previous verification failure, repeated-failure warning, write-drift risk, scope-drift risk, or external evidence risk could make a completion claim misleading.
@@ -70,8 +72,9 @@ missing, blocked, failed, stale, or only partially relevant.
 - Optional script-pack discovery evidence when the command contract exposes `script_pack_list`.
 - Synchronized surfaces expected by the changed contract: source, tests, fixtures, schemas, templates, manifests, docs, release metadata, generated output, and localized copies.
 - Known remaining risks, unverified assumptions, blocked decisions, and rollback notes.
-- Concrete follow-up candidates, if any, plus whether a bounded `next-action-menu` should be
-  included or intentionally omitted.
+- Concrete follow-up candidates, including gated actions such as commit, push, release, deploy,
+  dependency upgrade, migration, or manual verification when they are plausible next steps.
+- Whether a bounded `next-action-menu` must be included or intentionally omitted.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
@@ -120,11 +123,17 @@ missing, blocked, failed, stale, or only partially relevant.
    - Use `implemented but unverified` when the files changed but no relevant configured verification was run.
    - Use `blocked` when required evidence cannot be produced without a missing decision, unavailable environment, manual-only command, failed prerequisite, or user approval.
    - Use `not complete` when a required acceptance criterion is not implemented or verification contradicts the claim.
-7. Decide whether a next-action menu is warranted.
-   - If there are concrete, evidence-backed follow-up tasks that would make the next user turn
-     cheaper, read and apply `next-action-menu` before final reporting.
+7. Decide whether a next-action menu is required.
+   - For a non-trivial final report, read and apply `next-action-menu` before final reporting when
+     at least one concrete, evidence-backed follow-up task remains.
+   - Treat changed-file work, a created commit, push or release readiness, deploy preparation,
+     completed verification, paused implementation, or unresolved manual gate as non-trivial for
+     this decision.
+   - Do not omit the menu merely because the remaining useful actions are approval-gated. Include
+     gated actions such as push, publish, deploy, dependency upgrade, migration, or manual release
+     verification as menu rows with the gate stated plainly.
    - If no useful follow-up exists, the user asked not to include recommendations, or the only next
-     actions are speculative or approval-gated, omit the menu and keep the final report concise.
+     actions are speculative, omit the menu and keep the final report concise.
    - Do not treat this gate as automatic host behavior: the menu appears only when the skill is
      selected and its use conditions are met.
 8. Write the final report from evidence, not confidence.
@@ -140,8 +149,10 @@ missing, blocked, failed, stale, or only partially relevant.
 - Every user requirement is mapped to proof, a limitation, or an explicit out-of-scope decision.
 - Skipped, missing, failed, stale, or manual-only verification is visible.
 - Contract, template, schema, docs, test, and release drift is either resolved or named as remaining risk.
-- Useful follow-up tasks either appear through `next-action-menu` or are intentionally omitted with a
-  clear reason when the menu conditions are not met.
+- For non-trivial final reports, useful follow-up tasks appear through `next-action-menu` whenever
+  at least one concrete next action remains, including approval-gated next actions.
+- Omitted menus state a clear reason grounded in no concrete next action, user opt-out, or
+  speculative-only follow-ups.
 - No unconfigured command, hidden transcript, broad log, or invented tool result is treated as proof.
 
 <!-- mustflow-section: verification -->

package/templates/default/locales/en/.mustflow/skills/hot-path-performance-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.hot-path-performance-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: hot-path-performance-review
-description: Apply this skill when code is created, changed, reviewed, or reported and the main performance risk is ordinary work repeated many times, such as repeated I/O, repeated scans, hidden quadratic lookup, per-item allocation, lock hold time, sequential async waits, unbounded fan-out, or missing observability for hot paths.
+description: Apply this skill when code is created, changed, reviewed, or reported and the main performance risk is ordinary work repeated many times, such as repeated I/O, repeated scans, hidden quadratic lookup, allocation or GC churn, per-item parsing or serialization, lock hold time, sequential async waits, unbounded fan-out, or missing observability for hot paths.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -54,7 +54,7 @@ The review question is not only "which line looks slow?" It is "how often does t
 
 - Hot path: the request, loop, render, job, export, import, queue consumer, sync, report, or command path under review.
 - Multipliers: requests, rows, items, files, users, tenants, retries, pages, renders, workers, queue messages, shards, or nested loops that multiply the work.
-- Per-iteration cost: external calls, queries, filesystem reads, allocations, clones, DTO conversions, JSON parse/stringify, logging, formatting, regex, sorting, hashing, image or crypto work, and lock hold time.
+- Per-iteration cost: external calls, queries, filesystem reads, temporary arrays, object spreads, array spreads, concat copies, clones, DTO conversions, JSON parse/stringify, string splitting, logging, formatting, regex, sorting, hashing, image or crypto work, and lock hold time.
 - Boundary ledger: DB, network, cache, filesystem, IPC, provider SDK, queue, logger, metrics sink, transaction, pool, mutex, thread, goroutine, task, or UI main thread crossed by the path.
 - Data-size and tail-latency evidence when available: p50, p95, p99, row count, payload size, allocation count, query count, round-trip count, queue depth, pool wait, lock wait, cache hit rate, retry count, or timeout behavior.
 - Correctness boundaries: order, duplicates, idempotency, authorization, tenant isolation, consistency, partial failure, stale data, cancellation, retry semantics, and error behavior.
@@ -100,22 +100,27 @@ The review question is not only "which line looks slow?" It is "how often does t
 10. Reuse expensive clients and sessions. Per-request or per-item HTTP clients, DB clients, ORM clients, SDK clients, connection pools, TLS handshakes, regexes, date formatters, and thread pools are performance traps unless the API requires that lifecycle.
 11. Check cache honesty. A cache needs a bounded key space, invalidation or TTL, max size, authorization dimensions, negative-cache policy, stale behavior, and cache stampede protection such as locking, singleflight, early refresh, or request coalescing.
 12. Check logging and telemetry in hot paths. Repeated debug logs, eager log-string creation, whole-object serialization, high-cardinality metrics, and JSON formatting for discarded logs can dominate CPU and I/O during incidents.
-13. Check string, JSON, DTO, and clone churn. Repeated string concatenation, `JSON.parse(JSON.stringify(...))`, `cloneDeep`, broad object spread, deep copy, repeated DTO-to-DTO conversion, and repeated serialization can move the bottleneck into "clean" mapping code.
-14. Check large value passing and materialization. In value-copy languages or APIs, large structs, arrays, buffers, spread copies, full file reads, full JSON loads, and eager `collect` calls can turn neat code into memory traffic.
-15. Check regex, parsing, formatting, and locale work. Nested or ambiguous regexes, repeated date parsing, timezone conversion, numeric or locale formatting, and per-row formatter creation should be reviewed with worst-case input in mind.
-16. Check CPU-heavy work in request or UI paths. Image resizing, compression, encryption, hashing, diffing, report generation, spreadsheet export, and search indexing may need batching, worker offload, queueing, or streaming, but only with clear backpressure and failure behavior.
-17. Check queues and workers. Moving work to a queue only moves the bottleneck unless consumers batch DB writes, bulk external calls where safe, bound retries, apply jitter, define poison-message handling, and expose backlog.
-18. Check retry and timeout multiplication. A request with several calls, long timeouts, and several retries can become a tail-latency monster. Count worst-case wait and verify idempotency before adding more attempts.
-19. Review tail behavior, not just average. p50 can look fine while p95 or p99 holds locks, connections, workers, or thread-pool slots long enough to hurt everyone else.
-20. Add observability before large optimization when evidence is missing. Prefer query count, external-call count, payload bytes, allocation count, cache hit rate, queue backlog, pool wait, lock wait, retry count, and span timing over guessing.
-21. Rank the likely payoff. Usually fix repeated external round trips, N+1 access, hidden quadratic scans, overfetching, wide transactions, lock hold time, unbounded fan-out, and missing timeouts before micro-optimizing arithmetic.
-22. Label evidence honestly. If there is no configured benchmark or production trace, report the finding as static complexity or hot-path risk, not measured speedup.
+13. Check allocation and GC churn before micro-optimizing arithmetic.
+    - `filter().map().reduce()`, `flatMap`, `Object.values`, `Object.entries`, `split().map(trim)`, `slice`, and `sort` chains can allocate large temporary arrays.
+    - Spread accumulation, `concat` in loops, repeated object spread while building indexes, and `cloneDeep` can copy growing data many times.
+    - `JSON.stringify` or `JSON.parse(JSON.stringify(...))` used for comparison, cloning, cache keys, or logging can dominate CPU and allocation while losing type semantics.
+    - Repeated `RegExp`, `Date`, `Intl`, formatter, `Set`, or `Map` construction inside hot loops should move outside the loop or become request-scoped only when ownership and memory bounds are clear.
+14. Check string, JSON, DTO, and clone churn. Repeated string concatenation, `JSON.parse(JSON.stringify(...))`, `cloneDeep`, broad object spread, deep copy, repeated DTO-to-DTO conversion, and repeated serialization can move the bottleneck into "clean" mapping code.
+15. Check large value passing and materialization. In value-copy languages or APIs, large structs, arrays, buffers, spread copies, full file reads, full JSON loads, all-pages accumulation, and eager `collect` calls can turn neat code into memory traffic.
+16. Check regex, parsing, formatting, and locale work. Nested or ambiguous regexes, repeated date parsing, timezone conversion, numeric or locale formatting, and per-row formatter creation should be reviewed with worst-case input in mind.
+17. Check CPU-heavy work in request or UI paths. Image resizing, compression, encryption, hashing, diffing, report generation, spreadsheet export, and search indexing may need batching, worker offload, queueing, or streaming, but only with clear backpressure and failure behavior.
+18. Check queues and workers. Moving work to a queue only moves the bottleneck unless consumers batch DB writes, bulk external calls where safe, bound retries, apply jitter, define poison-message handling, and expose backlog.
+19. Check retry and timeout multiplication. A request with several calls, long timeouts, and several retries can become a tail-latency monster. Count worst-case wait and verify idempotency before adding more attempts.
+20. Review tail behavior, not just average. p50 can look fine while p95 or p99 holds locks, connections, workers, or thread-pool slots long enough to hurt everyone else.
+21. Add observability before large optimization when evidence is missing. Prefer query count, external-call count, payload bytes, allocation count, heap growth, GC pause, event-loop delay, cache hit rate, queue backlog, queue wait, pool wait, lock wait, retry count, and span timing over guessing.
+22. Rank the likely payoff. Usually fix repeated external round trips, N+1 access, hidden quadratic scans, overfetching, wide transactions, lock hold time, allocation churn, unbounded fan-out, and missing timeouts before micro-optimizing arithmetic.
+23. Label evidence honestly. If there is no configured benchmark or production trace, report the finding as static complexity or hot-path risk, not measured speedup.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Hot path, cost multipliers, data size, round-trip count, wait points, and copy or allocation points are explicit.
-- N+1 queries, repeated external calls, hidden quadratic scans, unbounded materialization, sequential waits, unbounded fan-out, per-item client creation, broad logging, repeated serialization, and lock or transaction hold time are fixed or reported.
+- N+1 queries, repeated external calls, hidden quadratic scans, unbounded materialization, temporary-array chains, spread or concat copy accumulation, sequential waits, unbounded fan-out, per-item client creation, broad logging, repeated parsing or serialization, allocation churn, and lock or transaction hold time are fixed or reported.
 - Cache, queue, retry, timeout, batching, bulk-write, concurrency, pagination, projection, index-fit, and observability behavior are explicit where relevant.
 - Correctness, authorization, tenant isolation, ordering, duplicates, partial failure, cancellation, and stale-data behavior remain intact or are called out as tradeoffs.
 - Performance claims are backed by configured evidence or labeled as static review risk.
@@ -151,7 +156,7 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 - Hot path reviewed
 - Cost ledger: iteration count, data size, round trips, wait time, copy or allocation count
 - Repeated external access, N+1, hidden quadratic scans, and multi-pass collection findings
-- DB, pagination, index-fit, transaction, lock, async, client reuse, cache, queue, retry, timeout, logging, serialization, clone, regex, parsing, formatting, and CPU-heavy work checked where relevant
+- DB, pagination, index-fit, transaction, lock, async, client reuse, cache, queue, retry, timeout, logging, temporary arrays, spread or concat accumulation, serialization, clone, regex, parsing, formatting, allocation, GC, and CPU-heavy work checked where relevant
 - Optimization or review recommendation
 - Evidence level: measured, configured-test evidence, static complexity risk, manual-only, missing, or not applicable
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/next-action-menu/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.next-action-menu
 locale: en
 canonical: true
-revision: 1
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: next-action-menu
-description: Apply this skill when a final report, completion note, repository improvement loop, or follow-up workflow should offer a bounded numbered next-action menu that a user can select with a single digit in the next turn.
+description: Apply this skill when a final report, completion note, repository improvement loop, or follow-up workflow should offer a bounded numbered next-action menu that a user can select with a single digit in the next turn. Use especially after non-trivial completed or paused work, commits, pushes, release or deploy preparation, verification, or remaining approval gates when concrete follow-up actions exist.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -36,6 +36,8 @@ scope, approval, verification, command contracts, release gates, or safety rules
 
 - A final report, completion note, handoff, or repository improvement cycle has one or more useful
   follow-up tasks.
+- A non-trivial task is being reported after changed files, a created commit, completed verification,
+  push readiness, release or deploy preparation, paused work, or another concrete approval gate.
 - The user repeatedly asks for "next recommended work", "continue", "proceed", or selects follow-up
   items after previous completion reports.
 - The agent needs to present a bounded backlog that can be selected by a single digit in the next
@@ -48,9 +50,10 @@ scope, approval, verification, command contracts, release gates, or safety rules
 - The current answer is a tiny direct response with no meaningful follow-up.
 - There are no evidence-backed next actions, or all plausible next actions are speculative.
 - The user asked not to include recommendations, menus, or follow-up prompts.
-- The next action requires a blocking product, security, privacy, legal, release, migration,
-  destructive, dependency, credential, deployment, or payment decision that has not been authorized.
-  Report the decision gate instead of offering it as a one-digit action.
+- The only possible next action requires a blocking product, security, privacy, legal, release,
+  migration, destructive, dependency, credential, deployment, or payment decision that has not been
+  authorized and there is no safe bounded action to describe. Report the decision gate instead of
+  offering it as a one-digit action.
 - Another interface already owns selection state and has a stricter picker, ticket, or work-order
   contract.
 
@@ -89,8 +92,11 @@ scope, approval, verification, command contracts, release gates, or safety rules
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Decide whether a menu is useful.
-   - Include a menu only when at least one concrete follow-up task is valuable.
+1. Decide whether a menu is useful or required.
+   - Include a menu when at least one concrete follow-up task is valuable.
+   - For non-trivial completion reports, commits, completed verification, push readiness, release or
+     deploy preparation, paused work, or unresolved approval gates, treat the menu as required when
+     any concrete next action exists.
    - Do not fabricate filler items to reach a fixed row count.
 2. Build at most nine items.
    - Use digits `1` through `9`.
@@ -108,6 +114,13 @@ scope, approval, verification, command contracts, release gates, or safety rules
    the host format allows it.
    - Use four columns: number, next task title, description, and recommendation score.
    - In Korean final reports, use `추천도` for the recommendation-score column label.
+   - Use non-breaking padding in short header cells so narrow renderers do not wrap Korean headers
+     vertically. Prefer this template:
+     `| 번호&nbsp;&nbsp; | 다음 작업 | 설명 | 추천도&nbsp;&nbsp; |`
+     `|---:|---|---|:---:|`
+     For English, prefer:
+     `| No.&nbsp;&nbsp; | Next task | Description | Score&nbsp;&nbsp; |`
+     `|---:|---|---|:---:|`
    - Keep descriptions short enough to scan but specific enough to execute.
    - Localize column labels to the report language when appropriate.
 6. Mark gated items plainly.
@@ -116,6 +129,8 @@ scope, approval, verification, command contracts, release gates, or safety rules
      genuinely plausible follow-ups.
    - The description must state the gate, such as explicit user approval, configured command intent,
      owner decision, or manual verification.
+   - A gated item in the table is only a visible next-action option; it is not approval to perform
+     that action.
 7. Interpret a single-digit next user message as a menu selection only when all conditions hold:
    - the immediately relevant previous assistant final report contained a next-action menu;
    - the digit maps to an item in that menu;

package/templates/default/locales/en/.mustflow/skills/quadratic-scan-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.quadratic-scan-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: quadratic-scan-review
@@ -84,33 +84,35 @@ The review question is not "is there a loop inside a loop?" That catches only th
 ## Procedure
 
 1. Name the repeated path and multiply call count by inner scan length. Review the product `outer_count * inner_count`, not the apparent number of loops.
-2. Search for the obvious collection-combinator shapes: `map` plus `filter`, `map` plus `find`, `forEach` plus `includes`, `filter` plus `indexOf`, `reduce` plus spread, and chained `filter().map().sort()` inside a repeated path.
+2. Search for the obvious collection-combinator shapes: `map` plus `filter`, `map` plus `find`, `forEach` plus `includes`, `filter` plus `indexOf`, `filter` plus `findIndex`, `reduce` plus spread, and chained `filter().map().sort()` inside a repeated path.
 3. Search for membership checks over arrays. `includes`, `indexOf`, `contains`, `find`, `some`, and list membership inside a loop usually want `Set.has` or `Map.has` unless the searched list is tiny and hard-capped.
 4. Search for code joins by ID. `posts.map(post => users.find(...))`, `users.map(user => orders.filter(...))`, permission lookups, likes, bookmarks, read state, tags, and relation lists usually need a `Map` or grouped `Map` keyed by ID or composite key.
 5. Check duplicate removal. `filter((x, i) => arr.indexOf(x) === i)` is O(N^2). Prefer `Set` for scalar values and `Map` keyed by stable identity for objects.
 6. Check sorted arrays. Sorting does not make `find` fast. If code repeatedly searches a sorted array, use a prebuilt map, binary search with a proven comparator, or a single sorted merge.
 7. Check repeated sorting. Sorting inside a per-item loop is usually worse than scanning once, keeping a top candidate, using a heap, or sorting once before the loop.
-8. Check copy-accumulation patterns. `reduce` with `[...acc, item]`, repeated object spread over a growing object, repeated string `+=`, and repeated concatenation can become quadratic copy work. Prefer push, builders, buffers, or one final copy at the boundary.
-9. Check JSON and serialization comparisons. Repeated `JSON.stringify` inside search, equality, sort, dedupe, or render logic multiplies object size by item count. Use explicit keys and precomputed normalized keys.
-10. Open helper bodies called from loops or render paths. Harmless helper names can hide full-list scans, database calls, resolver calls, serialization, sorting, or permission checks.
-11. Check ORM and lazy relations. A single visible loop can become one query per entity. Replace per-entity relation access with eager loading, joins, `WHERE id IN (...)`, batch loading, or DataLoader-style batching.
-12. Check GraphQL and nested resolvers. Parent-list resolvers plus per-field DB or API calls create hidden pairwise fan-out. Batch by parent IDs and preserve field-level authorization semantics.
-13. Check render-time lookup. `rows.map(row => columns.find(...))`, `items.map(item => selectedIds.includes(item.id))`, derived data recomputed on every render, and per-row helper scans should move to memoized sets or maps when inputs are large or stable.
-14. Check all-data-in-app joins. Fetching `allUsers`, `allOrders`, or `allLogs` and joining in application arrays is often a database join without an index. Push join, filter, sort, and pagination to the data store when the data store owns the index and semantics allow it.
-15. Check tree and graph construction. `nodes.map(node => nodes.filter(child => child.parentId === node.id))` should usually become `childrenByParentId` plus one assembly pass. `visited.includes(id)` in traversal should be a `Set`.
-16. Check event-log and time-window scans. Repeatedly scanning all previous events per event should usually become grouping, sorting once, and one pointer or rolling aggregate per key.
-17. Check interval overlap. All-pairs range checks are sometimes necessary, but overlap detection often only needs sorting by start and comparing adjacent or active intervals.
-18. Check incremental updates. Adding one item should not recompute a full ranking, group map, unread count, cart total, or dashboard aggregate unless the collection is fixed and tiny.
-19. Separate index from cache. A `Map` built from current input is an index. A cache stores results across calls or time. Use an index for repeated lookup over already-owned data before introducing cache invalidation.
-20. Require a hard cap for "small list" exceptions. Countries, enum options, or fixed config lists may stay arrays if the cap is real. User data, logs, orders, comments, permissions, tags, events, and uploaded rows need scalable lookup.
-21. Preserve behavior while changing shape. Before replacing scans with indexes, state how order, duplicates, first or last match, missing references, authorization filtering, and stable keys are preserved.
-22. Add growth evidence when feasible. If configured tests or fixtures can scale input size, prefer a small growth test that compares behavior at larger counts. If benchmarking is not configured, report complexity-only evidence instead of a speedup claim.
+8. Check queue and deletion patterns. JavaScript `shift()` in a large BFS or queue loop moves the remaining array repeatedly; use a head index or real queue. `findIndex` plus `splice` while matching requests to available items can scan and move the same growing array repeatedly; bucket by key and advance a consumption pointer instead.
+9. Check copy-accumulation patterns. `reduce` with `[...acc, item]`, repeated object spread over a growing object, repeated string `+=`, repeated `concat`, and repeated array spread over a growing result can become quadratic copy work. Prefer push, builders, buffers, or one final copy at the boundary.
+10. Check JSON and serialization comparisons. Repeated `JSON.stringify` inside search, equality, sort, dedupe, or render logic multiplies object size by item count. Use explicit keys and precomputed normalized keys.
+11. Open helper bodies called from loops or render paths. Harmless helper names can hide full-list scans, database calls, resolver calls, serialization, sorting, or permission checks.
+12. Check ORM and lazy relations. A single visible loop can become one query per entity. Replace per-entity relation access with eager loading, joins, `WHERE id IN (...)`, batch loading, or DataLoader-style batching.
+13. Check GraphQL and nested resolvers. Parent-list resolvers plus per-field DB or API calls create hidden pairwise fan-out. Batch by parent IDs and preserve field-level authorization semantics.
+14. Check render-time lookup. `rows.map(row => columns.find(...))`, `items.map(item => selectedIds.includes(item.id))`, derived data recomputed on every render, and per-row helper scans should move to memoized sets or maps when inputs are large or stable.
+15. Check all-data-in-app joins. Fetching `allUsers`, `allOrders`, or `allLogs` and joining in application arrays is often a database join without an index. Push join, filter, sort, and pagination to the data store when the data store owns the index and semantics allow it.
+16. Check tree and graph construction. `nodes.map(node => nodes.filter(child => child.parentId === node.id))` should usually become `childrenByParentId` plus one assembly pass. `visited.includes(id)` in traversal should be a `Set`. Very deep trees may also need an explicit stack to avoid call-stack failure.
+17. Check event-log and time-window scans. Repeatedly scanning all previous events per event should usually become grouping, sorting once, and one pointer or rolling aggregate per key.
+18. Check interval overlap. All-pairs range checks are sometimes necessary, but overlap detection often only needs sorting by start and comparing adjacent or active intervals.
+19. Check true all-pairs similarity separately. If every item must be compared with every other item, do not promise a linear rewrite. First narrow candidates with stable keys, categories, buckets, hashes, n-grams, ranges, or database indexes, then compare only within the candidate set.
+20. Check incremental updates. Adding one item should not recompute a full ranking, group map, unread count, cart total, or dashboard aggregate unless the collection is fixed and tiny.
+21. Separate index from cache. A `Map` built from current input is an index. A cache stores results across calls or time. Use an index for repeated lookup over already-owned data before introducing cache invalidation.
+22. Require a hard cap for "small list" exceptions. Countries, enum options, or fixed config lists may stay arrays if the cap is real. User data, logs, orders, comments, permissions, tags, events, and uploaded rows need scalable lookup.
+23. Preserve behavior while changing shape. Before replacing scans with indexes, state how order, duplicates, first or last match, missing references, authorization filtering, and stable keys are preserved.
+24. Add growth evidence when feasible. If configured tests or fixtures can scale input size, prefer a small growth test that compares behavior at larger counts. If benchmarking is not configured, report complexity-only evidence instead of a speedup claim.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Each suspected O(N^2) path has an outer count, inner count, and data-growth classification.
-- Repeated membership checks, code joins, duplicate removal, tree building, resolver fan-out, render-time lookup, helper-hidden scans, repeated sort, copy accumulation, and JSON comparison are fixed or reported.
+- Repeated membership checks, code joins, duplicate removal, tree building, resolver fan-out, render-time lookup, helper-hidden scans, repeated sort, queue `shift()`, `findIndex` plus `splice`, copy accumulation, interval scans, all-pairs candidate narrowing, and JSON comparison are fixed or reported.
 - Array-to-set or array-to-map changes preserve order, duplicates, missing records, first or last winner, authorization, and stable key behavior.
 - Small-list exceptions have an explicit hard cap or are reported as residual risk.
 - Performance claims are backed by configured evidence or labeled as static complexity risk.
@@ -146,7 +148,7 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 - Repeated path reviewed
 - Outer count, inner count, and data-growth classification
 - Hidden scan patterns found or ruled out
-- Membership, join, dedupe, helper, ORM, resolver, render, tree, graph, event, interval, sort, copy, string, and JSON checks where relevant
+- Membership, join, dedupe, helper, ORM, resolver, render, tree, graph, event, interval, all-pairs, queue, deletion, sort, copy, string, and JSON checks where relevant
 - Index, grouping, sorted merge, database join, or intentional all-pairs decision
 - Semantics preserved: order, duplicates, first or last winner, missing IDs, authorization, and stable keys
 - Evidence level: configured test, static complexity risk, manual-only, missing, or not applicable