Diagnose

The project also needs to tell Diagnose what to look for.
In speed.toml, classes_file points to the YAML file beside it.
F2 is the cardholder-data leakage category in that file.
It has two rules, and we’re going to read the first one.
The second stays enabled, so it can still appear in the output.

  - id: F2
    title: Cardholder data leakage
    rules:
      - look: added-lines
        match: '\b(log|logger|webhook|telemetry)\s*\.'
        say: "{n} file(s) with an observability sink call in the added lines"

Read the three fields together.
The look field selects added lines, match gives us the pattern, and say gives us the message to write when something matches.
Here the pattern looks for log, logger, webhook, or telemetry at a word boundary.
After that name, it allows whitespace and requires a dot.
So log dot error fits the pattern.
The name “Cardholder data leakage” tells us why the project includes this rule.
The pattern itself only looks for those names and a dot; it doesn’t check the arguments or even require a function call.

When a rule matches, Diagnose records an observation called a signal.
It writes these signals into a file called the risk surface, under the project’s failure categories.
That file also has fields for judgments we’ll make later.
Let’s run Diagnose for the payments task we just opened.

speed diagnose --feature payments --task 1

The console identifies the comparison as main to round-0 and reports two signals under F2.
Each of F2’s rules found something, which accounts for the two entries.
We’ll inspect the first entry.
To explain where it came from, start with the command that read our task record.

The shell joins the configured rules path to the fixture root, then reads Task 1’s JSON.
It takes the branch, agent model, and declared files from that record.
The comment calls out three fields it leaves behind: description, acceptance criteria, and review feedback.
Those fields describe or judge the work; the comment says Diagnose mustn’t take its verdict from them.
The shell then writes the branch diff into a temporary file for the Python engine to read.

The Git helper uses a three-dot comparison.
Here that means changes on round-0 since its common ancestor with main.
The opening showed one commit, but this comparison includes the course setup as well.
The task’s four declared files don’t restrict this diff.
This command shows just the service’s portion so we can find the logging change.

git diff main...round-0 -- src/payments/service.ts

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

Git shows this replacement as a whole added line, even though most of the call stayed the same.
That’s why an added-lines rule will examine it.
The shell sends the diff and rules to Python, along with the declared files and any configured spec path.
Those last two inputs serve other rules; this rule searches the added text.

The Python code walks through the diff, remembering the filename from each file header.
The hunk header supplies the line position.
When it reaches an added line, it removes the leading plus sign and keeps the filename, position, and text together.
For our example, that’s the service file, line 67, and the logging call.
Headers, removed lines, and unchanged lines aren’t entries in this list.
No TypeScript parsing is involved.

The rule’s look field sends that list to the added-lines matcher.
Look at pattern.search: it searches each line using the regular expression from our YAML file.
On the logging line it finds log dot, so count increases by one.
The matcher keeps the filename once and records the matching line and snippet as evidence.
That distinction matters if two lines in one file match: the count is two, but the file list still has one entry.
Several matches on the same line also increase the count only once.

Now read the rule’s message beside that count.
It says “files,” although the code counts matching lines.
We happen to have one line in one file, so the number looks right here.
The engine substitutes that count for the braces in the message and makes one signal for the rule.
It includes the file list and evidence, then the shell writes them to the risk surface.

  - id: F2
    failureMode: "Cardholder data leakage"
    plausible: undecided
    costOfMissing: undecided
    findableByReading: undecided
    signals:
      - observed: "1 file(s) with an observability sink call in the added lines"
        where:
          - "src/payments/service.ts"

There’s the message we just built, with the service path below it.
The three judgment fields remain undecided.
They ask whether the failure is plausible, what missing it would cost, and whether reading could find it.
The writer leaves them open because the match hasn’t answered those questions.
It hasn’t followed the request into serialiseFailure or checked what the logger receives.
A redacted logging call would match too, while a logging name outside this pattern could be missed.

I would describe this result like this.
“The first F2 rule matched the added log.error line in the payments service.
We need to follow serialiseFailure to see what reaches the log.”
That gives another engineer the location and the question to check.
We’ll keep both beside us when we run Review; its input doesn’t include this risk-surface file.

Shared intuition: we can explain the match by pointing to log dot in the added line.
Shared language: F2 is the category, the YAML supplies the rule, and the recorded observation is a signal.
A leak is a claim we’d need to check against what actually gets logged.
Shared behavior: open the named code and follow the data before reporting a defect.