mustflow 2.22.16 → 2.22.46

package/templates/default/locales/en/.mustflow/skills/release-publish-change/SKILL.md

@@ -0,0 +1,172 @@
+---
+mustflow_doc: skill.release-publish-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: release-publish-change
+description: Apply this skill when release publishing, package registry publication, remote release channels, Git tags, GitHub Releases, release assets, npm, PyPI, crates.io, Go modules, Docker images, Homebrew formulae or casks, app updater metadata, version bump decisions, artifact inspection, post-publish smoke tests, rollback or yanking plans, or user installation paths are created, changed, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.release-publish-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Release Publish Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep release work honest by treating a release as a remote state transition, not as a local code edit.
+
+The release is not done when tests pass locally, a version string changes, or a workflow succeeds. It is done only when the intended remote channel contains the expected artifact and a user-facing installation or update path has been smoke-tested through configured command intents or explicitly reported as unverified.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A task prepares, changes, reviews, or reports package publication, registry publication, Git tag release, GitHub Release creation, release assets, checksums, signatures, Docker image tags, Homebrew formulae, app updater feeds, appcast files, channel metadata, or installer distribution.
+- A change touches version bump logic, package metadata, release workflows, publish workflows, release assets, package contents, changelog-to-release wiring, post-publish smoke tests, or rollback and yanking guidance.
+- A final report claims that a version was published, released, installable, downloadable, updateable, yanked, deprecated, rolled back, or verified by the user installation path.
+- A release target includes npm, PyPI, crates.io, Go modules, Docker registries, GitHub Releases, Homebrew, Electron auto-update, Sparkle, Tauri updater, mobile stores, desktop installers, or another remote distribution channel.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only drafts release notes or changelog wording without publishing, package metadata, release artifact, or install-path claims. Use `release-notes-authoring` instead.
+- The task only changes dependency versions inside a project and does not publish the project. Use `dependency-upgrade-review`.
+- The task only checks local artifact integrity without changing or reporting release publication. Use `artifact-integrity-check` if available.
+- The task asks for a private experiment that must not affect remote tags, registries, release assets, or update channels.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Release target, version, channel, package name, module path, image name, tag, artifact names, expected assets, and intended audience.
+- Public contract source for versioning: package metadata, manifest, lock or generated metadata, changelog, release workflow, tag policy, and SemVer or project-specific compatibility rules.
+- Artifact source and inspection method: package file list, archive contents, generated distributions, checksums, signatures, SBOM, provenance, installer contents, image digest, updater metadata, or release asset manifest.
+- Remote publication surface: registry, Git tag, GitHub Release, Docker registry, tap, updater feed, appcast, CDN, package index, or store.
+- Recovery model: unpublish, yank, deprecate, republish with new version, move channel pointer, revoke asset, restore from backup, or forward fix.
+- Configured command intents for build, package inspection, release verification, docs validation, and user installation or updater smoke test. If no such intent exists, report the missing intent instead of inventing a raw command.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions, release preferences, and the command contract have been checked for the current scope.
+- The release target and version are known, or the work is explicitly limited to authoring a release procedure skill or checklist.
+- Remote publication, tag creation, push, registry upload, production updater change, and destructive yanking or unpublish actions are not executed unless the repository and host rules explicitly authorize them.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update version metadata, release workflow files, package manifests, artifact manifests, changelog or release-preparation docs, release validation tests, package fixture expectations, and installed-template metadata directly required by the release contract.
+- Update smoke-test expectations and package tests that encode the release or installation contract.
+- Add conservative release procedure text that describes configured command intents and required evidence.
+- Do not publish, tag, push, yank, delete, unpublish, overwrite assets, or alter remote channels unless explicitly requested and authorized by the active command contract and host rules.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the release surface.
+   - Package registry: npm, PyPI, crates.io, RubyGems, Maven, NuGet, SwiftPM, or similar.
+   - Source tag release: Go module, GitHub Release, generated assets, source archive, or checksum manifest.
+   - Container release: image tag, digest, multi-platform manifest, base image, provenance, or registry metadata.
+   - Installer or updater release: desktop installer, appcast, update feed, channel metadata, signature, release notes, or updater endpoint.
+   - Formula or distribution wrapper: Homebrew formula, cask, tap metadata, checksum, bottle, or livecheck.
+2. Declare the public API before choosing the version bump.
+   - Public API includes CLI output, flags, config schema, package exports, templates, generated artifacts, installer behavior, migration contract, deprecation behavior, update channel behavior, and documented examples.
+   - Use SemVer only after naming what this project treats as public API.
+   - Treat compatibility-affecting behavior, removed assets, changed binary names, moved module paths, changed updater channels, or stricter parsers as release-contract changes even when source APIs look unchanged.
+3. Inspect the artifact, not only the repository tree.
+   - Check package file lists, archive contents, generated distributions, binary entrypoints, README, LICENSE, metadata, generated schemas, template files, checksums, signatures, SBOM, provenance, image digest, and platform matrix as applicable.
+   - Do not claim artifact inspection from the source tree alone.
+   - Stale `dist`, build output, generated clients, package caches, or old release assets must be cleaned or reported before publication evidence is trusted.
+4. Classify channel permanence and recovery.
+   - npm name and version pairs, PyPI distribution filenames, crates.io versions, and Go module tags are effectively one-way release identifiers for practical purposes.
+   - Docker tags can move in many registries, but digests identify content and should be captured when reporting release evidence.
+   - GitHub Releases depend on Git tags, but release assets, checksums, signatures, and release body are separate evidence surfaces.
+   - App updater channels depend on metadata and signature state, not only uploaded installers.
+5. For npm-style package publication, verify package metadata, packed file list, entrypoints, bin links, README, LICENSE, access, provenance or trusted publisher setup, registry target, and exact published version behavior through configured intents.
+6. For PyPI-style publication, verify source distribution, wheel contents, metadata, Python version constraints, entrypoints, README rendering, filename uniqueness, and install smoke path through configured intents.
+7. For crates.io-style publication, verify manifest metadata, include and exclude rules, packaged file list, feature combinations, docs expectations, and yank-forward-fix policy.
+8. For Go modules, treat the Git tag as the release. Verify module path, semantic tag, major-version path rules, tag target commit, proxy/cache implications, and module consumer smoke path. Do not move or delete tags as a casual recovery shortcut.
+9. For Docker images, verify image digest, tag, platform manifest, labels, exposed ports, entrypoint, user, vulnerability or base-image expectations, and pull-run smoke behavior through configured intents.
+10. For GitHub Releases, verify tag, release body, generated notes policy, asset list, checksum files, signatures, archives, attached binaries, and download smoke behavior.
+11. For Homebrew, verify formula or cask URL, version, checksum, livecheck, bottle expectations, test block, audit result, and install smoke path through configured intents.
+12. For app updaters, verify installer artifact, update metadata, channel, minimum version, signature, release notes, feed URL, staged rollout rules, and updater smoke path from an older installed version when configured.
+13. Keep release notes and release publication separate.
+   - Release notes may say what changed only when evidence supports it.
+   - Publication evidence must say what remote artifact exists and how a user reaches it.
+14. Verify remote state after publication when authorized.
+   - Check the registry, tag, release page, asset download, digest, updater feed, tap, or package index that users actually consume.
+   - Then run the configured user installation, pull, download, or updater smoke intent.
+   - If remote publication was not authorized or not performed, report the release as prepared but not published.
+15. Report immutable or hard-to-recover mistakes honestly.
+   - Bad package version: usually deprecate, yank, or release a new version.
+   - Bad Go module tag: do not assume moving the tag fixes proxy/cache consumers.
+   - Bad Docker tag: distinguish moved tag from old digest still being referenced.
+   - Bad updater metadata: treat as a live channel incident if clients may already have seen it.
+16. Never call a release complete from local tests alone. The completion evidence must name the remote channel and the user installation or update path, or explicitly say that post-publish verification was skipped.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Version bump, release notes, package metadata, manifests, artifacts, workflows, tests, and docs agree.
+- The artifact contents have been inspected through configured evidence, not inferred from the source tree.
+- Remote publication status is classified as not started, prepared, published, verified, failed, yanked, deprecated, superseded, or unknown.
+- User installation, pull, download, or updater smoke test status is known or explicitly reported as skipped.
+- Recovery plan matches the channel's actual permanence and rules.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer configured release, package-inspection, artifact-inspection, install-smoke, updater-smoke, checksum, signature, provenance, or registry-verification intents when the command contract exposes them.
+
+Do not infer package manager, registry, Docker, Git, Homebrew, or updater commands from project files. If the needed intent is missing, report the missing command contract instead of writing a raw command into the skill or final release procedure.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the artifact contents differ from the intended release, stop release claims and fix the source, generated output, or packaging configuration before publication.
+- If the remote registry already contains the version, do not assume overwrite is possible. Report the channel-specific recovery path.
+- If publication succeeds but install smoke fails, treat the release as published but not verified and recommend channel-appropriate mitigation.
+- If a tag, asset, digest, checksum, signature, updater feed, or release body is missing, do not collapse the issue into "workflow failed"; name the missing remote surface.
+- If release evidence comes only from CI logs, report that no independent user-path smoke test was completed unless the configured CI explicitly performs that path.
+- If unpublish, yank, tag movement, channel rollback, or asset deletion is proposed, check host and repository authorization first and report the permanence risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Release target, version, and channel
+- Public API and version bump classification
+- Artifact contents inspected
+- Remote publication state
+- User installation, download, pull, or updater smoke path result
+- Synchronized version, docs, manifest, workflow, and test surfaces
+- Recovery or rollback classification
+- Command intents run
+- Skipped remote, publish, or install checks and reasons
+- Remaining release-publish risk

