mustflow 2.115.4 → 2.115.9

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

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.typescript-code-change
 locale: en
 canonical: true
-revision: 7
+revision: 8
 lifecycle: mustflow-owned
 authority: procedure
 name: typescript-code-change
-description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, project references, type-check performance, compiler-version behavior, TypeScript 6-to-7 migration surfaces, TypeScript 7 RC or nightly tooling, runtime data validation, type safety, or TypeScript tests are created or changed.
+description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, project references, type-check performance, compiler-version behavior, TypeScript 6-to-7 migration surfaces, TypeScript 7 stable, development, API-compatibility, or native-preview tooling, runtime data validation, type safety, or TypeScript tests are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -36,7 +36,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - `.ts`, `.tsx`, `.mts`, `.cts`, `*.d.ts`, `tsconfig*.json`, package entry metadata, exports, declarations, runtime validators, or TypeScript tests change.
 - The task touches module resolution, ESM/CJS interop, public package API, path aliases, generated declarations, or strict type errors.
 - The task touches project references, monorepo package boundaries, type-check speed, declaration emit speed, ambient type scope, large unions, generated types, or TypeScript build graph shape.
-- The task touches TypeScript compiler major-version behavior, TypeScript 6 transition deprecations, TypeScript 7 RC comparison, TypeScript 7 nightly comparison, `@typescript/typescript6`, `tsc6`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API use, declaration emit comparison, or editor language-service behavior.
+- The task touches TypeScript compiler major-version behavior, TypeScript 6 transition deprecations, TypeScript 7 stable adoption, TypeScript development-build comparison, `@typescript/typescript6`, `tsc6`, `typescript`, `typescript@next`, `@typescript/native-preview`, `tsgo`, compiler API use, declaration emit comparison, or editor language-service behavior.
 - The task touches external inputs such as JSON, HTTP responses, environment variables, config files, form data, URL params, local storage, message events, queue payloads, or user-provided objects.
 - A framework component written in TypeScript changes its props, events, routes, loader data, or exported types.
 
@@ -54,7 +54,12 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - Existing source entrypoints, public exports, declaration files, validators, schemas, type tests, and nearby tests.
 - The target runtime and module system: Node, browser, worker, Bun, edge, ESM, CJS, or mixed boundary.
 - Workspace package dependency graph, `tsconfig` references graph, public package entrypoints, path alias policy, generated-type locations, and current import-boundary evidence when the repository is a monorepo or large TypeScript project.
-- TypeScript compiler track and tooling entrypoint when relevant: TS6 stable API track through `@typescript/typescript6` and `tsc6`, TS7 RC compiler track through `typescript@rc` and `tsc`, TS7 nightly track through `@typescript/native-preview` and `tsgo`, future TS7 stable track through the stable `typescript` package, framework typecheck wrappers, editor extension settings, and any compiler API consumers.
+- TypeScript compiler track and tooling entrypoint when relevant. In the registry snapshot checked
+  on 2026-07-11, TS7 stable used `typescript` and `tsc`, TS6 JavaScript API compatibility used
+  `@typescript/typescript6` and `tsc6`, development builds used `typescript@next`, native
+  preview used `@typescript/native-preview` and `tsgo`, and `typescript@rc` referred to
+  historical prerelease evidence. Refresh registry and official release evidence before reusing
+  that mapping, then include framework typecheck wrappers, editor settings, and compiler API consumers.
 - Package API metadata when relevant: `type`, `main`, `module`, `browser`, `exports`, `types`, `typings`, `typesVersions`, `files`, `bin`, `sideEffects`, and documented import paths.
 - Existing verification intents from the repository command contract.
 
@@ -74,7 +79,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - Keep public runtime exports and declaration exports aligned.
 - Add focused tests or type tests only when they protect the changed contract.
 - Use existing schema validators or narrowly scoped type guards and assertion functions for external input boundaries.
-- Compare TS6 `tsc6`, TS7 RC `tsc`, and optionally TS7 nightly `tsgo` only as a bounded migration or diagnostics exercise when repository tooling explicitly supports those tracks.
+- Compare TS7 stable `tsc`, TS6-compatible `tsc6`, and optional `typescript@next` or native-preview `tsgo` only as a bounded migration or diagnostics exercise when repository tooling explicitly supports those tracks.
 - Do not weaken compiler, lint, module, package, or test boundaries to make the task appear complete.
 
 <!-- mustflow-section: procedure -->
