mustflow 2.74.2 → 2.74.4

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: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: typescript-code-change
-description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, compiler-version behavior, TypeScript 6-to-7 migration surfaces, native preview tooling, type safety, or TypeScript tests are created or changed.
+description: Apply this skill when TypeScript source, declarations, tsconfig, package exports, module resolution, compiler-version behavior, TypeScript 6-to-7 migration surfaces, TypeScript 7 RC or nightly tooling, type safety, or TypeScript tests are created or changed.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -35,7 +35,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 TypeScript compiler major-version behavior, TypeScript 6 transition deprecations, TypeScript 7 native preview comparison, `@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 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 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.
 
@@ -52,7 +52,7 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 - Relevant `package.json`, `tsconfig*.json`, lockfile, build config, test config, and package entry files.
 - 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.
-- TypeScript compiler track and tooling entrypoint when relevant: `typescript` with `tsc`, a TypeScript 6 transition release, `@typescript/native-preview` with `tsgo`, framework typecheck wrappers, editor extension settings, and any compiler API consumers.
+- 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.
 - 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.
 
@@ -72,7 +72,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 TypeScript 6 `tsc` and TypeScript 7 native preview `tsgo` only as a bounded migration or diagnostics exercise when repository tooling explicitly supports both.
+- 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.
 - Do not weaken compiler, lint, module, package, or test boundaries to make the task appear complete.
 
 <!-- mustflow-section: procedure -->
@@ -95,10 +95,15 @@ Preserve TypeScript's type, runtime validation, module, build, and public API bo
 15. Inspect generated declarations when package surfaces change. Declaration files must not leak source-only aliases, private paths, workspace-only package names, unpublished internal paths, or accidental public re-exports.
 16. 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.
 17. 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.
-18. For TypeScript 7 native preview work, keep `typescript` and `@typescript/native-preview` separate in dependency, script, editor, and verification surfaces. `tsgo` can compare compiler behavior, but it is not a drop-in promise for compiler API users, language-service plugins, custom transformers, or framework wrappers unless those surfaces are proven compatible.
-19. When comparing `tsc` and `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.
-20. Do not treat faster native preview results as sufficient verification. Keep existing `tsc` or framework typecheck as the compatibility baseline until repository policy explicitly adopts the native compiler path.
-21. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, and downstream-style consumer risk.
+18. 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.
+19. 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.
+20. 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.
+21. 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.
+22. Choose the narrowest configured verification intents that cover typecheck, lint, tests, build output, declarations, package contract risk, and downstream-style consumer risk.
 
 <!-- mustflow-section: assertion-policy -->
 ## Assertion Policy
@@ -120,7 +125,7 @@ Rejected by default:
 - Implementation `@ts-ignore`.
 - Compiler setting downgrades such as disabling strictness, null checking, indexed access safety, or declaration checking to make the patch pass.
 - Treating TypeScript 6 deprecation suppression as a long-term fix.
-- Replacing stable `tsc` verification with `tsgo` preview verification without an explicit repository policy and compatibility evidence.
+- Replacing stable `tsc`, TS6 `tsc6`, or framework verification with TS7 RC or nightly verification without an explicit repository policy and compatibility evidence.
 
 <!-- mustflow-section: public-api-policy -->
 ## Public API Policy