package/templates/default/locales/en/.mustflow/skills/routes.toml

@@ -108,6 +108,60 @@ route_type = "primary"
 priority = 20
 applies_to_reasons = ["unknown_change", "code_change"]
 
+[routes."api-contract-change"]
+category = "general_code"
+route_type = "primary"
+priority = 82
+applies_to_reasons = ["code_change", "public_api_change", "docs_change", "test_change"]
+
+[routes."typescript-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change"]
+
+[routes."javascript-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change"]
+
+[routes."python-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change"]
+
+[routes."go-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change"]
+
+[routes."rust-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change"]
+
+[routes."dart-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "test_change"]
+
+[routes."hono-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "security_change"]
+
+[routes."elysia-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "public_api_change", "security_change"]
+
 [routes."source-anchor-authoring"]
 category = "general_code"
 route_type = "primary"
@@ -156,12 +210,30 @@ route_type = "primary"
 priority = 55
 applies_to_reasons = ["code_change", "behavior_change"]
 
+[routes."database-migration-change"]
+category = "data_external"
+route_type = "primary"
+priority = 82
+applies_to_reasons = ["code_change", "data_change", "migration_change", "public_api_change", "test_change", "docs_change", "security_change"]
+
+[routes."dependency-upgrade-review"]
+category = "data_external"
+route_type = "primary"
+priority = 75
+applies_to_reasons = ["code_change", "docs_change", "security_change", "package_metadata_change", "release_risk"]
+
 [routes."dependency-reality-check"]
 category = "data_external"
 route_type = "adjunct"
 priority = 45
 applies_to_reasons = ["code_change", "docs_change", "security_change"]
 
+[routes."file-path-cross-platform-change"]
+category = "data_external"
+route_type = "primary"
+priority = 78
+applies_to_reasons = ["code_change", "public_api_change", "test_change", "docs_change", "security_change", "package_metadata_change"]
+
 [routes."cross-platform-filesystem-safety"]
 category = "data_external"
 route_type = "adjunct"
@@ -174,6 +246,12 @@ route_type = "primary"
 priority = 55
 applies_to_reasons = ["code_change", "behavior_change"]
 
+[routes."tauri-code-change"]
+category = "data_external"
+route_type = "primary"
+priority = 90
+applies_to_reasons = ["code_change", "security_change", "public_api_change"]
+
 [routes."process-execution-safety"]
 category = "data_external"
 route_type = "primary"
@@ -222,6 +300,18 @@ route_type = "primary"
 priority = 30
 applies_to_reasons = ["security_change", "privacy_change"]
 
+[routes."config-env-change"]
+category = "security_privacy"
+route_type = "primary"
+priority = 35
+applies_to_reasons = ["code_change", "docs_change", "security_change", "privacy_change", "package_metadata_change", "mustflow_config_change"]
+
+[routes."auth-permission-change"]
+category = "security_privacy"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "security_change", "privacy_change", "public_api_change"]
+
 [routes."security-regression-tests"]
 category = "security_privacy"
 route_type = "adjunct"
@@ -264,6 +354,48 @@ route_type = "primary"
 priority = 50
 applies_to_reasons = ["ui_change"]
 
+[routes."html-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "docs_change", "code_change"]
+
+[routes."css-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "docs_change", "code_change"]
+
+[routes."tailwind-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "docs_change", "code_change"]
+
+[routes."unocss-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "docs_change", "code_change"]
+
+[routes."flutter-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "code_change", "public_api_change"]
+
+[routes."astro-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "docs_change", "code_change"]
+
+[routes."svelte-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "code_change", "public_api_change"]
+
 [routes."pattern-scout"]
 category = "architecture_patterns"
 route_type = "adjunct"
@@ -312,6 +444,12 @@ route_type = "primary"
 priority = 55
 applies_to_reasons = ["release_risk", "docs_change"]
 
+[routes."release-publish-change"]
+category = "docs_release"
+route_type = "primary"
+priority = 58
+applies_to_reasons = ["release_risk", "package_metadata_change", "docs_change", "public_api_change"]
+
 [routes."search-ad-content-authoring"]
 category = "docs_release"
 route_type = "primary"

package/templates/default/locales/en/.mustflow/skills/rust-code-change/SKILL.md

@@ -0,0 +1,154 @@
+---
+mustflow_doc: skill.rust-code-change
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: rust-code-change
+description: Apply this skill when Rust source, Cargo metadata, features, traits, errors, ownership, async runtime, unsafe code, tests, examples, or public crate APIs are created or changed.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.rust-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# Rust Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve Rust ownership, error, trait, feature, async runtime, unsafe, and public crate boundaries while making a focused change. A Rust change is successful only when it clarifies ownership and contracts, not when it merely silences the borrow checker.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `.rs`, `Cargo.toml`, `Cargo.lock`, workspace config, feature flags, public exports, traits, error types, tests, examples, benches, FFI, async runtime, or unsafe code change.
+- The task touches ownership, borrowing, lifetimes, `Clone`, `Arc`, `Mutex`, `unwrap`, or public crate compatibility.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Rust files are read-only context and no Rust surface changes.
+- A generated Rust file should be regenerated by a declared command rather than edited.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- `Cargo.toml`, workspace manifests, lockfile policy, toolchain config, rustfmt, clippy, feature flags, docs.rs metadata, optional dependencies, and CI hints.
+- Relevant `src/lib.rs`, `src/main.rs`, modules, public re-exports, tests, examples, and docs examples.
+- Existing error handling convention and async runtime.
+- Public crate status, minimum supported Rust version, feature support policy, and downstream compatibility expectations when available.
+- Configured verification intents.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Determine whether the change affects ownership flow, public API, feature gates, optional dependencies, error contract, async runtime, or unsafe invariants.
+- Read local patterns before adding traits, lifetimes, clones, locks, boxed errors, feature bounds, or `Send + Sync + 'static` constraints.
+- Treat `clone`, `Arc<Mutex<_>>`, explicit lifetimes, `'static`, `Box<dyn Error>`, `unwrap`, feature changes, and `unsafe` as suspicious until their contract impact is justified.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Prefer truthful ownership and borrowing over broad cloning.
+- Follow the crate's existing application-versus-library error convention.
+- Keep feature-gated code and public re-exports synchronized.
+- Touch unsafe code only with explicit invariants preserved in nearby comments.
+- Add feature, async, or unsafe verification notes when configured command intents are missing.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Read Cargo metadata, features, optional dependencies, docs.rs metadata, toolchain config, public exports, relevant modules, and tests.
+2. Classify the change as ownership, API, error, feature, async, unsafe, dependency, or test-only.
+3. Resolve ownership problems in this order: identify the real owner, shrink borrow scopes, fix function signatures to accept references or slices when ownership is unnecessary, distinguish transfer from sharing, then consider clone or shared ownership only when the semantics require it.
+4. Before adding `clone`, verify it is a cheap handle clone such as `Arc`, `Rc`, or `Bytes`, a small intentional value clone, or a true independent ownership split. Reject large collection clones, loop clones, clone-then-borrow code, and whole-state clones made only to satisfy `spawn`.
+5. Before adding `Arc<Mutex<_>>`, verify multiple owners truly need shared mutable state. Keep critical sections short, document lock order when relevant, and do not hold a lock guard across `.await`, I/O, callbacks, or user code.
+6. Use explicit lifetimes only to describe real borrow relationships. Do not add `'static` or `T: 'static` to public APIs merely because an internal task boundary requires it.
+7. Use concrete error enums for library APIs when callers need to classify failures. Keep `Box<dyn Error>` mostly to binaries, examples, tests, prototypes, or explicitly opaque error policies.
+8. Avoid `unwrap` and vague `expect` in production paths. They are allowed only for tests, examples, startup policy, or invariants already proven by nearby code.
+9. If feature flags change, treat default features, no-default builds, all-features builds, optional dependency implicit features, public re-exports, docs examples, and feature-gated trait impls as compatibility surfaces. Features should be additive.
+10. Treat public re-exports, public dependency types, generic bounds, trait item sets, error enum variants, `#[non_exhaustive]`, and MSRV as public API. Tightened bounds, added required trait methods, removed re-exports, or changed error variants require compatibility review.
+11. Do not mix async runtimes. A Tokio crate should not casually gain `async-std` or runtime-specific APIs in library core. Do not call blocking I/O or CPU-heavy work in async paths without an established boundary such as async-native APIs, a blocking pool, or a dedicated worker.
+12. For async spawning, avoid leaking internal `Send + Sync + 'static` requirements into public APIs. Prefer owned task state, smaller spawn boundaries, local task structures, or caller-owned runtime decisions.
+13. Touch `unsafe` only when a safe design cannot express the required behavior. Every unsafe block needs a nearby `SAFETY:` explanation; every public `unsafe fn` needs `# Safety` docs. Keep unsafe scopes small and wrap them in safe abstractions only when callers have no hidden safety obligations.
+14. For FFI, keep Rust ABI types out of C boundaries. Use explicit ownership, `#[repr(C)]` where required, raw pointer plus length pairs, `CStr`/`CString`, RAII wrappers, null handling, panic boundaries, and documented thread-safety evidence before manual `Send` or `Sync`.
+15. Choose configured verification intents that cover format, lint, build, tests, feature combinations, docs, public API, unsafe, and FFI risk when available.
+
+<!-- mustflow-section: rejection-criteria -->
+## Review Rejection Criteria
+
+Reject or revise the patch when any of these appear without strong local justification:
+
+- New large `clone()` calls, clone-then-borrow code, loop clones, or state clones used only to appease ownership errors.
+- New `Arc<Mutex<AppState>>`-style shared bags, locks held across `.await`, or async I/O resources shared mainly by mutex.
+- New public `'static`, `Send`, or `Sync` bounds that exist only because an internal task was spawned.
+- New public `Box<dyn Error>` in a library where callers need typed failures.
+- New production `unwrap` or vague `expect` on I/O, parse, environment, network, FFI, lock, or user input paths.
+- Feature changes that remove APIs, change type meaning, rename features, expose internal optional dependency names, or fail default/no-default/all-features reasoning.
+- Public dependency types, re-exports, trait bounds, trait methods, or error enum variants changed without semver review.
+- Async runtime mixing, blocking I/O in async paths, or runtime ownership moved into a library core without a clear boundary.
+- Unsafe blocks without `SAFETY:` comments, unsafe functions without `# Safety`, undocumented manual `Send`/`Sync`, or FFI that exposes Rust layout types across C ABI.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Ownership changes are intentional, not compiler appeasement.
+- Public API, features, optional dependencies, and error contracts are synchronized.
+- Async runtime ownership is preserved and blocking work is isolated.
+- Unsafe and FFI invariants are preserved or no unsafe code was touched.
+- Missing feature, semver, docs, unsafe, or FFI verification is reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `mustflow_check`
+
+Report whether configured feature-combination, documentation, semver, Miri, sanitizer, and downstream-style verification exists when those surfaces change.
+
+When configured intents exist for these risks, prefer coverage equivalent to:
+
+- formatting and linting
+- workspace checks and tests
+- default, no-default, all-features, and relevant feature combinations
+- doctests and docs build for public crates
+- public API or semver compatibility checks for published crates
+- Miri or sanitizer-style checks for unsafe, raw pointer, FFI, or manual concurrency primitives
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If borrow-checker fixes produce broad clones or locks, revisit ownership boundaries before proceeding.
+- If feature-gated code cannot be verified, report the specific unverified feature surface.
+- If public API compatibility cannot be verified, report the exact exported symbols, trait bounds, feature gates, or errors at risk.
+- If async runtime or blocking boundaries are unclear, stop that part and inspect the runtime ownership before editing further.
+- If unsafe invariants are unclear, stop that part and request or inspect stronger evidence.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Boundary checked
+- Ownership, feature, async, or unsafe impact
+- Public API or error impact
+- Files changed
+- Command intents run
+- Skipped checks and reasons
+- Remaining Rust risk

package/templates/default/locales/en/.mustflow/skills/security-privacy-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.security-privacy-review
 locale: en
 canonical: true
-revision: 17
+revision: 19
 lifecycle: mustflow-owned
 authority: procedure
 name: security-privacy-review
@@ -48,6 +48,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - A change uses cache, Redis, generated state, search documents, or read models to make authorization, ownership, subscription, entitlement, payment, inventory, or admin decisions.
 - A change adds external URL fetching, webhook callbacks, redirects, browser previews, remote downloads, database-as-a-service rules, security headers, CORS, CSRF handling, or rate limits.
 - A change stores webhook payloads, external API requests or responses, retry errors, dead-letter jobs, AI prompts or outputs, email bodies, or provider diagnostic data.
+- A change adds or modifies public intake surfaces such as action handlers, webhook handlers, callback receivers, job enqueue endpoints, idempotency stores, replay APIs, or default verifier, authenticator, authorizer, normalizer, or deduplication collaborators.
 - A change records AI usage, model pricing, token counts, cache keys, feature metadata, prompt hashes, provider call metadata, retry cost, or failed AI calls that could include confidential content or identify users.
 - A change records AI budgets, feature policies, policy decisions, blocked reasons, model downgrades, agent steps, tool calls, provider budget status, or emergency disables that could reveal customer behavior, sensitive feature use, or regulated processing.
 - A change touches cookies, JWTs, reset tokens, invite tokens, OAuth callbacks, file upload or download, browser storage, business rules, pricing, entitlements, database queries, ORM bulk operations, or deployment configuration.
@@ -56,6 +57,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - A change touches cryptography, password hashing, token generation, random number generation, TLS/HTTPS, certificate validation, scanner gates, or a security invariant that could drift across architecture boundaries.
 - A change adds, imports, recommends, or installs third-party dependencies that may affect the software supply chain.
 - A change introduces or edits agent configuration, MCP/tool configuration, prompt files, model instructions, or repository-local rule files.
+- A change adds or modifies policy engines, architecture linters, rule catalogs, validators, generated compliance reports, or governance gates that can approve sensitive data, payment, API, AI, tier, or deployment boundaries.
 - A change affects CI/CD workflow permissions, fork pull-request handling, build scripts, package lifecycle scripts, deployment secrets, container users, storage buckets, debug flags, or public admin, metrics, GraphQL, cache, or search endpoints.
 - Documentation, templates, examples, tests, or final reports mention sensitive data handling, privacy behavior, secret handling, or user-identifying data.
 - A diff could expose data through filenames, paths, command output, screenshots, generated artifacts, package contents, or public docs.
@@ -82,6 +84,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - Cookie, JWT, OAuth, file upload, file download, business-value, database mutation, ORM bulk operation, CI/CD permission, deployment setting, or secret-source surface involved.
 - Cryptographic primitive, password hashing, random-token, secure transport, certificate validation, scanner gate, or security invariant involved.
 - Existing project rules for secrets, privacy, generated state, public docs, package contents, and command output.
+- Policy or rule-catalog source of truth, trusted metadata source, fallback behavior when a rule file is missing, and any untrusted repository-local fields that might be treated as ownership, tier, role, or exemption evidence.
 - Admin operation list, role or capability model, audit-log fields, cache visibility policy, and cache invalidation surface when those are involved.
 - Behavior analytics event names, event versions, actor identifiers, anonymous identifiers, properties, retention period, deletion or anonymization policy, and whether event writes can be delayed or lost.
 - Core event ownership, including which signup, login failure, account recovery, payment, refund, subscription, entitlement, permission, file, search, admin, webhook, queue, and security events must remain internally stored instead of only in a SaaS dashboard.
@@ -91,6 +94,8 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - Data classification policy when available, including sensitive personal data, ordinary personal data, product usage data, public content, AI prompts or outputs, and which classes may enter logs, analytics, support tools, AI providers, or cross-region backups.
 - Runtime and dependency patch policy, including supported or LTS version requirement, end-of-life ban, lockfile expectation, vulnerability scan source, patch response target, smoke-test surface, canary or rollback route, and whether experimental runtime choices are kept off survival paths.
 - Webhook and external-call record policy, including signature verification, processed-event deduplication, safe request hashes, redacted provider responses, unknown-result reconciliation, dead-letter retention, and whether raw payloads are needed or should be replaced by bounded metadata.
+- Public intake default policy, including whether verifiers, authenticators, authorizers, deduplication stores, idempotency stores, and normalizers are required by registration, explicit opt-in, or silently replaced by permissive defaults.
+- Attacker-controlled key and header limits for idempotency keys, webhook event ids, provider names, action names, replay ids, dedupe keys, request ids, and any in-memory map or queue keyed by public request data.
 - AI record policy, including prompt and output retention, cache-key hashing, provider request id handling, feature-key properties, pricing snapshots, token usage, failed-call errors, user or account identifiers, and whether raw prompts or generated text are omitted, redacted, encrypted, or retained under a narrow rule.
 - AI budget and gateway policy, including whether provider budgets are hard stops or only alerts, whether product-owned hard limits exist, which identifiers are recorded for user, organization, feature, model, request, provider call, policy decision, and whether blocked or downgraded decisions are logged without exposing prompt text.
 - Cache authority boundary, including which data is final source of truth and which values are disposable, stale, private, or shared.
@@ -154,6 +159,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 20. For cache purge, search reindex, ranking refresh, and generated-state rebuild endpoints, treat them as privileged state-changing operations with authorization, rate limiting, audit logs, idempotency, and bounded target selection.
 21. For external URL, webhook, preview, redirect, download, or callback behavior, check allowlists, protocol restrictions, redirect handling, DNS/IP re-resolution, private network ranges, link-local metadata endpoints, webhook signatures, timeout limits, retry limits, and open redirect parameters such as `next` or `redirect`.
    - For webhooks, verify the signature against the raw body before trusting parsed data. Store only the raw body reference or bounded raw payload when replay, verification, or support needs justify it.
+   - Do not silently install allow-all, unsigned, no-op, nil, null-object, or test-only verifiers for public webhook or callback endpoints. Missing verifier, authenticator, or authorization configuration should fail registration unless the caller explicitly selects a clearly named unsafe or local-only mode.
    - Store processed event identifiers to avoid duplicate effects. Keep provider event payloads, request bodies, and response bodies out of ordinary logs and dead-letter records unless they are redacted and have a retention rule.
 22. For database-as-a-service, storage bucket, or realtime rules, check that server-side policies are default-deny, ownership-scoped, and not left in public read/write development mode.
 23. For input sinks, check parameterized queries, ORM binding, static command maps, output encoding, HTML/Markdown rendering boundaries, unsafe dynamic evaluation, XML/YAML/Markdown parser options, redirect and sort parameters, page-size limits, and framework escape hatches.
@@ -163,6 +169,8 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
    - For direct-to-object-storage uploads, authorize the target resource before issuing the signed upload URL, confirm upload completion before making the asset usable, and keep pending, uploaded, processing, ready, failed, and deleted states separate.
    - Inspect actual file bytes instead of trusting extension or `Content-Type`. Re-encode images and strip metadata when practical before serving user uploads.
 25. For business logic, check that server code does not trust client-supplied prices, discounts, roles, owners, entitlement state, plan limits, usage counters, inventory, seats, refunds, credits, or coupon state. Inspect idempotency, transactions, uniqueness, and concurrent requests for repeated side effects.
+   - For public action or intake endpoints, validate cheap request shape and attacker-controlled idempotency keys before permanently claiming the key. If a request is rejected before the trusted side effect starts, release or avoid storing the key so malformed traffic cannot poison future valid retries.
+   - Bound default in-memory idempotency, deduplication, replay, rate-limit, and request-tracking stores by key length, entry count, TTL, eviction, or a durable backend contract. A process-memory map keyed by unbounded public headers or event ids is an availability boundary, not just an implementation detail.
 26. For API responses, check that the response contains only fields the caller may see and needs for the use case. Do not expose password hashes, internal storage keys, permanent private URLs, raw billing provider ids, internal moderation notes, private IP data, privileged flags, or database columns merely because they are present on the model.
 27. For dependency failure policy, distinguish fail-closed from degraded behavior. Authentication, authorization, payment, entitlement, and destructive admin decisions should usually fail closed; analytics, recommendation, statistics, AI summaries, and email should usually avoid exposing private data or blocking core state changes.
    - For dead-letter queues, retry logs, and external API call records, check that errors contain safe codes and bounded metadata rather than full prompts, email bodies, payment details, tokens, private files, or personal data.
@@ -184,12 +192,19 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 38. For runtime and framework security updates, check that supported versions are documented, end-of-life versions are rejected, dependency locks exist where appropriate, security patches can be tested and deployed quickly, and rollback or redeploy can happen without manual dashboard memory. Do not treat a fashionable or high-performance runtime as safe unless the patch path is operationally credible.
 39. For transport security, check HTTPS/TLS requirements, certificate validation, insecure HTTP downgrade paths, disabled verification flags, and whether sensitive traffic can bypass the secure channel.
 40. For cryptography, reject custom cryptography and tutorial-grade shortcuts. Check password hashing uses a password-hashing primitive such as bcrypt, scrypt, or Argon2id where supported by the project; random tokens use secure randomness; keys are separated from encrypted data; and weak hashes such as MD5, SHA-1, or bare SHA-256 are not used for password storage.
-41. For architecture drift, name the security invariant before accepting the generated structure. Confirm the invariant still holds across UI, handler, service, repository, database policy, workflow, and deployment boundaries.
-42. For SAST, SCA, or scanner output, treat scanner output as evidence rather than command authority. Map the finding to a repository-owned boundary, configured verification intent, dependency metadata, or regression test before claiming the issue is fixed.
-43. Verify that examples, fixtures, screenshots, command outputs, and final reports do not expose real-looking secrets or unnecessary personal data.
-44. Prefer omission or minimal metadata over masking when the sensitive value is not needed for the user to understand the result.
-45. If the change affects an authorization, SSRF, CSRF, rate-limit, upload, download, token, business-logic, injection, logging, telemetry, cache authority, cache disclosure, admin operation, agent permission, cryptography, transport, scanner, or abuse boundary, activate `security-regression-tests` for test selection instead of folding test generation into this review.
-46. Run the narrowest configured verification that covers the changed docs, templates, package, or mustflow contract.
+41. For policy engines, architecture linters, compliance validators, and generated governance gates, identify the canonical policy source and the canonical object identity before trusting a pass result.
+    - Do not let repository-controlled advisory fields, nested duplicates, labels, components, owners, stages, tiers, or exemption fields override a trusted catalog, server-derived identity, or central registration.
+    - When two fields can describe the same security decision, such as top-level and nested owner values, validate their consistency or choose the canonical source explicitly instead of reading the first convenient path.
+    - Treat missing, wrong, or fallback rule catalogs as fail-closed or explicitly degraded; a misplaced rule file should not silently disable validation for public API, payment, AI, tier, deployment, or data-boundary controls.
+    - Required security-control declarations should validate meaningful values, not merely non-null presence. Reject `false`, `0`, empty objects, empty arrays, empty strings, or type-mismatched placeholders unless the policy specifically allows that value.
+    - Derive deny decisions from metadata classes when possible instead of only from static name denylists that can miss newly introduced repositories, services, tenants, roles, or providers.
+42. For read-only commands that inspect repositories, remember that the underlying tool can still execute configured helpers. Disable or neutralize repository-local hooks, fsmonitor helpers, credential helpers, package lifecycle hooks, and executable lookup through untrusted PATH when the command is meant to be safe inspection.
+43. For architecture drift, name the security invariant before accepting the generated structure. Confirm the invariant still holds across UI, handler, service, repository, database policy, workflow, and deployment boundaries.
+44. For SAST, SCA, or scanner output, treat scanner output as evidence rather than command authority. Map the finding to a repository-owned boundary, configured verification intent, dependency metadata, or regression test before claiming the issue is fixed.
+45. Verify that examples, fixtures, screenshots, command outputs, and final reports do not expose real-looking secrets or unnecessary personal data.
+46. Prefer omission or minimal metadata over masking when the sensitive value is not needed for the user to understand the result.
+47. If the change affects an authorization, SSRF, CSRF, rate-limit, upload, download, token, business-logic, injection, logging, telemetry, cache authority, cache disclosure, admin operation, agent permission, cryptography, transport, scanner, policy-engine, rule-catalog, or abuse boundary, activate `security-regression-tests` for test selection instead of folding test generation into this review.
+48. Run the narrowest configured verification that covers the changed docs, templates, package, or mustflow contract.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions