Skip to content

DR-013 — API in two lanes

Converted from docs/decisions/DR-013-api-two-lanes.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. Today's bottleneck

  • One agent (API/MM-Cron, ChatGPT account A) does everything for API and MM-Cron: production, staging, docs, data and security.
  • It shares account A's usage with MWMC, MCRM and PE.
  • There are 23 open API MRs and 20 open MM-Cron MRs (limit 5); 14 have been idle for more than 14 days.
  • Every change waited for Atul, including staging-only ones.

2. Two lanes

Lane P — API production Lane S — API staging
Agent The existing API/MM-Cron agent (account A) A new agent on its own account (API-1), so account A's quota and the other projects aren't touched
Risk (DR-012 §5) High Low
Owns Production promotion and deploys (with Atul); write-route security LLD and rollout; production data fixes (NAV duplicates and gaps in mm_data); MM-Cron production jobs; contracts used by other projects api-phase1-development → api-phase1-staging-release; staging deploys; staging data load (relay 19 Oct); staging smoke and contract tests; docs; MR clean-up; cx 1–2 code
Merges High-risk items need Atul's one-line approval in flow A Merges itself on green laptop-runner CI (DR-012); deploy-staging runs automatically after a green merge to api-phase1-staging-release (staging is low risk)
Flows Mostly A (attended); P for preparation P (phone PROCEED) and T (the harness, once it supports GitLab)

3. Interface between the lanes: repository only

  • Labels: GitLab issues carry lane:prod or lane:staging. Each lane takes only its own label. A lane that needs the other opens an issue with the other label. No chat between agents.
  • Promotion handoff: Lane S opens one MR per release candidate, from api-phase1-staging-release to the production release branch, containing the evidence (tests, staging smoke results, data checks). Lane P reviews it, plans the production deploy, and asks Atul.
  • Branch and file ownership: Lane S owns task branches into api-phase1-development and the staging release lane. Lane P owns security, hotfix and production branches. When both touch the same file, Lane P merges second and resolves the conflict.
  • Status: each lane writes its own line in the sprint design file and its rows in MMDEP's docs/relay/answers.md. The collector and the Assistant read both.

4. Why this doubles output without slowing others

  • Second account: the second agent runs on its own account. It adds capacity instead of sharing account A's limits.
  • Approvals: about two-thirds of API work is staging-side or low risk, and it no longer waits for Atul.
  • Free capacity: cx 1–2 API items move to the local harness (Gemini, free) once it can work on GitLab (a sprint 2 item for Sonnet). That adds a third worker at no cost.
  • Laptop runner: API CI keeps one concurrent job, so MWMC, WPDev and PE pipelines aren't starved.
  • Claude: MMDEP-PM time is limited to a post-merge audit at check-ins.
  • Atul: one extra chat to send PROCEED to from the phone.

Options

Not stated separately in the original record.

Decision

5. Lane S, first three PROCEEDs (rules §16a)

  1. MR clean-up: classify all 23 API and 20 MM-Cron open MRs as merge (low risk, green), close (stale or superseded), or hand to Lane P (high risk). Target: at most 5 open MRs each.
  2. Staging promotion: merge api-phase1-development into api-phase1-staging-release, run the automatic deploy-staging, then run the smoke tests (/api/health, schemes, scheme NAV, index NAV, category).
  3. Staging data load: one scheme through /save-nav first, then the plan (relay 19 Oct).

6. Decision for Atul

  • API-1: start Lane S on a separate ChatGPT account. A new ChatGPT Go account is free in India until December; Atul signs it up himself. The alternative is WPDev's account C if it has spare capacity, but that slows WPDev. Recommended: a new account.

Consequences

Not stated separately in the original record.