mustflow 2.112.9 → 2.112.13

package/templates/default/locales/en/.mustflow/skills/cache-integrity-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.cache-integrity-review
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: cache-integrity-review
-description: Apply this skill when code is created, changed, reviewed, or reported and cache behavior can spread stale, wrong, private, overbroad, tenant-crossing, permission-wrong, version-incompatible, or source-overloading values through cache keys, query normalization, key versions, TTL and jitter, soft and hard TTL, stale-while-revalidate, stampede protection, request coalescing, negative caching, invalidation order, list or page caches, tag invalidation, L1/L2 cache layers, Redis fallback, cache-status ledgers such as hit, miss, bypass, stale, refresh, error, set-failed, evicted, or expired, origin-cost observability, value size, eviction policy, TTL-less keys, KEYS/SCAN use, hot keys, Redis Cluster hash tags, replica lag, Redis latency, HTTP Vary/no-cache/no-store semantics, permission caches, cache warming, or failure-path cache tests.
+description: Apply this skill when code is created, changed, reviewed, or reported and cache or client state behavior can spread stale, wrong, private, overbroad, tenant-crossing, permission-wrong, version-incompatible, partial-entity, persisted-storage, hydration, optimistic-update, or source-overloading values through cache keys, query normalization, key versions, TTL and jitter, soft and hard TTL, stale-while-revalidate, stampede protection, request coalescing, negative caching, invalidation order, list or page caches, tag invalidation, L1/L2 cache layers, Redis fallback, browser storage, service workers, SSR hydration, cache-status ledgers such as hit, miss, bypass, stale, refresh, error, set-failed, evicted, or expired, origin-cost observability, value provenance, value size, eviction policy, TTL-less keys, KEYS/SCAN use, hot keys, Redis Cluster hash tags, replica lag, Redis latency, HTTP Vary/no-cache/no-store semantics, permission caches, cache warming, or failure-path cache tests.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -48,6 +48,8 @@ and what happens to the source system when the cache misses or fails?"
 - Cache behavior can vary by tenant, actor, login state, membership tier, country, language, locale,
   A/B test, feature flag, adult verification, inventory policy, authorization, subscription, or
   request headers.
+- State is mirrored between server data, framework state, form state, URL state, query cache, localStorage,
+  IndexedDB, service worker cache, SSR hydration, normalized entity cache, or optimistic update layers.
 - A review or final report claims that caching is safe, fast, resilient, correct, isolated, warmed,
   invalidated, observable, or harmless under deploy, rollback, source failure, Redis failure, or
   concurrent updates.
@@ -72,7 +74,11 @@ and what happens to the source system when the cache misses or fails?"
 - Source of truth: database, provider, file, auth service, entitlement system, inventory source,
   canonical event stream, generated artifact, or other owner.
 - Cached value shape: detail item, list, page, search result, permission decision, session, rate
-  limit, inventory, feature flag, API response, rendered HTML, or derived aggregate.
+  limit, inventory, feature flag, API response, rendered HTML, partial entity, optimistic patch,
+  persisted browser value, hydrated state, or derived aggregate.
+- Value provenance and completeness: whether the value is full or partial, who last wrote it, when it
+  was fetched, when it becomes stale, what version it represents, whether it is optimistic or hydrated,
+  and which mutation or invalidation produced it.
 - Key dimensions: tenant, actor, viewer context, login state, membership tier, country, language,
   locale, A/B test, feature flag, adult verification, inventory policy, authorization state, headers,
   query parameters, schema version, and value version.
@@ -107,7 +113,8 @@ and what happens to the source system when the cache misses or fails?"
 - Add or tighten cache key construction, query normalization, key versioning, TTL and jitter,
   soft/hard TTL handling, stale-while-revalidate, request coalescing, singleflight, bounded fallback,
   load shedding, negative-cache policy, invalidation ordering, version checks, tag invalidation,
-  cache warming, cache observability, and focused tests tied to the changed cache surface.
+  cache warming, partial-entity merge policy, persisted-storage reset policy, optimistic rollback
+  lineage, cache observability, and focused tests tied to the changed cache surface.
 - Split cache policy by success, not-found, permission-denied, temporary failure, stale value, and
   unknown outcome when those outcomes need different behavior.
 - Add tests for tenant separation, permission changes, stale value bounds, concurrent misses, source
@@ -165,64 +172,92 @@ and what happens to the source system when the cache misses or fails?"
      a newer value.
    - Use updatedAt, monotonic version, CAS, conditional write, compare-and-set, or cache delete when
      ordering cannot be proven.
-10. Check list, query, and page caches separately from detail caches.
+10. Check async state staleness and current-owner checks.
+    - State captured before `await`, background refresh, debounce, polling, or optimistic mutation may
+      be stale by the time the result applies.
+    - Re-read current state, use functional updates, or compare generation, version, etag, sequence,
+      mutation id, or operation owner before writing into cache or UI state.
+    - Request coalescing is not obsolete-request discard. Same-key requests may share work; different
+      keys or superseded views need apply-time freshness checks.
+11. Check partial entity overwrite.
+    - A summary response should not erase fields that only a detail response owns.
+    - Define merge policy for partial values, field completeness, null versus absent fields, and
+      entity variants such as summary, detail, admin, viewer-specific, or permission-filtered views.
+    - If a cache normalizes by id, the id alone is not proof that two responses have the same
+      information quality or visibility.
+12. Check optimistic update lineage.
+    - Optimistic state needs a before snapshot, temporary version or mutation id, success merge rule,
+      and failure rollback rule.
+    - Concurrent optimistic mutations should not roll back later successful writes by restoring a
+      whole old cache snapshot blindly.
+    - Prefer per-mutation rollback, server refetch, or versioned merge when more than one mutation can
+      overlap.
+13. Check list, query, and page caches separately from detail caches.
     - List caches are harder than detail caches because latest, popular, tag, author, search, filter,
       and page keys all change when one entity changes.
     - Page-number caches are vulnerable to insertions and deletions. Prefer cursor keys, baseline
       time, snapshot token, or explicit duplicate and gap behavior for feeds and infinite scroll.
     - If tag-based invalidation is missing for compound queries, expect global flush pressure and
       report the operational cost.
