mustflow 2.115.5 → 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/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.
 

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

@@ -0,0 +1,207 @@
+---
+mustflow_doc: skill.threejs-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: threejs-code-change
+description: Apply this skill when Three.js renderers, scenes, cameras, meshes, materials, textures, shaders, glTF assets, animation, picking, WebGL, WebGPU, WebXR, resource disposal, or Three.js performance and tests are created, changed, reviewed, migrated, or upgraded.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.threejs-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Three.js Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Preserve renderer, scene, asset, interaction, GPU-resource, compatibility, and frame-budget
+contracts while making focused Three.js changes. Treat a visible frame as weak evidence: draw-call
+churn, shader recompilation, texture residency, hidden render passes, stale bounds, and leaked
+listeners or GPU resources can remain broken after the scene appears correct.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- `WebGLRenderer`, `WebGPURenderer`, scenes, cameras, controls, lights, shadows, render targets,
+  post-processing, TSL, node materials, custom shaders, or animation loops change.
+- Geometry, materials, textures, glTF/GLB, Draco, Meshopt, KTX2, instancing, skinning, animation,
+  disposal, context or device loss, or renderer migration changes.
+- `Raycaster`, pointer interaction, GPU picking, BVH acceleration, layers, WebXR input, or dense-scene
+  interaction changes.
+- Three.js package metadata, import boundaries, browser targets, tests, performance claims, or
+  migration documentation change.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- Babylon.js, PlayCanvas, a native engine, or raw WebGPU owns the rendering boundary.
+- The task changes only a static model or texture without changing Three.js loading, rendering,
+  ownership, compatibility, or package behavior.
+- The task asks only for the current Three.js release number; use source-freshness guidance unless
+  code or durable documentation changes too.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Installed and supported Three.js versions, import paths, addons, bundler, framework lifecycle,
+  browser and device targets, and configured verification intents.
+- Renderer ledger: backend, asynchronous initialization, fallback, canvas owner, animation-loop
+  owner, resize and pixel-ratio policy, context/device-loss behavior, and render-target owners.
+- Resource ledger: scene roots, geometries, materials, textures, skeletons, animation mixers,
+  controls, listeners, observers, workers, decoders, caches, and disposal owners.
+- Performance evidence: CPU and GPU frame time, `renderer.info`, draw calls, triangles, texture and
+  geometry counts, shader compilation, upload time, overdraw, render-target sizes, and target-device
+  measurements.
+- Interaction ledger: canvas bounds, pointer normalization, pickable set, domain mapping, layers,
+  bounds freshness, instance mapping, hover frequency, and accessibility fallback.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Read repository package and lock evidence before choosing current Three.js APIs or migration
+  advice. Refresh official docs, migration notes, package metadata, and browser platform sources
+  before embedding exact version, deprecation, removal, or support claims.
+- Classify WebGL, WebGPU, TSL/node-material, and WebXR features independently. A stable Three.js
+  release does not make every renderer backend or browser platform universally available.
+- Identify the framework component or route that owns mount, resize, animation, and cleanup before
+  editing renderer lifecycle.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Make focused Three.js source, tests, package metadata, docs, assets, and configuration changes
+  required by the task.
+- Add instrumentation or regression tests for lifecycle, picking, fallback, resource ownership,
+  shader/material behavior, bounds, resize, and performance contracts.
+- Preserve fallback and compatibility paths when supported browsers or devices still need them.
+- Do not switch renderer backends, force WebGPU-only delivery, raise pixel ratio, add expensive
+  passes, replace picking strategies, or introduce compression/decoder infrastructure without
+  repository evidence and an explicit compatibility and rollout plan.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. **Classify package and renderer tracks.**
+   - Separate the repository-pinned release, a proposed target release, WebGLRenderer,
+     WebGPURenderer, TSL/node-material, addon, and browser-platform tracks.
+   - Verify migration notes across every crossed release. Do not treat a future migration heading,
+     prerelease tag, or dev-branch documentation as the current stable contract.
+   - Check import boundaries such as core, addons, `three/webgpu`, and `three/tsl` against the
+     installed version and bundler instead of copying current examples into older support ranges.
+2. **Own renderer and frame lifecycle.**
+   - Make asynchronous renderer initialization, first render, animation loop, resize, pixel ratio,
+     visibility suspension, and teardown explicit and idempotent.
+   - Prefer `renderer.setAnimationLoop()` when renderer or XR lifecycle requires it. For on-demand
+     rendering, verify initialization and invalidate only from owned state changes.
+   - Update canvas size, camera projection, pixel ratio, composer and render-target sizes together.
+     Treat device pixel ratio as a GPU workload multiplier and cap or adapt it from measurements.
+3. **Keep scene state and ownership separate.**
+   - Use the scene as a render tree, not the domain database. Maintain entity-to-object and
+     instance-to-entity mappings outside renderer internals.
+   - Record shared versus exclusive ownership before disposal. Removing an object from a scene does
+     not dispose geometry, material, texture, render target, skeleton, mixer, control, listener,
+     worker, decoder, or cache resources.
+   - Verify route changes, hot reload, asset swaps, and repeated mount/unmount cycles do not produce
+     stepwise growth in renderer counters or duplicate loops and listeners.
+4. **Review geometry, bounds, culling, and instancing.**
+   - Reduce draw calls and state changes before chasing small JavaScript loop savings. Use merged
+     geometry, instancing, spatial chunks, LOD, and culling only when interaction, update, and
+     disposal semantics remain correct.
+   - After transform or attribute changes, update the required dirty flags and recompute stale
+     bounding volumes used by frustum culling or raycasting.
+   - Keep `InstancedMesh.instanceId` as a render index, not a domain identity. Define remapping,
+     deletion, visibility, hover, color, and bounds behavior explicitly.
+5. **Review materials, textures, shaders, lights, and passes.**
+   - Separate color textures from numeric data maps and verify color-space, format, compression,
+     mipmap, filtering, anisotropy, and upload policy per texture class.
+   - Treat material define changes as shader-variant changes. Prefer uniforms for value changes,
+     preload critical shader variants, and measure compile and upload stalls.
+   - Count shadow maps, transparent overdraw, cameras, mirrors, post-processing passes, and render
+     targets as repeated scene work. Keep expensive effects bounded by a target-device budget.
+   - Verify custom GLSL, `onBeforeCompile`, post-processing, and render-target assumptions before a
+     WebGPU or TSL migration; changing the renderer constructor is not a complete migration.
+6. **Review picking and interaction.**
+   - Convert pointer coordinates from `canvas.getBoundingClientRect()` into normalized device
+     coordinates. Do not normalize against the window unless the canvas contract is truly full-screen.
+   - Raycast a maintained pickable set or interaction proxies, not the whole scene on every pointer
+     move. Use layers deliberately and remember that parent-layer mismatch does not prune every
+     descendant traversal contract automatically.
+   - Map intersection objects to domain owners. Account for back-face rules, line/point thresholds,
+     transparent or discarded pixels, shader deformation, stale matrices and bounds, and instances.
+   - Use BVH or coarse colliders for dense static geometry when measured raycasting exceeds the
+     interaction budget. Use GPU ID picking only with an explicit readback and latency policy.
+7. **Review WebGPU, WebXR, and recovery.**
+   - Feature-detect after the owning initialization point and retain a tested WebGL fallback unless
+     deployment evidence permits otherwise. Browser name alone does not prove adapter, feature,
+     limit, driver, policy, or secure-context support.
+   - Treat WebGL context loss and WebGPU device loss as lifecycle transitions with resource rebuild
+     or a deliberate user-visible fallback, not only console errors.
+   - For WebXR, separate target-ray, grip, hand, gaze, and near-touch interaction; keep session
+     request, permission failure, end, re-entry, camera, and frame-loop behavior explicit.
+8. **Verify behavior and performance.**
+   - Test initial load, resize, background-tab return, route remount, asset replacement, fallback,
+     loss/recovery where supported, and representative pointer/XR interaction.
+   - Compare before/after CPU frame time, GPU frame time when measurable, draw calls, triangles,
+     texture and geometry counts, shader compilation, upload stalls, and render-target pixels on a
+     representative device. Do not call a change an optimization from source inspection alone.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Renderer, scene, frame loop, resources, interaction, and fallback each have an explicit owner.
+- Release status, renderer backend, feature status, and browser support are not collapsed into one
+  generic "current Three.js" claim.
+- Picking maps render intersections to domain semantics and has bounded per-event work.
+- Performance claims include counters or traces and repeated lifecycle operations do not leak.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot intents that cover the changed scope:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the installed Three.js track or browser target is unclear, preserve the existing API and
+  fallback and report the missing evidence.
+- If GPU timing is unavailable, report CPU timing and renderer counters separately and do not infer
+  GPU improvement from them.
+- If a renderer migration crosses unsupported shaders, passes, formats, or platform features, keep
+  the existing backend and report the smallest migration experiment instead of forcing parity.
+- If verification needs an unconfigured server, browser harness, asset generator, or benchmark,
+  report the missing command intent rather than running it raw.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Three.js surface and version/backend tracks
+- Renderer, scene, resource, and interaction owners
+- Compatibility, fallback, migration, and recovery decisions
+- Performance evidence before and after
+- Changed files and command intents run
+- Skipped checks and remaining rendering, lifecycle, picking, or device risk