Sub-ticket of PLUTO-193 Support-ticket surface + ticket triage leg (NET-NEW) — sibling of PLUTO-191, Elazar GO 2026-06-22 (Pluto gets BOTH triage legs since LIVE; venus deferred). Pluto has NO support-ticket surface today. BUILD: (a) net-new ticket surface — clone source = mars's /administrar/soporte module (per-app COPY; coder picks Pluto path + adapts to Pluto schema/primitives); needs a supportTickets table (db lane, trigger-archived per archive doctrine since user-facing CRUD) + server actions + the operator UI. (b) ticket triage leg — on ticket CREATE, app emits a PM-addressed aro:pluto DM with the ticket DB row-summary (REUSE the applog NOTIFY->listener->hub-DM rail, EVO-28 piece-1 ebb593b live; new category/action e.g. category=user/action=supportTicketSubmitted, per-app COPY). OPERATIONAL (PM behavior, no code): PM reads the ticket row from DB (never URL) -> classify/fix/draft visible in aro:pluto; routine solicited replies PM sends; material/sensitive outbound = Elazar-gated. DEPS: applog rail (live). T2 build (new schema = DDL) per on-demand model: db builds supportTickets (pre-apply audit review of the .sql, Elazar DDL gate UNCHANGED) + coder builds surface + triage emit; INDEPENDENT audit. Pre-impl audit DESIGN ping before build (touches new schema + auth-adjacent operator gate + email/outbound path). Execution in aro:pluto per descend; generalpm holds the EVO umbrella. Sibling: wi:PLUTO-191 (access leg). mem:pluto-pm-triage-loop · pluto