v6.13.1

Patch release: fixes two defects in upgrading an existing project with uds update that 6.13.0 exposed (a zh-TW commit-language section turned English; AGENTS.md rewritten into a different format without its index reminder), and adds a pre-release gate that performs a real upgrade from the previous stable release. If you already ran uds update to 6.13.0, run uds update again after upgrading to 6.13.1 to restore those sections.

Added

• scripts/check-upgrade-fidelity.sh, wired into pre-release-check.sh as step 24: a real cross-version uds update upgrade check, run before every release. The two regressions fixed above both share the same shape — they only fire when an EXISTING project, already updated by the previous stable release, runs uds update/uds update --apply against a NEWER version — and pre-release-check.sh's other 31 steps, and CI, all missed both, because none of them perform a real cross-version upgrade: uds init runs fresh (nothing to regress against), and uds update against a bundled registry version equal to the manifest's already-recorded version returns early before ever reaching the code that broke. This check builds three project shapes (matching the three real adopters that hit these bugs) with a REAL, published previous stable release fetched from npm, upgrades each with the CLI under test via both a plain uds update -y and uds update --apply, and asserts: content outside the UDS marker block never changes; content inside it changes only by the standards list/count a real upgrade is allowed to add; the commit-message-language heading (CLAUDE.md) is byte-identical, not merely present; the "this is just an index" reminder is present; uds update -y and uds update --apply agree on which generator produced a file; and a second --apply immediately after a first changes nothing. Fails loudly (exit 2, not a skip) if npm is unreachable or the previous version was never published — this check's entire value is exercising a real release, and silently passing without one would reopen exactly the blind spot it exists to close. Verified both ways: --cli="npx -y universal-dev-standards@6.13.0" reproduces both regressions above (the CLAUDE.md language flip and the AGENTS.md generator flip), with the actual diff printed; the local dev CLI (commits e1524872 + 8373207d applied) passes clean on all three shapes.

Fixed

• A plain uds update -y (not --apply) silently replaced a project's Traditional Chinese CLAUDE.md commit-message heading with the English one, and could report a --plan --integrations-only dry-run diff that ignored the project's display language. updateCommand's main flow and its --plan dry-run each independently derived the integration block's content language from output_language/commit_language alone (the commit-message language), ignoring display_language (the setting uds init and the reconciler have always used for "what language do you want to read"). A project installed with display_language: zh-tw and output_language: bilingual — a common combination — therefore got the correct ## 提交訊息語言 heading from init, and ## Commit Message Language from the next plain uds update, discarding a language choice that was already correct. Measured against two real adopters (asiaostrich-telemetry-server, EngramGraph) upgrading 6.12.0 → 6.13.0. The bug predates 6.13.0 (present since 2026-03-25, commit ad555d41) and was invisible whenever uds update ran against an already-current project, since it returns early before reaching this code in that case — it only ever surfaced on a real version bump, which is why it looked like a new regression. buildToolIntegrationConfig (used by --apply/the reconciler) already had the correct derivation, added 2026-09-16; both remaining call sites now share it via the new resolveIntegrationLanguage(manifest). A regression test reproduces the exact defect against a real temp project and the real generator (no mocking), and a static guard fails if the old inline derivation reappears anywhere in the CLI source.
• uds update --apply (the reconciler) rewrote a project's AGENTS.md into a completely different, opencode-shaped document the moment generateAgentsMd had ever written one — even on the very first --apply immediately after a fresh uds init, with nothing else changed. desired-state-calculator.js's calculateIntegrations resolved any manifest.integrations entry named AGENTS.md to the opencode tool via resolveToolKey, regardless of whether opencode (or its alias codex) was an actually-selected AI tool — uds init always records AGENTS.md there once the universal summary is written (a tracking marker, not a record of a tool choice), so every project with generateAgentsMd: true and no codex/opencode selected was affected. Per the generator's own design note (added 2026-08-20): the per-tool template is meant to replace the universal summary only when codex or opencode is genuinely selected. Confirmed on three real projects (asiaostrich-telemetry-server, EngramGraph, dev-platform's own .standards/), all with aiTools containing no codex/opencode entry. calculateIntegrations (and plan-executor.js's executeMigrateBlock) now check whether the tool is genuinely selected and, when it is not, generate through the SAME writeAgentsMdSummary a plain uds update already used — --apply and a plain uds update now agree. New regression tests drive the real uds init/uds update (no mocking); confirmed red against the reverted fix, including a second---apply idempotency check that caught a follow-on non-convergent-hash bug introduced while building the fix (see the next entry).
• The universal AGENTS.md summary's "this file is an index, not the standards" reminder (added 2026-08-18) never reached an existing project's managed block — only its fixed header, which a marker-based update never regenerates for a file that already exists. writeAgentsMdSummary only ever replaces the content BETWEEN the <!-- UDS:STANDARDS:START/END --> markers for a file that already exists; the reminder lived in the header, outside them. Measured against two real adopters (asiaostrich-telemetry-server, EngramGraph): the reminder was present in neither the file header nor the block, on either side of a real update. The reminder now also lives inside the marker block (worded identically to the per-tool generator's own disclosure, generateIndexDisclosure — not a third phrasing), so every project receives it on its next uds update/--apply, new file or existing. Building this block through the same wrapWithMarkers helper the per-tool generator already used (rather than hand-writing the marker lines) also fixed a related gap found while adding it: a brand-new AGENTS.md never carried the "DO NOT manually edit" warning comment either, since only the merge path used to add it.

Compare: v6.13.0...v6.13.1