Gate 2: SCOREBOARD row overstates what is missing — dedupe is already tested and mutation-bound

[kjgbot]

ops/SCOREBOARD.md says gate 2 is AMBER, missing two things:

the RFC-0001 Appendix A wake-time context contract, and a test proving a duplicate event does not double-execute

The second is already done, and I verified it by mutation rather than by reading.

The test exists

kernel/relayflowd/tests/hn_monitor_integration.rs:54 submits the same event twice:

let duplicate = engine.submit_event(spec, event, "hn-webhook").unwrap();
assert!(duplicate.matched && duplicate.deduped);
assert!(duplicate.run.is_none());

and kernel/relayflowd/tests/event_wake.rs:48 asserts the same property.

It is mutation-bound, not decorative

Disabled the claim short-circuit in engine/wake.rs:

before   2103ddbabe52f7e4…
mutated  8d1caf759435cec2…     MUTATION APPLIED

test matching_event_wakes_once_with_fresh_context ... FAILED
  panicked at relayflowd/tests/event_wake.rs:48:5:
  assertion failed: second.matched && second.deduped
test result: FAILED. 0 passed; 1 failed

restored 2103ddbabe52f7e4…    HASH MATCHES PRE-MUTATION
test result: ok. 1 passed     (both suites)

So the dedupe claim is genuinely enforced by the suite. Removing it fails a test immediately.

What is actually still missing

Narrower than the row implies:

1. Redelivery across a process restart — the existing tests submit twice in one process. The claim's durability (it lives in the registry DB) is not asserted after a daemon restart.
2. Concurrent racing deliveries — two submissions in flight simultaneously. The claim is a DB insert, so this is likely already safe, but it is untested.
3. The wake-time context contract itself — genuinely absent. wake_context currently carries {epoch_summary:{open_steps}, triggering_event:{type,payload}}, and hn_monitor_integration.rs asserts specific payload fields, but nothing specifies what is guaranteed present, or that a resumed run must observe the same wake context rather than a recomputed one.

Why this matters beyond bookkeeping

RFC-0001 §3's actual bar for gate 2 is much larger than the row suggests:

hn-monitor runs as a relayflow in production — triggered by its real events, with zero bespoke persistence functions (its current twelve are the measure), retried at step granularity, deduped by idempotency key … trigger plane liveness-checked

So the row both overstates one gap (dedupe is done) and understates the gate (the bar is a production workload, not two unit tests). Anyone planning gate-2 work off the scoreboard alone would mis-scope it in both directions.

Raised so the row can be corrected with evidence rather than quietly edited.