@@ -112,14 +117,16 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 30. Inspect generated declarations when package surfaces change. Declaration files must not leak source-only aliases, private paths, workspace-only package names, unpublished internal paths, accidental public re-exports, stale `paths` aliases, or wrong ESM/CJS declaration shapes.
 31. For TypeScript 6 migration work, treat deprecation warnings as future TypeScript 7 removal risk. `ignoreDeprecations` is a temporary compatibility valve, not proof that the project is ready for 7.0. Prefer removing deprecated options and updating resolver or module choices to match the project runtime.
 32. Treat TypeScript 6 `--stableTypeOrdering` as a migration comparison tool for declaration and error-order differences, not as a permanent performance-neutral default. If it changes errors or declaration output, look for inference or declaration-stability issues instead of snapshotting noise.
-33. For TypeScript 7 migration work, keep the tracks separate:
-   - TS6 stable API track: `@typescript/typescript6` and `tsc6` for compiler API, transformer, ESLint, framework wrapper, and peer-dependency compatibility.
-   - TS7 RC compiler track: `typescript@rc` and `tsc` for RC compiler verification.
-   - TS7 nightly track: `@typescript/native-preview` and `tsgo` for nightly diagnostics only.
-   - Future TS7 stable track: stable `typescript` once upstream publishes TypeScript 7 on the normal stable path.
-34. Keep compiler API consumers, language-service plugins, custom transformers, and framework typecheck wrappers on the TS6 API track until their owners explicitly support the TS7 API surface. Treat TS7 RC `tsc` as compiler verification, not proof that JavaScript compiler API consumers can migrate.
-35. When comparing TS6 `tsc6`, TS7 RC `tsc`, and optional TS7 nightly `tsgo`, classify differences before editing code: real type error, declaration emit order or printback noise, unsupported option, unsupported API, watch or incremental behavior gap, language-service gap, generated-output drift, or framework wrapper mismatch.
-36. Do not treat faster TS7 RC or nightly results as sufficient verification. Keep the repository's existing `tsc`, `tsc6`, or framework typecheck as the compatibility baseline until repository policy explicitly adopts a different compiler track.
+33. For TypeScript 7 migration work, refresh official release and registry evidence, then keep the
+   tracks separate. The following mapping is a snapshot checked on 2026-07-11:
+   - TS7 stable compiler track: `typescript` and `tsc` for repository adoption and ordinary compiler verification.
+   - TS6 JavaScript API compatibility track: `@typescript/typescript6` and `tsc6` for compiler API, transformer, ESLint, framework wrapper, and peer-dependency compatibility until each owner supports the TS7 API surface.
+   - Development compiler track: `typescript@next` for explicitly requested next-minor or next-major testing, never as a stable replacement.
+   - Native-preview track: `@typescript/native-preview` and `tsgo` for explicitly requested comparison only.
+   - Historical prerelease track: use `typescript@rc` only to reproduce a named prerelease or when current official registry metadata assigns it to a new release candidate.
+34. Keep compiler API consumers, language-service plugins, custom transformers, and framework typecheck wrappers on the TS6 API compatibility track until their owners explicitly support the TS7 API surface. Stable TS7 `tsc` output does not prove that JavaScript compiler API consumers can migrate.
+35. When comparing TS7 stable `tsc`, TS6-compatible `tsc6`, `typescript@next`, or native-preview `tsgo`, classify differences before editing code: real type error, declaration emit order or printback noise, unsupported option, unsupported API, watch or incremental behavior gap, language-service gap, generated-output drift, or framework wrapper mismatch.
+36. Do not treat faster development or native-preview results as sufficient verification. Keep the repository's adopted stable compiler, TS6 API compatibility check, or framework typecheck as the baseline until repository policy explicitly adopts a different track.
 37. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, downstream-style consumer risk, and type-check performance risk.
 
 <!-- mustflow-section: assertion-policy -->
@@ -176,7 +183,7 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - `tsconfig` defaults, ambient `types`, import attributes, `import defer`, or explicit resource management syntax are adopted without runtime, bundler, compiler-track, and generated-output evidence.
 - `skipLibCheck` or weakened strictness is used as release validation for a library/package.
 - TypeScript 6-to-7 migration warnings are silenced instead of classified and either fixed or reported.
-- TS7 RC or nightly output differences are accepted as harmless without classification.
+- TS7 stable, development, or native-preview output differences are accepted as harmless without classification.
 - Compiler API, transformer, language-service, or framework typecheck surfaces are moved off the TS6 API track without compatibility proof.
 
 <!-- mustflow-section: postconditions -->
