mustflow 2.112.10 → 2.112.13

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

package/templates/default/locales/en/.mustflow/skills/observability-debuggability-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.observability-debuggability-review
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: observability-debuggability-review
@@ -94,79 +94,88 @@ The review question is not "does the code emit telemetry?" It is "when this path
    - List logs, metrics, traces, spans, events, audit entries, alerts, dashboards, runbooks, and exporter self-metrics touched by the path.
    - Mark each signal as symptom, cause evidence, correlation evidence, saturation evidence, recovery evidence, or noise.
    - A success-only log is not enough; failure classification and missing-work evidence matter more.
-3. Check metrics for numerator and denominator.
+3. Prefer trace-first diagnosis for distributed or cross-boundary failures.
+   - Compare normal and failing trace trees before reading only the final error log.
+   - Look for the first divergence in span order, missing span, retry branch, cache hit or miss, DB call count, dependency latency, worker shard, feature flag, release id, queue age, or pool wait.
+   - Logs should explain branch decisions inside that trace; metrics should show whether the incident is isolated or systemic.
+4. Align trace, log, and profiler evidence on one time axis when timing or ordering may matter.
+   - Trace evidence identifies the affected request, job, message, or operation.
+   - Profiler evidence identifies what the process was doing during the same window: CPU, wall wait, lock contention, allocation, GC, or pool wait.
+   - Do not treat a slow span as self-explanatory until the same window's process, pool, dependency, and queue evidence have been checked where available.
+5. Check metrics for numerator and denominator.
    - Error counters need total attempt counters so an operator can compute rates.
    - Cache hits need total lookups, fill errors, stale-served counts, origin latency, and eviction or lock-wait evidence when cache correctness matters.
    - Rate limits need allowed, blocked, shadow-blocked, delayed, retry-after, policy, and key-type evidence rather than only `rate_limited_total`.
-4. Reject average-only latency.
+6. Reject average-only latency.
    - Prefer histograms or equivalent distribution evidence for p95, p99, and tail behavior.
    - Separate success latency from error latency; fast failures should not make the service look healthy.
    - Label outcome and status class with bounded cardinality where the local metric system supports it.
-5. Protect metric cardinality.
+7. Protect metric cardinality.
    - Do not put raw URL paths, query strings, user ids, order ids, emails, message ids, idempotency keys, exception messages, SQL text, or arbitrary provider codes into metric labels.
    - Use route templates, dependency names, operation names, status classes, bounded reason enums, policy names, and feature flag names.
    - Keep high-cardinality fields in traces, structured events, audit records, or sampled logs when they are safe and needed for narrowing.
-6. Check trace and log correlation.
+8. Check trace and log correlation.
    - Logs should include trace id and span id, or the local equivalent, when distributed tracing exists.
    - Spans should include dependency name, operation name, route template, outcome, safe error type, retry attempt, timeout or cancellation class, and release or environment attributes when useful.
    - If a log line cannot be joined to a request, job, message, or batch run, it is weak incident evidence.
-7. Check async and queue context propagation.
+9. Check async and queue context propagation.
    - HTTP to worker, queue, stream, pub/sub, webhook, cron, and batch boundaries should propagate or intentionally fork trace context.
    - Producers should inject safe context into messages when the system needs end-to-end diagnosis; consumers should extract it before doing work.
    - A new trace at the worker boundary can be correct only when the handoff is intentionally modeled and linked by message, job, or causation id.
-8. Separate attempt from operation.
+10. Separate attempt from operation.
    - Retries should expose each dependency attempt and the final logical operation result.
    - A final success after two failed attempts is a business success and a dependency warning.
    - Record attempt number, max attempts, retry decision, delay, retry-after use, dependency name, and final exhaustion reason with bounded labels.
-9. Classify timeout, cancellation, and deadline.
+11. Classify timeout, cancellation, and deadline.
    - User cancellation, upstream deadline, server timeout, dependency timeout, pool acquire timeout, queue visibility expiry, and shutdown cancellation are different events.
    - Do not merge all of them into one generic error metric or log reason.
    - Preserve cancellation semantics without turning intentional caller cancellation into a dependency incident.
