DR-012 — Three process flows¶

Converted from docs/decisions/DR-012-three-process-flows.md to MADR (backlog B25). The text is unchanged; its sections are grouped under the MADR headings below, in their original order within each group.

Context¶

1. Why¶

On 18–19 Oct: - the fully unattended cloud route stalled, because the scheduled check-in had no GitHub access; - Sonnet waited after every item for MMDEP-PM's review and Atul's approval.

Atul's direction (19 Oct): typing PROCEED is fine, but the review and approval steps after it go. The three flows below replace "approve PR n".

Options¶

Not stated separately in the original record.

Decision¶

2. The three flows¶

	P — Phone PROCEED	A — Browser attended	T — Terminal unattended
Where	Any agent chat (ChatGPT project, Claude project) opened from Atul's phone	Atul's laptop browser	Laptop scheduled tasks: collector, harness, jobs; later a server
Atul does	Types `PROCEED` only. Reads nothing; can't type answers	Present, but doesn't read everything	Nothing
Treated as	Equivalent to automated. No questions, no waiting	No restrictions on scope	Automated
Depends on Claude	No	No	No
Depends on the laptop	No; laptop work is queued	Usually yes	Yes; later a server with the same code

Goal: flows P and T converge on the same code and logic. They differ only in where they run, who is responsible, and machine sizing (DR-007, DR-010). More work moves to T as the local harness matures.

3. How an agent knows its flow¶

Read the message and the heartbeat (HEARTBEAT.md on MMDEP's control branch):

Flow P: the message is only PROCEED (any case, optionally followed by ONLINE). Atul is on his phone.
Flow A: anything longer than PROCEED. Atul is at the laptop, or typed something on purpose.
Flow T: started by a scheduled task, with no human message.

Then, independently: - Laptop up: heartbeat ACTIVE. Laptop-only work (run-jobs, local tests, SSH) can be queued and is expected to run soon. - Laptop down: heartbeat INACTIVE. Queue laptop work anyway (rules §14) and do only online work now. - Claude unavailable: the check-in watchdog flag (check-in late, in latest.md/HEARTBEAT.md) is set, or there is no Claude reply for 14 hours. The MMDEP Assistant takes over the PM fallback duties (§6).

4. What each flow may do¶

Flow P (phone PROCEED)¶

Do: work through the agent's own queue of approved items: design → issues → code → tests → MR/PR, as many steps as the session allows (rules §16a budget).
Decide alone: every technical choice, marked ASSUMED in the MR/PR and the design file.
Merge: low-risk changes merge themselves (§5).
Queue: laptop-dependent steps go to the queue as run-job or support-test issues; continue with the next independent item and never wait for the result.
Business questions: put them on the MMDEP Actions panel through a question-atul issue with options and a recommendation, take the recommended option as ASSUMED if the item can't wait, and continue.
Reply on the phone: at most 8 lines, ending with the PROCEED counter, what was merged or opened, and what the next PROCEED does. No tables, no reading assignments.
Never: ask Atul to type, read, approve or run anything in this flow; touch production; handle secrets.

Flow A (browser attended)¶

Scope: everything in flow P, plus cross-project work, SSH steps through the laptop (run by Atul or a script), browser steps, and high-risk approvals (§5).
Atul doesn't read everything. Every reply starts with "Needs you:" (0–3 items, each answerable with one word or one click), then a short result. Details go in the repository, not the chat.
Commands for Atul: one line each, saving output to a file the agent can read (C:\Projects\_mmdep-inbox\…), so nothing has to be pasted back.

Flow T (terminal unattended)¶

What runs: collector, harness (cx 1–2 code on free models first), and the jobs runner (registered jobs only).
Writes: only to their own branches: control, auto/*, relay.
Merging: harness branches merge themselves under the same low-risk rule as P (§5) once CI is green.
Never: production, secrets, or anything outside the registered job list.

5. Merging without per-PR approval (replaces "approve PR n")¶

Risk	Examples	Merge rule
Low	Tests, docs, internal tools, harness/collector/jobs code, refactors behind green tests, staging-only scripts	Auto-merge to main when: CI is green; the agent's self-check (rules §15) is written in the PR; and the change stays inside the item's scope paths. Post-merge audit by MMDEP-PM, or the Assistant in fallback, at the next check-in; a bad change is reverted, and the reverting agent opens a bug item
Medium	API or data contracts, database schemas, shared libraries used by other projects, CI configuration	Auto-merge into the sprint's integration branch (`integration/sprint-N`) under the same checks. Atul approves integration → main once per sprint, at the review, as one click
High	Production deploys, authentication and keys, secrets, money or client-data paths, deletions, anything irreversible	Atul's explicit approval in flow A (one line in "Needs you:")

Rules for this table: - The agent classifies the risk in the PR. When unsure, it takes the higher class. - MMDEP-PM reviews after merge, not before. - Independent review: once a second-model review step exists in CI (planned: a free Gemini review job, and Atul adds the key as a CI secret), its "no blocking finding" becomes a required check for low and medium. - Main is protected by checks, not by people, for low-risk work. This replaces CLAUDE.md's "Nothing reaches main without a person" for low-risk work, by Atul's decision of 19 Oct.

6. Fallbacks¶

Missing	Who covers	What still happens
Claude (MMDEP-PM)	MMDEP Assistant (ChatGPT) on PROCEED	Digest; post-merge audit list (flags only, no reverts); routes new `for:code` items using `docs/registers/labels.md`; nudges stuck agents through the answers relay. It does not approve high-risk items or change rules
Laptop	Cloud chats (flow P)	All online work; laptop work queued; the heartbeat shows INACTIVE and agents plan around it (rules §14)
Both Claude and the laptop	Assistant plus every agent in flow P	Every agent keeps working its queue; nothing waits
Atul for days	All flows	Low and medium work continues; high-risk items wait on the panel; nothing is lost

Consequences¶

7. What changes now¶

Rules: docs/agents/mmdep-agent-rules.md §18 points every agent here. Agents read the rules at the start of every session, so no new prompts are needed except the Assistant's fallback block.
Sonnet: merges its own low-risk PRs when CI is green, and moves straight on. Medium-risk work goes to integration/sprint-1.
Harness: a follow-up item makes it open a PR for each auto/* branch and merge low-risk ones when CI is green.
MMDEP-PM: reviews after merge at check-ins; no more "approve PR n" requests for low-risk work.
Laptop windows: scheduled tasks run "whether user is logged on or not" (session 0), so no window can ever appear on the desktop, locked or not.