Skip to content

ADR-004

Title

The MMDEP orchestrator is the coordination implementation of TEM

Status

Proposed (draft by Claude Code from Atul's decision of 2026-10-03; to be reviewed through the MMDEP merge request workflow)

Context

The Technology Estate Manager (TEM) issues in this repository (#11, #17–#23, #26, #27) describe a planned implementation that registers projects, agents, roles and assignments, and runs bounded agent work loops, handovers and MCP connectivity.

Separately, a local orchestrator, the "MMDEP orchestrator", has been built and used since September 2026, with its own spec (docs/spec/000-orchestrator-design.md in its repository). It already answers several TEM Phase 1 questions with working code and tests: the registry and role map (#18), local MCP reachability (#19), dispatch (#20), the bounded work loop (#21), and the task → change → approval → merge slice (#23).

ADR-002 says implementation must not live in this governance repository.

Decision

  1. The MMDEP orchestrator is TEM's coordination implementation. It covers tasks, human items (approvals, questions, inputs, manual steps), approvals, dispatch, isolated workspaces, the ledger, role maps, cross-project task impact, and messages between agents.
  2. Its code stays in its own repository (currently GitHub moneymarche-dev/MMDEP; see ADR-005). It does not move into this repository (ADR-002).
  3. Governance stays here: standards, ADRs, the decision register, the Portfolio Register, the estate register, estate reports, and the TEM issues.
  4. Truth is split by kind and linked, not copied:
  5. a repository holds content: code, specs, project decisions, committed handovers;
  6. the orchestrator holds coordination: tasks, items, approvals, the ledger, roles.
  7. Each links to the other.
  8. The orchestrator is a facilitator, not a regulator. It offers model processes that evolve from project experience, and prefers existing GitLab and GitHub features to its own code.
  9. TEM-Evidence stays separate. The estate collectors, evidence packs and the estate dashboard share vocabulary with the orchestrator, not its runtime.

Alternatives

  • A separate TEM implementation repository, built from scratch. Rejected: it would duplicate working, tested coordination code.
  • Keep the orchestrator as an unrelated local tool. Rejected: two coordination systems would split the programme's records.
  • Move the orchestrator's code into this governance repository. Rejected by ADR-002.

Consequences

Positive

  • TEM Phase 1 builds on evidence instead of a fresh design.
  • One coordination record (inbox, approvals, ledger) across projects.

Responsibilities

  • The TEM issues are linked to the orchestrator spec sections that answer them; new TEM requirements are raised here and implemented there.
  • Material changes to the orchestrator's role in the programme need a new ADR here.
  • The orchestrator's registrations reference the Portfolio Register (see the decision register entry for registries); it never redefines a product.
  • "MMDEP orchestrator" and "MMDEP governance repo" are always written out in full where both could be meant.

Cross-project dependencies

  • Declared product dependencies stay in the Portfolio Register here (ADR-002). The orchestrator holds only execution-level impact links, and they point to the register entry (accepted by Atul in orchestrator item #59).