-10. Review external dependency spans and metrics.
+12. Review external dependency spans and metrics.
     - `GET https://api.vendor.example` is not enough; add a stable dependency name and operation name.
     - Track attempts, latency distribution, status class, retryable decision, timeout class, circuit-open decisions, and provider request id when safe.
     - Keep provider host, endpoint, and response details out of metric labels when they are unbounded or sensitive.
-11. Review database and transaction evidence.
+13. Review database and transaction evidence.
     - Avoid raw SQL in logs and telemetry where it can contain personal data or secrets.
     - Prefer query name, table or collection, operation, rows returned, rows affected, duration, timeout class, and safe error category.
     - Transaction flows should expose begin, commit, rollback, retry, after-commit side effects, external-call-before-commit risk, and compensation or reconciliation evidence when relevant.
-12. Review idempotency and partial-success evidence.
+14. Review idempotency and partial-success evidence.
     - Payment, order, entitlement, file, webhook, queue, and batch paths need idempotency key, dedupe key, message id, request id, attempt, side-effect state, and unknown-outcome markers where safe.
     - Ask where evidence remains when DB write succeeds but event publish fails, provider call succeeds but local state fails, cache write succeeds but origin rollback happens, or compensation fails.
     - Metrics and logs should distinguish attempt, success, failure, compensation, retry exhausted, and unknown outcome.
-13. Review queue, stream, and batch signals.
+15. Review queue, stream, and batch signals.
     - Consumers need queue delay or message age, processing duration, inflight count, ack or commit failures, redelivery count, retry count, DLQ count, poison reason, and oldest message age where supported.
     - Batch jobs need last success timestamp, last completion timestamp, duration, processed count, failed count, skipped count, and stale-job alert evidence.
     - Silent pipelines need heartbeat or synthetic item evidence when "no input" can look like success.
-14. Review pools and saturation.
+16. Review pools and saturation.
     - CPU can be low while worker, thread, DB connection, HTTP connection, queue, semaphore, or rate-limit pools are saturated.
     - Track active, max, queued, queue wait, acquire duration, timeout count, rejection count, and per-dependency pool names with bounded labels.
     - Missing saturation evidence should downgrade performance and reliability claims.
-15. Review feature, config, release, and migration attribution.
+17. Review feature, config, release, and migration attribution.
     - Logs, traces, and metrics should carry service version, git sha or release id, deployment environment, region, schema or migration version, config version, and relevant feature flag or experiment variant when local policy allows.
     - If a 5 percent feature flag cohort can fail separately, the telemetry must let operators split healthy and broken cohorts.
-16. Check alert and runbook usefulness.
+18. Check alert and runbook usefulness.
     - Every new critical metric should answer what panel, alert, or runbook sentence it supports.
     - Pager alerts should indicate user impact or clear operator action, not only "a counter changed."
     - Logs that page humans should have matching counters or rates so operators can see when the event started and how fast it is happening.
-17. Check telemetry self-observability.
+19. Check telemetry self-observability.
     - Exporters, collectors, custom metric collectors, log sinks, trace queues, and sampling pipelines need dropped, failed, queued, scrape error, and export latency evidence when they can blind operators.
     - If telemetry failure can hide product failure, treat missing self-metrics as an operational risk.
-18. Check signal pipeline loss and read-path visibility.
+20. Check signal pipeline loss and read-path visibility.
     - Compare produced, accepted, exported, stored, and query-visible signal counts when the path depends on logs, metrics, traces, or events for diagnosis.
     - Use canary events or synthetic heartbeats when "no telemetry" could mean no traffic, collector failure, broken parser, dropped queue, retention gap, or dashboard read failure.
     - Track event timestamp versus observed timestamp, queue oldest age, DLQ oldest age, parser or mapping failures by service and version, and duplicate or sequence-gap evidence.
     - Separate telemetry write-path health from read-path health. A sink can store data that dashboards cannot query, and dashboards can be healthy while new signals are not arriving.
     - If collector, sink, dashboard, or production telemetry checks are outside repository commands, report the manual-only boundary.
-19. Check sampling policy.
+21. Check sampling policy.
     - Head sampling can drop rare errors and slow traces.
     - Error, slow, retry-exhausted, high-latency, partial-success, DLQ, and compensation-failure traces often need keep rules, tail sampling, or explicit event evidence.
