MoneyMarche (GitLab) legacy review: first pass¶
What this is¶
This is a read-only classification of the documents and issues in the MoneyMarche GitLab repository. Each item is marked now, later or obsolete, twice: once for this orchestrator (MMDEP-local, the repo you're reading) and once for the TEM decision.
In GitLab, TEM means the Technology Estate Manager (issues #11, #17–#23, #26, #27). It is a planned implementation that registers projects, agents, roles and assignments, and runs bounded agent work-loops, handovers, MCP connectivity and estate-evidence collection. TEA is the Technology Estate Audit workstream, which TEM supports.
The TEM decision, as I read it: how this local orchestrator relates to TEM. - Is it TEM's implementation? - A feasibility proof-of-concept for TEM Phase 1? - Or a separate tool?
Nothing in GitLab mentions this local orchestrator.
Every command I ran (read-only): ls/find/cat on the working tree; git status, git log, git branch -r; git fetch, which failed with HTTP Basic: Access denied and changed nothing; glab auth status; glab issue list --all; and glab issue view for 11, 16–23, 26 and 27, with --comments for 11, 17 and 23. I also extracted the text of the three .docx files with Python's zipfile. Nothing was written in C:\Projects\MoneyMarche or in GitLab.
Headline findings¶
- The same name means two things. In GitLab, "MMDEP" (Money Marche Digital Engineering Program) is the governance repository: standards, ADRs, requirements, research (ADR-002). Here, "MMDEP" is an orchestrator. The two share no code or history. Anyone reading "MMDEP item #12" or "MMDEP ledger" in one world will misread it in the other.
- TEM Phase 1 asks questions this orchestrator already answers with evidence.
| TEM issue | Question | What exists here |
|---|---|---|
| #18 | Registry model: project/agent/role/assignment, handover protocol | agents.yaml registry + role map + items as the handover envelope (stories 2, 4, iteration 1) |
| #19 | Local MCP reachability from Claude/ChatGPT | Proven for Claude desktop and Claude Code over local stdio; the stdin hang was found and fixed (#12, test in tests/test_mcp_stdio.py) |
| #20 | Pull/push to agents | Pull only: people pull items via MCP/CLI; agents are dispatched by mmdep run. No push into a desktop app |
| #21 | Bounded work-loop: start, state, limit, timeout, duplicates, interrupt, recovery | Parking, 3-attempt limit, slot timeout and recovery, item-only release (iteration 1). Iteration 2 adds the wall-clock timeout, kill switch and idempotency key (stories 3, 6, 8), almost exactly #21's list |
| #22 | Local model evaluation harness | Live DeepSeek runs and the ledger (#16 rejected: broken output); backlog "agent evaluation loop"; legacy/benchmark_harness.py |
| #23 | Vertical slice task → change → tests → CI → deploy → runtime → evidence | Task → change → approval → merge is done. Tests are iteration 2 story 5. CI, deploy and runtime are not covered |
| #26/#27 | Deterministic estate collectors, pre- and postflight evidence | Not covered; different domain (servers, AWS) |
- The TEM evidence vocabulary is worth adopting later. It uses VERIFIED / OBSERVED / INFERRED / PROPOSED / UNKNOWN / CONFLICTING / STALE, with source, collector, time and freshness per fact (#11). It maps onto our assumptions register and ledger detail.
- Platform decisions already made there apply here.
- GitLab.com is the engineering platform (ADR-001, Accepted).
mainis protected and changes go through merge requests (Repository and Delivery Standard).- These fit spec 0.3's long-term enforcement ("protected
mainon the server"). - Its branch prefixes (
feature/,fix/,docs/, …) differ from ours (iter-NN/…). - CI compute quota is exhausted for September 2026 on the GitLab MMDEP repo (#11), and Release-C waits for CI capacity (#16). This is the reason for the self-hosted runner request (separate manual item).
- The standards match our rules: no secrets in repos, no personal data in handoffs, "chat history is not a record". These back iteration 2 story 7 (redaction) and the status-in-iteration-file rule.
Classification: documents¶
"Orch" = this orchestrator; "TEM" = the TEM decision.
| Document | Orch | TEM | Note |
|---|---|---|---|
readme.md |
later | now | Defines GitLab MMDEP as governance only. Behind the naming collision |
adr/ADR-001-GitLab.md |
now | now | GitLab.com is the platform, which settles "where repos live" for GitLab origins (backlog) |
adr/ADR-002-MMDEP-Portfolio-Governance.md |
now | now | Implementation must not live in the governance repo; TEM gets its own repo (#11) |
adr/ADR-003-React-First-WordPress-API-Boundary.md |
obsolete | obsolete | Website product decision |
06-Decisions/Decision-Register.md |
later | later | Pattern for an ADR index; ours has none yet |
01-Project/Portfolio-Register.md |
later | now | Project list: candidates for MMDEP-local projects after billing (webapp, api, mm-crons, portfolio-engine on GitHub) |
01-Project/AI-Session-Coordination.md |
now | now | Handoff fields; matches the status-section rule and item bodies |
01-Project/Cross-Project-Triage-Brief.md |
later | now | Triage format "Fact → Affected → Implication → Action → Constraints → candidate" |
01-Project/Portfolio-Engine-External-Source-Reference-Index.md |
obsolete | later | Portfolio Engine product; relevant to TEM only as a dependency |
02-Requirements/01–07-*.md (7 files) |
obsolete | obsolete | Website Phase 1 product requirements |
02-Requirements/Mutual_Fund_Data_API_Integration_Spec_v1.docx |
obsolete | later | Legacy API evidence; TEM estate input |
03-Architecture/Portfolio-Architecture-Principles.md |
later | later | Product independence; "shared component only on demonstrated need" matches principle 7 |
03-Architecture/Product-Catalogue-and-Variant-Model.md |
obsolete | obsolete | Website domain model |
03-Architecture/Website-React-WordPress-Architecture.md |
obsolete | obsolete | Website |
04-Standards/Repository-and-Delivery-Standard.md |
now | now | Protected main, merge requests, no secrets; the target for GitLab origins |
04-Standards/Cross-Project-Knowledge-Governance.md |
later | now | Evidence vs decision; "AI assumptions are proposals until accepted" matches principle 6 |
04-Standards/Cross-Project-Triage-and-Operating-Model.md |
later | now | Legacy-capability classes (Alive/Dormant/…); TEA/TEM roles |
07-Roadmap/Portfolio-Roadmap.md |
obsolete | later | Website roadmap |
07-Roadmap/Portfolio-Engine-Deployment-and-Snapshot-Plan.md |
obsolete | later | Portfolio Engine |
08-Templates/AI-Session-Handoff-Template.md |
later | now | A candidate structure for item bodies and handover |
08-Templates/Cross-Project-AI-Handoff-Template.md |
later | now | "Evidence vs accepted decisions vs open proposals" |
09-Research/Technology-Estate/CI-CD-MMDEP-FOUNDATION-2026-09-06.md |
later | now | CI foundation with deployment deliberately disabled |
09-Research/Technology-Estate/ESTATE-AUDIT-TASK-001-*.md |
later | now | GitLab estate inventory (2 groups, 8 repos, project IDs) |
09-Research/Technology-Estate/ESTATE-AUDIT-TASK-002-*.md |
later | now | CI foundation evidence; duplicate MR pipelines noted |
.gitlab-ci.yml |
later | now | MR and default-branch validation only; a model for our CI when origins move |
09-Research/Website/* (README, 2 docx, CSS 3.2 MB) |
obsolete | obsolete | Website sources |
wp-content/…/images/reference/* (12 images) |
obsolete | obsolete | Website assets |
Empty .gitkeep folders, empty CHANGELOG.md |
obsolete | obsolete | Scaffolding |
Classification: issues (27; open unless stated)¶
| Issue | Orch | TEM | Note |
|---|---|---|---|
| #1 Website architecture and Phase 1 requirements | obsolete | obsolete | Website |
| #2–#4 Cross-project knowledge/governance model (three duplicates) | later | later | Produced the governance standard |
| #5–#8 Placeholder/Temporary | obsolete | obsolete | Clean-up candidates, in GitLab, by a person |
| #9 TASK-001 GitLab baseline | later | now | Done; evidence above |
| #10 TASK-002 CI/CD foundation | later | now | Done; CI quota issue |
| #11 TEM P1: implementation repo + evidence schema | now | now | The TEM boundary: separate technology-estate-manager repo, blocked on repo creation |
| #12–#15 TEA NAV/MM-Crons audits, Release-B | obsolete | later | Estate content, not orchestrator |
| #16 Release-C gate (CI recovery) | later | now | Waits for CI capacity; see the runner item |
| #17 TEM Phase 1 design + feasibility | now | now | Parent; our iteration 1 and 2 results are feasibility evidence |
| #18 Registry + communication protocol | now | now | See the table above |
| #19 Local environment + MCP reachability | now | now | Proven here for Claude (stdio) |
| #20 Pull/push adapters | later | now | Only pull here |
| #21 Bounded work-loop + interruption | now | now | Iteration 2 stories 3, 6, 8 |
| #22 Local model evaluation harness | later | now | Backlog "evaluation loop" |
| #23 Vertical slice to deployment | later | now | Stops at merge here |
| #24, #25 TEA AWS audit, TEA processes | obsolete | later | Estate |
| #26, #27 TEM collectors, pre/postflight evidence | obsolete | later | Different domain |
Not covered in this pass (time-box)¶
- The TEM Phase 1 requirement sketch (
09-Research/Technology-Estate/TEM-PHASE1-REQUIREMENT-SKETCH-2026-09-23.md, MR !50) and MR !51 (the cross-project investigation index). They aren't in the local clone (last commit 2026-09-06),git fetchfailed authentication, and reading merge requests needsglab mr view, which is outside the commands you allowed. This is the most important gap for the TEM decision. - Comments on issues other than #11, #17 and #23. Of these, #16 (3 comments) and #26/#27 (1 each) are most relevant.
- Full text of the three
.docxfiles (only headings read); the other GitLab repos in the estate (Website, api, mm-crons, webapp, …); merge requests and pipelines in general. - Remote branches not merged locally (
docs/architecture-takeover-2026-08,docs/technology-estate-pilot-1,docs/sync-phase1-website-status), which I didn't inspect.
Proposed next steps (for Atul)¶
- Fix the local clone's git credential (
git fetchinC:\Projects\MoneyMarche) and allowglab mr view 50 51. Then a second pass reads the TEM requirement sketch. - Decide the TEM relationship. The confirm items raised with this review cover the assumptions I'm proceeding on. The final decision needs the sketch.
- Consider giving TEM #17–#21 the evidence from here, as a comment written by a person in GitLab, not by me.
Second pass (2026-09-27): MRs !50 and !51¶
These were read with glab mr view 50|51 and glab mr diff 50|51 (read-only, allowed on #19). Both merge requests are open, not merged, so the documents are proposals, not accepted MMDEP governance records. Note: glab hung until timeout when started without stdin redirected; with stdin from /dev/null it answered at once. That's the same class of problem as MMDEP's stdin fix (#12).
!50: TEM Phase 1 Requirement Sketch (2026-09-23)¶
TEM Phase 1 has three goals: (G1) communication and continuity between agents and people, (G2) proportionate testing and acceptance, (G3) deployment and estate-audit automation. Its principles include "execute, do not decide", "evidence before inference", replaceable agents and models, reversible specialization, "unknown remains unknown", and no autonomous consequential production action. The abstraction is domain-neutral: identity → capability → role → assignment → task → context → evidence → result → decision/approval.
Its feasibility programme, F1–F12, against what exists in the MMDEP orchestrator:
| Test | Question | Evidence here | Status |
|---|---|---|---|
| F1 | Local environment: core, state store, MCP, modest resources | SQLite store, stdio MCP server, CLI; no LLM needed for dispatch or state | Shown |
| F2 | MCP reachability from browser/desktop sessions | Claude desktop and Claude Code (VS Code) over local stdio, in use daily. Browser sessions: not tested | Partly shown |
| F3 | Pull: an agent retrieves assigned work and context | People and Claude Code pull items and answers via MCP (list_items, get_item) |
Shown for items; no task pull for external agents |
| F4 | Push to agent environments | None; the dispatcher starts local agents itself, and nothing pushes into a desktop app | Not shown |
| F5 | Agent result return | Dispatched agents: result → commit → item → ledger. External agents: only via raise_item |
Partly shown |
| F6 | Handover A → state → B without the chat | Items, iteration files and the status-section rule provide the state. There has been no real handover: every session so far kept its own conversation context | Designed, not shown; needs a test with a fresh agent |
| F7 | Bounded work-loop: limit, timeout, failure, interrupt | Attempt limit (3), slot timeout and recovery, fallback, item-only release (iteration 1); wall-clock timeout, kill switch, idempotency and expiry are iteration 2 stories 3, 6, 8 | Mostly shown; completes with iteration 2 |
| F8 | Multiple agent forms, differences recorded | DeepSeek and Qwen (local, live runs and failures recorded), Claude CLI (capped), Codex (story 10) | Partly shown |
| F9 | VS Code / desktop without UI automation | Claude Code in VS Code via the project's .mcp.json |
Shown for Claude Code |
| F10 | Future-agent adapter model | agents.yaml registry + adapter kinds, deny-by-default role map |
Shown as a design |
| F11 | Task → change → tests → CI → deploy → runtime → evidence | Up to the merge (with approval). Tests: story 5. CI, deploy and runtime: none | Partly shown |
| F12 | Weekly triage from accumulated state | None; backlog: mmdep status, reports |
Not shown |
Where the MMDEP orchestrator differs from the sketch:
- Agent, role and assignment: the sketch wants three separate entities. Here, roles are keys in the role map, and an "assignment" is only assigned_agent / executed_by on a task. There is no assignment record with its own provenance (declared, observed or derived).
- Message envelope: the sketch proposes a structured envelope with AI_AGENT / HUMAN / BOTH / TEM destinations. Here, every item goes to a person, and there's no agent-to-agent message.
- A tension to flag: the sketch lists "autonomous merge approval" as a Phase 1 non-goal. Spec 0.4 (approved, #18) lets low-risk stories merge to main on green tests plus a second-opinion review, with human approval in a batch at the iteration review, before any release. That isn't autonomous approval, since a person still approves before release. But main does change without a person first, which the sketch's wording would not allow. Worth a conscious decision before the convergence decision (before iteration 4, per #20).
!51: cross-project investigation inventory + integrated work plan (2026-09-26)¶
- The first cross-project investigation index, covering TEM/TEA, API/MM-Crons, Portfolio Engine, MCRM and Website, with status, acceptance and TEM relevance per row.
- TEM already has implementation work: "INV-TEM-P1-P2" records Pilot 1/P2 GitLab source-control collectors with competing A/B implementations (MRs !36, !37, !39, !40, !42), status PARTIAL, P2 not accepted. TEM is therefore not only a design: there is collector code to reconcile, which matters for any convergence decision.
- A flow that could apply here too: project investigation → evidence/report → MMDEP index → TEM evidence → issue/action → technical review → PM acceptance → retained record. The division of labour is "TEA authorizes and accepts, TEM collects and executes". That matches this orchestrator's "people decide, the dispatcher executes".
- New names seen: MCRM (Catalogue Manager; product catalogue authority is open) and MMClone/WPDEV (website promotion path).
Classification additions¶
| Item | Orch | TEM | Note |
|---|---|---|---|
| !50 TEM Phase 1 requirement sketch | now | now | The yardstick for iterations 2–4 and the convergence decision; F1–F12 above |
| !51 investigation inventory | later | now | Index pattern; TEM P1/P2 collector state |
| !51 integrated reporting + TEM work plan | later | now | Workstreams A/B/C; TEA/TEM split |
| TEM P1/P2 collector MRs !36–!42 | later | now | Not read (outside this pass); needed before convergence |
Still not covered¶
The collector MRs !36–!42, comments on most issues, and the other estate repositories.