@@ -206,7 +213,7 @@ Use configured oneshot command intents when available:
 
 If a package API changes, include the configured release or package-surface verification when available.
 
-Report whether configured verification exists for declaration output, package artifact contents, downstream-style consumer fixtures, minimum supported TypeScript version, latest supported TypeScript version, TS6/TS7 RC comparison, optional TS7 nightly comparison, ESM, CJS, and bundler-style resolution when those surfaces change.
+Report whether configured verification exists for declaration output, package artifact contents, downstream-style consumer fixtures, minimum supported TypeScript version, adopted stable TypeScript version, TS6 API compatibility, optional `typescript@next` or native-preview comparison, ESM, CJS, and bundler-style resolution when those surfaces change.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -215,7 +222,7 @@ Report whether configured verification exists for declaration output, package ar
 - If external input has no validation pattern, add a narrow validator/guard/assertion or report the missing boundary instead of casting.
 - If module resolution is unclear, inspect the package and compiler configuration before changing imports.
 - If generated declaration output cannot be inspected, report the package API risk and the missing verification intent.
-- If TS7 RC or nightly disagrees with the repository's TS6 or stable baseline, keep the baseline as the compatibility path, classify the difference, and report whether it is a project bug, compiler bug, unsupported feature, or expected declaration/order drift.
+- If TS7 stable, `typescript@next`, or native preview disagrees with the repository's adopted compiler, TS6 API compatibility, or framework baseline, keep the declared baseline as the compatibility path, classify the difference, and report whether it is a project bug, compiler bug, unsupported feature, or expected declaration/order drift.
 - If a framework, plugin, transformer, or compiler API consumer depends on the JavaScript compiler implementation, do not move it off the TS6 API track unless the dependency explicitly supports that path.
 - If verification commands are missing, report the missing intents instead of inventing package-manager commands.
 

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.version-freshness-check
 locale: en
 canonical: true
-revision: 10
+revision: 11
 lifecycle: mustflow-owned
 authority: procedure
 name: version-freshness-check
@@ -35,7 +35,7 @@ Prevent agents from writing stale external version references from memory, while
 - Generated or edited files introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, toolchain versions, setup actions, scaffold commands, install commands, or migration examples.
 - CI workflows, release workflows, Dockerfiles, package metadata, lockfiles, runtime files, framework configuration, README examples, docs, tests, fixtures, or templates mention external versions such as GitHub Actions refs, Node, Bun, Deno, Python, Rust, Tauri, Astro, Next, SvelteKit, Electron, Docker images, package managers, SDKs, plugins, or generators.
 - Python wording mentions current/stable/support status, Python 3.14+ or 3.15+ syntax, standard-library APIs, runtime flags, changed default behavior, security defaults, or examples that depend on `requires-python`.
-- TypeScript wording mentions current/stable/RC/nightly status for TypeScript 6, TypeScript 7, `@typescript/typescript6`, `tsc6`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
+- TypeScript wording mentions current/stable/development/prerelease/native-preview status for TypeScript 6, TypeScript 7, `@typescript/typescript6`, `tsc6`, `typescript`, `typescript@next`, `typescript@rc`, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
 - Go wording mentions current/stable/support status, Go release numbers, `go.mod` language version behavior, `toolchain` behavior, standard-library APIs, `GOEXPERIMENT`, runtime defaults, container behavior, JSON experiments, third-party Go framework releases such as Gin, framework minimum-Go requirements, or examples that depend on a specific Go or framework version.
 - Java wording mentions current/stable/GA/LTS/support status, Java or JDK release numbers, Oracle/OpenJDK/vendor support tracks, JEP status, preview or incubator APIs, JVM flags, GC behavior, virtual-thread behavior, `ScopedValue`, structured concurrency, final-field reflection restrictions, applet removal, HTTP/3, AOT cache, Compact Object Headers, JFR, JMH, container memory or CPU behavior, Maven or Gradle toolchains, bytecode target, or examples that depend on a specific Java version.
 - Rust wording mentions current/stable/support status, Rust release numbers, `rust-version`, edition behavior, `rust-toolchain`, Cargo resolver or workspace behavior, standard-library APIs, compiler lints, target behavior, release profiles, or examples that depend on a specific Rust version.
