📖About

Ninad ruling (2026-08-14, CLI-252): Sam (agt_026, Customer Support) works like a diligent support executive. Every user complaint becomes a TICKET carrying: the user (a registry person), the issues, the root causes, the proposed resolutions with their own statuses, the ticket status, and progress in cost and duration. Sam communicates proactively: continuous INFORMAL updates in his chat with the user, and FORMAL milestone updates by email.

Scope, on the agent-centric modular architecture (thin shim, one composer, registry-central data): 1. Ticket store in the REGISTRY (support_tickets, ticket_resolutions, ticket_updates) behind ONE composer module — the app, the steward and Sam's chat all read/write through it; duration and cost derive from the record, never typed. 2. Sam Support app (owner agt_026) on the pattern-library build path (work-tracker pattern), registered with owner + access policy per the mandatory rule, showing tickets, root causes, resolutions, statuses, cost and duration. 3. Ticket Steward droid (Sam's) — scheduled daily: sends milestone emails on status changes via the estate mailbox under Sam's name, posts informal chat updates into the user's own conversation, nudges stale tickets; emits run-audit on every run; template-based composition so the steward works even when the support track's LLM lane is off. 4. A defined budgeted task on the support service's own track (support-core) per the admission rule — the activity decides the track. 5. Regression tests; handbook metric definitions for every displayed number.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 6 pending must-have criteria stamped met at bypass_end on live re-performance evidence (CAROL-INI-3020): test test_ini3825.py: PASS (4 passed in 1.10s) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• A registry-backed ticket store behind one composer holds tickets with user (registry person), issues, root causes, resolutions with their own statuses, ticket status, and derived cost and duration (must_have)
• A live app owned by Sam (agt_026) on the work-tracker pattern shows the ticket list and full detail, registered with owner + access policy and reachable through its route (must_have)
• Sam's Ticket Steward droid is registered with a durable daily trigger and run-audit, sends formal milestone emails under Sam's name on status changes, and posts informal chat updates into the user's conversation (must_have)
• Ticket operations are a defined budgeted task on the support service's own track, admitted without cap expansion (must_have)
• The steward's composition is template-based so ticket communication works even when the support track's LLM lane is switched off (must_have)
• Regression tests prove: ticket lifecycle through the composer, derived duration/cost, steward milestone detection, and app registration with owner/policy/pattern (must_have)