mustflow 2.115.4 → 2.115.9

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.python-code-change
 locale: en
 canonical: true
-revision: 5
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: python-code-change
@@ -127,13 +127,13 @@ Preserve Python runtime, standard-library, packaging, import, architecture, asyn
    - rebuild large dicts after bulk deletion when long-lived memory and iteration cost matter;
    - avoid eager default factories hidden in `dict.get(key, expensive())` or `setdefault(key, expensive())`.
 15. Treat newer syntax and typing features as semantic tools, not style trophies:
-   - use template string literals only when a handler needs the static and interpolated parts separately, such as SQL builders, shell command objects, logging templates, or markup renderers; do not replace ordinary f-strings when the result is just a string;
-   - when runtime code reads annotations, use the supported annotation inspection API and choose the intended format explicitly instead of assuming `__annotations__` already contains runtime values;
-   - use sentinel values to distinguish "argument omitted" from `None`, but compare sentinels by identity and keep public signatures readable;
+   - use Python 3.14+ template string literals only when a handler needs the static and interpolated parts separately, such as SQL builders, shell command objects, logging templates, or markup renderers; do not replace ordinary f-strings when the result is just a string;
+   - when runtime code reads annotations, use Python 3.14+ `annotationlib` or the official inspection API supported by the declared runtime, and choose the intended format explicitly instead of assuming `__annotations__` already contains runtime values;
+   - use sentinel values to distinguish "argument omitted" from `None`, but compare sentinels by identity and keep public signatures readable; in the official snapshot checked on 2026-07-11, the built-in sentinel facility was Python 3.15+ prerelease-only, so refresh the current release status before adoption;
    - prefer `Mapping` or narrower read-only protocols for read-only inputs so immutable mapping implementations are not rejected accidentally;
-   - use closed or extra-key `TypedDict` forms only when the supported Python and type-checker versions agree with that shape.
+   - use closed or extra-key `TypedDict` forms only when the supported Python and type-checker versions agree with that shape; the Python 3.15-only forms were prerelease-only in the official snapshot checked on 2026-07-11, so refresh status before adoption.
 16. Keep `finally` as cleanup, not outcome selection. Do not add `return`, `break`, or `continue` inside `finally` blocks because they can mask exceptions and cancellation; move result decisions outside cleanup or make suppression an explicit documented contract.
-17. Use explicit lazy imports only for startup-sensitive module-scope dependencies after checking version support and import-time side effects. Do not lazily import plugins, registries, monkey patches, model definitions, ORM mappings, or observability setup whose import side effects are part of startup correctness.
+17. Use Python 3.15+ explicit lazy imports only for startup-sensitive module-scope dependencies after checking version support and import-time side effects. The syntax was prerelease-only in the official snapshot checked on 2026-07-11; refresh the current Python 3.15 release status before placing it in stable-target examples. Do not lazily import plugins, registries, monkey patches, model definitions, ORM mappings, or observability setup whose import side effects are part of startup correctness.
 18. Keep process, archive, and concurrency safety explicit:
    - subprocess calls use argument lists, checked failure handling, timeouts, bounded captured output, and a narrow `shell=True` exception when the project already permits it;
    - archive extraction, including `tarfile`, keeps untrusted archive inspection, extraction filters, partial-extract cleanup, and older-runtime defaults visible;
@@ -215,7 +215,11 @@ Report missing package, type, or test intents rather than inventing raw tool com
 - If build backend, package manager, lockfile, dependency group, optional dependency, or editable-install behavior is ambiguous, keep the existing owner and report the missing packaging contract instead of migrating tools.
 - If the supported Python version blocks a syntax choice, rewrite to the supported form.
 - If the supported Python version blocks a standard-library feature, changed default, diagnostic flag, or helper API, use the supported equivalent or report the runtime-support decision instead of silently raising `requires-python`.