-11. Check cache layers.
+14. Check persisted browser and hydration caches.
+    - localStorage, IndexedDB, service workers, browser HTTP cache, SSR hydration payloads, and
+      framework-persisted query caches can revive old private or schema-incompatible values after
+      reload, logout, tenant switch, deploy, or rollback.
+    - Persisted private caches should be partitioned or cleared by user id, tenant id, schema version,
+      permission context, locale where relevant, and app build or service-worker version when needed.
+    - Test or review multi-tab, multi-device, admin-versus-user, logout/login, tenant switch,
+      background refresh, and hydration-first-visible-state paths when those risks exist.
+15. Check cache layers.
     - Local in-memory cache splits truth per server. L1, L2, and DB each need TTL, invalidation,
       bypass, and failure behavior.
     - Deleting L2 while L1 survives can leave "sometimes stale" bugs that depend on load-balancer
       routing.
-12. Check cache outage fallback.
+16. Check cache outage fallback.
     - Redis down plus unbounded DB fallback can kill the source. Fallback needs rate limit, load
       shedding, stale serve, circuit breaker, bulkhead, or another source-protection mechanism.
     - Decide whether cache failure is disposable or correctness-sensitive. Sessions, permissions,
       rate limits, inventory, idempotency, and dedupe caches are not ordinary performance caches.
     - Compare normal cached traffic with an allowed bypass path or known miss path when evidence is
       available. If bypass is faster, fresher, or more correct, the cache policy itself is suspect.
-13. Check Redis keyspace and memory behavior.
+17. Check Redis keyspace and memory behavior.
     - Review value size, key size, key schema, bounded key cardinality, max memory, eviction policy,
       expired keys, evicted keys, and whether TTL-less keys are turning cache into state storage.
     - `noeviction` makes writes fail at memory limit. `volatile-*` policies only evict keys with TTL,
       so TTL-less keys can crowd out real cache behavior.
     - `KEYS *` in application code is a production bomb. Use `SCAN` only from bounded admin or
       maintenance paths with explicit limits.
-14. Check Redis latency, replication, and distribution.
+18. Check Redis latency, replication, and distribution.
     - Redis Slow Log does not include client round-trip time, connection wait, serialization,
       application loop overhead, DNS, TLS, or network path time. Do not use it as the only latency
       proof.
     - Review replica lag, failover behavior, cold replica warmup, persistence spikes, memory
       fragmentation, client connection pools, shard imbalance, and command mix when a cache incident
       is operational rather than semantic.
-15. Check hot keys and Redis Cluster distribution.
+19. Check hot keys and Redis Cluster distribution.
     - Sharding does not save one hot key. Use replicas, local L1, request coalescing, prewarm,
       chunking, or workload-specific splitting where semantics allow it.
     - Redis Cluster hash tags are useful for intentional multi-key locality, but overusing the same
       tag can force too many keys into one slot.
-16. Check HTTP cache semantics.
+20. Check HTTP cache semantics.
     - If responses vary by `Authorization`, `Cookie`, `Accept-Language`, `Accept-Encoding`, content
       negotiation, or user context, verify `Vary` and cache-control behavior.
     - `no-cache` means revalidate before reuse. `no-store` means do not store. Do not use one when
       the other is required.
     - Check freshness, validation, private versus public cacheability, CDN behavior, browser behavior,
       and generated-client or proxy expectations.
-17. Check permission and entitlement caches as security boundaries.
+21. Check permission and entitlement caches as security boundaries.
     - A permission cache, role cache, organization-membership cache, subscription cache, admin cache,
       or entitlement cache must be invalidated by revocation, role change, organization move,
       subscription expiry, ownership change, and emergency access changes.
     - Short TTL alone is not enough for decisions that should fail closed or revoke promptly.
-18. Check cache warming and cold-start behavior.
+22. Check cache warming and cold-start behavior.
     - Deployment, autoscale, failover, and rollback can create synchronized cold caches that push
       traffic to the source.
     - Prewarm only keys with clear ownership and backpressure. Do not build an unbounded warming job
       that becomes the outage.
     - Load-test or smoke the cold, warm, failover, replica-lag, source-slow, and cache-down scenarios
       when the repository has configured evidence. Otherwise report those as manual operational gaps.
-19. Check observability.
+23. Check observability.
     - Hit rate alone lies. Break down hits, misses, bypasses, stale serves, refreshes, negative hits,
       refresh failures, evictions, expirations, fallback serves, Redis errors, and set failures by
       endpoint, key-pattern, tenant, status-code, and cache layer where useful.
@@ -232,13 +267,17 @@ and what happens to the source system when the cache misses or fails?"
       cache write failures, and whether a high hit rate hides a small set of expensive miss paths.
     - Keep cache metrics labels bounded; put high-cardinality keys in logs or traces only when the
       repository privacy rules allow it.
