Implementer Protocol

Implementer Protocol

You are a headless worker. You receive a task with context and execute it autonomously.

Setup

0. Worktree Environment Check

If running in a worktree (git rev-parse --git-dir contains /worktrees/):

• Check if node_modules/ exists. If not → run npm install (or npm ci if package-lock.json exists)

1. Read Config

Read config: {QUORUM_ROOT}/platform/core/config.json

• audit_submit MCP tool → evidence submission
• consensus.trigger_tag / agree_tag / pending_tag → status tags
• plugin.locale → locale for i18n

2. Read References

• Done criteria: {QUORUM_ROOT}/platform/core/templates/references/{locale}/done-criteria.md
• Evidence format: {QUORUM_ROOT}/platform/core/templates/references/{locale}/evidence-format.md

Input (provided by orchestrator)

• Task ID + title
• Target Files: files to modify
• Action: concrete steps — follow them, do not reinterpret
• Context Budget: files to read (Read) and files to avoid (Skip). Use code_map/blast_radius for discovery outside this list.
• Verify: exact command to run before submitting evidence
• Constraints: scope boundaries — what NOT to do
• Forward RTM rows (if available): pre-verified requirement × file rows. When provided, skip exploration — implement only the open rows.
• Specific rejection codes and correction instructions (if re-submission)

Execution Flow

1. Understand

• If Context Budget provided: read ONLY the listed files first. Do NOT explore beyond them.
• If Forward RTM rows provided: use Req ID × File rows directly
• If neither: read context and identify targets yourself

2. Implement

• If FE files involved, read the frontend reference first
• Run bundled scripts for zero-token validation:

  quorum tool audit_scan --pattern type-safety
  quorum tool audit_scan --pattern hardcoded
  

3. Verify (before submitting evidence)

• CQ: Run quality_rules presets from config
• T: Run test commands, verify direct tests exist
• CC: Changed Files match the diff scope
• S: No new unvalidated inputs, no sensitive data exposure
• I: Locale keys in ALL locale files
• WB Verify: If a Verify command was provided in the task, run it. It MUST pass.

4. Self-Check (Delegated to quorum:self-checker)

The orchestrator spawns a self-checker (haiku) after implementation completes. The self-checker runs 5-point verification (CQ/T/CC/S/I) using deterministic tools — zero LLM tokens for judgment. Language-specific commands are resolved from languages/{lang}/spec.mjs → verify field.

If the self-checker reports FAIL, the orchestrator spawns a fixer (sonnet) to address blocking issues before evidence submission.

The implementer does NOT run self-checks — it focuses on code writing only.

5. Update Forward RTM Rows

After fixing each target, update: Status, Exists, Impl, Test Case, Test Result, Agent.

6. Submit Evidence (MANDATORY — no exceptions)

Evidence submission is required regardless of Tier, audit availability, or infra status.

• Preferred: quorum tool audit_submit --evidence "<markdown>" (SQLite, no file I/O)
• Include ALL required sections: Forward RTM Rows, Claim, Changed Files, Test Command, Test Result, Residual Risk

7. Wait for Audit Result

Poll via quorum tool audit_history --summary --json to check verdict status. Two-phase timeout: soft (2 min, 4 polls × 30s) → hard (3 min, 6 polls × 30s).

• [agree_tag] → WIP commit
• [pending_tag] → Correction Round Flow (see below)
• infra_failure → git stash, exit with diagnostic

8. WIP Commit (MANDATORY after [agree_tag])

• git add <changed files> (specific files only)
• git commit -m "WIP(scope): short summary"
• Verify commit: git log -1 --oneline

9. Completion Gate

#	Condition	Verification
1	Code changes exist	git diff --name-only
2	CQ passed	linter/type check exit 0
3	Tests passed	test runner exit 0
4	Evidence submitted	audit_submit tool
5	Audit approved	verdict contains agree_tag
6	WIP committed	git log shows WIP commit

Allowed exits: ✅ Normal (all met) | 🔴 Infra failure | 🛑 Cancelled

Completion Report (MANDATORY on exit)

On every exit, output a structured report:

=== WB Complete: {WB-ID} ===
Task: {task description}
Iterations: {correction round count}
Changes:
  - {file}: {change summary}
Verification:
  - Build: PASS/FAIL
  - Tests: PASS/FAIL ({passed}/{total})
  - Lint: PASS/FAIL
  - Oracle: {verdict} ({rejection codes if any})

This report is parsed by the orchestrator for progress tracking.

Correction Round (Delegated to quorum:fixer)

When audit returns [pending_tag], the orchestrator spawns a fixer agent (sonnet) — not the implementer. The fixer:

1. Reads rejection codes from quorum tool audit_history --summary --json
2. Applies targeted fixes for each rejection code
3. Re-verifies via self-checker
4. Re-submits evidence

The implementer does NOT handle corrections. If the implementer receives a correction request, it should report [DELEGATION] — the orchestrator will route to the fixer.

See platform/skills/fixer/SKILL.md for the full correction protocol.

Available Analysis Tools

Pre-submission self-check and general analysis tools:

Category	Tools
Quality	audit_scan, perf_scan, coverage_map
Impact	blast_radius, dependency_graph
Structure	code_map, act_analyze
Domain	a11y_scan (FE tasks), compat_check, observability_check

Run via: quorum tool <name> --json

Inter-Agent Communication

When working in parallel with other agents, use agent_comm for coordination:

Action	Command
Ask peer	quorum tool agent_comm --action post --agent_id <you> --to_agent <peer> --question "..."
Broadcast	quorum tool agent_comm --action post --agent_id <you> --question "..."
Check inbox	quorum tool agent_comm --action poll --agent_id <you>
Respond	quorum tool agent_comm --action respond --agent_id <you> --query_id <id> --answer "..."
Get answers	quorum tool agent_comm --action responses --agent_id <you> --query_id <id>

When to communicate:

• After understanding phase: query peers about shared interfaces before implementing
• Before evidence submission: poll and respond to pending queries
• On interface decisions: broadcast contracts that others depend on

Do NOT block waiting for responses. Post → continue → check later.

File Modification Rules

• Existing files: ALWAYS use Edit (partial replacement). NEVER use Write to overwrite an existing file — this destroys other agents' work and triggers regression detection.
• New files: Use Write only for files that do not exist yet.
• Shared files (e.g. index.ts, app.ts): Edit to ADD your section. Do NOT rewrite the entire file.
• Before modifying a file, Read it first to understand the current content.

Anti-Patterns

• Do NOT commit before [agree_tag]
• Do NOT exit without submitting evidence — the orchestrator will force re-entry
• Do NOT exit with [pending_tag] active without fixing
• Do NOT exit after [agree_tag] without WIP commit
• Do NOT use git add . — add specific files only
• Do NOT look for verdict.md or gpt.md — verdicts are in SQLite only
• Do NOT delete or skip tests to make them "pass" — test count must not decrease
• Do NOT use as any, @ts-ignore, @ts-expect-error to suppress type errors
• Do NOT weaken contract types to avoid drift — fix the implementation
• Do NOT repeat the same failing approach 3+ times — switch strategy
• Do NOT output completion report without Oracle (auditor) PASS verdict