📖About

Refactor the System Services service (system-services) toward the instantiation seam of the standing ruling (design #557, policy P.01.03.07.08) so it can be re-used by any client project with zero code copies. Scope: (1) inventory every hard-coded project/estate fact in the service's droids and apps — source paths, destination repos and branches, schedules, data stores, credentials, retention rules — and move each into per-instance configuration with the estate's current values as the default instance; (2) make the estate glue injectable — droid identity, run-audit store, registry address — so a project instance runs the same code under its own identities on its own workspace; (3) declare the service's extension points; (4) update the service's Service Track Handbook entry FIRST with the constraints found, and again at the end with the achieved reuse level, so the handbook documents constraints before and after. The handbook initiative filed in the same arc (topic tag service-reusability) is the prerequisite: constraints are documented there before this refactor closes. End state: enabling this service for a project can deploy a dedicated instance at a pinned version where all project-specific behaviour is configuration, and anything the seam cannot express is a named, documented gap.

⚖️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)
• Arc sequencing: phase 4 (operations-plane), step 1/4 — System Services — Sequence: PHASE 4 of 5 (Operations plane, re-pointed onto the kernel), position 1 of 4. First in the phase. phase 3 must be complete first Why this phase: The estate's own care-of-the-fleet tracks. They become instantiable only once a project has its own kernel to be cared for. (orion)
• [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

• An inventory of every hard-coded project/estate fact in the System Services service's droids and apps exists on the record, and each fact is either moved to per-instance configuration or documented in the handbook entry as a named constraint with a reason. (must_have)
• The estate's own deployment runs as the default instance of the refactored code with no behaviour change, proven by the service's existing checks or a before/after run comparison. (must_have)
• Estate glue (droid identity, run-audit store, registry address) is injectable per instance; a second instance cannot write to estate stores by construction. (must_have)
• The service's Service Track Handbook entry documents the constraints before the refactor and the achieved reuse level after it. (must_have)
• A config-only second instance is stood up in a sandbox as proof, or the precise blockers preventing one are named in the handbook entry as the remaining gaps. (must_have)