audit
Technical notes on web development, DevOps, and AI integration.
6 articles
- 19:31backend
Removing a Status Guard, Keeping One Hard Rule
Dropping a forward-only guard on a booking state machine, and why one hard rule beats a total ban for real accountability.
TL;DR: The author replaced a rigid forward-only state machine guard with one hard rule: rejecting a ticket requires a written note and notifies the applicant. The guard blocked legitimate fixes and pushed admins into duplicate-ticket workarounds. Removing it shifted safety from blind prevention to auditable accountability.
#workflow#backend#state-machine - 15:19backend
Recovery-Only Rebuild: Lessons from a Corrupted Ledger
A rebuild turned 20 healthy ledger rows into 77 UNKNOWN. The fix: a recovery-only contract that fills gaps and never rewrites healthy rows.
TL;DR: A rebuild tool corrupted a court-rulings ledger, inflating twenty healthy rows to seventy-seven, mostly tagged UNKNOWN. The cause was structural: per-tab raw files re-parsed as new records, proving raw-is-truth doesn't make re-parses safe. The redesign makes rebuild recovery-only: healthy rows stay verbatim, only missing cases are appended, sub-tab files are skipped, and any UNKNOWN aborts all writes.
#python#data-engineering#sqlite - 15:19backend
Tracing Harvested Data with Agent Guardrails and SQLite Logs
Two local guards for scraping pipelines: an AGENTS.md rulebook for coding agents and a per-target SQLite audit log made idempotent with UPSERT.
TL;DR: When a harvest run died, git couldn't trace which commit produced the data—it records file changes, not execution context. The fix was two guards: an AGENTS.md rulebook forbidding writes to harvested data and secrets in commits, plus a per-target SQLite audit log. UPSERT on a unique commit-case-tab key keeps re-runs idempotent, turning provenance recovery into a single query.
#sqlite#scraping#audit-trail - 11:14backend
Through One Door: A Retry-Safe Harvest Ingest Contract
A scraping workspace kept apart from the app, and a replayable single-door API delivery: resumable queue, stable dedupe key, ship log.
TL;DR: A mid-run interruption exposed the risk of writing scrape results straight into the app database, so this commit isolates all scraping tools and stores per-page, per-subtab queue rows with status and attempt logs on disk. Resuming is then deterministic. Shipping happens separately through one ingest endpoint, using stable deduplication keys and exponential backoff so idempotent retries make replays safe.
#scraping#idempotency#data-engineering - 10:30backend
The Raw-First Pattern for Gated Data Harvests
Why gated data harvests save verbatim raw text before parsing: an idempotent ledger, a resumable cursor, and retroactive rebuilds.
TL;DR: When scraping captcha-gated, session-locked court portals, save the verbatim rendered text first and parse later from local files. Resumable cursors and idempotent upserts keep crashes from corrupting data. This bronze-layer approach means parser fixes apply retroactively without ever hitting the fragile site again.
#scraping#idempotency#audit-trail - 13:28backend
A Complaint Born Without a Trace
An empty complaint timeline was not a rendering bug: the first history row was never inserted, because twin functions CreateRegistration and CreateReport had drifted apart.
TL;DR: A new complaint had no status history because CreateReport never seeded the initial NULL-to-submitted row, while its twin CreateRegistration did. The fix wraps report creation in a transaction that inserts both the report and its opening history entry atomically. A new regression test now guards the behavior, highlighting the need to test twin functions side by side.
#golang#mysql#audit-trail