Created
Jun 26, 05:29
Started
Jun 26, 06:03
Completed
Jun 26, 08:03
DevOps handoff
Type
Docs
Shape
—
Worktree Slug
cap-session-concurrency
Repositories
mcritchie-studio
Release Train
—
Branch
feat/cap-session-concurrency
Local URL
—
QA URL
—
Production URL
—
Acceptance Criteria
Expected Test Plan
No expected checks recorded.
Checks Run
No completed checks recorded.
Agent Context
Operator directive: cap parallel work at 5 concurrent operations per session — at most 5 agents / heroku-run dynos / parallel board-writing commands in flight at once, applies to EVERYTHING in a session. WHY: prod board Postgres (essential-0) has a 20 hard connection limit; a heavy QA-release burst (parallel review agents + ship heroku-run dynos + bin/task/bin/release CLI + web/worker pools) spiked past 20 -> FATAL: too many connections -> board briefly 500'd, self-recovered. (DB is only 27MB real data; the 1.62GB storage figure is a stale metric post raw_payload trim — connections are the real constraint, not storage.) EDIT: docs/agents/index.md 'Parallel Work Quick Start' (the AGENTS.md source, installed to root AGENTS.md via bin/install-agent-docs) + the qa-release skill (heaviest fan-out — review in waves of <=5). Doc-only.
Stage Timeline
Who handled each stage, the time it took (measured), and the model / tokens / cost reported (best-effort) — plus who's on it right now. — means the agent didn't report that metric.
Conversation
QA review feedback, agent handoffs, and follow-up notes for this task.
Cap is only in qa-release SKILL.md, not the canonical SOP it defers to: SKILL.md says 'the SOP wins' on conflict, yet devops-cycle-design.md §1.4 step 2 (and the ~line 470 parallel-review block) still says 'review all of it at once / Launch the whole batch concurrently' — leaving the heaviest QA-release burst uncapped and overriding this PR's skill edit. Add the ≤5-concurrent / waves-of-≤5 cap to §1.4 step 2 + the parallel-review line so SOP and skill agree. Also correct the board-DB plan label from essential-0 to essential-1 (the 20-conn ceiling is identical, so the cap stands). AGENTS.md/index.md cap block is solid — keep as-is.
Rework done. (1) Added the ≤5-concurrent / waves-of-≤5 cap to devops-cycle-design.md §1.4 step 2 AND the parallel-review block (step 3), so the canonical SOP now agrees with the skill — no more 'all at once' override. (2) Kept the label essential-0, NOT essential-1: heroku pg:info reports essential-0 live (Connections 7/20); the reviewer's essential-1 was likely from the stale 'essential-1 incident' memory. The 20-connection ceiling is identical on essential-0/1, so the cap stands either way — flagging for the operator if a plan change is actually pending.
SOP §1.4 still uncapped — see PR #224 comment. Add ≤5-concurrent/waves cap to devops-cycle-design.md §1.4 step 2 + the ~L470 parallel-review block so SOP matches the skill; fix essential-0→essential-1 label. index.md cap block is good.
Re-submit (rebased). The prior 'SOP §1.4 still uncapped' blocks were against an 11-behind branch — now rebased clean onto current origin/release (0 behind). The ≤5-concurrent/waves cap is in devops-cycle-design.md §1.4 step 2 (L403 header + L408 'Cap the fan-out at 5 concurrent agents') AND the parallel-review block (L476 'Honor the ≤5-concurrent cap'), plus index.md + the qa-release skill. Plan label kept essential-0: heroku pg:info reports essential-0 live (7/20 conns), not essential-1 — 20-conn ceiling identical so the cap stands.
Sealed-bid sizing
Edit →Alex (PM)
—
Avi (PO)
—
Dev
—
Actual
XL
We emailed a one-tap sign-in link to . It expires shortly and can only be used once.
No email? Check spam, or close this and try again.
