title: MMDEP Programme Manager operating model — documentation, summaries and write path status: proposal (Atul's inputs of 11 Oct treated as baseline, not final) author: Claude (chat, MMDEP-PM role, taking over from the ChatGPT MMDEP-PM agent) date: 2026-10-11 sources: governance repo (local copy, about 6 Oct): readme, 01-Project/AI-Agent-Registry, 01-Project/Portfolio-Register, 01-Project/Repository-and-Reference-Map, 04-Standards/Cross-Project-Knowledge-Governance, 04-Standards/Repository-and-Delivery-Standard

MMDEP Programme Manager operating model¶

1. What the governance repo has today¶

Strong and reused as is: - the agent role registry (role IDs, PRIMARY / DEPENDENCY / REFERENCE scope, a compact role record); - the repository and reference map; - the knowledge-governance standard (evidence vs decision, the promotion lifecycle); - the delivery standard, ADRs and templates.

Gaps: - No per-project area. Project knowledge is scattered: 09-Research/Website, 09-Research/Technology-Estate, a Portfolio Engine index in 01-Project, a Portfolio Engine plan in 07-Roadmap. - Empty placeholder folders: APIs, Backend, Website, Assets, Downloads, Meetings, References, Scripts, docs. - Theme code inside the governance repo (wp-content/), against its own rule that code lives in product repos. - The registry lacks: MCRM, the production website (maintenance and SEO), MMCLONE and testing, old staging, and the future recommendation engine. The Portfolio Register still lists webapp as active. - No single portfolio status view, and no cross-project dependency register.

2. How summaries are kept¶

The existing rule stays: project repositories are authoritative for project detail; the governance repo holds short summaries and cross-project records.

01-Project/
  AI-Agent-Registry.md          (existing; add the missing roles)
  Portfolio-Register.md         (existing; correct webapp, add projects)
  projects/<project-id>.md      NEW: one card per project, in the registry's role-record form plus 10 lines:
                                purpose · repos · roles and seats · state (GREEN/AMBER/RED) · current work ·
                                next milestone · blockers · dependencies · last checkpoint (link) · updated
  Portfolio-Status.md           NEW: one table, all projects, refreshed weekly (later by MCL)
  Cross-Project-Dependencies.md NEW: who waits on whom, with links (e.g. WPDev ← production refactor ← MCRM catalogue)

How projects contribute: - Each project lead keeps its current-state record in its own repo. - At each milestone, or weekly, the lead updates its card by MR; the PM reviews and merges. - Later, MCL drafts the card from repository facts.

How projects learn: - Each project's AGENTS.md points to its card, the dependency register and the standards. - Cross-project questions go to the PM as a labelled issue, not by editing another project's repo (registry rule 6).

Clean-up: - remove the empty placeholder folders; - move wp-content/ to the product repo or delete it (TEA checks first); - fold 09-Research/Website into the website project's card and evidence.

3. Write path for the PM¶

Option	Cost to Claude usage	Authority	Decision
4. Write to a local folder; an agent or script commits to a branch and opens the GitLab MR	Low (one file write per document)	GitLab stays authoritative (DR-001)	Use now. I write to a separate outbox folder, `C:\Projects\_outbox\governance\` (not the working copy, so git state is never disturbed). A delegated agent or script copies the files into a branch and opens the MR; Atul or the PM approves
1. GitHub (MMDEP repo)	Low	Second home for governance	Only for the orchestrator's own design and PM working notes (as now)
3. MMDEP MCP hosted, so every agent reads and writes through it	Build effort (Claude Code)	Single bridge	The real fix. After the tools box test (the hosted-hub phase)
2. Google Drive via script	Low	Another home	No: adds a third place
5. Claude in Chrome on GitLab	High (page reads, acts as Atul)	—	Read-only, occasionally; not for writing

4. Roles¶

MMDEP-PM: taken over by the reviewer chat, from the ChatGPT agent. A role transfer under STD-AI-CONT-001 (kind A): the outgoing agent writes a handover into the governance repo, the PM reconciles and confirms, and the registry is updated.
TEA (audits): retired from ChatGPT. Becomes deterministic collectors (scripts on the GitLab runner or the tools box, plus Gemini for summaries), as already proposed. Evidence goes to the governance repo; decisions stay with people.
TEM (building estate tools): handed to a developer agent in its own repo, guided by the PM through Work Requests.
Interim rule until the MCP exists: ChatGPT agents read anything, but write only in their PRIMARY repos. A cross-project need becomes an issue labelled cross-project in their own repo, routed by the PM.

5. First steps (low usage)¶

Atul relays one prompt to the ChatGPT MMDEP-PM agent: write its role-transfer handover into the governance repo (draft in chat, 11 Oct).
After the handover arrives: the PM writes the project cards, Portfolio-Status and Cross-Project-Dependencies to the outbox, using the handover plus the facts already gathered.
A delegated agent opens the GitLab MR.
Registry and Portfolio Register corrections go in the same MR.

6. Decision (Atul, 11 Oct): the outgoing ChatGPT PM does the groundwork before retiring¶

Before handing over, the ChatGPT MMDEP-PM agent: - writes the handover; - verifies facts from the other repos and builds the governance structure (§2: project cards, Portfolio-Status, Cross-Project-Dependencies, registry and Portfolio Register corrections); - opens MRs adding the MMDEP section to AGENTS.md in each project's PRIMARY repo, so project agents follow MMDEP without being contacted one by one.

Conditions: - branches and MRs only, never direct to main; - every fact carries repo/path/ref and is marked evidence or decision; - one shared AGENTS.md section text; - the PM reviews (sampling, plus all AGENTS.md MRs); Atul or the project lead merges.

The weekly triage scheduler keeps running and reports into the governance repo.

6a. Revised (Atul, 11 Oct 16:58): two steps, because the agent is out of date¶

The ChatGPT PM hasn't been used for several weeks. It may not know about MMCLONE, the testing repos, or the production website work, so its facts can't be the baseline.

Step	Who	What	Writes
1. Dump	ChatGPT PM	Reports what it knows, with the last date it knew each fact; its scheduler details; open commitments; questions	None (chat reply only)
2. Reconcile	PM (Claude)	Compares the dump with verified facts (checkpoint §10–§11); writes one facts sheet to the outbox: each fact marked verified, stale, or unknown	Outbox
3. Execute	A CLI agent on Atul's laptop (Copilot CLI while that subscription runs, or Gemini CLI once billing is on; not the free Gemini key), with `glab`	Verifies facts from the local clones; builds the governance structure (§2); opens the `AGENTS.md` MRs; creates labels once the scheme is approved	Branches and MRs only
4. Handover text	ChatGPT PM	Writes the narrative handover from the facts sheet	One MR

Why a CLI agent for step 3: it reads the actual repositories rather than memory, and glab can create labels, which the ChatGPT connector couldn't. glab acts as Atul, so Atul runs it or approves the session. Label creation is deterministic, so it's a small script, not an agent task.

The conditions above still apply.