title: MMDEP plan review, October 2026 — step 1: objectives and phases status: review for discussion (Atul and reviewer chat); changes reach the spec only through an approve item author: Claude (chat, MMDEP-PM role) date: 2026-10-10 inputs: spec 000 v0.11 (§1, §9, §15B, §17.0, §18); docs/design/MMDEP-current-design.md; the discussions of 10 Oct (checkpoint §8); GitHub and GitLab state read on 10 Oct
MMDEP plan review — step 1: objectives and phases¶
1. Objectives: where we are, and what 10 October adds¶
| # | Objective (spec §1) | Where we are | What 10 Oct adds | Guardrail or mitigation |
|---|---|---|---|---|
| 1 | Coordination without waiting | Only for MMDEP itself. Atul relays prompts between the reviewer chat, Claude Code and ChatGPT by hand | Issues as the bus for every project; scheduled cloud sessions (reviews, digest); a Gemini task shaper between lead and worker; Claude in Chrome reads GitLab and can relay bounded prompts to ChatGPT with Atul's approval | Nothing merges, releases or deploys without Atul. Relayed prompts go one at a time, each approved |
| 2 | One accountable owner per role | Written as §5C; PE's AGENTS.md assigns roles; no common role table |
PM role moves to the reviewer chat; labels name roles, never agents; trailers name the agent | Role changes by approve item; one coder per project |
| 3 | Safety by infrastructure | Strong on the desktop (agent account, worktree grants, guards). Weak on GitHub: no enforced protection on main in MMDEP, Portfolio Engine or MCRM (private repos on GitHub Free; checked 10 Oct) |
Finding made today; fix proposed (§4, R1) | GitHub Pro, or move agent-written repos to GitLab with protected main |
| 4 | Evidence and decision kept apart | Held for MMDEP; in PE, ChatGPT both produces and accepts evidence | Independent reviewer (AC-1 or cloud review session) from a different vendor; Atul decides from reports | Reviews are advisory; only Atul approves |
| 5 | A full trail | MMDEP ledger covers MMDEP only; forge activity is not recorded | Trailers on every agent commit and comment; run records (from the PE pilot); the read-only GitHub adapter becomes a priority | Agents all act as moneymarche-dev until a bot account exists; trailers mitigate |
| 6 | Cross-project visibility and impact | None in MMDEP; Atul holds it in his head; GitLab has more than 130 open MRs across projects | Digest across repos; Chrome gives the reviewer chat GitLab visibility; the website dependency map | GitLab visibility depends on Atul's laptop being on |
| 7 | Cost-effective AI | All dispatch agents capped at 0; Claude Code and ChatGPT on paid plans; Gemini free | Copilot dropped; Gemini as a cheap task shaper and terminal agent (paid tier for private content); cloud review sessions capped per run | Budget per process (§5); free tiers only for public or synthetic data |
| 8 | Governance authority in GitLab | ADR-004–006 and the handover amendment are drafts waiting for Atul's MR | Chrome access makes the governance repo readable to the PM role | MRs to GitLab are still submitted by Atul |
| 9 | Staged maturity | Gates defined (D6, §17.0, §15B), but aimed at synthetic pilot projects | Proposal: gate the real projects in stages (observe → advise → dispatch) instead | Each stage has a gate with evidence |
The objectives themselves still hold. What changes is how we reach them: through the forges the projects already use, starting with real projects in read-only and advisory stages, instead of building parallel channels and synthetic pilots first.
2. The approved phase plan (spec 0.11), in short¶
- Development phase 1 (now), with these rules:
- only Claude Code develops
mmdep; - free plans;
- GitHub
mainguarded by drift checks, a pre-push hook and PRs merged by Atul; - no bot account;
- projects where other agents write live on GitLab Free with a protected
main. - Exit to phase 2 (D6):
- enforced repository protection;
- a PR flow with a second developer and a separate reviewer;
- a generic
AGENTS.md; - the release command and manual;
- the readiness gate met and one test project run end to end.
- Iteration 3, still open:
- views trial,
mmdep-inboxissue mirror, read-only GitHub adapter, requests back (online view phase 1); - DR-002 stage 1 sandboxes;
- triage type, evidence retention, release command, CI standard;
- accounting kickoff docs;
- HO-1;
- release #80.
- Online view: phase 1 (Drive, Sheet, mirror) → phase 2 (MCP on Bluehost) → phase 3 (AWS), each behind a gate.
- Next projects: the pilot suite on synthetic data (accounting first, then billing, expenses, compliance), after the §17.0 readiness gate (2 of 6 met).
- Later iterations: 3b daily operation; 4 multi-agent quality and forges; 4b deployment assist; 5 planning, GitLab, TEA estate loop, documents.
3. Where the plan and reality have drifted apart¶
- Business priority. The money comes from the website and MCRM (Atul, 10 Oct), and they fund hardware and tools. The plan's next projects are synthetic pilots (accounting and others), which earn nothing.
- Phase 1 rule broken in practice. ChatGPT writes to Portfolio Engine and MCRM on GitHub Free, where
maincan't be protected. The rule said such projects go on GitLab with a protectedmain. - The online view is partly overtaken. Phase 1 builds a Sheet, an artifact board and an issue mirror so chats can see the inbox. The reviewer chat now reads GitHub directly, and GitLab through Chrome. ChatGPT reads GitHub with its connector.
- DR-002 stage 1 is partly overtaken. The PE pilot tested the forge bus on a real repo and showed what it needs: claims, verification, run records, and a controller owned by MMDEP, not by the project lead.
- MMDEP doesn't see the real work. No real project is registered or observed, so objectives 1, 5 and 6 can't be measured.
- Atul is the bottleneck twice: as relay and as reviewer. MCRM's PRs wait for an independent review; GitLab has more than 130 open MRs.
- The calendar. Atul is away 16–30 Oct, and only advisory work can run unattended.
4. Proposed re-phasing (for decision)¶
| Stage | When | What | Gate to the next stage |
|---|---|---|---|
| 1a Stabilise | 11–15 Oct | Release #80; merge PR #2; labels in the GitHub repos; PM role transfer; Gemini paid tier; decide repository protection (R1); vacation processes: MCRM review session and digest, dry-run on 13–14 Oct | Dry run checked by Atul before 16 Oct |
| 1b Advise (unattended) | 16–30 Oct | Cloud review session on MCRM PRs (advisory comments); digest twice a week; ChatGPT continues under a WIP limit of 5 open PRs per project; no merges | Two weeks of reviews: Atul rates their usefulness on return; no unauthorised change |
| 1c Observe | November | Read-only GitHub adapter into the ledger (issues, PRs, labels, ages, review debt); GitLab read through local mirrors or a read-only token; website dependency map; AC-1 audit controller (generic, desktop, Gemini paid or another engine); Gemini task shaper; HO-1 issue templates | Digest and review debt produced from the ledger; AC-1 used on two projects |
| 1d Dispatch, one real project | December | The website, or MCRM if the website's dependencies block it: roles, labels, protected main, Test Runner and test environment, AC-1 reviews, the H1 harness for bounded tasks |
An adapted readiness gate (§17.0 for a real project) |
| Phase 2 (D6) | After 1d | Unchanged in intent: a second developer agent plus a separate reviewer, enforced protection everywhere, the release command | D6 |
Drop or defer (proposal):
- Drop: the views trial, the mmdep-inbox mirror and requests back (replaced by issues and the digest); the DR-002 sandbox repos (replaced by stage 1b's advisory reviews on a real repo, which is lower risk than code).
- Defer: the synthetic pilot suite (accounting and the others) until the business asks for it; online phases 2 and 3 unchanged (gated).
- Keep: Drive snapshots (done); the release command; evidence retention; the triage type.
5. Security, cost and performance: risks and mitigations¶
| # | Risk | Area | Mitigation | Owner, when |
|---|---|---|---|---|
| R1 | main not protected in GitHub repos where agents write |
Security | GitHub Pro for the account (about USD 4 a month; check the current price), enabling rulesets that require PRs. Or move agent-written repos to GitLab with protected main. Until then: agents only open PRs, never push to main (stated in each AGENTS.md), and the digest flags direct pushes |
Atul, by 15 Oct |
| R2 | Private content sent to Gemini's free tier | Security | Billing enabled with a prepayment, so prompts fall under paid terms; until then public and synthetic content only | Atul, by 15 Oct |
| R3 | All agents act as Atul on GitHub, GitLab and in Chrome | Security, trail | Trailers and report headers now; per-action approval for any browser write; a bot account later, which needs GitHub Pro or an organisation | Reviewer, now; bot in 1c |
| R4 | Prompt injection through issue or PR text | Security | Issue text is data; controllers act only on labelled issues from moneymarche-dev containing the role line; reviews only comment and label |
Built into AC-1 and the review prompt |
| R5 | Laptop travels and holds sign-ins | Security | BitLocker, a strong PIN, screen locked; revoke sessions if lost | Atul, before 16 Oct |
| R6 | Unattended cloud sessions use up the Claude plan | Cost | At most 3 PRs per review run and weekdays only; the digest only reads; usage checked after week 1 | Reviewer |
| R7 | Agents produce faster than Atul reviews | Cost, performance | WIP limit of 5 open PRs per project; independent reviews in advance, so Atul decides from reports | ChatGPT and reviewer, from 16 Oct |
| R8 | Laptop memory (local models paused) | Performance | Heavy reading runs in the cloud; local models (Antigravity, Ollama) wait for hardware funded by revenue | Later |
| R9 | GitLab visibility depends on the laptop and Chrome | Performance | Best effort while away; in 1c, local mirrors or a read-only GitLab token | 1c |
| R10 | Production outage while Atul is away | Security, operations | A named emergency contact with stated limits; TEA's manual deployment with preflight, postflight and a deployment record, run by a person | Atul names the contact, by 15 Oct |
6. Decisions needed for step 1¶
- Accept the re-phasing (1a–1d) and the drop/defer list, so Claude Code can raise spec 0.12 as an approve item?
- Repository protection (R1): GitHub Pro now, or move agent-written repos to GitLab?
- First real project for 1d: the website (pending its dependency map) or MCRM?
- The synthetic pilot suite: defer fully, or keep accounting's kickoff docs as a small background task?
7. Repository protection: what each forge offers (checked 10 Oct)¶
| GitLab Free (private) | GitHub Free (private) | GitHub Pro (private) | |
|---|---|---|---|
Protected main |
Yes: "allowed to push and merge" and "allowed to merge" set to Maintainers, Developers + Maintainers, or No one | No (rulesets need Pro; confirmed by the API on all three repos) | Yes (rulesets, including no bypass for admins) |
| Per-user exceptions, code-owner approval | Premium | — | Partly |
| Real enforcement against an agent | Only if the agent uses its own account with the Developer role; Atul (Maintainer or Owner) merges | — | Only if the agent uses its own account; a required approval can't come from the same account |
The key point: protection only stops an agent that works under an identity with fewer rights than Atul. Today every agent uses Atul's account (moneymarche-dev on GitHub, "money marche" on GitLab), so even a protected branch would let an agent merge through Atul's token. Real enforcement needs an agent account (one per vendor, or one shared "agents" account) as Developer on GitLab, or a collaborator on GitHub Pro. GitLab Free allows 5 users per top-level group, enough for Atul, the legacy developer and two or three agent accounts.
8. Code and work in separate repositories (Atul's model, restated 10 Oct)¶
- Each project has two repositories (DR-001, code vs estate/work):
- Code repository:
mainprotected, or worked on by only two agents: a coder and a reviewer, each the other's backup (a takeover handover prepared in advance, §5C). - Work repository: specs, evidence, decisions, handovers and the issues that drive the work. The lead or PM, and others by role, work here.
- Labels are the control where protection is missing: an agent acts only on issues carrying its
role:label andstate:ready. This is a rule agents follow (it lives inAGENTS.mdand the controllers' code), not a lock. It becomes enforceable when agents have their own accounts. - Detection backs the rule up: the digest and the read-only GitHub adapter flag:
- commits to
mainwithout a PR; - PRs without a linked, labelled issue;
- work by a role the issue wasn't labelled for.
9. Local folders: a register and a gatekeeper¶
Problem: C:\Projects has similar names and duplicate folders created by agents. Local work can bypass the issues: for example, valuable untracked files in a PE checkout that never reached GitHub (seen in the Gemini pilot run record).
Proposal:
1. A folder register at C:\Projects\README.md, started by Atul on 10 Oct. One row per top-level folder:
- project;
- kind: code clone, work repo, runtime, hub, scratch or archive;
- remote URL;
- the role or agent allowed to write;
- status.
2. Agent rules: agents create folders only inside their assigned workspace, or under C:\Projects\_scratch\<agent>\. A new top-level folder needs an issue and a register row first. Work that matters is committed and pushed to a branch, or attached to its issue, within the same session.
3. A gatekeeper check, read only, as a script (no AI needed; later mmdep folders check). Daily, or before a digest, it lists:
- folders not in the register;
- the same remote cloned twice;
- clones with uncommitted or untracked files, and their age;
- folders not touched for 30 days (archive candidates).
It writes a report and never moves or deletes anything. It skips mmdep_runtime and mmdep_hub.
4. Enforcement where possible: agents run by MMDEP already run as mmdep-agent, which is denied write access outside its granted worktree. Claude Code and Gemini CLI run as Atul, so they are covered by detection and by deny rules in their settings (for example Claude Code's deny rules for paths outside the project).
10. The rules so far: which to enforce harder, keep, or relax¶
| Rule | Source | Proposal |
|---|---|---|
Nothing reaches main without a person |
CLAUDE.md, spec §9 | Enforce harder: agent accounts plus protected branches (GitLab Free, or GitHub Pro) |
| Only a person approves, merges, deploys; agents hold no deploy credentials | spec §11, §15.6–15.7 | Keep, strict |
Agents can't answer or approve items (respond refuses agents; never MMDEP_ACTOR as a human) |
stories 2 and HU-1 | Keep (already enforced in code) |
Never touch mmdep_runtime or the hub database |
CLAUDE.md | Enforce harder: Claude Code deny rules for those paths (cheap); the gatekeeper skips them |
| Branches only; status-only commits; specs changed only by approve item | CLAUDE.md | Keep |
| Tests pass before an approve item; tests for every behaviour | CLAUDE.md | Keep; the Test Runner enforces it for dispatched tasks |
| Secrets never in repo, items, ledger or logs; tokens in Credential Manager | spec §11 | Enforce harder: the PE controller reads the Gemini key from an environment variable; move it to Credential Manager. Redaction already exists |
| No client data in code, tests or fixtures | CLAUDE.md | Keep; add a pre-commit pattern check (PAN and Aadhaar formats) |
| Free tiers only for public and synthetic data | spec §5B | Enforce harder: a paid Gemini tier for private content |
| Free plans only (phase 1) | spec §9 | Relax: spend is allowed by approval within a monthly budget (Gemini prepayment, GitHub Pro if chosen) |
| No bot account yet | spec §9 (D5) | Relax: agent accounts are now needed for enforcement and an honest trail |
| Forges are read-only for Claude Code | CLAUDE.md | Relax narrowly: comment and label only, on labelled work-request issues (LOOP-1, AC-1) |
Projects where other agents write live on GitLab Free with a protected main |
spec §9 (D5) | Re-decide: GitLab Free plus agent accounts, or GitHub Pro plus agent accounts (R1) |
| One lead and one coder per project | spec §5C | Refine: code repository = coder plus reviewer as mutual backups; work repository = lead/PM |
| Agents act only on issues labelled for their role | new (10 Oct) | Add to every AGENTS.md, with detection in the digest |
Folder register; scratch only under _scratch\<agent> |
new (10 Oct) | Add, with the gatekeeper check |
| Reviewer chat: documents and issues only | Atul, 10 Oct | Extend and codify: may also read local folders and GitLab through Chrome; any write outside its docs/ branches or issues needs Atul's approval per action |
| Low-risk merges after a second-opinion review into an integration branch | spec 0.4 | Use once AC-1 exists: documentation PRs that pass AC-1 merge in a batch Atul approves |
| Prompts are pointers; NEW/RESUMED; 3 turns per Work Request; session names | STD-AI-CONT-001 v1.1 | Keep |
No new dependency without a reason; Windows first; stdin= on every subprocess; PowerShell quoting |
CLAUDE.md | Keep (the stdin= rule also applies to project controllers such as PE's) |