[Auto-Detected][P1] PR #589 targets master but is a 9.13.1-based legacy branch (conflicting, would downgrade trunk) #590

Finding

• Files: whole PR (441 files differ from master; package.json, manifest.json, versions.json, .github/workflows/release.yml, packages/calendar, src/**)
• Persona: Regression Skeptic / Architecture Judge — P1
• PR Legacy/9.13.1 #589 has base master but head branch legacy/9.13.1 is cut from the 9.13.1 tag (merge-base 7d8e83b); master is 44 commits ahead at 9.14.0-beta.6. GitHub reports mergeable: CONFLICTING / DIRTY. git diff origin/master HEAD = 441 files, +18310/−40378. The PR's own RELEASING.zh-CN.md says the merge target is legacy/9.13.1, so the base looks wrong.
• Impact if forced through: master is downgraded to 9.13.2 (package.json 9.14.0-beta.6 -> 9.13.2, versions.json entries for 9.14.0-beta.x lost), 9.14 features removed, and release.yml (deleted on master in c065ed6 "remove tag-triggered Release workflow") is resurrected, re-enabling tag-triggered releases.

Linked PR: #589

Root Cause Analysis

• DevOps: CI on this PR targets master; ci.yml adds legacy/** triggers, but there is no branch protection signal preventing a PR from a stale-tag branch from targeting master. Resurrected release.yml would publish artifacts on any tag push.
• Engineering: Wrong baseRefName on PR creation (fork-local PR Add authoer information #2 merged into the fork's legacy/9.13.1, then the same branch was opened upstream against master). Commit list: "fix(legacy)…" + "Merge PR Add authoer information #2…".
• Architecture: A maintenance line diverged from a release tag should live on its own long-lived branch; it must not be proposed against the development trunk.

Recommended Resolution

Close or retarget PR #589 to a dedicated legacy/9.13.1 branch (maintainer-created) — do not merge into master. If any fix is wanted on trunk (settings i18n, blank-task cleanup, settings-invalidation signature), re-submit as small PRs rebased on current master, without version/manifest/release workflow/CI changes.