+    - If a rare failure can be sampled out, require fallback event logs for key span boundaries, duration, outcome, reason, tenant or job slice, feature flag, and deployment version.
     - If sampling is outside the repository, report the manual-only evidence boundary instead of assuming critical traces are retained.
-20. Check privacy before telemetry leaves the process.
+22. Check privacy before telemetry leaves the process.
     - Redact or classify tokens, passwords, authorization headers, cookies, raw bodies, emails, phone numbers, payment data, personal identifiers, prompt text, confidential document text, provider payloads, and full SQL before logger, metric, trace, baggage, or exporter entry.
     - Baggage should be small, safe, low-lifetime, and intentional. Do not use it as a general request metadata bag.
     - Report sink-side masking as insufficient when sensitive data can already leave the process unredacted.
-21. Require telemetry tests or contract evidence where feasible.
+23. Require telemetry tests or contract evidence where feasible.
     - Good tests assert stable event names, bounded label values, denominator counters, trace-context propagation, redaction, sampling flags, feature flag attributes, release attributes, and failure-category mapping.
     - Source-level guards can prevent raw URL or user id metric labels when runtime telemetry tests are not available.
     - If dashboards, alerts, production traces, or load evidence are manual-only, complete available checks and report the evidence gap.
@@ -176,6 +185,7 @@ The review question is not "does the code emit telemetry?" It is "when this path
 
 - The changed path has an incident question, signal ledger, metric model, trace and log correlation model, telemetry pipeline survival boundary, cardinality boundary, privacy boundary, and evidence level.
 - Missing denominators, average-only latency, success-only logs, uncorrelated logs, raw URL labels, raw user labels, raw SQL telemetry, lost async trace context, attempt and operation collapse, generic timeout or cancellation buckets, missing dependency names, missing queue age, missing batch last-success timestamp, missing pool saturation, missing release attribution, decorative metrics, unsafe baggage, telemetry self-blindness, and sampling that drops critical failures are fixed or reported.
+- Normal-versus-failing trace comparisons and trace/log/profiler time-axis alignment are used or reported as unavailable when timing, ordering, retry, queue, pool, or dependency behavior is the likely cause.
 - Observability claims are backed by configured tests, schema or fixture evidence, local telemetry conventions, dashboard or alert files, static review evidence, or labeled as manual-only or missing.
 
 <!-- mustflow-section: verification -->
@@ -208,7 +218,7 @@ Prefer the narrowest configured test, build, docs, release, or mustflow intent t
 ## Output Format
 
 - Observability boundary reviewed
-- Incident question, signal ledger, metric model, trace and log correlation, cardinality, identity propagation, attempts versus operation, timeout or cancellation classification, external dependency, DB and transaction, idempotency and partial success, queue or batch, cache, pool saturation, rate limit, feature or release attribution, alert or runbook, telemetry self-observability, signal pipeline survival, sampling, privacy, and test evidence findings
+- Incident question, signal ledger, normal-versus-failing trace comparison, trace/log/profiler time-axis alignment, metric model, trace and log correlation, cardinality, identity propagation, attempts versus operation, timeout or cancellation classification, external dependency, DB and transaction, idempotency and partial success, queue or batch, cache, pool saturation, rate limit, feature or release attribution, alert or runbook, telemetry self-observability, signal pipeline survival, sampling, privacy, and test evidence findings
 - Observability fixes made or recommended
 - Evidence level: configured-test evidence, telemetry fixture evidence, dashboard or alert file evidence, static review risk, manual-only, missing, or not applicable
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/race-condition-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.race-condition-review
 locale: en
 canonical: true
