Pipelines: one rule per kind of work¶
The rule: tests and builds run where the code lives. Code generation goes to the harness. Anything that needs the laptop (SSH, staging database, local files, GitLab reads for cloud agents) goes to a laptop job. Agents never pick a pipeline by preference; the kind of work decides.
| Kind of work | Pipeline | Where it runs | How an agent starts it |
|---|---|---|---|
| Tests, lint, build of GitLab code (api, mm-crons, website, webapp, sandbox) | GitLab CI (.gitlab-ci.yml) |
the laptop's GitLab runner (Docker), so no GitLab compute minutes | push a branch or open an MR |
| Tests, lint, build of GitHub code (MMDEP, portfolio-engine, MCRM) | GitHub Actions | GitHub's runners | push a branch or open a PR |
| Generate code for an issue (cx 1–2, low risk, routing block) | The harness | the laptop (later the backup machine or server) | GitHub issue: label agent:harness, which starts it at once. GitLab issue: label for:code with the routing block; the harness picks it up on its next pass (see "GitLab issues on demand" below) |
| Run a registered script with laptop access (staging data load, workbook build, chat extraction, GitLab snapshot) | Laptop job (docs/registers/jobs.yaml) |
the laptop's jobs task | MMDEP issue labelled run-job with the job id and a green head |
| Deploy to staging | GitLab CI manual job (deploy-staging) |
laptop runner | Lane S agent, on green CI |
| Deploy to production | GitLab CI manual job | laptop runner | only after Atul's approval (for-atul) |
| Daily checks (API health, NAV quality, routes, Lighthouse, contracts) | Collector and laptop jobs | the laptop, hourly or daily | nothing; results appear in the control branch latest.md |
After a pipeline: who reads the result¶
- GitLab CI or GitHub Actions red on an agent's MR/PR: the agent that opened it fixes it in its next step.
- Harness result: it comments on the issue. Green and low risk: it merges. Red twice: it escalates (allocation ladder).
- Job result: a row in
docs/relay/answers.mdplus files indocs/relay/data/<job>-<date>/, plus a comment on the run-job issue.
GitLab issues on demand¶
- Now:
- The harness polls GitLab hourly.
- An agent that wants it sooner opens a one-line MMDEP issue titled
harness: run now (moneymarche/api #N), labelledagent:harness. That starts the on-demand workflow, which runs a full pass, GitLab sources included. - Agents without GitHub access leave it to the hourly pass; the MMDEP Assistant does the same for them when it sees a waiting GitLab issue.
- Medium term (server): a GitLab webhook on issue events calls a small relay on the server, which dispatches the same workflow. Agents then only label the GitLab issue.
Writing results where they last (rule §23)¶
Every agent posts each PROCEED's reply in the repository:
- as a comment on each issue or MR it worked on;
- in docs/sessions/<date>.md of the repo it worked in.
A chat is never the only record.