-- If template strings, annotation runtime access, lazy imports, sentinels, immutable mappings, or typed extra keys are useful but version-gated, keep a fallback or report the required support bump instead of smuggling the newer feature into a lower-runtime project.
+- If Python 3.14 template strings or annotation inspection are useful but the project supports older runtimes, keep a fallback or report the required stable-runtime bump.
+- If Python 3.15 lazy imports, built-in sentinels or immutable mappings, or advanced `TypedDict`
+  shapes are useful, first refresh the official release and feature status. When the target remains
+  prerelease, keep them out of stable-target code and examples unless the repository explicitly
+  adopts that prerelease track.
 - If third-party stubs or package metadata are wrong, document the local workaround and keep it narrow.
 - If `Any`, `cast`, `type: ignore`, runtime `Protocol`, or type guard behavior is needed, keep it local, justified, and backed by runtime validation or tests where the type claim can lie.
 - If performance risk appears in collections, generators, copies, or caches, report the input-size assumption or use an existing benchmark/profile intent when configured.

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.release-publish-change
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: release-publish-change
@@ -60,7 +60,7 @@ The release is not done when tests pass locally, a version string changes, or a
   and whether each belongs to publication, branch CI, tag CI, release asset generation, or another
   independent verification path.
 - 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.
+- Configured command intents for build, package inspection, release verification, docs validation, and user installation or updater smoke test. For post-publish checks, also identify the exact immutable version, intended registry or channel, consumer environment, public entrypoints, and runtime or platform evidence. If no such intent exists, report the missing intent instead of inventing a raw command.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
@@ -101,6 +101,14 @@ The release is not done when tests pass locally, a version string changes, or a
    - 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.
+   - Keep pre-publish packed-artifact checks separate from post-publish registry checks. A local tarball or workspace install does not prove that the immutable registry version users receive is installable.
+   - Run the post-publish smoke in a fresh consumer root outside the source checkout. Install the exact immutable name and version from the intended registry without workspace links or local archive fallbacks.
+   - Use a fresh or isolated package-manager cache strategy and prefer current registry metadata. A cache-only success is not independent remote-channel evidence.
+   - Disable lifecycle scripts by default so a package cannot repair missing build output during installation. If lifecycle scripts are an intentional public contract, test that behavior separately with the required sandbox and approval boundary.
+   - Execute the public command shims, exported entrypoints, or documented import path that users invoke. Calling an internal module file directly does not prove that package-manager shims, aliases, permissions, or entry metadata work.
+   - Exercise every documented command alias that is part of the release contract, then run one minimal documented workflow that crosses initialization or configuration validation when applicable.
+   - Retry only bounded transient registry conditions such as propagation delay, throttling, or transport reset. Do not retry authentication, package metadata, entrypoint, or runtime failures into a false pass.
+   - Keep temporary state owned and removable, preserve the primary failure if cleanup also fails, and report the exact package version, registry, package-manager version, runtime, operating system, and public entrypoints exercised.
 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.
@@ -137,7 +145,7 @@ The release is not done when tests pass locally, a version string changes, or a
 - Remote publication status is classified as not started, prepared, published, verified, failed, yanked, deprecated, superseded, or unknown.
 - Branch, tag, and publication workflow checks are classified separately as green, failing, pending,
   skipped, not applicable, or unknown.
-- User installation, pull, download, or updater smoke test status is known or explicitly reported as skipped.
+- Independent consumer-root installation, pull, download, or updater smoke status through public entrypoints is known with environment evidence, or explicitly reported as skipped.
 - Recovery plan matches the channel's actual permanence and rules.
 
 <!-- mustflow-section: verification -->