-revision: 1
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: race-condition-review
-description: Apply this skill when code is created, changed, reviewed, or reported and shared state can be observed across interleaving execution flows, including check-then-act, read-modify-write, stale reads after await or I/O, lock scope and order, tryLock, timeout or retry behavior, cache miss fill, lazy initialization, atomics and memory ordering, database transaction races, uniqueness, distributed locks, idempotency, atomic file creation, event or outbox ordering, queue duplicates, shutdown, cancellation, timers, close/send races, shared collections, object reuse, fake immutability, sleep-based race tests, log ordering, and state-machine transitions.
+description: Apply this skill when code is created, changed, reviewed, or reported and shared state can be observed across interleaving execution flows, including check-then-act, read-modify-write, stale reads after await or I/O, lock scope and order, tryLock, timeout or retry behavior, cache miss fill, lazy initialization, atomics and memory ordering, database transaction races, uniqueness, distributed locks, fencing tokens, idempotency state records, atomic file creation, event or outbox ordering, inbox or dedupe consumers, per-key serialization, queue duplicates, shutdown, cancellation, timers, close/send races, shared collections, object reuse, fake immutability, sleep-based race tests, log ordering, and state-machine transitions.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -59,7 +59,9 @@ The review question is not "does this code use threads?" The stronger question i
 - Interleaving points: `await`, I/O, database calls, callbacks, hooks, plugin calls, event publish, queue insert, lock release, timer scheduling, retry, cancellation, shutdown, close, send, and other function calls after a state read.
 - Synchronization boundary: lock scope, atomic operation, compare-and-swap, transaction, row lock, unique constraint, conditional update, singleflight, idempotency record, outbox, or file atomic create/rename behavior.
 - Ordering and duplication rules: event order, queue delivery semantics, duplicate messages, same-user or same-resource concurrency, retry replay, cancellation timing, timer overlap, and shutdown drain behavior.
+- Idempotency and ownership rule: business idempotency key, processing/succeeded/failed record state, duplicate-in-progress behavior, fencing token or generation owner, and whether same-key work is serialized while unrelated keys can run concurrently.
 - Evidence surface: existing tests, fixtures, schema constraints, command intents, logs, metrics, sequence numbers, request ids, transaction ids, versions, or manual-only concurrency evidence.
+- Incident file when a concurrency failure was observed: test name, seed, worker or thread count, scheduler settings, timeout, input, build hash, OS/runtime version, environment slice, and exact failure time when available.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
@@ -82,61 +84,68 @@ The review question is not "does this code use threads?" The stronger question i
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Name the shared fact. State the exact value or invariant another execution flow could change: balance, status, cache entry, uniqueness, queue offset, file existence, socket state, collection membership, timer owner, shutdown flag, or object ownership.
-2. Build a stale-read ledger.
+1. Preserve the incident file before changing code when a race was observed.
+   - Capture the failing test or workflow name, random seed, worker or thread count, scheduler or CPU-affinity setting when relevant, timeout, input, build hash, OS/runtime version, environment variables that affect scheduling, and exact failure time.
+   - Do not replace a missing incident file with "ran many times"; repeated passing runs are weaker than one reproducible failing condition.
+2. Name the shared fact. State the exact value or invariant another execution flow could change: balance, status, cache entry, uniqueness, queue offset, file existence, socket state, collection membership, timer owner, shutdown flag, or object ownership.
+3. Build a stale-read ledger.
    - For each shared state read, mark every later `await`, I/O, DB call, callback, event publish, queue insertion, lock release, timer, retry, cancellation, shutdown, close, send, or function call before the action.
    - Ask whether the read is still true after each interleaving point. If the answer relies on hope, the path is not race-safe.
-3. Catch check-then-act.
+4. Catch check-then-act.
    - Treat patterns such as `if exists then create`, `if balance >= amount then withdraw`, `if status == pending then approve`, duplicate email checks, coupon redemption, order number generation, and filesystem `exists` then `open` as unsafe until proven atomic.
    - Prefer atomic conditional updates, atomic create, insert with unique constraint, compare-and-swap, row locks, or file creation modes that fail when the target already exists.
-4. Catch read-modify-write.
+5. Catch read-modify-write.
    - `++`, `+=`, `push`, `append`, `map[key] = value`, collection mutation, get-then-set, and counter updates are shared-state writes, not harmless syntax.
    - Use atomic operations only when the invariant is one variable. If the invariant spans fields, rows, objects, or messages, use a transaction, lock, state machine, or conditional write that protects the whole fact.