-20. Check tests beyond the happy path.
+    - For developer or support diagnostics, expose safe provenance such as cache key class, fetchedAt,
+      staleAt, dataVersion, source, lastInvalidatedAt, lastMutationId, writer, isOptimistic, and
+      isHydrated when local UI or tooling patterns allow it.
+24. Check tests beyond the happy path.
     - "Second call is faster" is not enough.
     - Cover concurrent misses, update during read, delete then recreate, source failure, Redis
-      failure, synchronized TTL expiry, old-version cached value, permission change, tenant
-      separation, list invalidation, negative-cache classification, deploy rollback, and cache-layer
-      bypass when those risks exist.
-21. Label evidence honestly. If the repository lacks deterministic cache, Redis, CDN, HTTP, browser,
+      failure, synchronized TTL expiry, old-version cached value, stale response after newer value,
+      partial response after detail response, permission change, tenant separation, list invalidation,
+      negative-cache classification, optimistic failure, persisted-storage reset, deploy rollback,
+      and cache-layer bypass when those risks exist.
+25. Label evidence honestly. If the repository lacks deterministic cache, Redis, CDN, HTTP, browser,
     or load tests, report the missing evidence instead of claiming the cache is safe.
 
 <!-- mustflow-section: postconditions -->
@@ -248,6 +287,8 @@ and what happens to the source system when the cache misses or fails?"
   and observability are explicit or reported as missing.
 - Tenant, viewer, permission, entitlement, feature-flag, locale, query, schema-version, and header
   variance cannot silently share the wrong value.
+- Partial entity responses, stale async results, optimistic mutations, persisted browser storage, SSR
+  hydration, multi-tab state, and version conflicts cannot silently overwrite or revive the wrong value.
 - Stampede, synchronized expiry, negative cache, invalidation ordering, update race, list cache,
   page cache, tag invalidation, L1/L2 layering, Redis outage, hot key, Redis Cluster, and HTTP cache
   semantics are fixed or reported where relevant.
@@ -297,8 +338,9 @@ browser, server, benchmark, or load-test commands outside the command contract.
   decisions
 - Key normalization, key version, query normalization, viewer context, tenant and permission boundary
   checks
-- Stampede, negative-cache, invalidation-order, update-race, list/page/tag, L1/L2, Redis, hot-key,
-  HTTP cache, permission-cache, warming, and observability checks where relevant
+- Stampede, negative-cache, invalidation-order, update-race, stale async state, partial-entity,
+  optimistic-update, persisted-storage, hydration, list/page/tag, L1/L2, Redis, hot-key, HTTP cache,
+  permission-cache, warming, and observability checks where relevant
 - Cache-integrity fixes made or recommended
 - Evidence level: configured-test evidence, static review risk, manual-only, missing, or not applicable
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/concurrency-invariant-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.concurrency-invariant-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: concurrency-invariant-review
@@ -59,6 +59,7 @@ The review question is not "is the code correct in this order?" The stronger que
 - Invariant: the business or data fact that must remain true across multiple fields, rows, messages, callbacks, operations, or lifecycle states.
 - Time-order points: `await`, I/O, DB calls, callbacks, event listeners, plugin hooks, logging, metrics, lock release, condition wait, notify, retry, timeout, queue ack, scheduler tick, cancellation, shutdown, close, send, and publication.
 - Synchronization evidence: exact lock identity, lock order, condition predicate, atomic memory-ordering story, transaction isolation, row lock, unique constraint, fencing token, idempotency record, queue dedupe, or deterministic test harness.
+- Failure evidence for timing bugs: incident file, wait-for graph, lock-order graph, happens-before handoff logs, generation counters, pool saturation, and configured or manual sanitizer, detector, record/replay, profiler, or kernel-tracing evidence when available.
 - Runtime and deployment shape: single thread, worker pool, process pool, multi-instance service, distributed cache, database, queue, scheduler, coroutine runtime, or reactive runtime.
 
 <!-- mustflow-section: preconditions -->
@@ -102,9 +103,11 @@ The review question is not "is the code correct in this order?" The stronger que
    - Record nested acquisition order such as `account lock -> ledger lock -> notification lock`.
    - Reject paths that acquire the same pair in reverse order unless the runtime and lock type make that impossible.
    - Check reentrant callbacks and external code called under a lock for hidden reacquisition.
+   - When local instrumentation exists, prefer a runtime lock-order graph that records edges from already-held locks to newly acquired locks and fails on cycles.
 7. Check condition variables and notifications by state, not signal.
     - A condition variable wait should be inside a loop that rechecks the predicate.
     - The loop must tolerate spurious wakeup, another waiter consuming the work first, and notifications that arrive before this worker starts waiting.
+    - Prefer generation counters or versioned predicates when the same event can be missed, duplicated, delayed, or consumed by another waiter.
     - `notify` and state changes should happen under the same synchronization boundary.
     - A lost notification is possible when code trusts the signal instead of a persistent state predicate.
 8. Check atomics, memory visibility, and CAS.
@@ -136,21 +139,27 @@ The review question is not "is the code correct in this order?" The stronger que
     - Shutdown should define stop-accepting, drain, cancel, flush, close, and in-flight side-effect ownership.
     - `closed = true` is not enough if futures, workers, sockets, buffers, queues, or async continuations keep running.
     - Mutexes, semaphores, read-write locks, connection checkouts, rate-limit tokens, and permits must release on every exception path.
