root a50e9586f2
Some checks failed
lakehouse/auditor 13 blocking issues: cloud: claim not backed — "Verified live (current synthetic data):"
auditor: cap auto-resets on new head SHA (was per-PR-forever, now per-push)
Operator feedback: manual jq-edit-state.json + restart isn't
sustainable. Each push should naturally get a fresh budget; old
counter discarded the moment the SHA moves. Cap intent shifts
from "PR exhaustion" to "per-push attempt limit" — bounded
recovery from transient upstream errors, not a forever limit.

Mechanism:
- The dedup branch above (`last === pr.head_sha → continue`)
  unchanged.
- New branch: when `last` exists AND we have a non-zero count,
  AND we've fallen through to here (which means SHA != last,
  i.e. a new push), drop the counter to 0 BEFORE the cap check.
- Cap check fires only on same-SHA retries (transient errors that
  consumed multiple attempts).

Net behavior:
- push code → 3 audits run → cap → quiet → push more code →
  cap auto-resets → 3 more audits → cap → quiet
- No manual jq ever needed in steady state.
- Operator clears state.audit_count_per_pr.<N> = 0 only if a
  single SHA somehow needs MORE than the cap.

Pre-existing manual reset still works (state edit + daemon
restart for the change to take effect). Documented in the new
log line that fires on the rare same-SHA-burned-cap case.

Verified compile (bun build auditor/index.ts → green). Daemon
restart needed to activate; current cycle 4616's `[1/3]` audit
on 6ed48c1 finishes first, then restart.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-27 08:15:06 -05:00
2026-04-22 02:41:15 -05:00
2026-03-27 05:54:09 -05:00
2026-04-22 02:41:15 -05:00
Description
Rust-first object storage system
6.3 GiB
Languages
TypeScript 38.4%
Rust 35.8%
HTML 13.9%
Python 7.8%
Shell 2.1%
Other 2%