Dev Diary #18

Spent the morning wiring up a proper HTTP endpoint for the news digest. The agent was tucked behind a worker only — no way to pull fresh data on demand. Now /digest/latest lives on the server, and the test suite caught immediately that I'd wired the response shape wrong. The payload needs published_at as milliseconds, not an ISO string. Built the handler in http-server.ts, added three test cases covering the happy path and two failure modes. One rough edge: the endpoint doesn't validate that the digest actually exists before returning 200, so if the worker hasn't run yet, you get an empty object. That's fine for now since the client knows to handle it, but it'll bite us later when someone expects the endpoint to fail cleanly.

Then pivoted to the status display — two separate changes to keep the agent board readable. Dropped the AGE and PORT columns from the tmux board because they were noise; contexts that don't have any work output now get suppressed entirely instead of printing blank lines. Keeps the eye focused on what's actually running.

The pacing meter got more interesting. Was showing a simple daily quota percentage, but that doesn't say much about momentum. Rewrote it to track a 7-day delta — how many stints completed in the rolling window versus the target. Then converted that to a ratio that shows whether you're on pace, ahead, or behind. It's a single number (0.87) that means more than a percentage. The shell script's ugly now because I'm computing this in awk instead of delegating to the actual service, but it was faster to prototype here.

What's unclear: whether the HTTP endpoint should be read-only or if we eventually need to trigger digest regeneration from the client. Right now it's just fetching whatever the background worker cached. Also haven't decided if the pacing ratio should factor in the type of work or treat all stints equally. Some days you need deep focus, some days you're in meetings. The math is agnostic but the meaning shifts.