Changing how data was passed in made reports suddenly come back in English, and auditing several parts of the system turned up a real bug and a real blind spot
Yesterday was less about building something new and more about checking what already existed. The checking turned up an unexpected bug and an unexpected blind spot.
Asked in Korean, started getting answers in English
I reworked how data gets passed to the AI roles. It used to fetch data on demand by calling tools as needed; I switched it to gathering everything needed up front and passing it in as one batch. Processing speed improved noticeably.
But there was a side effect: reports suddenly started coming back in English. Tracing it down, the Korean data was getting embedded inside English-language system instructions, and the model apparently inferred "this conversation is happening in English."
The fix was simple: explicitly state that the narration must always be in Korean regardless of the language of the source material.
It was a good reminder that when you change how data is passed in, the format itself is a signal to the model, not just the content.
Data archive audit — one bug, one blind spot
The data archive(new tab) umbrella project got another audit pass. Two useful findings came out of it this time.
One was a real bug. There was a mechanism meant to double-record board data so a later observation at the same point in time wouldn't overwrite an earlier one — but a defect let late-arriving backfilled historical data overwrite the newest observed value instead. Fixed by reordering so the newest value always wins.
The other was a blind spot. It turned out that the job linking historical news to tickers was actually only covering a subset of top tickers, not the full universe.
Articles existed for the rest of the tickers, they just weren't being linked. The fix is known; whether to actually apply it is still an open decision.
Second piece of the network watchdog fell into place
Following up on the network watchdog program(new tab) from yesterday's post. WiFi recovery was already built; I added monitoring for remote-access disconnects as well.
The two failure modes carry different risk. If the network itself is down, everything else is stalled anyway, so an aggressive response (even a reboot) is fine. But if only the remote-access program dies while the network is fine, the machine itself may still be running — a reboot is off the table, and recovery has to be limited to gently restarting just that program.
I also verified the permissions in practice: set up the needed permission grants and actually confirmed the service could be restarted under them. All that's left now is deciding to actually flip the switch.
Also this week
- Reviewing the live-trading safety documentation, I found that code the docs described as "not built yet" had actually already been implemented — the docs just hadn't kept up with reality. Since this is the only path that touches real account funds, I started a careful code audit before actually using it.
- Caught my own mistake during that audit: the logic that judged whether data was stale used "today's date" as the reference and didn't account for market holidays, which could trigger false positives even on normal trading days. Rewrote it to use "most recent trading day" instead.
- Cleaned up the logic that used to attempt direct recovery on network failure. The main process no longer tries to recover — it retries a few times and then just skips. Recovery is now entirely the network watchdog's job.
Looking back, yesterday wasn't a day of building something new — it was a day of doubting things that already existed. Three separate places turned out to be hiding things I wouldn't have found otherwise.
Top comments (0)