-15. Check thread-local and async context.
+15. Check deadlocks and starvation as wait-for systems.
+    - A thread stack dump alone is not enough. Build a wait-for graph that connects threads, locks, condition variables, futures, queues, pool workers, callbacks, and external waits.
+    - Separate lock-order deadlock, lost notification, callback reentry, sync-over-async, and thread-pool starvation; a saturated pool can freeze progress without any mutex cycle.
+    - Record executor queue length, active worker count, blocked worker count, work-stealing or scheduler state, and blocking waits inside worker pools when local evidence exists.
+16. Check thread-local and async context.
     - Thread-local context is hidden global state in thread pools.
     - Clear request, tenant, auth, transaction, and locale context before the thread is reused.
     - Async, coroutine, virtual-thread, and reactive runtimes can break assumptions that thread-local state follows logical work.
     - Treat every `await` as a point where the world can change before the continuation resumes.
-16. Check concurrency tests as evidence, not decoration.
+17. Check concurrency tests as evidence, not decoration.
     - `Thread.sleep(100)` is not deterministic proof.
     - Prefer barriers, latches, fake schedulers, deterministic executors, controlled promises, transactional fixtures, version assertions, queue dedupe fixtures, and explicit interleaving tests.
     - Use stress or repeated tests only as supplementary evidence when deterministic ordering is unavailable.
+    - Treat sanitizer, detector, model-checker, record/replay, profiler, and kernel-scheduler diagnostics as configured or manual evidence only; report them when useful but unavailable.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Shared state, owners, invariants, and time-order points are named or missing evidence is reported.
 - Locks, atomics, conditions, transactions, distributed leases, queues, schedulers, shutdown, thread-local context, async yields, collections, caches, and tests are checked where relevant.
+- Deadlock, starvation, lost-notification, and lock-order claims are backed by wait-for, lock-order, generation, pool, or configured/manual diagnostic evidence when relevant.
 - The chosen fix or recommendation preserves the whole invariant, not just one field or one method call.
 - Deterministic evidence covers the highest-risk interleaving when the repository has a configured way to exercise it.
 
@@ -186,6 +195,7 @@ Prefer the narrowest configured test, build, docs, release, or mustflow intent t
 - Invariant and time-order table reviewed
 - Check-then-act and read-modify-write findings
 - Lock identity, lock scope, lock order, condition variable, atomics, memory visibility, CAS ABA, publication, immutability, collections, cache, database, distributed lock, idempotency, queue duplicate, state transition, scheduler, shutdown, resource release, thread-local, async `await`, and test-evidence checks where relevant
+- Wait-for graph, lock-order graph, generation counter, pool-starvation, and configured/manual diagnostic evidence where relevant
 - Concurrency fixes made or recommended
 - Tests or verification evidence
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/cross-platform-filesystem-safety/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.cross-platform-filesystem-safety
 locale: en
 canonical: true
-revision: 6
+revision: 7
 lifecycle: mustflow-owned
 authority: procedure
 name: cross-platform-filesystem-safety
-description: Apply this skill when file paths, directories, symlinks, reparse points, real paths, path traversal, reserved names, null bytes, atomic file writes, temporary files, file copies, generated outputs, clone or checkout materialization, Windows/POSIX path behavior, line endings, file permissions, durable writes, failure classification, or filesystem cleanup are created, changed, reviewed, or reported.
+description: Apply this skill when file paths, directories, symlinks, reparse points, real paths, path traversal, reserved names, null bytes, NTFS alternate data streams, Windows 8.3 short names, Windows namespace prefixes, atomic file writes, temporary files, file copies, generated outputs, clone or checkout materialization, Windows/POSIX path behavior, line endings, file permissions, durable writes, failure classification, or filesystem cleanup are created, changed, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -35,6 +35,7 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 - A change handles user-provided paths, repository-relative paths, real paths, symlinks, Windows reparse points or junctions, temporary files, generated output, backups, manifests, locks, caches, or latest pointers.
 - Code materializes large or externally sourced trees such as Git checkouts, cloned repositories, project scaffolds, dependency trees, archive extractions, template installs, generated snapshots, or package artifacts.
 - Behavior must work on Windows and POSIX path separators, drive roots, case differences, reserved names, maximum path lengths, executable extensions, line endings, permissions, or rename semantics.
+- Code or config serves files to a browser, preview server, dev server, test UI, static asset server, attachment endpoint, snapshot endpoint, or package artifact where a denied path, filename alias, or platform-specific path form could expose private files.
 - A test or final report claims a path is inside the project, symlink-safe, traversal-safe, race-safe, atomic, idempotent, cleanup-safe, or cross-platform.
 
 <!-- mustflow-section: do-not-use-when -->
@@ -49,7 +50,7 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 
 - Affected path inputs, output paths, base directory, trust boundary, and whether each path is user-controlled, template-controlled, generated, or repository-owned.
 - Current filesystem helpers, path validation rules, symlink policy, case-sensitivity policy, write strategy, cleanup strategy, temporary-file strategy, permission strategy, and platform expectations.
