📖About

Build a new app, the Service Track Handbook, following the same format and rendering conventions as the existing Agent Handbook (agent-handbook) and App Handbook (app-handbook) apps, but focused on ONE question per entry: how can this service track be re-used for any client project. One entry per service track of every live Carol service. Each entry must state, from reading the service's ACTUAL droids and code (verify by doing, never from records alone): (a) the reuse level — usable as-is / config-only / needs seam refactor / estate-bound; (b) the constraints — every hard-coded fact (paths, repos, schedules, data stores, credentials, identities) and every piece of estate glue (run-audit wiring, registry address, crontab identity) that binds the track to the Carol estate today; (c) the exact configuration changes required to instantiate it for a new project under the standing instantiation ruling (design #557, policy P.01.03.07.08: one shared codebase, dedicated per-project deployment at a pinned version, custom behaviour only through configuration and declared extension points); and (d) explicit step-by-step reuse instructions a project enablement flow can follow. The handbook is the SST for reuse constraints: live-from-source where facts already have a home (cite the registry, never copy it). Register the app with an owner and both access policies (agents + humans) per the two-audience access law.

⚖️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] 5 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (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)
• [delivery-check] 5 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• Arc sequencing: phase 1 (foundation), step 1/2 — Service Track Handbook: all 41 tracks graded — Sequence: PHASE 1 of 5 (Foundation — the seam and the record that grades it), position 1 of 2. First in the phase. no predecessor — this phase opens the arc Why this phase: Nothing else in the arc can be graded or built until the instance-config seam exists and every track carries an assessed reuse level. (orion)
• [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 Service Track Handbook app exists, is registered in the registry with a named owner agent and both access policies (agents and humans), and renders in the same format family as the Agent Handbook and App Handbook apps. (must_have)
• Every service track of every live (non-merged) Carol service has a handbook entry; no entry is a stub. (must_have)
• Each entry states the reuse level, the constraints found by reading the service's actual droids and code, the configuration changes required for a new project, and explicit step-by-step reuse instructions. (must_have)
• Facts that already live in the registry or another SST are cited live, never duplicated into handbook prose. (must_have)
• A reader following one entry can either instantiate the track for a new project or is told precisely which refactor initiative must land first. (must_have)