@@ -148,8 +153,8 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - Package entry metadata changes without checking runtime entry, type entry, declaration output, and supported resolver modes.
 - `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.
-- Native preview output differences are accepted as harmless without classification.
-- Compiler API, transformer, language-service, or framework typecheck surfaces are moved to TypeScript 7 native preview without compatibility proof.
+- TS7 RC or nightly 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 -->
 ## Postconditions
@@ -159,7 +164,7 @@ Reject or revise the patch when any of these appear without explicit evidence an
 - Runtime exports, type exports, and declaration output agree.
 - Assertions are narrow, justified, and contained.
 - Any public API or module-system risk is reported.
-- TypeScript 6/7 migration, native preview, and compiler-entrypoint risks are classified when relevant.
+- TypeScript 6/7 migration, RC, nightly, stable, and compiler-entrypoint risks are classified when relevant.
 - No type-checking or test guard was weakened without an explicit user request and risk report.
 
 <!-- mustflow-section: verification -->
@@ -176,7 +181,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, TypeScript 6/7 comparison, native preview 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, latest supported TypeScript version, TS6/TS7 RC comparison, optional TS7 nightly comparison, ESM, CJS, and bundler-style resolution when those surfaces change.
 
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
@@ -185,8 +190,8 @@ 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 TypeScript 7 native preview disagrees with stable TypeScript, keep stable TypeScript as the compatibility baseline, classify the difference, and report whether it is a project bug, compiler-preview 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 migrate it to native preview unless the dependency explicitly supports that path.
+- 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 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.
 
 <!-- mustflow-section: output-format -->
@@ -196,7 +201,7 @@ Report whether configured verification exists for declaration output, package ar
 - Files changed
 - Type and module safety notes
 - Public API or declaration impact
-- Compiler-version or native-preview notes
+- Compiler-version, RC, nightly, or API-track notes
 - Command intents run
 - Skipped checks and reasons
 - Remaining TypeScript risk

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

@@ -2,7 +2,7 @@
 mustflow_doc: skill.unocss-code-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: unocss-code-change
@@ -56,7 +56,7 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 
 - Confirm extraction targets before adding utilities or moving class maps.
 - Identify whether the project uses default pipeline extraction, explicit `content.pipeline.include`, `@unocss-include`, safelist, or custom extractors.
-- Identify whether the project uses the classic preset stack, `presetWind4`, theme compatibility tokens, shortcut layers, variant groups, icons, attributify, directives, or framework-specific plugin order.
+- Identify whether the project uses the classic preset stack, `presetWind4`, theme compatibility tokens, shortcut layers, variant groups, icons, attributify, directives, reset packages, compatibility presets, or framework-specific plugin order.
 - Identify whether shortcuts, rules, variants, or safelist entries are design-system vocabulary or one-off hiding places.
 - If the config is unclear, do not introduce attributify, custom rules, custom variants, broad shortcuts, or broad safelists. Use plain `class` utilities with complete static strings.
 
@@ -82,7 +82,16 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 6. Keep safelists small, finite, named, and bounded by approved token lists and maximum generated count. Treat feature-local safelists over 50 classes, shared safelists over 200 classes, or total safelists over 300 classes as design/extraction failures unless explicitly justified.
 7. Do not generate safelists from whole theme objects, full color palettes, all shades, all spacing values, all breakpoints, or broad property and variant multiplication.
 8. Use token allowlists before writing shortcuts, rules, variants, or safelists. Do not use every theme key as an allowed product value.
-9. For Wind4 migration, verify preset choice, theme token migration, preflight ownership, variant behavior, and compatibility with existing Tailwind-like class vocabulary before changing utilities at call sites.
+9. For Wind4 migration, verify preset choice, theme token migration, reset ownership, variant behavior, and compatibility with existing Tailwind-like class vocabulary before changing utilities at call sites. Use a token rename matrix instead of vague "theme review":
+   - `fontFamily` -> `font`;
+   - `borderRadius` -> `radius`;
+   - `easing` -> `ease`;
+   - `breakpoints` -> `breakpoint`;
+   - `verticalBreakpoints` -> `verticalBreakpoint`;
+   - `boxShadow` -> `shadow`;
+   - size scale families that now share spacing -> `spacing`;
+   - `container.maxWidth` -> `containers.maxWidth`.
+   Also check duplicate resets from existing `@unocss/reset` or `normalize.css`, remove `presetRemToPx` when Wind4 covers the behavior internally, and do not combine `presetLegacyCompat` with Wind4 OKLCH color behavior.
 10. Use `extendTheme` or equivalent merge hooks when preserving existing theme tokens matters. Do not replace the whole theme object if the local config expects extension semantics.
 11. Add shortcuts only for repeated product primitives. Prefer static shortcuts when all combinations are known. Dynamic shortcuts must be anchored, token allowlisted, and free of broad catch-all groups.
 12. Do not use shortcuts as one-off wrappers for long class strings in a single screen.
@@ -131,7 +140,9 @@ Preserve UnoCSS extraction, preset, shortcut, rule, safelist, blocklist, variant
 <!-- mustflow-section: preset-icon-shadow-policy -->
 ## Preset, Icon, And Shadow DOM Policy
 
-- Wind4 migration must preserve theme tokens, preflight expectations, variant semantics, and generated CSS size before call-site cleanup.
+- Wind4 migration must preserve theme tokens, reset ownership, variant semantics, generated CSS size, and color behavior before call-site cleanup.
+- Wind4 includes Tailwind 4-style reset behavior. Existing `@unocss/reset` or `normalize.css` imports need duplicate-reset review.
+- Wind4 migration should remove obsolete `presetRemToPx` usage and avoid `presetLegacyCompat` when OKLCH color compatibility matters.
 - Icon utilities are production assets. Verify the chosen icon collections, loader ownership, package footprint, currentColor inheritance, accessibility label path, and whether dynamic icon names require a finite safelist.
 - Shadow DOM and web component styles need an explicit injection owner. Do not assume global utility CSS reaches closed or separately injected roots.
 - Framework plugin order is part of extraction. Svelte, Vue, Astro, MDX, transformers, variant-group handling, and attributify can change whether the token exists before UnoCSS scans it.
@@ -158,7 +169,7 @@ Reject the change when:
 - Custom variants accept arbitrary selectors or themes.
 - Blocklist removes utilities without an actionable developer-facing signal.
 - JSX/TSX attributify lacks prefix, transformer, or type support.
-- Wind4 migration replaces theme or preflight behavior without compatibility review.
+- Wind4 migration replaces theme, reset, color, or preflight behavior without compatibility review.
 - Icon utilities accept unbounded runtime icon names.
 - Shadow DOM utility usage has no style injection owner.
 

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: 6
+revision: 7
 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+ standard-library APIs, runtime flags, changed default behavior, security defaults, or examples that depend on `requires-python`.
-- TypeScript wording mentions current/stable/beta/native preview status for TypeScript 6, TypeScript 7, `@typescript/native-preview`, `tsgo`, compiler API compatibility, or migration readiness.
+- 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.
 - 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, or examples that depend on a specific Go 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.
 - HTTP delivery wording mentions current support, baseline status, default behavior, standard status, or compatibility for zstd content coding, compression dictionary transport, SSE/EventSource, WebTransport, WebSocket fallback, HTTP/2, HTTP/3, QUIC, CDN behavior, proxy buffering, or browser transport APIs.
@@ -96,12 +96,12 @@ Prevent agents from writing stale external version references from memory, while
 12. For framework and runtime majors such as Astro, Tauri, Electron, Next, SvelteKit, Node, Bun, Deno, Python, Rust, or Java, check migration notes, config schema, plugin and adapter compatibility, generated files, security model, deployment target, and rollback path before recommending a major change.
 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 version-gated features such as Python 3.14+ `map(strict=True)`, `functools.Placeholder`, `heapq` max-heap helpers, import-timing flag behavior, 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 TypeScript 6 and 7 claims, refresh official TypeScript sources before writing durable wording. Treat TypeScript 6 stable releases, TypeScript 7 native preview or beta packages, `@typescript/native-preview`, `tsgo`, and future stable `typescript` package behavior as distinct tracks. Do not call native preview output "latest stable TypeScript" just because it is newer.
-16. For TypeScript native-preview examples, make the selected track explicit: side-by-side comparison, beta testing, editor preview, or repository adoption. If the project has compiler API consumers, transformers, framework wrappers, or declaration snapshots, classify the reference as migration-sensitive.
+15. 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.
+16. 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.
 17. 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`, `errors.AsType`, `sync.WaitGroup.Go`, `testing/synctest`, `testing.B.Loop`, `os.Root`, `os.OpenInRoot`, `omitzero`, `go.mod` `tool`, `ReverseProxy.Rewrite`, container-aware `GOMAXPROCS`, goroutine leak profiles, `encoding/json/v2`, or `GOEXPERIMENT` APIs.
 18. For Go examples that use newer standard-library APIs or runtime defaults, either keep the example behind an explicit Go version floor or provide a supported fallback. Do not call an experimental `GOEXPERIMENT` feature or a newer `go` directive behavior a general Go best practice when the repository declares lower support.
 19. For Rust release, toolchain, standard-library, Cargo, edition, lint, target, or MSRV claims, refresh official Rust release notes, standard-library docs, the Cargo Book, Rust Reference, or rustc book before writing durable wording. Check `rust-version`, edition, `rust-toolchain.toml`, CI toolchain matrix, target triples, docs.rs metadata, and crate publish policy before using or recommending version-gated features such as let chains, match `if let` guards, `cfg_select!`, `assert_matches!`, `core::range`, `Vec::push_mut`, `HashMap::get_disjoint_mut`, `Option::take_if`, `LazyLock`, `OnceLock`, `workspace.lints`, `resolver = "2"`, Rust 2024 `unsafe_op_in_unsafe_fn`, or release-profile defaults.