-- Expected behavior for missing paths, existing files, directories, symlinks, dangling symlinks, reparse points or junctions, path traversal, null bytes, Windows namespace prefixes, Windows reserved names, alternate data streams, trailing spaces or dots, collisions, long paths, large files, and permissions errors.
+- Expected behavior for missing paths, existing files, directories, symlinks, dangling symlinks, reparse points or junctions, path traversal, null bytes, Windows namespace prefixes, Windows reserved names, NTFS alternate data streams, Windows 8.3 short names, trailing spaces or dots, collisions, long paths, large files, and permissions errors.
 - Path-length, filename-length, collision, staging, promotion, and cleanup expectations for clone, checkout, scaffold, install, archive, and generated-tree flows, including the deepest known entry path when available.
 - Failure classification expectations for filesystem and platform errors such as Windows path length, POSIX `ENAMETOOLONG`, reserved names, case collisions, Unicode aliases, file locks, permissions, quota, cross-device moves, missing executable bits, line endings, watcher limits, and descriptor limits.
 - Whether atomicity requires best-effort rename, same-directory temporary files on the same volume, file fsync, parent directory fsync, Windows replacement behavior, or reader-safe latest pointers.
@@ -69,7 +70,7 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 - Prefer repository-local safe helpers over ad hoc path string checks.
 - Do not rely on string prefix checks alone when symlinks, drive roots, or real paths matter.
 - Do not lowercase paths as a universal containment strategy. Case-insensitive comparison may be appropriate for a specific platform boundary, but it must not collapse distinct POSIX paths or replace real containment checks.
-- Do not accept null bytes, Windows device names, namespace bypass prefixes, alternate data streams, or platform-invalid path segments as ordinary filenames.
+- Do not accept null bytes, Windows device names, namespace bypass prefixes, alternate data streams, 8.3 short-name aliases, or platform-invalid path segments as ordinary filenames.
 - Do not recursively delete, overwrite, or copy broad directories unless the target is resolved, bounded, and intentionally owned by the task.
 - Do not claim operating-system mitigations such as Windows RedirectionGuard unless the application actually enables and verifies the mitigation in the relevant process boundary.
 - Do not change system-wide or user-wide settings such as Windows registry long-path flags, global Git config, Developer Mode, WSL mount metadata, Linux sysctl limits, Docker Desktop storage backends, antivirus exclusions, or shell profile files from this skill. Report the missing prerequisite or require an explicit configured setup command.
@@ -78,7 +79,7 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 ## Procedure
 
 1. Classify each path as trusted repository path, user input, generated state, template source, package artifact, temporary file, external path, or unknown.