@@ -98,8 +98,14 @@ Prevent agents from writing stale external version references from memory, while
 13. For Python standard-library or runtime-behavior claims, refresh official Python documentation before writing durable wording. Check `requires-python`, CI/runtime matrices, and container images before using or recommending Python 3.14+ standard-library APIs or version-gated features such as template string literals, `annotationlib`, Python 3.14+ `map(strict=True)`, `functools.Placeholder`, `heapq` max-heap helpers, import-timing flag behavior, `finally` flow-control warnings, or changed security defaults.
 14. For Python examples that use newer standard-library APIs, either keep the example behind an explicit runtime floor or provide a supported fallback. Do not call a Python 3.14-only API a general Python best practice when the repository declares lower support.
 15. For Python 3.15+ claims, keep beta, release-candidate, and stable tracks separate. Refresh official docs before using explicit lazy imports, built-in `frozendict`, built-in `sentinel`, unpacking comprehensions, typed `TypedDict` extra items, startup configuration files, or changed encoding behavior in durable examples.
-16. For TypeScript 6 and 7 claims, refresh official TypeScript sources before writing durable wording. Treat TS6 stable API track (`@typescript/typescript6`, `tsc6`), TS7 RC compiler track (`typescript@rc`, `tsc`), TS7 nightly track (`@typescript/native-preview`, `tsgo`), and future TS7 stable `typescript` behavior as distinct tracks. Do not call RC or nightly output "latest stable TypeScript" just because it is newer.
-17. For TypeScript examples, make the selected track explicit: TS6 API compatibility, TS7 RC compiler verification, TS7 nightly comparison, editor preview, or repository adoption. If the project has compiler API consumers, transformers, framework wrappers, or declaration snapshots, classify the reference as migration-sensitive and keep API consumers on the TS6 API track until support is explicit. Check exact support before relying on `rootDir` defaults, ambient `types` defaults, import attributes, subpath imports, `import defer`, `using`, or `await using`.
+16. For TypeScript 6 and 7 claims, refresh official TypeScript and registry sources before writing
+    durable wording. The snapshot checked on 2026-07-11 mapped TS7 stable to `typescript` and
+    `tsc`, TS6 JavaScript API compatibility to `@typescript/typescript6` and `tsc6`,
+    development builds to `typescript@next`, native preview to `@typescript/native-preview`
+    and `tsgo`, and historical prerelease evidence to `typescript@rc`. Reclassify every tag
+    from current evidence; do not call development, preview, or RC output "latest stable
+    TypeScript" merely because it is newer or separately installable.
+17. For TypeScript examples, make the selected track explicit: TS7 stable compiler adoption, TS6 API compatibility, `typescript@next` development comparison, native-preview comparison, historical prerelease reproduction, editor preview, or framework-owned verification. If the project has compiler API consumers, transformers, framework wrappers, or declaration snapshots, classify the reference as migration-sensitive and keep API consumers on the TS6 API compatibility track until support is explicit. Check exact support before relying on `rootDir` defaults, ambient `types` defaults, import attributes, subpath imports, `import defer`, `using`, or `await using`.
 18. For Go release, toolchain, standard-library, runtime, or experiment claims, refresh official Go release notes or package documentation before writing durable wording. Check the repository's `go` directive, `toolchain` directive, CI/runtime matrix, and container target before using or recommending version-gated features such as expression operands to `new`, range-over-function iterators, generic type aliases, reflect iterator methods, `errors.AsType`, `sync.WaitGroup.Go`, `testing/synctest`, `testing.B.Loop`, `T.ArtifactDir`, `B.ArtifactDir`, `F.ArtifactDir`, `testing/cryptotest.SetGlobalRandom`, `os.Root`, `os.OpenInRoot`, `omitzero`, `go.mod` `tool`, `ReverseProxy.Rewrite`, container-aware `GOMAXPROCS`, goroutine leak profiles, `encoding/json/v2`, or `GOEXPERIMENT` APIs.
 19. For Go framework and dependency release claims, refresh the source that owns the artifact before writing durable wording. For Gin, prefer official Gin release notes, pkg.go.dev module metadata, and the upstream repository release or source files for claims about latest stable version, minimum Go version, HTTP/3 support, BSON support, binding behavior, router options, logger options, trusted proxy behavior, or `Context` APIs. Keep framework upgrade advice separate from repository adoption, because a framework minor can still require a Go toolchain, CI image, Docker base, middleware, route, or binding migration.
 20. For Go examples that use newer standard-library APIs, framework APIs, or runtime defaults, either keep the example behind an explicit Go or framework version floor or provide a supported fallback. Do not call an experimental `GOEXPERIMENT` feature, a newer `go` directive behavior, or a newly added framework method a general Go best practice when the repository declares lower support.
