mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-09 18:06:45 +08:00
c7f259c70a
The `triage` status key was reserved so the server could read `status = 'triage'` as "in Triage": migration 475 added a CHECK against it, 476 renamed any pre-existing custom `triage` status (and the issues and saved views pointing at it), and issuestatus refused the key on every write path. Migration 483 then moved Triage onto issue.triage_state, and nothing reads the status that way any more. What is left is a rewrite of live customer data in the deploy path that buys nothing, plus a name the product does not need to own — users see a status's display name, not its key, so reserving the key never stopped anyone from calling a custom status "Triage". 475-477 are emptied rather than reverted with a new migration: they have never run outside development and CI, because releases deploy from tags and the newest tag predates them. Migration 486 drops the constraint on databases that did migrate off main, which would otherwise refuse a key the server now accepts; 476's rename is not reversed, since the replacement is an ordinary custom key by then. 478 loses the matching `triage` fast-path entry, where the key falls through to the same answer either way. The Go side goes with it: the Triage constant, ErrReservedStatus, the Resolve refusal, IsBuiltIn's extra name, ErrStatusReservedForTriage and its two handler mappings, the leading Triage rank in the issue sort, and the CLI and docs lines that told users the key was reserved. Every triage_state path is untouched. Tests now pin the reverted behavior: the emptied migrations leave a workspace's custom `triage` status, issues and saved views exactly as they were, 486 drops the barrier on a database that already has it, and `triage` works end to end as an ordinary custom status key. Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>