📖About

Ninad ruling (2026-08-15, CLI-262): a user talking to an agent gets the SAME experience irrespective of channel - WhatsApp or web. Recorded as a DESIGN POLICY and implemented uniformly. The prompt stack is defined once per agent: (1) engine layer - registry persona + Mind + doctrine + grounding (the one engine, 3872); (2) the agent's own BRIEF (one source per agent, e.g. Carol's prompt_all.md); (3) the tier overlay for the caller's category; (4) the per-person layer (prompt written for them + the agent's memory of them); (5) channel constraints - the ONLY channel-specific layer (WhatsApp prose-only per the Meta classifier rule; web window features). Carol WhatsApp joins the one engine at the COMPOSER seam this slice: her turns carry the engine's persona+Mind layer plus her canonical builder stack, and her web door carries the same builder stack - one composer per layer, channel bits ride the channel layer only. Her tool loop and metered lane stay as door config until the lane runtime loop (3873) formalizes full turn convergence. Prior art bare: 3872, 3875, 3871, 1301, 1302.

⚖️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)
• [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 design policy on record: an agent's experience (prompt stack, features, memory of the person) is channel-invariant; only the channel-constraints layer may differ per channel; every agent chat door and channel handler implements the same five-layer stack (must_have)
• Carol WhatsApp turns carry the engine's persona+Mind layer (the same layer web turns carry) composed with her canonical builder stack - proven by a test that composes both channels for the same sender and asserts the shared layers are identical (must_have)
• Carol's web door carries her BRIEF and tier and person-memory layers (her canonical builder), so web and WhatsApp read from the same sources - no second copy of any layer (must_have)
• WhatsApp channel constraints preserved: prose-only outbound, her metered lane and billing tickets unchanged (must_have)
• The design register and cookbook record the five-layer stack and its one-source-per-layer rule (must_have)