mustflow 2.115.5 → 2.115.9

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.5"
+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",