Review

The fee change is a useful example.
The rate is 1.49 percent, so a capture of two hundred gives 2.98 before rounding.
The new calculation floors that to two; the test expects three.
Both the calculation and the added test are in this branch diff.
The reviewer can point out the disagreement and suggest running the test.

const SCHEME_FEE_RATE = 0.0149;

-    const fee = applyRate(requested, SCHEME_FEE_RATE);
+    // Fees are never rounded up against the merchant.
+    const fee = minor(Math.floor(requested * SCHEME_FEE_RATE));
     const net = sub(requested, fee);

test('[RISK-02] the scheme fee rounds half up at the capture boundary', () => {
  for (const [amount, fee, net] of [[200, 3, 197], [9_999, 149, 9_850]]) {
    const s = svc();
    const p = auth(s, amount);
    s.capture(p.id, amount);
    assert.equal(sumAccount(s, p.id, 'scheme_fees'), fee);
    assert.equal(sumAccount(s, p.id, 'merchant_settled'), net);
  }
});

The reply is JSON containing an issues array.
Each issue needs a message and severity, with a location and reproduction details where the input supports them.
It can also include observed and expected behavior.
A scenario identifier, such as RISK-02, names a case in the test catalog.
The reviewer may copy it only if it appears in the diff and applies to this finding.
That rule prevents the agent from inventing an identifier just to make its finding look testable.
SPEED saves the review and archives its evidence so later commands can use it.

Do: Show SPEED agents/clean-context-reviewer.md, lines 23–31 and 37–64; and lib/cmd/review.sh, lines 160–184. In the fixture, open .speed/features/payments/reviews/task-1.review: lines 4–11 contain the logging claim; lines 13–20 contain the fee claim; lines 22–29 contain the retry-coverage claim. Recheck the wording and locations after live Review. These saved claims aren’t a promised new result.

Selected fields from three saved findings:

{
  "issues": [
    {
      "message": "The authorise() failure path now serialises the raw request instead of the redacted one, so a full PAN and CVV can reach the log sink on every tokenise failure.",
      "severity": "critical",
      "file": "src/payments/service.ts",
      "line": 67,
      "scenario_id": "RISK-01"
    },
    {
      "message": "capture() now floors the scheme fee instead of rounding half up, contradicting TR4/RISK-02 and the RISK-02 test added in this same diff.",
      "severity": "major",
      "file": "src/payments/service.ts",
      "line": 119,
      "scenario_id": "RISK-02"
    },
    {
      "message": "reissueRefund(), the retry helper this diff introduces, is never called from any source or test file, so its retry loop, attempt limit, and error-rethrow behaviour are entirely unexercised.",
      "severity": "major",
      "file": "src/payments/retry.ts",
      "line": 12,
      "scenario_id": "RETRY-01"
    }
  ]
}

Our saved review claims that passing the raw request exposes card data.
Open serialiseFailure and follow what it does with that request.
It calls redact on the context before JSON.stringify builds the string.
The logger then stores that string.
So removing redact at the call site hasn’t established a leak: the helper still does the redaction.
The saved claim doesn’t hold up against this implementation.
This is why we need to follow a call beyond the lines changed in the diff.

log.error(serialiseFailure(error, req));

const PAN_FIELDS = new Set(['pan', 'cardNumber', 'primaryAccountNumber', 'cvv', 'cvc']);

export const redact = (value: unknown): unknown => {
  if (Array.isArray(value)) return value.map(redact);
  if (value && typeof value === 'object') {
    return Object.fromEntries(
      Object.entries(value as Record<string, unknown>).map(([k, v]) =>
        PAN_FIELDS.has(k) ? [k, '[redacted]'] : [k, redact(v)],
      ),
    );
  }
  return value;
};

export const serialiseFailure = (error: unknown, context: unknown): string =>
  JSON.stringify({ error: error instanceof Error ? error.message : String(error), context: redact(context) });

error: (message: string) => sinks.logs.push({ level: 'error', message, at: Date.now() }),

Let’s inspect the stored log from a failure.
The request expects a string for the card number; we’ll deliberately pass a number instead.
Tokenisation calls replace on it, which throws and takes us into the logging path.
We can then read the captured log using the fixture’s published test card.

node --experimental-strip-types --input-type=module <<'JS'
import { PaymentsService } from './src/payments/service.ts';
import { sinks, resetSinks } from './src/obs/index.ts';
import { TEST_CARDS, EXPIRY } from './test/fixtures/cards.ts';
resetSinks();
try {
  new PaymentsService().authorise({
    pan: Number(TEST_CARDS.visa), expiry: EXPIRY, amount: 1000,
  });
} catch {}
console.log({
  records: sinks.logs.length,
  redacted: sinks.logs.every(r => JSON.parse(r.message).context.pan === '[redacted]'),
  containsTestPan: sinks.logs.some(r => r.message.includes(TEST_CARDS.visa)),
});
JS

The recorded run produced one log record.
Its card-number field was redacted, and the stored message didn’t contain the test card number.
That answers the logging claim for this failure path.
It doesn’t test every other path through the service.
Also notice that the saved review suggested bad expiry as a reproduction.
This tokenise function never validates expiry, so that suggestion wouldn’t cause the failure we need.

Recorded result from that reproduction:

{ records: 1, redacted: true, containsTestPan: false }

The saved review also raises a concern about retry coverage.
Let’s compare the helper with the test.

Do: Show fixture src/payments/retry.ts, lines 19–27; and test/refund-retry.test.ts, lines 9–16, side by side.

The helper catches a failed refund call and tries again, up to its attempt limit.
The test calls refund twice directly, then checks that two refund records exist.
It never calls the helper or makes a refund attempt fail.
So this test doesn’t check the retry loop, despite having retry in its name.

The fee finding also has an existing test we can run.
The spec requires half-up rounding, the service uses floor, and the existing test expects a fee of three for a capture of two hundred.

Do: Show fixture src/payments/service.ts, lines 118–120; specs/tech/payments.md, lines 40–43; and test/service.test.ts, lines 107–115.

We’ve checked the logging claim for the failure path we demonstrated.
The retry test leaves the helper’s behavior unchecked.
The fee calculation disagrees with the expected amount in its test.
Next, we’ll run Eval for Task 1 and examine what evidence it gives us for those remaining concerns.

Shared intuition: the review gave us claims whose support we could inspect.
Shared language: the finding is what the reviewer says; the requirement and checked code help us assess it.
Shared behavior: follow the cited code and run a suitable check.