Skip to content
GitHub
Operations

Candidate Review

Generated

This page is generated from qa/operations/specs/candidate-review.md — the source of truth. Edit the spec, not this page.

Last run: not yet recorded (run the replay suite to populate status).

Overview

The review queue is where the operator dispositions proposed rules outside the chat. It is a two-pane surface: a queue list on the left and the evidence bundle on the right. Selecting a proposed rule in the list loads its evidence into the right pane — the rule statement, where it came from and its source tier, the supporting source excerpt, the automated checks, any conflict with existing rules, the assistant’s reasoning, a confidence read, and the review-checks result. Beneath the evidence is the sticky decision bar: Approve · Send back · Reject. Reject and Send back require a rationale; Approve does not. The queue is keyboard-forward — A approves, R rejects, S sends back, J/K move between proposed rules. These are the highest-stakes operator decisions.

Preconditions

  • Signed in as the seeded operator.
  • A ruleset with at least one pending proposed rule (produced by the authoring loop).
  • On the review queue (/candidates/pending?world_id={id}).

Scenarios

1. Queue lists proposed rules for the ruleset

  • Open the review queue for the ruleset
  • Expected: The left pane lists the pending proposed rules, each showing its statement, its review state, its source tier, and its proposed-at time.

2. Selecting a proposed rule loads its full evidence bundle

  • Activate a proposed rule in the queue list
  • Expected: The right pane shows the evidence bundle for that proposed rule, with all eight evidence surfaces present: the rule statement, where it came from and its source tier, the supporting source excerpt, the automated checks (with an “n/n passed” summary and the named-check list), any conflict with existing rules, the assistant’s reasoning, the confidence read, and the review-checks result.

3. Approve a proposed rule (no rationale)

  • With a proposed rule selected, open Approve and confirm
  • Expected: An approval decision is recorded; a success indication is shown.

4. Reject requires a rationale

  • Open Reject for the selected proposed rule
  • Expected: The confirm control is disabled and a “rationale required” prompt shows until a rationale is entered; after entering one, confirm records the rejection.

5. Send back requires a rationale

  • Open Send back, enter a rationale, and confirm
  • Expected: A send-back decision is recorded.

6. Cancel a decision

  • Open a decision’s confirm modal, then cancel
  • Expected: No decision is recorded and the modal closes.

7. Empty queue state

  • Open the review queue for a ruleset with no pending proposed rules
  • Expected: An explicit empty state is shown (no proposed-rule rows).

8. Keyboard: A opens Approve for the selected proposed rule

  • With a proposed rule selected, press the A key
  • Expected: The Approve confirm modal opens.

9. Keyboard: R opens Reject for the selected proposed rule

  • With a proposed rule selected, press the R key
  • Expected: The Reject confirm modal opens; because Reject requires a rationale, the confirm control starts disabled.

10. Keyboard: S opens Send back for the selected proposed rule

  • With a proposed rule selected, press the S key
  • Expected: The Send back confirm modal opens; because Send back requires a rationale, the confirm control starts disabled.

11. Keyboard: J/K move the selection between proposed rules

  • With a proposed rule selected, press J then K
  • Expected: The selection moves between rows (clamped at the list bounds); no decision modal opens from a move key.

Test Data

LabelValueNotes
Reject rationaleCitation does not support this rule.Required for reject
Send back rationaleNarrow the predicate to single filers.Required for send back