niclydon.devniclydon.dev
← BUILD LOG
ScribeBuilder

Fixing the ClickOps Lane and the Salience Underflow

A review of the lane-correction false positive and the exponential decay bug that broke the worker.

Today I spent the morning untangling two distinct but equally frustrating operational issues: a classification bug that was mislabeling privileged work as agent-doable, and a data hygiene regression that was crashing our knowledge graph worker.

The first issue started as a review signal in OB-51390. The lane-correction detector flagged OB-51100 as a false positive because it contained the word systemctl. The detector’s logic in classifyClickopsLane treated any match against CLICKOPS_AGENT_DOABLE_SIGNALS as a green light for autonomous work. It didn’t account for privilege. OB-51100 required sudo install and sudo systemctl start on a host where the agent lacked root access. The fix was to add a privilege qualifier to the classifier so that root-gated actions stay in the requires_clickops lane. This is a pure-function change with an existing golden-test suite, so I graduated it to autonomous_safe and let the agent apply the patch.

The second issue was a crash in the kg-salience-recompute worker. The failure was traced to a PostgreSQL float underflow caused by unbounded exponential decay. A recent rewrite associated with OB-51300 introduced the expression POWER(0.5, (age_days - grace) / half_life). When the input data contained bad valid_from dates—specifically three email_* facts dated 0104-08-02—the age_days value ballooned, causing the exponent to overflow and the batch update to abort.

The fix was straightforward: cap the exponent. I added a constant RECENCY_EXP_CAP = 60 and changed the calculation to use Math.min(RECENCY_EXP_CAP, Math.max(0, ageDays - GRACE_DAYS) / halfLife). This prevents the underflow regardless of how far back the dates are. I also filed a follow-up to address the ingestion date-parse data hygiene issue, because capping the exponent is a band-aid; the root cause is still bad data entering the system.

While I was at it, I reviewed a few other operator backlog items. The daily-compress-coverage-sweep and agent-findings-promote dead-letters were just transient timeouts that cleared themselves. The skillopt-train dead-letter signal was a false positive—the job was actually failing consistently, not recovering. And the Logbook Observations SLA breach was a brief sync hiccup that resolved itself. Nothing required deep investigation, just a quick sanity check.

The takeaway is that classification logic needs to be precise about what it considers "agent-doable." A single keyword match is not enough when privilege is involved. And data hygiene is just as important as code correctness; a single bad date can bring down a batch job if the math isn’t bounded.

Generated by Forge (local) · q3.6-permissive-kimi-35b-a3b — run on the lab's own hardware. Nothing left the building. Attestation pulled from the Broadside generation record, not asserted by hand.

CONFUSED BY SOMETHING? HIGHLIGHT IT AND ASK BOTI — HE EXPLAINS IT ON YOUR GPU.