@@ -123,7 +129,7 @@ Prevent agents from writing stale external version references from memory, while
 - Major or migration-required changes are either explicitly approved, deferred with a recommendation, or left unchanged with the risk reported.
 - Python standard-library examples and runtime-default claims match the declared Python support matrix or name the required runtime floor.
 - Python template strings, annotation inspection, explicit lazy imports, immutable mappings, sentinels, and advanced `TypedDict` shape claims are either official-source checked or omitted.
-- TypeScript 6 stable API, TypeScript 7 RC compiler, TypeScript 7 nightly, and future stable TypeScript tracks are not collapsed into one generic "latest TypeScript" claim.
+- TypeScript 7 stable compiler, TypeScript 6 JavaScript API compatibility, `typescript@next` development, native-preview, and RC prerelease tracks are not collapsed into one generic "latest TypeScript" claim.
 - Go release, `go.mod` language version, standard-library API, framework dependency API such as Gin, runtime-default, and `GOEXPERIMENT` claims match the declared Go support matrix or name the required runtime or framework floor.
 - Java release, JDK vendor, source or target release, bytecode target, JEP status, standard-library API, virtual-thread behavior, preview or incubator API, build-tool support, JVM flag, GC behavior, and container-runtime claims match the declared Java support matrix or name the required runtime, toolchain, and feature floor.
 - Rust release, `rust-version`, edition, standard-library API, Cargo resolver, lint-default, target, and nightly/stable claims match the declared Rust support matrix or name the required API-specific runtime floor.
@@ -152,7 +158,7 @@ Choose the narrowest configured intent that proves the changed versioned surface
 - If official sources conflict, prefer the source that owns the artifact being referenced and report the conflict.
 - If a freshness check requires network, credentials, or a connector that is not available, report the boundary and avoid current-version claims.
 - If a proposed major or migration-required version is better for greenfield work but risky for the existing project, present both choices and ask before changing the project.
-- If TypeScript 7 RC, nightly, or stable freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from comparison-only checks.
+- If TypeScript stable, development, native-preview, or RC freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from comparison-only checks.
 - If Go release, framework release, or experiment freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, `go` directive adoption, framework adoption, CI support, and `GOEXPERIMENT` adoption separate.
 - If Java release, JEP, JVM flag, GC, or toolchain freshness changes during the task, update wording to a dated or track-specific claim and keep latest GA, latest LTS, repository runtime, vendor support, preview or incubator status, product feature status, default-enabled behavior, build-tool support, and CI or container adoption separate.
 - If Rust release or toolchain freshness changes during the task, update wording to a dated or track-specific claim and keep official release status, MSRV adoption, edition adoption, CI support, target support, and nightly or unstable features separate.

package/templates/default/locales/en/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: en
 canonical: true
-revision: 22
+revision: 23
 lifecycle: user-editable
 authority: binding
 ---
@@ -129,6 +129,13 @@ mustflow-managed details are under `.mustflow/`.
   nested repository's local routing files.
 - Shared workspace skills provide procedure guidance only. They do not override the nested
   repository's `AGENTS.md`, command contract, edit scope, safety rules, or source of truth.