-5. Do not trust a single event loop after `await`.
+6. Do not trust a single event loop after `await`.
    - In JavaScript, Python async, UI runtimes, and coroutine systems, a state read before `await` can be stale after the continuation resumes.
    - Re-read, validate a version, hold the correct synchronization boundary, or move the decision into an atomic operation.
-6. Review lock scope by invariant, not by field.
+7. Review lock scope by invariant, not by field.
    - A lock around one setter does not protect a multi-field or multi-row rule if reads and writes outside the lock can observe intermediate state.
    - Keep callbacks, hooks, events, plugin calls, external I/O, logging, JSON conversion, and long calculations outside locks unless the invariant truly requires them.
    - Define and follow a global lock order when more than one lock can be acquired.
-7. Treat `tryLock`, timeout, and retry as risk multipliers.
+8. Treat `tryLock`, timeout, and retry as risk multipliers.
    - Check what partial state remains when lock acquisition fails, times out, or is retried.
    - Verify rollback, idempotency, duplicate side-effect prevention, and retry budget. A retry can make a race rarer or louder, not correct.
-8. Review cache miss fill and lazy initialization.
+9. Review cache miss fill and lazy initialization.
    - Multiple misses for the same key should not all rebuild, fetch, insert, or publish the same value unless duplication is harmless and bounded.
    - Use singleflight, promise memoization with failure cleanup, once initialization, durable uniqueness, or explicit cache-authority rules.
    - Double-checked locking needs a memory-ordering story in runtimes where construction visibility is not automatically safe.
-9. Review atomics and memory ordering.
+10. Review atomics and memory ordering.
    - Atomics protect a specific operation on a specific value. They do not automatically make surrounding objects, arrays, maps, or multi-field invariants safe.
    - Check acquire/release or stronger memory ordering where the language exposes it, and report missing expertise or evidence instead of guessing.
-10. Review database races.
+11. Review database races.
     - A database transaction does not erase a race by itself. Check isolation level, row locks, predicate locks, uniqueness, conditional updates, and whether `SELECT` then `UPDATE` can be invalidated before commit.
     - Prefer `UPDATE ... WHERE status = ...`, insert-or-ignore/upsert with unique constraints, version columns, row locks, or serializable isolation when the invariant requires it.
     - Application-level duplicate checks are advisory only; unique facts belong in the database or another durable single-writer authority.
-11. Review distributed locks as debt.
-    - Lock expiry, process pauses, network delay, clock skew, and split ownership can let two workers believe they own the same work.
-    - Keep data correct if the distributed lock breaks: unique constraints, idempotency keys, fencing tokens, conditional writes, or state transitions should still reject stale owners.
-12. Review event, queue, and outbox ordering.
-    - Publishing an event before or after a state change can split the world unless a durable outbox or equivalent boundary ties them together.
-    - Queue consumers should assume duplicates, reordering, delayed delivery, redelivery after timeout, and concurrent work for the same user or resource.
-    - Use inbox deduplication, per-aggregate ordering, conditional state transitions, or idempotent side effects where needed.
-13. Review filesystem races.
+12. Review distributed locks as debt.
+   - Lock expiry, process pauses, network delay, clock skew, and split ownership can let two workers believe they own the same work.
+   - Keep data correct if the distributed lock breaks: unique constraints, idempotency keys, fencing tokens, conditional writes, or state transitions should still reject stale owners.
+13. Review event, queue, and outbox ordering.
+   - Publishing an event before or after a state change can split the world unless a durable outbox or equivalent boundary ties them together.
+   - Queue consumers should assume duplicates, reordering, delayed delivery, redelivery after timeout, and concurrent work for the same user or resource.
+   - Use inbox deduplication, per-aggregate ordering, per-key serialization, conditional state transitions, or idempotent side effects where needed.
+   - Same-key work should expose whether the current record is processing, succeeded, failed, cancelled, or dead. A duplicate arriving while the first attempt is still processing is not the same as replaying a completed result.
+   - Business idempotency keys should describe the intended operation, not just the transport request id, when retries or duplicate submissions must return the same logical result.
+14. Review filesystem races.
     - `exists` then `open`, temp file name selection, cleanup by path, and replace-in-place can race.
     - Prefer atomic create, safe temporary file APIs, same-directory temp files, fsync where durability matters, and atomic rename or replace semantics appropriate to the platform.
