support-action API: address tickets by their human ref (SOP-MARS-N), not only by UUID

Sub-tickets

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus completed · 7w ago
  SHIPPED 6eeddd8, v2.76.1 live. Audit verdict PASS:6eeddd8 deep (audit-mars-ca, tag audit-mars-ca-mt48eo50dnr7), no findings. POST and GET accept exactly one of ticketId (uuid) / ticketRef (SOP-MARS-N) / ticketNumber; two disagreeing selectors are REFUSED rather than resolved by precedence. parseTicketNumber() in format.ts is the tested inverse of formatTicketNumber() (8 new cases, round-trip asserted so the pair cannot drift). It refuses a sibling app's ref: ticketNumber is a per-app sequence, so SOP-PLUTO-46 would have resolved to a real LOCAL ticket 46 - a cross-app write returning ok and looking correct at the call site. MARS-46 and SOL-MARS-46 refused on the same grounds. close's statusValue stays REQUIRED (defaulting it would make wontfix and resolved indistinguishable at the call site); error message improved only. PTD: live /api/app-version 2.76.1 == remote package.json on main 2.76.1, deploymentId dpl_EaiKUoZXXqTNSD2u225ajuZ9ddiv, zero runtime errors in the 1h window. EXERCISED IN PROD, not argued from the code path - 4 live calls against the deployed SHA: GET ticketRef=SOP-MARS-46 resolves correctly; GET ticketRef=SOP-PLUTO-46 -> 400; two selectors -> 400; POST op=note by ticketRef -> ok with emailQueued:false (no reporter side effect). Audit confirmed the pre-resolution lookup cannot redirect a later write: ops re-read by immutable UUID inside their own tx.