-2. Reject impossible or dangerous path text early. Check null bytes, empty segments, absolute paths where relative paths are required, Windows device names such as `CON` or `NUL`, namespace prefixes such as `\\?\`, alternate data streams using colon segments, trailing dots or spaces when Windows compatibility matters, and platform-invalid characters before writing.
+2. Reject impossible or dangerous path text early. Check null bytes, empty segments, absolute paths where relative paths are required, Windows device names such as `CON` or `NUL`, namespace prefixes such as `\\?\`, alternate data streams using colon segments, 8.3 short-name aliases such as generated `PROGRA~1`-style names, trailing dots or spaces when Windows compatibility matters, and platform-invalid characters before writing.
 3. Establish the base boundary. Use normalized repository-relative paths for storage and real-path checks for filesystem safety when symlinks may be present.
 4. Use Unicode normalization for validation only when detecting platform aliases such as superscript Windows device-name variants. Do not rewrite or persist normalized filenames unless the repository policy explicitly says so.
 5. For externally sourced trees, use a `preflight -> dangerous operation -> classifier -> safe cleanup` pipeline. Estimate the materialized path budget before writing, including destination root, project directory, generated subdirectories, deepest known repository or archive entry, Windows path-length behavior, POSIX path and component limits, byte limits, case collisions, reserved names, and safety headroom.
@@ -86,13 +87,13 @@ Keep filesystem behavior safe across Windows and POSIX while preventing path tra
 7. For Windows Git checkout or clone materialization, prefer a per-invocation `core.longpaths=true` setting when product code invokes Git. Do not mutate global Git config from application code unless the user explicitly chose that setup action. Long-path support still depends on operating-system, Git, filesystem, and downstream tool behavior, so checkout failures must remain classifiable.
 8. For symlink-heavy repositories on Windows, detect whether checkout produced real links or plain-text symlink stubs before running build logic. Report missing Developer Mode, `core.symlinks`, or native symlink support as an environment prerequisite; do not silently replace file symlinks with junctions or copies unless the repository contract explicitly supports that compatibility mode.
 9. For POSIX, do not assume that forward slashes make paths safe. Check `ENAMETOOLONG`, byte-based per-component name limits, mount permissions, executable bits, case-sensitive import paths, symlink loops, file descriptor limits, watcher limits, quota, and cross-device rename behavior.
-10. Check containment with path-aware logic. Prefer relative-path or resolved-path containment helpers over raw string prefixes, and include a path-separator boundary so partial path traversal cannot let sibling names masquerade as children.
+10. Check containment with path-aware logic. Prefer relative-path or resolved-path containment helpers over raw string prefixes, and include a path-separator boundary so partial path traversal cannot let sibling names masquerade as children. Apply deny rules to the same canonical path form that will be opened, not to a raw URL or display path that the operating system may reinterpret.
 11. Check case behavior explicitly. Windows and many macOS volumes preserve case but compare case-insensitively by default; POSIX commonly compares case-sensitively. State whether the code preserves spelling, rejects conflicting names, or relies on the host filesystem.
 12. Check collisions before materializing Git trees, archives, generated files, uploaded names, or dependency trees. Include case-only collisions, Unicode normalization aliases, reserved Windows names with extensions, trailing dot or space aliases, duplicate archive entries, and byte-limit collisions from multibyte names.
 13. Check symlink, reparse point, and junction behavior explicitly. Decide whether they are rejected, followed only within the root, or treated as ordinary path entries. Test dangling, outside-target, loop, text-stub, and junction-like cases when relevant.
 14. Close time-of-check to time-of-use gaps where practical. Prefer opening or writing through safe helpers that reject symlinks at the final operation, then verify the opened target when the platform and helper support it.
 15. Treat high-level path APIs as incomplete defenses when the runtime cannot expose descriptor-relative open, no-follow, or opened-file verification. Do not claim race-free behavior from resolve-then-open code alone.
-16. Check traversal and root handling across platforms. Account for absolute paths, drive letters, UNC-like paths, mixed separators, empty paths, dot segments, reserved names, long paths, and case sensitivity where relevant.
+16. Check traversal and root handling across platforms. Account for absolute paths, drive letters, UNC-like paths, mixed separators, empty paths, dot segments, reserved names, long paths, case sensitivity, NTFS alternate data streams, 8.3 short names, and Windows namespace prefixes where relevant.
 17. Classify filesystem failures before generic network, auth, or unknown failures. Use stable categories such as `path_too_long`, `filename_too_long`, `byte_limit_exceeded`, `invalid_path`, `reserved_name`, `case_collision`, `unicode_collision`, `symlink_escape`, `permission_denied`, `file_locked`, `cross_device_move`, `disk_full_or_quota`, `executable_bit_missing`, `line_ending_mismatch`, `watcher_limit`, and `descriptor_limit`.
 18. For writes, prefer same-directory temporary-file then rename or replace behavior when readers may observe the file. Keep the temporary file on the same volume, use unpredictable names, least-privilege creation permissions, and safe no-follow writes when the project already has that helper.
 19. Treat atomic writes as platform-specific. POSIX rename semantics, Windows replacement behavior, cross-filesystem moves, network filesystems, fsync availability, and directory fsync support differ; report best-effort guarantees honestly.
@@ -136,7 +137,7 @@ Use release checks when template files, package artifacts, or installed workflow
 - If root containment is unclear, stop before writing or deleting and report the ambiguous path owner.
 - If the platform cannot prove symlink-safe behavior, fail closed or document the exact remaining gap.
 - If atomic replace, file fsync, parent directory fsync, no-follow open, or final-target verification is not available on the platform, downgrade the claim to best-effort and keep the write boundary narrow.
-- If Unicode normalization, Windows namespace prefixes, alternate data streams, or reparse points could change the effective target, fail closed or report the exact unhandled path class.
+- If Unicode normalization, Windows namespace prefixes, alternate data streams, 8.3 short names, or reparse points could change the effective target, fail closed or report the exact unhandled path class.
 - If clone, checkout, scaffold, install, extraction, or generated-tree materialization fails, classify filesystem and platform causes before reporting network, token, auth, dependency, or unknown causes.
 - If a fix requires elevated host settings or global user configuration, stop at a clear prerequisite report unless an explicit configured command intent and user request authorize the setup.
 - If a test depends on platform-specific symlink support or permissions, state the platform boundary and keep assertions narrow.
@@ -147,7 +148,7 @@ Use release checks when template files, package artifacts, or installed workflow
 
 - Filesystem surface reviewed
 - Path trust classes, invalid-name handling, case policy, and root boundary
-- Null byte, reserved-name, Unicode normalization, namespace prefix, alternate data stream, symlink, reparse-point, traversal, race, atomic write, durability, permission, copy, delete, scan, and cleanup decisions
+- Null byte, reserved-name, Unicode normalization, namespace prefix, alternate data stream, 8.3 short-name, symlink, reparse-point, traversal, race, atomic write, durability, permission, copy, delete, scan, and cleanup decisions
 - Clone, checkout, scaffold, install, extraction, preflight, staging, promotion, path-length, collision, failure-taxonomy, and diagnostic-preservation decisions
 - Host-setting prerequisites reported or deferred
 - Windows/POSIX assumptions and skipped platform checks

package/templates/default/locales/en/.mustflow/skills/dependency-upgrade-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.dependency-upgrade-review
 locale: en
 canonical: true
-revision: 5
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: dependency-upgrade-review
-description: Apply this skill when dependency versions, lockfiles, package manager metadata, security advisory fixes, generated dependency outputs, runtime engine constraints, Python runtime support, peer dependency contracts, framework plugins, TypeScript compiler tracks, CI actions, Docker base images, or toolchain versions are upgraded, downgraded, pinned, widened, regenerated, reviewed, or reported.
+description: Apply this skill when dependency versions, lockfiles, package manager metadata, security advisory fixes, vulnerability scanner alerts, generated dependency outputs, runtime engine constraints, Python runtime support, peer dependency contracts, framework plugins, dev servers, test runners, TypeScript compiler tracks, CI actions, Docker base images, or toolchain versions are upgraded, downgraded, pinned, widened, regenerated, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -56,6 +56,7 @@ Review dependency upgrades as runtime, build, security, package, and generated-o
 - Ecosystem and package manager: JavaScript or TypeScript, Python, Go, Rust, JVM, .NET, Ruby, PHP, Swift, Docker, CI actions, or another declared system.
 - Package declarations, lockfiles, workspace files, runtime-version files, package-manager config, toolchain files, CI/Docker files, generated outputs, and command contract entries.
 - Release notes, migration notes, changelog, advisory range, fixed range, compatibility notes, or local issue evidence when available from approved context.
+- Advisory exploit preconditions, including operating system, host binding, public network exposure, dev-server mode, privileged UI/API flags, protocol peer role, unauthenticated reachability, and whether the affected package runs in production, CI, development, containers, or remote workspaces.
 - Impacted runtime paths, build paths, test paths, generated clients, mocks, fixtures, docs examples, deployment images, and package publish output.
 
 <!-- mustflow-section: preconditions -->
@@ -93,9 +94,11 @@ Review dependency upgrades as runtime, build, security, package, and generated-o
 8. For security upgrades, keep the patch narrow. Identify advisory id, affected range, fixed range, direct or transitive path, exploit-relevant code path, minimum patched version, scanner recheck, and whether stricter validation, escaping, TLS, redirect, auth, or parser behavior can break callers.
    - For lockfile-only or transitive vulnerability alerts, do not treat the lockfile line as the root cause. Trace the vulnerable package back to the direct dependency or framework plugin that resolves it, then update the narrowest parent version, override, or package-manager resolution that satisfies the fixed range.
    - After regenerating the lockfile, confirm the old vulnerable version is absent from the resolved graph and that any override is recorded in the manifest rather than hidden as unexplained lockfile churn.
+   - For devDependency advisories, decide whether the affected tool ever binds to a non-localhost host, runs in a container with published ports, serves worktree files, exposes a browser or test UI, accepts remote API tokens, writes source or snapshot files, reruns tests, or executes project code. A devDependency can still be security-sensitive when it is reachable from another machine or CI/preview surface.
+   - For protocol and crypto dependency advisories, classify whether the package acts as client, server, agent, parser, verifier, or keyring. Check unauthenticated reachability, panic or assertion behavior, attacker-controlled key sizes, packet or frame ordering, unsolicited responses, and resource exhaustion before reducing the finding to "DoS only".
 9. Review the lockfile as a graph, not a blob. Check direct and transitive replacements, newly introduced packages, removed packages, optional/platform packages, source URLs, integrity or checksum changes, peer resolution, engine requirements, native prebuilds, and postinstall or lifecycle scripts.
 10. Review runtime boundaries that dependency upgrades commonly break: ESM/CJS and package `type`, `exports` and conditional exports, browser/node/edge conditions, Node engine support, Python dependency markers and extras, Go module path changes, Cargo feature unification, native builds, SSR/client split, WebView/native split, and generated client or SDK types.
-11. Treat framework, plugin, code generator, formatter, linter, bundler, ORM, protobuf, OpenAPI, GraphQL, database driver, and test-runner upgrades as behavior changes when their output, config schema, plugin API, CLI flags, or generated code can change.
+11. Treat framework, plugin, code generator, formatter, linter, bundler, ORM, protobuf, OpenAPI, GraphQL, database driver, dev-server, browser-test, and test-runner upgrades as behavior changes when their output, config schema, plugin API, CLI flags, file-serving policy, privileged UI gates, or generated code can change.
 12. For Python runtime upgrades, treat `requires-python`, CI matrices, base images, dependency markers, wheels, packaging output, standard-library API availability, and security-default changes as one compatibility contract. Review version-gated standard-library usage and changed defaults before assuming the upgrade is only a dependency resolution change.
 13. For Python upgrades that adopt newer standard-library behavior, call out affected paths such as archive extraction, subprocess handling, async lifecycle, import/resource loading, typing surfaces, data-class shapes, and diagnostic flags. Keep fallbacks or compatibility wording when the repository still supports older interpreters.
 14. For TypeScript upgrades, classify the compiler track explicitly: TS6 stable API track through `@typescript/typescript6` and `tsc6`, TS7 RC compiler track through `typescript@rc` and `tsc`, TS7 nightly track through `@typescript/native-preview` and `tsgo`, future TS7 stable track through the stable `typescript` package, editor extension preview, or framework-owned wrapper. Do not treat a nightly package as a stable replacement for the `typescript` package unless the repository policy says so.
@@ -116,6 +119,7 @@ Review dependency upgrades as runtime, build, security, package, and generated-o
 - Python runtime upgrades classify standard-library availability, changed defaults, packaging output, and security-behavior impact.
 - TypeScript compiler-track changes distinguish TS6 stable API compatibility, TS7 RC compiler verification, TS7 nightly comparison work, and future TS7 stable adoption.
 - Security fixes are narrow unless the user explicitly accepted a broader modernization.
+- Advisory exploit preconditions are checked against local scripts, config, CI, containers, remote workspaces, and docs before an alert is dismissed as development-only or unreachable.
 - Tests and scanners were not weakened to pass the upgrade.
 
 <!-- mustflow-section: verification -->
@@ -158,6 +162,7 @@ Prefer the narrowest configured intent that proves the actual upgraded dependenc
 - Python runtime, standard-library, packaging, and changed-default risks when relevant
 - TypeScript compiler-track, RC, nightly, and API compatibility risks when relevant
 - Security advisory and fixed-range notes when relevant
+- Exploit preconditions, dev-server exposure, protocol role, and scanner recheck notes when relevant
 - Surfaces synchronized
 - Command intents run
 - Skipped dependency checks and reasons

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.memory-lifetime-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: memory-lifetime-review
@@ -59,6 +59,7 @@ The question is not only "where was it allocated?" The stronger review question
 - Retainer graph: the longer-lived owner, the shorter-lived object, the reference path between them, and the expected point where that reference should be severed.
 - Repetition path: repeated requests, screen open/close, route changes, tab switches, reconnects, retries, scheduled runs, test cases, or long-running sessions that can accumulate retained state.
 - Error and success paths: normal completion, early return, partial read, cancellation, timeout, retry, exception, unmount, shutdown, and dependency failure behavior.
+- Diagnostic evidence for native or low-level memory faults: first sanitizer or memory-checker report, invalid write/read address, watchpoint condition, allocator or quarantine behavior, fuzzing input, core dump, symbols, build id, shared library list, and configured or manual diagnostic boundary.
 - Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
 
 <!-- mustflow-section: preconditions -->
@@ -116,8 +117,21 @@ The question is not only "where was it allocated?" The stronger review question
     - C and C++: ownership transfer must be explicit across raw pointers, containers, callbacks, and failure paths; `shared_ptr` cycles need `weak_ptr` or a different ownership shape.
     - Rust: `Rc`, `Arc`, `RefCell`, task handles, channels, and cycles can leak even when memory safety is preserved; use weak ownership or explicit shutdown when ownership is not truly shared.
     - Python: weak references are useful for caches and observer maps, but not as a substitute for a clear lifetime owner; check global dicts, LRU caches, callbacks, generators, files, and async tasks.
-11. Reject finalizers as the main plan. Finalizers, destructors, drop hooks, or weak callbacks can be last-resort diagnostics or safety nets, but the review should still identify deterministic cleanup for resources and reference removal.
-12. Add a repeated-lifecycle proof when feasible. Prefer a focused test or probe that repeats the risky lifecycle, then asserts listener count, registry size, cache size, goroutine/task completion, handle closure, queue depth, or retained object count. If heap snapshots, leak profilers, sanitizer runs, or platform-specific diagnostics are not configured intents, report them as manual evidence gaps instead of running raw commands.
+11. For native or low-level memory corruption, chase the first invalid access instead of the crash line.
+    - Treat the crash line as a victim until the first invalid write, invalid read, use-after-free, double free, uninitialized value, or ownership violation is identified.
+    - Prefer the first sanitizer, memory-checker, or watchpoint report over later cascade failures.
+    - Use watchpoint, reverse-debugging, core dump, symbol, build-id, allocator, quarantine, or memory-poison evidence only through configured or manual diagnostics; do not infer raw commands from tool names.
+12. Separate diagnostic build axes when they exist.
+    - ASan/UBSan/LSan, TSan, MSan, release-with-asserts, debug allocator, guard-page allocator, hardware tagging, and fuzzing-with-sanitizers expose different bug classes and usually should be reported as separate configured or manual evidence surfaces.
+    - Do not claim memory-corruption proof from a normal unit test unless it actually exercises the ownership and lifetime boundary.
+13. Treat dangling references as ownership failures.
+    - Ask which owner promised the object would remain alive across async callbacks, observer lists, event buses, lambda captures, coroutines, workers, caches, intrusive lists, and queues.
+    - Prefer stable handles, owner id plus generation id, unregister-on-drop or RAII boundaries, weak-reference lock windows, and queueing copied identifiers instead of raw object pointers or references when local style supports them.
+14. Preserve production crash evidence when reproduction is unavailable.
+    - Core dump, exact binary, symbols, build id, shared library list, process maps, allocator state, failing input, and deployment version can be the only evidence for a memory fault.
+    - If those artifacts are unavailable or manual-only, report that boundary instead of implying the crash was diagnosed from logs alone.
+15. Reject finalizers as the main plan. Finalizers, destructors, drop hooks, or weak callbacks can be last-resort diagnostics or safety nets, but the review should still identify deterministic cleanup for resources and reference removal.
+16. Add a repeated-lifecycle proof when feasible. Prefer a focused test or probe that repeats the risky lifecycle, then asserts listener count, registry size, cache size, goroutine/task completion, handle closure, queue depth, or retained object count. If heap snapshots, leak profilers, sanitizer runs, memory-checker runs, fuzzers, core dump inspection, or platform-specific diagnostics are not configured intents, report them as manual evidence gaps instead of running raw commands.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -126,6 +140,7 @@ The question is not only "where was it allocated?" The stronger review question
 - Long-lived owners no longer retain short-lived objects beyond their intended lifecycle, or the remaining retention is intentional and bounded.
 - Caches, queues, registries, debug stores, and logging or telemetry buffers have capacity, eviction, truncation, or copied-value boundaries where they can grow.
 - Async, stream, worker, goroutine, thread, and native-resource paths have deterministic cancellation, close, shutdown, or release behavior where the platform supports it.
+- Native or low-level memory fault analysis names the first invalid access evidence or reports the missing diagnostic boundary instead of blaming the final crash line.
 - Tests or configured verification cover the highest-risk repeated lifecycle when feasible.
 
 <!-- mustflow-section: verification -->
@@ -162,6 +177,7 @@ Use the narrowest configured test, build, docs, release, or mustflow intent that
 - Retainer paths found or ruled out
 - Long-lived owners and short-lived objects checked
 - Timers, listeners, subscriptions, streams, workers, goroutines, threads, native handles, caches, queues, registries, closures, and logs checked where relevant
+- First invalid access, diagnostic build axis, dangling ownership, fuzzing or core-dump evidence where relevant
 - Cleanup symmetry changes made or recommended
 - Repeated-lifecycle proof: configured, manual-only, missing, or not applicable
 - Command intents run