+- Resolve every verification intent named by a shared workspace skill against the selected child
+  repository's own `.mustflow/config/commands.toml`. Do not run a parent-root intent merely to
+  satisfy a child task, and do not treat the parent intent as a skipped child check.
+- Require parent-root verification only when the task edits parent-owned files, changes
+  parent-owned orchestration, or the child result explicitly depends on a parent-owned artifact or
+  contract. Unrelated parent worktree changes, locks, or manifest drift do not block a child-only
+  completion claim.
 - If a nested repository lacks a local skill index or uses a different local agent convention,
   do not treat that absence as meaning no applicable workspace-level skill exists; consult the
   shared workspace registry while keeping child-repository authority local.

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.115.4"
+version = "2.115.9"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -95,7 +95,10 @@ creates = [
   ".mustflow/skills/astro-code-change/SKILL.md",
   ".mustflow/skills/axum-code-change/SKILL.md",
   ".mustflow/skills/babylon-code-change/SKILL.md",
+  ".mustflow/skills/threejs-code-change/SKILL.md",
   ".mustflow/skills/bun-code-change/SKILL.md",
+  ".mustflow/skills/deno-code-change/SKILL.md",
+  ".mustflow/skills/ada-code-change/SKILL.md",
   ".mustflow/skills/c-code-change/SKILL.md",
   ".mustflow/skills/css-code-change/SKILL.md",
   ".mustflow/skills/cpp-code-change/SKILL.md",
@@ -115,6 +118,8 @@ creates = [
   ".mustflow/skills/vue-code-change/SKILL.md",
   ".mustflow/skills/vite-code-change/SKILL.md",
   ".mustflow/skills/python-code-change/SKILL.md",
+  ".mustflow/skills/php-code-change/SKILL.md",
+  ".mustflow/skills/pascal-code-change/SKILL.md",
   ".mustflow/skills/powershell-code-change/SKILL.md",
   ".mustflow/skills/shell-code-change/SKILL.md",
   ".mustflow/skills/structured-config-change/SKILL.md",
@@ -332,7 +337,10 @@ minimal = [
   "astro-code-change",
   "axum-code-change",
   "babylon-code-change",
+  "threejs-code-change",
   "bun-code-change",
+  "deno-code-change",
+  "ada-code-change",
   "c-code-change",
   "css-code-change",
   "cpp-code-change",
@@ -352,6 +360,8 @@ minimal = [
   "vue-code-change",
   "vite-code-change",
   "python-code-change",
+  "php-code-change",
+  "pascal-code-change",
   "powershell-code-change",
   "shell-code-change",
   "rust-code-change",
@@ -503,7 +513,10 @@ patterns = [
   "astro-code-change",
   "axum-code-change",
   "babylon-code-change",
+  "threejs-code-change",
   "bun-code-change",
+  "deno-code-change",
+  "ada-code-change",
   "c-code-change",
   "css-code-change",
   "cpp-code-change",
@@ -523,6 +536,8 @@ patterns = [
   "vue-code-change",
   "vite-code-change",
   "python-code-change",
+  "php-code-change",
+  "pascal-code-change",
   "powershell-code-change",
   "shell-code-change",
   "rust-code-change",
@@ -685,7 +700,10 @@ oss = [
   "astro-code-change",
   "axum-code-change",
   "babylon-code-change",
+  "threejs-code-change",
   "bun-code-change",
+  "deno-code-change",
+  "ada-code-change",
   "c-code-change",
   "css-code-change",
   "cpp-code-change",
@@ -705,6 +723,8 @@ oss = [
   "vue-code-change",
   "vite-code-change",
   "python-code-change",
+  "php-code-change",
+  "pascal-code-change",
   "powershell-code-change",
   "shell-code-change",
   "rust-code-change",
@@ -886,7 +906,10 @@ team = [
   "astro-code-change",
   "axum-code-change",
   "babylon-code-change",
+  "threejs-code-change",
   "bun-code-change",
+  "deno-code-change",
+  "ada-code-change",
   "c-code-change",
   "css-code-change",
   "cpp-code-change",
@@ -906,6 +929,8 @@ team = [
   "vue-code-change",
   "vite-code-change",
   "python-code-change",
+  "php-code-change",
+  "pascal-code-change",
   "powershell-code-change",
   "shell-code-change",
   "rust-code-change",
@@ -1071,7 +1096,10 @@ product = [
   "astro-code-change",
   "axum-code-change",
   "babylon-code-change",
+  "threejs-code-change",
   "bun-code-change",
+  "deno-code-change",
+  "ada-code-change",
   "c-code-change",
   "css-code-change",
   "cpp-code-change",
@@ -1091,6 +1119,8 @@ product = [
   "vue-code-change",
   "vite-code-change",
   "python-code-change",
+  "php-code-change",
+  "pascal-code-change",
   "powershell-code-change",
   "shell-code-change",
   "rust-code-change",
@@ -1262,7 +1292,10 @@ library = [
   "astro-code-change",
   "axum-code-change",
   "babylon-code-change",
+  "threejs-code-change",
   "bun-code-change",
+  "deno-code-change",
+  "ada-code-change",
   "c-code-change",
   "css-code-change",
   "cpp-code-change",
@@ -1282,6 +1315,8 @@ library = [
   "vue-code-change",
   "vite-code-change",
   "python-code-change",
+  "php-code-change",
+  "pascal-code-change",
   "powershell-code-change",
   "shell-code-change",
   "rust-code-change",