m-senior-developer
11d1d675dd
Replace the round-1 summariser approach with the full anchor pattern: A. _post_rejection_retrigger(round_, client, issue, verdict_comment_content, logger) - Renamed from _notify_assignee_on_reject - Non-agent/no-assignee path: post a non-mentioning coordinator note and return - Agent path: build full anchor comment via _build_retrigger_comment B. Anchor comment structure (verbatim, no summarising): 1. [@AssigneeName](mention://agent/<id>) 2. Verdict: REJECT (round <id>) 3. ## ANCHOR — Original requirements + full issue description in blockquote 4. ## Why this was rejected + full judge verdict in blockquote 5. ## Instructions for rework + REWORK_INSTRUCTIONS constant (verbatim) 6. Trailing audit line C. Round.retrigger_comment_id + DebateQueue.set_retrigger_comment_id D. 8 required tests (D1–D8): mention, verbatim description, no-drift constant, member skip, no-assignee skip, accept no-op, id persistence, race regression E. test_retrigger_on_reject_end_to_end integration test Removed: _extract_rejection_reasons, _build_rejection_followup (summarisers) Added: REWORK_INSTRUCTIONS constant, MulticaClient.get_agent_name Unit: 63 passed. Integration: 1 passed.
coordinator
Tool-MAD middle-management layer for multica.
Why this exists
Multica's agents produce work and self-set issue status to in_review. Nothing in multica ever looks at that state — it's a dead end. Reviewers, when mentioned manually, tend to catch surface issues (length, structure) and miss semantic ones (scope drift, fabricated experiments, answering the wrong question).
This daemon is the missing middle-management layer. When an issue transitions to in_review, it:
- Convenes a debate round: posts one comment on the issue mentioning a fixed set of debaters, each given a role-specific evidence-gathering prompt (e.g. Senior Developer greps the committed code for LLM API calls; Code Reviewer diffs the described method against the source; Project Manager Senior checks scope satisfaction against the original description).
- Waits for every debater to reply (up to a timeout).
- Posts a second comment mentioning the judge (Reality Checker), with the assembled debater transcript + the original issue body, and a hardcoded decision rule.
- Parses the judge's structured verdict (
VERDICT: ACCEPTorVERDICT: REJECT\n- R<n>: <failure>) and acts:ACCEPT→ PUT statusdone, post acceptance summaryREJECT→ PUT statusin_progress, post rejection listing every failure, re-trigger the original assignee
The pattern is Tool-MAD (Multi-Agent Debate with heterogeneous tool augmentation). Reference: arxiv 2601.04742.
Why debaters catch what a single judge misses
Each debater runs on a different agent (different runtime, different tool access, different role prompt) and is forced to ground its argument in a specific tool's output — not in its own recollection of the text. Example: if the question is "does this paper describe real LLM agent experiments", Senior Developer's grep for anthropic|openai|ollama|model= in the committed code either returns hits or it doesn't — that's a hard fact, not an opinion. The judge reads 4 grounded arguments and applies the decision rule "any debater reporting evidence of scope drift ⇒ REJECT."
A naive LLM-as-a-judge reviewer reads the paper and scores it on surface dimensions. An agent-as-judge driven by debaters catches the underlying substitution. See WYL-41 for the live failure case that motivated this build.
Run
pip install -e .
cat > ~/.coordinator/env <<'EOF'
COORDINATOR_SERVER_URL=http://localhost:8089
COORDINATOR_WORKSPACE_ID=<wid>
COORDINATOR_TOKEN=<coordinator-member-pat>
EOF
chmod 600 ~/.coordinator/env
coordinator
Logs go to stderr and to ~/.coordinator/coordinator.log. State file is ~/.coordinator/seen.json.
Status
- WYL-42 skeleton + watcher (this commit)
- WYL-43 dedicated admin PAT
- WYL-44 hook watcher to real round trigger
- WYL-45 debate round orchestration
- WYL-46 verdict parser + action executor
- WYL-47 dry-run against WYL-41