-20. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Do not call a Rust 1.95+ or 1.96+ API a general Rust best practice when the repository declares a lower MSRV, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
+20. For Rust examples that use newer language or standard-library APIs, either keep the example behind an explicit Rust version floor or provide a supported fallback. Use an API-by-API MSRV ledger for features such as `cfg_select!`, match `if let` guards, `core::range` items, `Vec::push_mut`, `assert_matches!`, and `debug_assert_matches!`; do not collapse them into a single "latest Rust" bucket, and do not treat nightly-only behavior or target-specific linker behavior as stable without explicit evidence.
 21. For HTTP standards, browser APIs, proxy defaults, CDN defaults, and transport support claims, prefer official RFCs, standards bodies, MDN or browser vendor docs, and vendor-owned proxy/CDN documentation. Keep WebTransport, compression dictionary transport, zstd content coding, SSE/EventSource, HTTP/2, HTTP/3, QUIC, and proxy-buffering claims track-specific and dated when support is changing.
 22. For HTTP delivery examples that depend on newer or unevenly supported behavior, require feature detection, fallback behavior, or explicit deployment constraints. Do not present WebTransport, dictionary compression, or zstd negotiation as a universal default when the project still needs browsers, proxies, CDNs, or networks that may not support it.
 23. For Docker images, decide whether the project prefers semver tags, distro tags, LTS tags, date tags, or digests. Do not replace a digest or pinned base image with a floating tag unless the repository policy says so.
@@ -116,9 +116,9 @@ Prevent agents from writing stale external version references from memory, while
 - Repository-pinned versions are preserved unless the task, policy, and compatibility classification support changing them.
 - 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.
-- TypeScript 6 stable, TypeScript 7 beta/native-preview, and future stable TypeScript tracks are not collapsed into one generic "latest TypeScript" claim.
+- 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.
 - Go release, `go.mod` language version, standard-library API, runtime-default, and `GOEXPERIMENT` claims match the declared Go support matrix or name the required runtime 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 runtime 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.
 - HTTP standard, browser-support, proxy-default, CDN-default, and transport-support claims are not written from stale memory and keep feature detection or fallback boundaries explicit where support varies.
 - Docs and examples do not make unverifiable current-version claims.
 
@@ -144,7 +144,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 native preview freshness changes during the task, update wording to a dated or track-specific claim and keep repository adoption separate from preview comparison.
+- 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 Go 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, CI support, and `GOEXPERIMENT` 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.
 - If HTTP delivery support changes during the task, update wording to a dated or track-specific claim and keep standards, browser support, CDN behavior, proxy defaults, and repository adoption separate.

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.74.2"
+version = "2.74.4"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"