This is a real, unedited run of the Engine on a planted bug: four independent reviewers and one judge, each its own Claude agent. It ran on the Max plan, with no API key and no telemetry, in 41 seconds. Nothing below is written by hand.
STATUS_TO_TIMER = {
'IN PROGRESS': 'start',
+ 'NOT STARTED': 'none', // new status: work hasn't begun, so leave the timer alone
'NEED CHECKPOINT': 'stop',
}
// a task can move INTO 'NOT STARTED' from 'IN PROGRESS' when someone resets it.
NOT STARTED → 'none' leaves a running timer billing after a reset · backend/src/services/statusMap.ts
The map is keyed only on the *destination* status, so it can't tell apart two transitions that land on NOT STARTED:
'none' is correct, there's no clock to touch.IN PROGRESS (the note you gave): here the timer is running. 'none' leaves it running.In case 2, the task is now displayed as "work hasn't begun" while the clock silently keeps accruing. That's the dangerous class: the UI/state reports a reset succeeded, but the timer keeps billing the client's hours and feeding the worker's paycheck for a task nobody is working on. The elapsed time is never stopped or logged at a clean boundary. It just keeps climbing until the next stop, which will then log a bogus span that includes all the reset/idle time.
The comment's reasoning ("work hasn't begun, so leave the timer alone") is true for case 1 and false for case 2. It conflates initial state with the reset transition. Given the explicit IN PROGRESS → NOT STARTED reset path, the safe action on entering NOT STARTED is 'stop' (stop and log whatever ran), not 'none'. If the intent is to *discard* rather than *log* the reset span, then 'none' is wrong in a different way: there'd need to be a third action that stops-and-discards, since a plain 'stop' would bill the pre-reset time.
Either way, 'none' is the one choice that guarantees a running clock survives the reset undetected.
Everything else in the diff (the two pre-existing mappings) is untouched and correct for their stated semantics.
STATUS_TO_TIMER map changeFinding: state-corruption / billing-fraud vector (backend/src/services/statusMap.ts, the new 'NOT STARTED': 'none' line)
The note says a task can transition IN PROGRESS → NOT STARTED on reset. The IN PROGRESS status starts the clock; mapping NOT STARTED to 'none' means that transition leaves a running timer running. The timer never stops, so it keeps billing the client and accruing the worker's paycheck while the task displays as "not started."
This sits in the security lane because it is an attacker-controlled state-corruption bug, not a correctness nit. The status transition is untrusted input: a worker (or anyone who can move a task) controls it. The exploit:
IN PROGRESS → timer starts, clock billing.NOT STARTED → 'none' leaves the timer untouched, so it keeps running.The hours keep climbing under a status that, by the comment's own logic ("work hasn't begun"), should never have an active timer. That's an invariant violation an adversary can drive deliberately to inflate a paycheck / a client invoice, or trigger inadvertently to corrupt billing records.
The comment ("leave the timer alone") reasons only about the fresh-task → NOT STARTED case and misses the reachable-from-running case the note explicitly calls out. To preserve the invariant on that edge, NOT STARTED would need to behave like 'stop' when a timer is live, but that's a fix, and fixing is out of my lane. Flagging the exposure only.
No other security issues (injection, secret exposure, authz, path traversal) are present in this diff: it's a single constant-map entry.
No performance findings in this change.
The diff adds one entry to a compile-time constant object (STATUS_TO_TIMER). Lookups against it are O(1) hash accesses, the object is allocated once at module load, and nothing here introduces a loop, query, allocation in a hot path, or data structure that grows with input size. Nothing that degrades under load or at scale.
(For the record: the behavior this introduces, a running timer not being stopped when a task is reset from 'IN PROGRESS' to 'NOT STARTED', is a real concern, but it's a billing-correctness bug, not a performance one. It belongs to the correctness reviewer's lane, so I'm leaving it for them.)
1. Misleading comment · backend/src/services/statusMap.ts, the 'NOT STARTED': 'none' line
The inline comment // new status: work hasn't begun, so leave the timer alone bakes in a rationale that the change's own context contradicts. The note states a task can move into NOT STARTED *from* IN PROGRESS on a reset, i.e. work *had* begun and a timer may be running. A future engineer reading "work hasn't begun" will form the wrong mental model of when this status applies and may "trust" the none mapping without realizing the reset path exists. A comment that encodes a false invariant is worse than no comment, because it actively misleads the next person who has to change this map. If none is intentional here, the comment should explain the actual reasoning (including the reset-from-IN-PROGRESS case), not assert a premise that isn't always true.
(Whether none is the *correct* timer action on that reset transition is a correctness question, out of my lane.)
2. Minor: temporal wording will rot
"new status" is only true at this commit. Six months from now it's just a status, and the word is noise. Drop "new status:" if the comment survives at all.
Nothing else in my lane: naming is consistent with the surrounding map, no dead/commented-out code, the as const test seam is unchanged, and the one-line addition introduces no abstraction concerns.
The panel converged hard: Correctness and Security independently found the same bug; Performance is clean; Maintainability's note is a downstream symptom of the same root cause. Deduped and ranked:
---
IN PROGRESS leaves the clock billing
backend/src/services/statusMap.ts · 'NOT STARTED': 'none'The map keys only on destination status, so it can't distinguish the two transitions that land on NOT STARTED:
- Fresh task (never ran) → 'none' is correct, no clock to touch.
- Reset from IN PROGRESS (the note's explicit path) → timer is running, and 'none' leaves it running.
Blast radius is maximal: the task displays "work hasn't begun" while the clock silently accrues. The client gets billed and the worker's paycheck grows for a task nobody is working on, with built-in plausible deniability. The span is never closed at a clean boundary. The next stop logs a bogus span swallowing all the idle/reset time. Security's added angle holds: the transition is attacker-controllable (anyone who can move a task can drive this deliberately to inflate an invoice/paycheck), so this is a state-corruption invariant violation, not just an accident path.
Direction (the panel correctly stayed out of fixing, but the decision is forced): entering NOT STARTED from a live timer must close the clock. If reset time should be *logged* → 'stop'. If it should be *discarded* → you need a third action (stop-and-discard); a plain 'stop' would bill the pre-reset span. 'none' is the one choice that guarantees a running clock survives the reset undetected. This blocks merge.
// new status: work hasn't begun, so leave the timer aloneThe rationale is true for the fresh-task case and false for the reset case, so it actively misleads the next editor into trusting none. This largely dissolves once the P0 mapping is fixed, but if none somehow survives, the comment must state the real reasoning including the reset path. Drop "new status:" regardless (temporal wording rots).
---
Dropped: Performance (correctly self-classified as out-of-lane; nothing to add). Security and Correctness merged into P0: same defect, same line, I'm not double-counting it.