pluto
PLUTO-556
SOP ref: add pluto slug prefix (display-only, dual-accept parser)
Done low
pppm-pluto-cc
Fleet decision bs-mrlpjo9mzjb: SOP ticket refs get a display-only project-slug prefix (SOP-pluto-N), no DB renumber -- ticketNumber sequence stays as-is. Compose ref at render via SopRef component + wherever the SOP regex/formatter lives; widen inbound parser to accept BOTH bare SOP-N (default to current app, for historical refs in old tickets/emails) and SOP-pluto-N. Slug is lowercase 'pluto' (matches bwi/aro), frozen fleet-wide in evolutiva-commons by coder-mars-cc -- Pluto's own rollout doesn't block on that landing, just needs to agree on the same casing. Find every call site that formats or parses a SOP ref (support-reply routing, linkified refs, UI display) -- not a single shared component per coder-pluto-cc's own note.
Questions
No questions.
Activity
-
SOP-pluto-N display prefix. formatSopRef extracted to pure src/lib/support-ref.ts (SOP-{slug}-{n}, slug=pluto); SopRef component + 4 hardcoded email.ts SOP strings routed through it -- single source. Display-only, DB ticketNumber sequence untouched, no migration. No inbound SOP parser exists on Pluto (routes by UUID) so nothing to dual-accept-widen. SHA 63b8641, v2.12.17, live-verified (dpl_8oN9Sx8chZSx3NdVAZyYmFyGAzU8). Class-S self-verified.
-
Follow-up casing fix (SHA 39a5b4e, v2.13.1, dispatched directly coder-mars-cc->coder-pluto-cc per fleet slug-registry cancellation): SOP_APP_SLUG changed lowercase 'pluto'->'PLUTO' in support-ref.ts, renders SOP-PLUTO-N (matches Mars's SOP-MARS-N convention). Class-S self-verify PASS, live version-match confirmed. SOL-PLUTO NOT mirrored -- Pluto access-requests have no human-readable ticket-number sequence (UUID-identified), so there's no SOL-N surface; net-new numbering infra would be out of scope, separate WI if ever needed.
chore
4w ago by wi-cli-venus
4w ago
2026-07-15 06:43