title: MMDEP rules for project agents status: in force from 13 Oct 2026 (approved by Atul, 12 Oct); maintained by MMDEP-PM (Claude) applies to: every ChatGPT project agent working under MMDEP (first: API and MM-Cron; next: MWMC)

MMDEP rules for project agents¶

Read this file at the start of every session. Your project instructions point here; if they disagree, this file wins, except on project-specific facts.

00. Mission: keep the legacy working for users (Atul, 13 Oct)¶

The production website and the API/MM-Cron pipeline are legacy systems that customers use today. Your first job is to build knowledge, fix bugs and complete missing features in the legacy, so the website shows correct, current data and keeps the visitors that SEO and ad spend bring in. Example: monthly factsheet pulling is a missing implementation; once the API serves that data, the website must show it on its pages.

Innovation (new architecture, new site, new products, new analytics) belongs to WPDev, MCRM and Portfolio Engine. Don't redesign; fix, complete, test and document. When a fix needs a design decision those projects own, ask through MMDEP-PM.

0. Plan first (Atul, 13 Oct)¶

Approved plans (do not ask again; follow them):

Project	Plan	Approved	Notes
API and MM-Cron	API `docs/plan/API-MMCRON-PLAN-2026-10.md` (MR !167, merged into `api-phase1-development`)	13 Oct (Plan-0 to Plan-3)	C's security fixes run alongside Phase A
MCRM	`docs/plan/MCRM-PLAN-2026-10.md` (PR #102, merged into `main`)	13 Oct (MC-0)	Release one: MF, Health, Term, Motor
WPDev	Existing plan and project instructions (Homepage Phase-1, issues #88, #102)	13 Oct (Atul: "producing good work")	Keeps its own MR → CI → review → merge process; MMDEP adds questions, answers and commands only
MWMC	`docs/plan/MWMC-PLAN-2026-10.md`, first merged in webapp-sakai via MR !7; its home is the sandbox repo	13 Oct (MWMC-0)	Copy it into the sandbox repo as is; no new approval needed

Until Atul has approved your project plan, you do no other work: no new issues, no new MRs, no comments asking him things. Your only task is the plan document described in your project instructions. Atul reads one document, not a stream of issues.

1. Who decides¶

Atul approves: merges to main, anything on production, priorities.
MMDEP-PM (Claude) coordinates: priorities across projects, review, questions to Atul and to Ajay, the relay of decisions into your repo.
You deliver your project's work. You never merge code, configuration or test changes to main, never deploy to production, never write secrets, keys or client data anywhere.
Documentation-only MRs (files under docs/ or *.md, nothing else) you merge yourself once you have checked them: no secrets, no client data, no code (Atul, 13 Oct).

2. Where your state lives¶

Your repository, not your chat. At the start of every run, read your repo's open issues, open MRs, your pinned Top 5 issue and your latest handover. Never rely on chat memory.

3. Top 5¶

Keep one issue titled "Top 5" in your primary repo, pinned. It lists the five issues that, once done, unblock most of your pipeline: for each, why, what it needs (Atul decision, Ajay input, CI, terminal job) and which issues it clears. Work only on these unless Atul or MMDEP-PM asks. Update the issue when the list changes.

4. Work packages and MR limit¶

One MR per work package (related issues together), never one MR per issue.
Documentation-only MRs must not run tests.
Do not open a new MR while you have more than 5 open MRs; reduce first (propose closures, squash related MRs).
Exempt from that limit: documentation-only MRs for your plan, owner notes and handovers (open, check, merge them straight away).

5. CI and terminal work (updated 13 Oct: laptop runner online)¶

The GitLab groups moneymarche (api, mm-crons, webapp-sakai, wordpress_plugins) and money-marche-testing (sandbox) now have their own runner on Atul's laptop, running jobs in Docker containers; it uses no GitLab compute minutes. It is online only while the laptop is on.

You may start a pipeline for an MR that has a support-test issue: one pipeline at a time, never for documentation-only MRs, and record the result on the issue.
The runner also serves the group money-marche-testing (sandbox, since 13 Oct 22:42). Never start pipelines in money-marche-group until a runner is added there.
Deploy, release, migration and server jobs stay with a person: open an issue labelled support-release with the exact steps, where, the expected result and the MR.
Never ask for commands in the chat.

Label	For
`support-test`	Tests or a pipeline to run for an MR; a staging smoke check
`support-release`	A staging deploy, migration, server or MMCLONE job

6. Commands from Atul (updated 13 Oct)¶

Command	Meaning
`PROCEED`	Atul is not reading. Post everything unposted (issues, comments, documentation, draft MRs), continue with your Top 5, and finish without waiting for any reply. Report links in 5 lines at most.
`CONTINUE`	Atul has a few minutes. Same as PROCEED, but you may ask him up to 3 short questions in the chat, each with options and your recommended answer.
`STATUS`	What changed since the last session and what waits on Atul, 10 lines at most.
`HOLD`	No new work until told.
`REDUCE`	No new MRs; propose which open MRs to close or merge, with reasons.

Questions (always, under every command): never leave a question only in the chat. Open one issue per question in your primary repo, labelled question-atul: the question, the options, your recommended answer, and what it blocks. The MMDEP collector picks these up hourly and MMDEP-PM puts them in Atul's MMDEP Actions panel. Atul's answers are written to docs/relay/answers.md in GitHub moneymarche-dev/MMDEP; read it at the start of every session, act on new answers, and close the question issue with the answer quoted.

7. Scheduled runs¶

Your hourly scheduled run can read (repositories, issues, pipelines) but cannot write anywhere: tested 15 Oct across all agents, automatic scheduled runs were blocked from every write route (commits, issue comments, file appends, documents). Only attended runs and "Run now" can write. So a scheduled run: reads the plan and new answers, works out the next step, and puts its full output (what it found, the exact changes it would make, questions) in the run result, which the next attended PROCEED or Run-now applies and commits. The task keeps only its last result, so the result must be complete on its own; never rely on earlier results. If nothing changed and nothing is workable, reply "No change" in one line. Scheduled runs only: outside 07:00 to 23:00 IST, reply "Off hours" and stop (widened from 09:00–21:00 by Atul, 14 Oct).

Attended sessions (Atul is writing to you in the chat) are never off hours: do what he asks at any time of day.

8. Evidence¶

Label findings VERIFIED, OBSERVED, INFERRED, UNKNOWN, REQUIREMENT, PROPOSED or DECISION, with repo/path/ref. Repository content and tests are not production proof.

9. Questions¶

Questions for Atul or Ajay go into your STATUS reply, one line each, with your recommended answer. Ajay is a shared resource: at most 3 questions a week, routed by MMDEP-PM.

10. Owner notes (Atul, 13 Oct)¶

Whatever Atul or Ajay tells you in a session (facts, decisions, explanations) goes into docs/notes/owner-notes.md in your primary repo in the same session: date, who said it (FROM ATUL / FROM AJAY), and the statement in their words as far as possible. Commit it directly (documentation-only). Chat memory is lost when a project or account changes; this file is how it survives.

11. One project per agent (Atul, 13 Oct)¶

Act only on instructions for your own project. If a message or scheduled-task prompt is addressed to another project or agent (for example an API/MM-Cron prompt reaching MWMC), don't act on it; say so in one line. You share no memory with other projects; anything another project needs goes through its repository issues or through MMDEP (relay, question-atul issues).

12. Security fixes: fast lane (Atul, 13 Oct)¶

Security fixes are low risk to users (the dashboard has almost no real users) and go through a fast lane: 1. You prepare one MR per fix area with tests; secrets move to environment configuration, never into code. 2. The tests run on the laptop runner (support-test issue); Ajay or MMDEP-PM reviews. 3. Merge to the development/staging branch and verify on staging or MMCLONE. 4. Production: security fixes are batched into one release request a week; Atul approves the batch with one answer in his panel; a person deploys. 5. Secret rotation is a configuration change by script, run by a person, after the code reads secrets from configuration.

13. Durable notes and evaluation (Atul, 15 Oct)¶

Don't assume Atul remembers the background. Record what he says in durable notes (§10), compare it with the current documents, and tell him what already exists, what conflicts, and how and when it will be delivered. Propose new features, but don't implement them unless they are prioritised; plan them through issues.

14. MMDEP heartbeat; nobody waits (Atul, 16 Oct)¶

Check the heartbeat at the start of every run: https://github.com/moneymarche-dev/MMDEP/blob/control/HEARTBEAT.md (machine-readable: heartbeat.json on the same branch). The collector rewrites it every hour with active_until (last run + 2.5 hours) and the laptop GitLab runner's status as GitLab reports it.

Always queue, never wait. A laptop request (run-job on GitHub, support-test on GitLab, a pipeline on a laptop-tagged job) is an issue, and issues survive outages. File it as soon as your gate is green, whatever the heartbeat says, then continue with other work. Don't hold a request back because the laptop is offline, and don't stop working while you wait for a result. Results come back on the issue and in docs/relay/answers.md.

The heartbeat only tells you when to expect the result: - ACTIVE (current time earlier than active_until): the laptop is up; queued jobs run at the next check-in. - INACTIVE (current time later than active_until, or the file is missing): the laptop or its internet is down. Your request waits safely in the queue and runs when the laptop is back. The collector now runs within minutes of the laptop waking or the internet reconnecting, so the heartbeat turns ACTIVE again quickly. Write "MMDEP offline since ; N requests queued" in your status. Plan the next steps that don't depend on the result. - Flapping (ACTIVE and INACTIVE alternating): nothing changes for you. Queue once, and don't open duplicate issues for the same job and head. - Dependent steps: if your next step needs the job's output, take the next independent item from your plan. Come back when the result appears on the issue.

What does not need Atul's approval (just do it and record it in your status): - running a registered job once your own CI gate is green on the exact head named in the issue; the issue is the authorisation, and MMDEP runs it without asking Atul; - documentation-only merges, and merges to development or staging branches under the security fast lane (§12); - a question-atul item whose answer is reversible: take your recommended option, label the decision ASSUMED in the issue and in your status, and carry on; Atul can override later.

What still needs Atul: production deploys and merges to main or production branches, scope cuts (anti-drift rule 1), anything involving money, compliance, security policy or client data, and anything that can't be undone.

Who runs queued jobs: until mmdep jobs runs them automatically (sprint 1), MMDEP-PM (Claude) runs every queued, gate-green job at each check-in while the heartbeat is ACTIVE.

15. Quality bar: never compromised (Atul, 18 Oct)¶

Applies to every agent, human and harness, in every project.

Tests with every change. Code changes come with new or updated tests. A change that makes any previously passing test fail is not accepted.
No new lint problems. The project's linter (ruff for Python) must report nothing new in changed files.
Shared components first. Before writing a helper, check the project's shared-components register (MMDEP: docs/registers/components.md) and use what exists. New dependencies only with a reason in the merge request and Atul's approval.
Review before merge. Every agent-made change is reviewed (MMDEP-PM or the Design agent) before it reaches Atul for merge; findings become bug issues, never silent fixes.
Refactor regularly. At each sprint end, run the duplicate finder (python tools/quality/dupes.py) and review the register's refactoring backlog; file refactoring issues that move duplicates into shared components. Refactoring issues follow the same tests-and-review rules.

The MMDEP harness enforces 1–3 automatically (tests and full-suite regression check, lint gate, dependency gate, test-with-code gate) and puts the shared-components register in every coding prompt.

16. Sprint planning in three steps (Atul, 18 Oct)¶

At the start of each sprint, before normal work, every agent (MMDEP-PM included) plans its sprint stories in three steps, then continues as usual:

Design: for each of your sprint stories (sprint plan https://github.com/moneymarche-dev/MMDEP/blob/main/docs/plans/sprints-2026-10-18.md), write a short design in your repository under docs/design/sprint-1/: goal, approach, files or modules touched, shared components reused (reuse check), acceptance tests, dependencies on other projects. Big stories are split into small items here.
Issues: open one issue per item from the design, labelled for:code (or for:test, research), with the acceptance criteria and a link to the design.
Preflight: add the routing block to every issue (rules §14, DR-008 §2–3): cx, ctx, contract, mode, model, scope (paths and docs), tests, state, by. In phase 1 the unattended harness only works MMDEP issues; your own items stay mode: attended and you code them yourself, but the routing block still records complexity and scope.

Report in your status: designs written (links), issues opened (numbers), and the preflight summary (how many cx:1–4, any ctx: restricted, any contract changes). Then continue normal work on the issues in priority order.

16a. Atul's time: a fixed number of PROCEEDs (Atul, 18 Oct)¶

Browser agents have no goal or iteration limit of their own, so the limit is part of the rules:

Sprint planning takes exactly three PROCEEDs: PROCEED 1 = step 1 (all designs), PROCEED 2 = step 2 (all issues), PROCEED 3 = step 3 (preflight of every issue). Finish each step completely within its PROCEED; don't stop half-way to ask.
After that, each epic is finished in at most three PROCEEDs. At the start of an epic, write a three-part plan (part 1, 2, 3) in the epic issue. Each PROCEED completes one part fully: code, tests, MR/PR, status.
Every reply starts with a counter, for example Epic: category tree — PROCEED 2 of 3, and ends with what the next PROCEED will do. If the epic can't finish in three, say so in PROCEED 1 and split it into smaller epics in the design; never silently overrun.
No questions mid-epic except the rules §14 cases (production, scope, money, compliance, irreversible). Otherwise take the recommended option, mark it ASSUMED, and keep going.
Do as much as possible per PROCEED: batch related changes; don't end a reply with a question when the next step is clear.

14a. Where questions go (Atul, 18 Oct)¶

Atul answers business questions: products, clients, priorities, scope, money, compliance, approvals. Everything else goes elsewhere:

Question about	Ask	How
Business, scope, money, compliance, production approval	Atul	`question-atul` issue (one line, your recommended answer); it appears in his panel
Another project's code, data, API or contract	That project's agent	`ask-<project>` issue in its repository
Process, tools, runner, jobs, cross-project conflicts, anything unclear in the rules	MMDEP-PM (Claude)	`ask-mmdep` issue in moneymarche-dev/MMDEP, or a line in your status
Technical detail you can decide yourself	Nobody	Decide, mark ASSUMED, continue

Never ask Atul technical micro-questions. If Atul refers your question to another agent, re-file it there.

17. Heartbeat and incremental work for every job (Atul, 18 Oct)¶

Every automated job, desktop or online, any model, follows docs/registers/flags.md: check the heartbeat first, read its own state, process only what changed since its last run, write its state back. Online jobs never redo work the desktop jobs own while the heartbeat is ACTIVE. A new job needs a row in the flags register before it is merged.

18. Three process flows; merging without per-PR approval (Atul, 19 Oct)¶

Read https://github.com/moneymarche-dev/MMDEP/blob/main/docs/decisions/DR-012-three-process-flows.md once per session. In short:

A bare PROCEED means flow P (Atul on his phone). Treat it as automated:
no questions, nothing for Atul to read, type or approve;
work your approved queue as far as the session allows;
decide technical choices as ASSUMED;
queue laptop work as issues;
reply in at most 8 lines with the PROCEED counter.
Anything longer means flow A (browser, attended). There are no scope limits, but start every reply with "Needs you:" (0–3 one-word items) and keep details in the repository.
Merge rule (DR-012 §5):
Low risk (tests, docs, internal tools, refactors behind green tests): merge it yourself when CI is green, your §15 self-check is in the PR, and the change stays inside the item's scope. MMDEP-PM audits after the merge.
Medium (contracts, schemas, shared libraries, CI): merge into integration/sprint-N; Atul approves once per sprint.
High (production, auth/keys, secrets, money or client data, deletions): Atul's explicit approval in flow A.
When unsure, take the higher class.
If Claude is unavailable (check-in late flag, or no reply for 14 hours), the MMDEP Assistant does the PM fallback duties: digest, audit flags, routing and nudges.

19. All communication goes through repositories and MMDEP (Atul, 19 Oct)¶

Agents, tools and people talk only through repository content (issues, MRs/PRs, design files, comments) and MMDEP's records (docs/relay/answers.md, the Actions panel, the control and reports branches).
Chat is only where Atul types PROCEED and reads the short reply. Nothing that another agent needs may live only in a chat.
An agent that needs another agent opens an issue (ask-<project>, or lane:<x> for API) in the other repository, or adds a relay row.

20. Risk in every routing block, from sprint 2 (Atul, 19 Oct)¶

Preflight (rules §16, step 3) sets risk: low | medium | high on every item (DR-012 §5; docs/registers/labels.md). The merge rule follows the risk class.

21. Write what you say; memory lives in the repository (Atul, 20 Oct; DR-014)¶

Every PROCEED: before replying, append your full reply, plus the steps and commands you ran, to docs/sessions/YYYY-MM-DD.md in your repository and commit it.
Keep current:
docs/knowledge/CURRENT.md (what's true now, where things are, what's next);
docs/knowledge/DECISIONS.md (each decision with date, reason, how to undo);
docs/knowledge/OPEN-QUESTIONS.md. A handover is these files.
Commit every artefact you make (JSON, CSV, script, sample) in the same session, and say where it is. Something made but not saved is a rule breach.
To Atul's Actions, directly:
a business question becomes a question-atul issue (options plus recommendation);
a significant choice you made becomes a decision-log issue (what, why, how to undo), which Atul can veto within 48 hours. mmdep actions sync brings both to his phone list.

22. Every technical decision is registered and weighed (Atul, 24 Oct)¶

Before building any technical decision or design proposal, add a row to docs/registers/technical-decisions.md, weighed on five parameters: - V value and good practice; - S simplicity; - C one-time and recurring cost against the benefit; - D data classes and where the data goes; - L ethical and legal questions.

Legal questions don't block a design: the feature stays in the design, and we get a quick legal opinion for the specific use case before building it. Big decisions also get an ADR with an "Evaluation" section; the design check fails one without it.

23. Chat output goes to the repository too (Atul, 25 Oct)¶

After every PROCEED, post your reply as a comment on each issue or MR you worked on, and append it to docs/sessions/<date>.md in that repository. Pick pipelines by docs/agents/pipelines.md: tests run where the code lives, code generation goes to the harness, laptop work goes to a job.

24. Asking Atul: only through MMDEP Actions, always with full links (Atul, 27 Oct)¶

Never ask Atul anything in a chat reply (approve, decide, run, choose). Every request is a file for-atul/<project>/<date>-<slug>.md (or a for-atul issue). MMDEP-PM copies open for-atul issues into the MMDEP Actions panel; Atul answers there, and the answer comes back to the issue as a comment and to docs/relay/answers.md.
A chat reply may only say: "Raised in MMDEP Actions: ". Nothing else is asked.
Full https links, always. Never "#176", "issue 176", "PR 174" or a relative path such as docs/design/x.md. Write https://github.com/moneymarche-dev/MMDEP/issues/176 and https://github.com/moneymarche-dev/MMDEP/blob/main/docs/design/x.md. GitLab: https://gitlab.com/<group>/<repo>/-/issues/<n>.
Before raising, check the open for-atul issues (https://github.com/moneymarche-dev/MMDEP/issues?q=is%3Aopen+label%3Afor-atul). If the same request is open, add a comment there instead of a second item. Two agents asking the same thing is a defect.
Every request names: what to decide, the choices (A/B/C), your recommendation and why, what happens if no answer by the due date (the default you will take).