-14. Review shutdown, cancellation, timers, close, and send.
+15. Review shutdown, cancellation, timers, close, and send.
     - Shutdown should define who stops accepting work, who drains, who cancels, and who owns in-flight side effects.
     - Cancellation must be idempotent and safe when completion happens at the same time.
     - Timers and schedulers need one current owner; old timers should not update new state.
     - WebSocket, channel, stream, socket, queue, and emitter paths need a clear rule for close/send races and double close.
-15. Review shared collections and object reuse.
+16. Review shared collections and object reuse.
     - Iteration over a collection that another flow can mutate needs a lock, snapshot, immutable copy, version check, or concurrent collection semantics.
     - Object pooling, buffer reuse, mutable DTO reuse, and reused request contexts are unsafe if async work can still hold references.
     - Fake immutable objects with mutable internals, getters, shared maps, or cached arrays should be treated as mutable shared state.
-16. Review tests and logs with suspicion.
+17. Review tests and logs with suspicion.
     - `sleep`-based race tests are usually probability tests. Prefer deterministic barriers, fake schedulers, controlled promises, version assertions, unique constraints, or repeated stress only as supplementary evidence.
+    - Shake the schedule, not only the load: widen context-switch windows with configured deterministic barriers, fake schedulers, controlled yields, delay injection, or repeated stress harnesses only when the repository command contract allows them.
     - Logging can hide or change a race. Log order is not event order across threads, processes, async tasks, buffers, or machines.
-    - Use monotonic sequence numbers, request ids, transaction ids, version columns, or state transition logs when ordering is evidence.
-17. Escalate broad status fields into state-machine review.
+    - Use happens-before logs at handoff points such as queue push/pop, mutex unlock/lock, atomic release/acquire, promise/future completion, channel send/receive, callback registration/execution, plus monotonic sequence numbers, request ids, transaction ids, version columns, or state transition logs when ordering is evidence.
+    - Treat race detectors, thread sanitizers, deterministic record/replay, profilers, kernel tracing, or stress tools as configured or manual diagnostics only; never infer raw commands from the tool names.
+18. Escalate broad status fields into state-machine review.
     - If values such as `pending`, `processing`, `done`, `failed`, `cancelled`, `closed`, or `deleted` drive behavior, draw allowed transitions and reject stale concurrent transitions.
     - Use `state-machine-pattern` when the race fix needs a transition table, event union, transition log, retry reconciliation, or effect ordering.
 
@@ -144,9 +153,11 @@ The review question is not "does this code use threads?" The stronger question i
 ## Postconditions
 
 - Shared state reads, interleaving points, and stale-read risks are identified or ruled out.
+- Observed concurrency failures preserve the incident file needed to reproduce the same timing envelope when available.
 - Check-then-act and read-modify-write paths are atomic, guarded, constrained, or explicitly reported as residual risk.
 - Locks protect whole invariants, have a clear ordering rule, and avoid slow or reentrant work where possible.
 - Database, cache, queue, event, filesystem, cancellation, shutdown, timer, close/send, collection, and object-reuse races are checked where relevant.
+- Idempotency processing states, duplicate-in-progress behavior, fencing tokens, outbox/inbox handoffs, and per-key serialization are checked where relevant.
 - Tests or configured verification cover the highest-risk concurrency invariant when feasible.
 
 <!-- mustflow-section: verification -->
@@ -178,9 +189,11 @@ Prefer the narrowest configured test, build, docs, release, or mustflow intent t
 ## Output Format
 
 - Shared state and invariant reviewed
+- Incident file captured or reported missing
 - Interleaving points checked
 - Check-then-act and read-modify-write findings
 - Async stale-read, lock scope/order, tryLock/timeout/retry, cache/lazy init, atomic/memory ordering, database transaction, uniqueness, distributed lock, idempotency, filesystem, event/outbox, queue, shutdown, cancellation, timer, close/send, shared collection, object reuse, fake immutable, test, log, and state-machine checks where relevant
+- Idempotency record states, fencing token, inbox or dedupe, per-key serialization, and duplicate-in-progress checks where relevant
 - Race fixes made or recommended
 - Tests or verification evidence
 - Command intents run