@@ -155,7 +163,7 @@ Use configured oneshot command intents when available:
 - `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.
+Prefer configured release, package-inspection, artifact-inspection, install-smoke, updater-smoke, checksum, signature, provenance, or registry-verification intents when the command contract exposes them. A local packed-artifact check may support pre-publish confidence, but it does not satisfy an independent post-publish installation claim.
 
 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.
 
@@ -180,7 +188,7 @@ Do not infer package manager, registry, Docker, Git, Homebrew, or updater comman
 - Artifact contents inspected
 - Remote publication state
 - Branch, tag, and publication check-suite state
-- User installation, download, pull, or updater smoke path result
+- User installation, download, pull, or updater smoke result, including exact immutable version, registry or channel, public entrypoints, package manager, runtime, operating system, retry outcome, and skipped platforms
 - Synchronized version, docs, manifest, workflow, and test surfaces
 - Recovery or rollback classification
 - Command intents run

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

@@ -546,6 +546,18 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "performance_change", "security_change", "package_metadata_change", "release_risk"]
 
+[routes."ada-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "data_change", "performance_change", "security_change", "package_metadata_change", "release_risk"]
+
+[routes."pascal-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "data_change", "performance_change", "security_change", "package_metadata_change", "release_risk"]
+
 [routes."shell-code-change"]
 category = "general_code"
 route_type = "primary"
@@ -570,6 +582,12 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "migration_change", "security_change", "package_metadata_change", "release_risk"]
 
+[routes."deno-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "docs_change", "performance_change", "security_change", "privacy_change", "data_change", "migration_change", "package_metadata_change", "release_risk"]
+
 [routes."docker-code-change"]
 category = "general_code"
 route_type = "primary"
@@ -618,6 +636,12 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "data_change", "migration_change", "performance_change", "security_change", "privacy_change", "package_metadata_change", "release_risk"]
 
+[routes."php-code-change"]
+category = "general_code"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["code_change", "behavior_change", "public_api_change", "test_change", "docs_change", "data_change", "migration_change", "performance_change", "security_change", "privacy_change", "package_metadata_change", "release_risk"]
+
 [routes."powershell-code-change"]
 category = "general_code"
 route_type = "primary"
@@ -1176,6 +1200,12 @@ route_type = "primary"
 priority = 85
 applies_to_reasons = ["ui_change", "code_change", "behavior_change", "public_api_change", "data_change", "security_change", "privacy_change", "performance_change", "test_change", "docs_change", "migration_change", "package_metadata_change", "release_risk"]
 
+[routes."threejs-code-change"]
+category = "ui_assets"
+route_type = "primary"
+priority = 85
+applies_to_reasons = ["ui_change", "code_change", "behavior_change", "public_api_change", "data_change", "security_change", "privacy_change", "performance_change", "test_change", "docs_change", "migration_change", "package_metadata_change", "release_risk"]
+
 [routes."react-code-change"]
 category = "ui_assets"
 route_type = "primary"

package/templates/default/locales/en/.mustflow/skills/skill-authoring/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.skill-authoring
 locale: en
 canonical: true
-revision: 9
+revision: 11
 lifecycle: mustflow-owned
 authority: procedure
 name: skill-authoring
-description: Apply this skill when creating or maintaining `.mustflow/skills/*/SKILL.md` procedures and `.mustflow/skills/INDEX.md` routes.
+description: Apply this skill when creating or maintaining logically rigorous `.mustflow/skills/*/SKILL.md` procedures and `.mustflow/skills/INDEX.md` routes.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -30,6 +30,7 @@ Create narrow, repeatable mustflow skill procedures without turning skills into
 - A `.mustflow/skills/<name>/SKILL.md` file is created, renamed, split, removed, or substantially changed.
 - `.mustflow/skills/INDEX.md` needs a new or updated route for a skill.
 - A skill needs clearer use conditions, exclusion conditions, required inputs, command intent references, verification, or failure handling.
+- A skill contains broad, conditional, exception-bearing, authority-sensitive, or completion claims whose logical scope needs review.
 - A broad prompt, checklist, or outside recommendation needs to be adapted into mustflow's skill format.
 
 <!-- mustflow-section: do-not-use-when -->
@@ -47,6 +48,10 @@ Create narrow, repeatable mustflow skill procedures without turning skills into
 - Existing `.mustflow/skills/INDEX.md` and nearby skill documents.
 - `.mustflow/config/commands.toml` command intent names relevant to verification.
 - Any repository evidence showing that the task is repeatable and not better handled by an existing skill.
+- Nearby rules that can require, forbid, narrow, override, or create exceptions to the proposed procedure.
+- The selected repository boundary for every command intent or verification claim, including any
+  explicit parent-owned dependency.
+- At least one representative positive case and one boundary or counterexample for material rules.
 - Canonical source locale, localization policy, and template metadata when the skill is part of an installed template.
 
 <!-- mustflow-section: preconditions -->
@@ -69,19 +74,34 @@ Create narrow, repeatable mustflow skill procedures without turning skills into
 2. Search existing skills before adding a new one. Prefer updating a matching skill over creating overlapping procedures.
 3. Use a stable folder name and matching frontmatter `name`. Set `mustflow_doc` to `skill.<name>`, `metadata.mustflow_schema` to `"1"`, `metadata.mustflow_kind` to `procedure`, `metadata.pack_id` to the package namespace, and `metadata.skill_id` to `<pack_id>.<name>`.
 4. Write the standard sections: Purpose, Use When, Do Not Use When, Required Inputs, Preconditions, Allowed Edits, Procedure, Postconditions, Verification, Failure Handling, and Output Format.
-5. Run the skill quality gate before accepting the draft: trigger is concrete, non-use boundaries are explicit, required inputs are observable, allowed edits are narrow, procedure steps are actionable, verification names configured intents, failure handling says what to do when evidence is missing, output format matches the evidence expected, overlap with nearby skills is controlled, and template impact is decided.
-6. Reject broad advice disguised as a skill. A skill should not say only "be careful", "write better tests", "sync docs", or "think about security" unless it names a repeatable trigger, source files to inspect, allowed edits, verification, and reporting evidence.
-7. Keep the procedure concrete and bounded. Include what to read, what to change, what to avoid, and what evidence to report.
-8. Reference command intent names only. Do not include raw shell command blocks or claim that the skill authorizes command execution.
-9. Update `.mustflow/skills/INDEX.md` with a compact route that includes trigger, required input, edit scope, risk, verification intents, and expected output.
-10. If the skill is installed by a template, update the canonical skill copy plus installation metadata, package tests, and public docs that list installed files. Do not fan out routine skill edits into every localized skill copy by default; localized skill copies may be absent, and non-source template locales should fall back to the canonical source-locale skill text unless locale-specific skill text is intentionally maintained and translation review is available.
-11. If a portable Agent Skills artifact is part of the task, create or validate it as a derived export, not as the mustflow-native canonical source. Use portable-only top-level fields and string-to-string metadata. A `gh skill publish --dry-run` check may validate the export artifact when available, but `gh skill publish --fix` must be limited to the export directory because it can remove installed provenance metadata and mustflow-native fields.
+5. Normalize material rules before accepting the draft.
+   - Rewrite each material rule mentally as `conditions -> required, allowed, or forbidden action -> observable result`. Keep the prose natural, but make the condition, modality, actor, scope, and result unambiguous.
+   - Distinguish a necessary condition from a sufficient condition. Do not infer the converse: a rule saying `A requires B` does not say that every `B` permits or proves `A`.
+   - Name quantifier and scope when they matter: one item, every item, at least one item, only configured items, the selected repository, the current platform, or another bounded set. Avoid `always`, `never`, `all`, `only`, and equivalent absolutes unless every permitted exception is excluded or explicitly subordinate to a higher-authority rule.
+   - Attach exceptions to the rule they narrow. State whether an exception waives a requirement, permits an action, or changes only reporting; do not let an exception silently authorize commands or erase safety constraints.
+6. Run the logical consistency gate across Purpose, Use When, Do Not Use When, Required Inputs, Preconditions, Allowed Edits, Procedure, Postconditions, Verification, and Failure Handling.
+   - Check whether the same reachable condition both requires and forbids an action. Resolve the contradiction or state the higher-authority discriminator.
+   - Separate different authority dimensions instead of forcing them into one total order. Goal ownership, safety constraints, repository scope, command authority, evidence quality, and preferences can constrain the same action without being interchangeable.
+   - Check reachability and termination. Every required input may be present or missing; every verification may pass, fail, be unavailable, or be skipped; each material branch must lead to an action, handoff, bounded retry, or stop state.
+   - Attack universal and completion claims with a counterexample. Narrow or qualify any claim that one realistic permitted case can falsify.
+   - Require postconditions to be observable from named evidence. A procedure step, local test, workflow success, or report is not proof of a broader state unless the evidence actually covers that state.
+   - Resolve verification intent names against the repository being changed. A shared parent skill
+     does not impose parent-root verification on child-only work; require a parent check only when
+     parent-owned files, orchestration, artifacts, or contracts are direct inputs to the result.
+7. Run the skill quality gate before accepting the draft: trigger is concrete, non-use boundaries are explicit, required inputs are observable, allowed edits are narrow, procedure steps are actionable, verification names configured intents, failure handling says what to do when evidence is missing, output format matches the evidence expected, overlap with nearby skills is controlled, logical branches terminate, and template impact is decided.
+8. Reject broad advice disguised as a skill. A skill should not say only "be careful", "write better tests", "sync docs", or "think about security" unless it names a repeatable trigger, source files to inspect, allowed edits, verification, and reporting evidence.
+9. Keep the procedure concrete and bounded. Include what to read, what to change, what to avoid, and what evidence to report.
+10. Reference command intent names only. Do not include raw shell command blocks or claim that the skill authorizes command execution.
+11. Update `.mustflow/skills/INDEX.md` with a compact route that includes trigger, required input, edit scope, risk, verification intents, and expected output.
+12. If the skill is installed by a template, update the canonical skill copy plus installation metadata, package tests, and public docs that list installed files. Do not fan out routine skill edits into every localized skill copy by default; localized skill copies may be absent, and non-source template locales should fall back to the canonical source-locale skill text unless locale-specific skill text is intentionally maintained and translation review is available.
+13. If a portable Agent Skills artifact is part of the task, create or validate it as a derived export, not as the mustflow-native canonical source. Use portable-only top-level fields and string-to-string metadata. A `gh skill publish --dry-run` check may validate the export artifact when available, but `gh skill publish --fix` must be limited to the export directory because it can remove installed provenance metadata and mustflow-native fields.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - The expected output can be produced with clear evidence, executed command intents, skipped checks, and remaining risks.
 - Any missing command intent, unknown input, or authority conflict is reported instead of hidden.
+- Material rules have bounded scope, explicit exception behavior, reachable failure branches, and observable postconditions.
 
 <!-- mustflow-section: verification -->
 ## Verification
@@ -100,6 +120,11 @@ If the skill changes tests or behavior-sensitive template output, also use the r
 - If two skills overlap, tighten their use and non-use conditions or merge the duplicate procedure.
 - If a needed command intent is missing, record the missing intent instead of inventing a command inside the skill.
 - If the draft can be applied to almost any task, narrow the trigger or turn the material into workflow guidance instead of a skill.
+- If a reachable condition both requires and forbids the same action, do not hide it behind priority language. Split authority dimensions, add the missing discriminator, or stop with an explicit conflict.
+- If a universal or completion claim fails one realistic permitted counterexample, narrow the claim to the evidence actually established.
+- If a branch can retry, wait, or defer without a bound or stop state, add a termination condition before accepting the skill.
+- If a skill makes a child task depend on parent-root verification without naming a direct parent
+  dependency, remove the cross-root obligation.
 - If translation confidence is low, keep the source skill authoritative and mark translations for review through template metadata.
 
 <!-- mustflow-section: output-format -->
@@ -108,6 +133,7 @@ If the skill changes tests or behavior-sensitive template output, also use the r
 - Skill files added, updated, renamed, or removed
 - Skill index routes changed
 - Quality gate result and overlap decision
+- Logical consistency result, counterexamples checked, and material claims narrowed
 - Command intents referenced
 - Template or localization metadata updated
 - Portable export validation result when relevant

package/templates/default/locales/en/.mustflow/skills/skill-refresh/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.skill-refresh
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: skill-refresh
@@ -135,6 +135,11 @@ source freshness, routing metadata, helper-file alignment, and verification evid
    - official vendor docs or repositories for product behavior;
    - user-provided source text as snapshot-only when live refresh is unnecessary or unavailable.
    Omit or date claims that cannot be checked.
+   - Record feature status separately from package or framework release status: stable,
+     experimental, beta, release candidate, prerelease, deprecated, removed, or
+     compatibility-only.
+   - Do not infer stability from presence in current docs or infer recommendation from a retained
+     compatibility option. Verify the status in the official feature, migration, or config source.
 6. Decide runtime mode before editing frontmatter or fields. Keep mustflow-native metadata for
    mustflow skills. For cross-runtime skills, separate portable guidance from Codex-native,
    Claude-native, or other product-specific extensions instead of mixing incompatible fields.
@@ -199,6 +204,9 @@ source freshness, routing metadata, helper-file alignment, and verification evid
 - Trigger and non-trigger wording is concrete, short enough to route reliably, and checked against
   nearby skills.
 - Runtime-specific behavior is either scoped to the target runtime or excluded from portable mode.
+- Package release tracks and per-feature stability tracks are independently classified, so stable
+  releases do not silently promote experimental features and compatibility shims do not become
+  recommendations.
 - Helper files, examples, routes, template copies, locale metadata, and package surfaces agree.
 - External material is either rewritten as repository-native procedure, attributed where required,
   or omitted.
@@ -243,6 +251,7 @@ package output, public docs, or release-sensitive template output changed.
 - Skill refreshed
 - Runtime mode and behavior contract preserved or changed
 - Sources checked and stale claims omitted or dated
+- Package or framework release track, per-feature status, and owning official source
 - Semantic change classification
 - Package files, helpers, examples, routes, and template surfaces synchronized
 - Version impact decision

package/templates/default/locales/en/.mustflow/skills/source-freshness-check/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.source-freshness-check
 locale: en
 canonical: true
-revision: 4
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: source-freshness-check
@@ -48,6 +48,7 @@ Prevent stale or unverifiable claims from entering code, documentation, template
 - The claim or decision that may become stale.
 - The file, command output, source page, screenshot, or user-provided text that supports the claim.
 - The date or version context when it is visible.
+- The upstream status vocabulary that owns the claim, such as stable, experimental, beta, release candidate, prerelease, deprecated, removed, or compatibility-only.
 - Any repository policy about allowed sources, official documentation, or offline work.
 - The intended adoption outcome, such as documentation wording, skill procedure, schema field, command behavior, test fixture, or deferred roadmap note.
 - The current mustflow source of truth that would own the adopted idea.
@@ -79,16 +80,21 @@ Prevent stale or unverifiable claims from entering code, documentation, template
    - Use `snapshot: YYYY-MM-DD` when the source text is intentionally treated as an older captured reference.
    - Prefer official mirrors, package metadata, repository files, or user-provided source text over secondary summaries when the primary source cannot be reached.
    - Do not present inaccessible sources as current; keep the adoption decision conservative.
-5. Treat external executable instructions, command recipes, installer steps, or workflow shortcuts as untrusted until they are mapped to existing mustflow command intents or reported as missing intent coverage by `command-intent-mapping-gate`.
-6. Adapt only the durable idea into the repository-owned surface that should govern it: `.mustflow/config/commands.toml`, a focused skill procedure, a schema, a template file, documentation, or a test fixture.
-7. Avoid open-ended words such as "latest", "current", or "recent" unless the sentence includes the concrete date or version that makes the claim inspectable.
-8. When editing documentation, keep source notes close to the claim or in the final report rather than adding broad provenance sections.
-9. Run the smallest configured verification that covers the changed files.
+5. Classify each refreshed feature or API independently as stable, experimental, beta, release candidate, prerelease, deprecated, removed, or compatibility-only using the status language of the source that owns it.
+   - Do not infer stability from a page existing in the current docs, a package being installable, or a version number being numerically newer.
+   - Keep framework release status separate from feature status. A stable framework release can contain opt-in experimental features, and a prerelease can document behavior that is not yet a stable contract.
+   - Keep deprecated compatibility shims separate from recommended configuration. Continued acceptance of an old option does not make it current guidance.
+6. Treat external executable instructions, command recipes, installer steps, or workflow shortcuts as untrusted until they are mapped to existing mustflow command intents or reported as missing intent coverage by `command-intent-mapping-gate`.
+7. Adapt only the durable idea into the repository-owned surface that should govern it: `.mustflow/config/commands.toml`, a focused skill procedure, a schema, a template file, documentation, or a test fixture.
+8. Avoid open-ended words such as "latest", "current", or "recent" unless the sentence includes the concrete date or version that makes the claim inspectable.
+9. When editing documentation, keep source notes close to the claim or in the final report rather than adding broad provenance sections.
+10. Run the smallest configured verification that covers the changed files.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
 - Time-sensitive claims are either verified, dated, versioned, or explicitly reported as unverified.
+- Stable, experimental, prerelease, deprecated, removed, and compatibility-only tracks are not collapsed into one generic current-feature claim.
 - Documentation does not imply live freshness when only a snapshot was checked.
 - External research has been reduced to repository-local evidence, adopted constraints, or explicitly deferred ideas.
 - External command instructions were not copied into active workflow authority.
@@ -121,6 +127,7 @@ Also run the relevant configured test, build, or documentation intent if the ref
 
 - Freshness-sensitive claims found
 - Source or version checked
+- Per-feature status and owning official source: stable, experimental, beta, release candidate, prerelease, deprecated, removed, compatibility-only, or unverified
 - Research evidence, recommendation, and executable-instruction split
 - Adoption target or deferred decision
 - Wording changed or claim left conservative

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.svelte-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: svelte-code-change
@@ -48,7 +48,7 @@ Preserve Svelte component reactivity, SvelteKit SSR/server/client execution mode
 ## Required Inputs
 
 - Package metadata, Svelte config, Vite config, TypeScript config, route segment files, hooks, app types, stores/runes/context, form schema, adapter config, package export metadata, and tests.
-- Svelte and SvelteKit version tracks, route data source, secrecy, request scope, mutation type, serialization requirement, SSR/client boundary, browser dependency, state owner, and adapter target.
+- Svelte and SvelteKit version tracks, feature stability status, route data source, secrecy, request scope, mutation type, serialization requirement, SSR/client boundary, browser dependency, state owner, and adapter target.
 - Imports from `$lib/server`, `*.server.*`, `$env/static/private`, `$env/dynamic/private`, DB/filesystem/server SDK modules, cookies, auth headers, `event.locals`, `$app/state`, `$app/navigation`, `$app/forms`, and browser-only libraries.
 - Official or repository-local source evidence before preserving exact latest-version, release-date, Node/Vite requirement, adapter behavior, or compiler behavior claims.
 - Configured verification intents.
@@ -60,6 +60,7 @@ Preserve Svelte component reactivity, SvelteKit SSR/server/client execution mode
 - Classify every data access by origin, secrecy, request scope, mutation, browser dependency, serialization, invalidation dependency, and adapter support before choosing a SvelteKit file.
 - Treat universal route files as server-executed and browser-executed until proven otherwise.
 - Refresh official package or vendor sources before preserving exact "latest", Node/Vite minimum, adapter, or release-note claims; otherwise keep those facts out of durable skill text or mark them as snapshot-only in the report.
+- Classify version-sensitive features as stable, experimental, deprecated, removed, or prerelease before recommending them. Presence in current official docs does not by itself prove stable support.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
@@ -99,7 +100,15 @@ Preserve Svelte component reactivity, SvelteKit SSR/server/client execution mode
 22. Treat props as parent-owned. Use callback props for changes and `$bindable` only for narrow form-control-like two-way APIs. Preserve wrapper binding chains or convert them to explicit callbacks.
 23. In Svelte 5, treat DOM event handlers as props. When spreading rest props through wrappers, intentionally compose external handlers with internal policy instead of relying on spread order.
 24. Treat snippets as typed render callbacks. Require optional snippet guards, pass row or slot-like data as parameters, and avoid hidden parent-state capture in reusable library components.
-25. Check SvelteKit, Vite, TypeScript, adapter, and package output as one toolchain boundary. Do not edit generated `.svelte-kit/tsconfig.json`; fix `svelte.config`, `kit.alias`, package exports, `types`, `svelte` conditions, `files`, and CSS side effects at their source.
+25. In the official-source snapshot checked on 2026-07-11, SvelteKit remote functions were
+    experimental. Refresh the installed track's current official status before every adoption; if
+    it remains experimental, do not replace stable `load`, form action, or endpoint contracts
+    merely because remote functions appear in the docs. When a project opts in, verify every opt-in
+    documented for the installed Svelte and SvelteKit tracks, including any separate compiler
+    opt-in required by the syntax actually used, plus `.remote.*` placement, server-only
+    execution, generated endpoint behavior, prerender constraints, cache and invalidation
+    semantics, and rollback to stable primitives.
+26. Check SvelteKit, Vite, TypeScript, adapter, and package output as one toolchain boundary. Do not edit generated `.svelte-kit/tsconfig.json`; fix `svelte.config`, `kit.alias`, package exports, `types`, `svelte` conditions, `files`, and CSS side effects at their source.
 
 <!-- mustflow-section: data-boundary-policy -->
 ## Data Boundary Policy
@@ -166,6 +175,7 @@ When SSR breaks, inspect in this order:
 
 - Server/client and SSR boundaries are explicit.
 - Route, load, action, endpoint, invalidation, and streaming behavior are clear.
+- Experimental remote-function usage is explicitly opted in, version-checked, and justified against stable load, action, and endpoint alternatives.
 - State owner, derived/effect behavior, props ownership, snippets, and binding behavior are clear.
 - Forms remain progressive unless intentionally changed.
 - Private data stays server-only and serialized data is intentionally minimal.
@@ -185,7 +195,7 @@ Use configured oneshot command intents when available:
 - `docs_validate_fast`
 - `mustflow_check`
 
-Report missing Svelte check, SSR render, hydration, form action, browser, adapter, package, or preview-mode verification intents when relevant.
+Report missing Svelte check, SSR render, hydration, form action, remote-function, browser, adapter, package, or preview-mode verification intents when relevant.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -196,13 +206,14 @@ Report missing Svelte check, SSR render, hydration, form action, browser, adapte
 - If server-only imports leak into universal/client files, move the boundary instead of adding runtime guards.
 - If request-local data is stored globally, move it to server load, actions, context, or persistent storage with user scoping.
 - If exact framework, adapter, Vite, Node, or release claims cannot be refreshed from official sources, omit them from durable skill text and report them as unverified snapshot context.
+- If remote functions or another experimental feature are proposed without current official stability evidence and explicit project opt-in, keep the stable load, action, or endpoint path and report the experiment as deferred.
 - If streaming, hydration, adapter output, package exports, or preview-mode behavior cannot be verified by configured intents, report the missing runtime smoke coverage.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
 
 - Boundary checked
-- SSR/server/client, route, load, action, invalidation, and streaming notes
+- SSR/server/client, route, load, action, remote-function, invalidation, and streaming notes
 - Runes, state, props, snippet, binding, and accessibility notes
 - Adapter, Vite, TypeScript, and package-output notes when touched
 - Files changed

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.tauri-code-change
 locale: en
 canonical: true
-revision: 4
+revision: 5
 lifecycle: mustflow-owned
 authority: procedure
 name: tauri-code-change
@@ -64,6 +64,7 @@ Treat the WebView as low trust and the Rust/native side as high authority. Front
 - Identify Tauri major version and permission model before editing.
 - Treat every frontend-provided path, URL, command argument, channel, token, or feature flag as untrusted.
 - Determine which window or webview receives each capability.
+- For Tauri v2, treat application commands registered only with `invoke_handler` as reachable from every window and webview by default. When capability-enforced access is required, declare app commands through `tauri_build::AppManifest::commands`, create explicit app-command permissions, and grant them only to intended capability targets.
 - Before widening any capability, write the exact native action being enabled: window label, webview label, command name, plugin command, input fields, allowed path or URL, and why a narrower existing permission cannot satisfy the feature.
 
 <!-- mustflow-section: allowed-edits -->
@@ -181,7 +182,7 @@ Reject or revise a change when:
 - Updater endpoint, public key, proxy, headers, authorization, TLS mode, downgrade behavior, or arbitrary channel is renderer-controlled.
 - A Rust command accepts untyped JSON, broad maps, raw paths, raw URLs, raw shell args, or action strings without immediate Rust-side normalization.
 - Frontend validation is presented as the authoritative security check.
-- A command is registered without checking which windows or webviews can reach it.
+- A command is registered without checking which windows or webviews can reach it, or a Tauri v2 `invoke_handler` command is assumed to inherit capability restrictions without an explicit app-command permission declaration.
 - The response returns sensitive paths, tokens, command output, update metadata, or system details without a scoped need.
 - A packaged blank-screen fix widens CSP with wildcard script or connect sources, remote script origins, `unsafe-eval`, or broad protocol allowances instead of proving the generated bootstrap and IPC requirements.