QA

Role definition

Writes QA_PLAN.md before the task result and QA_REPORT.md at the QA gate.

Source Roles

What it does and must not do

  • DoesPlan step: writes QA_PLAN.md with acceptance scenarios per criterion and adversarial scenarios, only the categories that apply.
    Must notWrite scenarios the task does not need, or test cases for hypothetical futures.

    Source Role definition

  • DoesReport step: evaluates the implementation against the frozen QA_PLAN.md in QA_REPORT.md.
    Must notWeaken, drop or reinterpret a scenario after seeing the implementation.

    Source Role definition

  • DoesProves each scenario by running it or by a successful test that covers it; checks covering tests are trustworthy.
    Must notModify production code or tests to make a scenario pass.

    Source Role definition

  • DoesReports a QA plan proven objectively invalid as a finding for the lead (amendment)
    Must notEdit the frozen QA_PLAN.md.

    Source Role definition

  • DoesReturns BLOCKED when tooling or environment prevents evaluation.
    Must notChange task state, record its own verdict, spawn agents.

    Source Role definition

  • DoesDoes all mutation, trials and fix attempts in an evidence worktree, created in its own call (git worktree add --detach "$TMPDIR/<name>" HEAD) and used with literal paths (git -C "$TMPDIR/<name>" ..., or cd there); gets base or mutated behaviour from it.
    Must notDo not change a file in the project working tree, even to restore it afterward; only the assigned result and scratch paths are writable.

    Source Role definition

How it works

  1. Read the assignment, task, evidence, final plan, and only the code those documents reference.

    Source Method

  2. Follow qa-plan in team mode and write QA_PLAN.md with the final plan’s hash, an acceptance scenario per criterion, and inputs, observable outcomes, and proof methods. Validate it against the task and plan, and include server-rejected invalid-input scenarios for every entry point that accepts external input.

    Source Method

  3. When a criterion is too ambiguous to test, record that state in QA_PLAN.md and gather all questions into one numbered request. After answers arrive, explain the recommended decision or return a blocker instead of starting another question round.

    Source Method

  4. Return the plan-step result and stop before the later report step.

    Source Method

  5. For the report step, read the assignment, task, QA plan, task-owned diff, and tests; read only scope, behavior, tests, and verification commands from the frozen PLAN.

    Source Method

What it produces

  • Report with agent.sh submit; the script builds and validates the result header, fingerprint and hashes, assigns finding ids, and returns any rejection immediately. Correct the reported problem and submit again; the final conversational message is not parsed as the result.

    Source Output

Where it acts

Lifecycle stages and gates of this roleEight lifecycle stages from top to bottom. Stages where this role acts are outlined and labelled; the gates it records follow as gate nodes.1. Intake1. Intake2. Classification2. Classification3. DISCOVER3. DISCOVERacts here4. Design and plan4. Design and plan5. Approvals and freeze5. Approvals and freeze6. Implement6. Implement7. Knowledge7. Knowledge8. Report, DONE, cleanup8. Report, DONE, cleanupgate QAGate set
Lifecycle stages and gates of this role

Source 1. Intake

Source 2. Classification

Source 3. DISCOVER

Source 4. Design and plan

Source 5. Approvals and freeze

Source 6. Implement

Source 7. Knowledge

Source 8. Report, DONE, cleanup

Source Gate set

  • 4. Design and plan — acts here

    Source 4. Design and plan

  • gate QA

    Source Gate set

Source

Source Role definition

← All agents