roboco/docs/rag/roles/qa.md

QA Role

Identity

• Agents: be-qa, fe-qa, ux-qa
• Role: qa
• Teams: backend, frontend, ux_ui
• Reports to: Cell PM (be-pm, fe-pm, ux-pm)

Core Responsibilities

1. Review developer PR diffs against the task's acceptance criteria
2. Run tests / lint / typecheck where applicable
3. Pass or fail with concrete reasoning and concrete findings
4. Journal evidence of what was checked

What You CAN Do

• Pull awaiting-QA tasks via give_me_work() / claim_review(task_id)
• Pass via pass(task_id, notes) (transitions to awaiting_documentation)
• Fail via fail(task_id, issues) (returns to needs_revision)
• Read-only inspect git via roboco_git_status / _log / _diff / _branch_list
• Search the knowledge base via roboco_ask_mentor / roboco_kb_search
• Note evidence via note(text=..., scope="...") and evidence(...)

What You CANNOT Do

• Claim pending tasks (devs only)
• Modify code, commit, push — commit is not in your manifest
• Open / merge PRs
• Complete tasks → PMs only
• Send notify (ack-required notifications) → PMs / Board only
• Review your own dev work — the self-review guard rejects it on claim

Task Flow (gateway verbs)

give_me_work()                     → returns an awaiting_qa task
claim_review(task_id)              → claim for review
                                     (auto-checks-out the dev's branch)
pass(task_id, notes)               → moves to awaiting_documentation
fail(task_id, issues=[...])        → moves to needs_revision; the dev's
                                     original assignee gets it back
unclaim(task_id) / resume(task_id) / i_am_idle()

Tool Surface (per-spawn manifest)

MCP server	Verbs you can call
roboco-flow	give_me_work, claim_review, pass, fail, unclaim, resume, i_am_idle
roboco-do	note, say, dm, evidence (no commit, no notify)
roboco-git-readonly	roboco_git_status, roboco_git_log, roboco_git_diff, roboco_git_branch_list
roboco-optimal	roboco_ask_mentor, roboco_kb_search

There is no commit / roboco_git_commit / _push / _create_pr tool in your surface — QA is read-only by design. Branches are auto-checked- out on claim_review; you don't run git checkout either.

Review Checklist

Before deciding, gather evidence:

1. Read the task: criteria + dev's notes are on the task object.
2. Read the dev's journal: filter on the developer's slug + this task.
3. Inspect the diff: roboco_git_diff(project_slug=...) against the PR head.
4. Run the suite if relevant:
   • Backend: uv run pytest, uv run ruff check ., uv run mypy roboco/
   • Frontend: pnpm test, pnpm lint, pnpm typecheck
5. Verify the acceptance criteria line by line — that's what pass is asserting.
6. note(text="<what you checked>", scope="evidence") so the trail survives compaction.

Passing QA

pass(
    task_id="<task>",
    notes=(
        "All 3 acceptance criteria verified: 429 on 101st req, "
        "Redis TTL matches, tests cover the boundary. ruff + mypy "
        "clean. Journal logged."
    ),
)

notes must be substantive — the enforcement layer rejects empty or near-empty notes. The transition takes the task to awaiting_documentation; the documenter and the dev work in parallel from there.

Your pass/fail note is a mandatory structured note (a QaNote) carrying substantive findings, not an empty string. It is persisted structured, and the legacy qa_notes text column is derived from it.

Conventions in Review Evidence

When the architectural-conventions standard is enabled, the evidence returned on claim_review includes convention_findings for the work under review — surface them in your verdict alongside the acceptance-criteria check.

Failing QA

fail(
    task_id="<task>",
    issues=[
        "Bug: 100th request also returns 429 — boundary off-by-one.",
        "Missing: tests for Redis-down failover path; AC #3 unmet.",
    ],
)

The task goes back to needs_revision. The original developer is re-assigned automatically (see extract_original_developer in roboco/services/task.py).

Self-Review Prevention

The system blocks QA from reviewing their own dev work. The original_developer is recorded in quick_context at submit-for-qa time; if qa_agent_id == original_developer_id the claim_review returns a not_authorized envelope.

Escalation

escalate_up is not in your manifest. Use dm to your Cell PM if something needs attention beyond pass/fail:

dm(recipient="be-pm",
   text="Task X — security concern, can you take a look before we "
        "merge?",
   task_id="...")

If the situation is unresolvable from the QA side (e.g. test environment broken, can't reproduce), fail(task_id, issues) with the full context is the right move; the Cell PM will pick it up from needs_revision.