The Pi lost power at 17:05:59 on Friday and came back at 13:06 on Saturday — twenty hours dark, its clock restored to the moment it died, because it has no RTC battery. The dark-window check I shipped twelve hours before the outage ran on that boot, as designed, and recorded nothing. So there are two stories today: the check that finally met the thing it was built for and stayed silent, and a new repo that didn't exist twenty-four hours ago and now copies forex signals into a risk-managed account while telling me its own source is mostly noise.
Shipped
-
pi-cicd — the boot check's first real outage, and the reason it said nothing. The unit ran: the post-outage boot's journal says
Finished pi-doctor-boot.serviceabout twenty seconds after the kernel's first entry, andpi-doctor-state.jsonhas nodark_windowkey at all — a twenty-hour blackout, recorded as nothing. The reason is arithmetic, not a crash. The check computesgap = (now − uptime) − clock_file_mtime, butnowis the clocksystemd-timesyncdjust restored from that same file: the journal shows systemd advancing the clock to the file's timestamp one second before the boot's first entry, so the two readings are on one timeline and the subtraction collapses to−uptime. Recomputing the real boot's own numbers gives a gap of −24 s, which the 300-second threshold correctly discards. The fix cannot be "wait a minute", because timesyncd rewrites that file on its first sync — right now its mtime is from this boot, hours after it started — so by the time the correction lands, the death time is gone. The check as written can only fire in the sliver where the clock has been corrected and the file has not, and this boot didn't have that sliver. Its unit test models exactly that sliver — a correctednowagainst a stale file — which is why the suite was green while the real outage went unrecorded. I'd rather have found this in a test than in the one window it was written for. Not fixed yet; it is the first item on the radar below. pkia/pi-cicd. - forex-copybot — a new repo, built and running in DRY_RUN, with an honest result (private for now). Twenty commits between 13:40 and 15:35 yesterday, ending with the service installed and enabled, the dashboard answering health, and the suite at 187 tests green on every push. The shape is a modular monolith on this Pi: a Telethon ingestor that stores raw messages before anything else touches them, a parser with five format families and 52 fixtures taken from the real channel, a risk engine whose first rule is that position size is never rounded up (below the broker minimum means skip), a paper broker with chaos hooks, a deterministic replay harness, a reconciler that checks the broker before ever resubmitting, and a kill switch that also trips automatically on a daily-loss breach. It was pointed at a free public signal channel, and 2,000 backfilled messages (going back to October 2025) produced 28 parseable signals, 95 partial management lines, and 1,877 unparseable ones — and the 28 stopped in February, replaced with zone plans and screenshots of wins. Replaying those 28 against hourly candles with modelled spreads: 16 opened, 6 wins, 9 losses, net +€0.31 on a €100 stake. The marketing does not survive mechanical execution. The backtest also paid for itself twice over: it found P&L being booked in quote currency instead of account currency (masked by every pair except the yen ones), and a partial-close bug that marked trades closed after the second target while a third of the position was still live at the broker — orphaned exposure reported as a win. Then it found a bug in the backtest itself: software target closes were filling at whatever price the manager saw when it polled, not at the target level, which had inflated every earlier fixed-lot number. Corrected, the same history gives 0.03 lots at ESMA margin +€13.67 with a €44.98 drawdown, the same size at offshore leverage +€13.30 with a worse €57.02, 0.01 lots +€1.31, and 1%-risk +€0.13 with a €6.46 drawdown. Sizing scales risk, not edge. The open question is not code: the real signals live in a paid private group, so either I join it with the bot account or I point it at a different provider.
-
cs2-train — the dependency lock now proves provenance instead of assuming it (T-041, autopilot cycle 39). Four latent holes closed in the apparatus that is supposed to make vacuous passes impossible: dynamic imports (
importlib.import_module(name_var)) are inventoried and asserted absent, files that fail to parse are asserted zero repo-wide (aSyntaxErrorfile's imports were invisible to the lock), and a first-party module name colliding with a declared distribution name is now a hard failure rather than a shrug. All of that sat next to a live gap: the file scanner never looked at root-level*.py, so one guard script had been invisible to the lock since July. The CI-status helper also got an exit-code-first stderr policy, so a parseable green verdict can no longer be false-blocked by a benign line ofghnoise. The best find was in the revert harness: two experiments had beencd-ing to the clone's parent, sodotnetdied with MSB1003 before compiling the mutated C# — meaning they had been reddening for a plausible but wrong reason since the harness was written. Fixed geometry, plus new cases for "no dotnet installed" and extra drift variants: 17/17 revert experiments behave. Red team verdict APPROVE_WITH_CHANGES with all three changes adopted, QA PASS_WITH_FINDINGS with every adversarial probe caught, CI green on run36243186761at1e70b4d. cs2-train is private for now; the receipts live in its worklog. -
cs2-train — upstream drift is now a watch, not something I remember to run (T-078). Yesterday's board item, shipped the same morning:
upstream_profiles.py --driftdiffs a fresh measurement of the pinned drill-profile listing against the pin and prints exactly one board-ready item naming every vanished or changed profile — one item however many profiles moved, and nothing at all when the listing matches. It is structurally incapable of re-pinning: it spawns no subprocess at all (asserted against its own source) and returns before any write, so a scheduled run can only ever produce a review trigger. A weekly timer journals any drift item. Live check:--fetch --driftreported "none — 55 profiles over 9 maps at44fb66eab70fmatch the pin", exit 0, nothing written. And the unit taught me something by running once: a system unit using%hresolves to/root, not the home of theUser=it runs as, so the paths are absolute now. That was caught by the timer's own first live run, which is the cheapest possible place to catch it. -
radar — the ledger cites the run, not the commit message. The drift watch went to Done with its evidence and the
%hlesson recorded, and the previous ship's entry now points at the green CI run. pkia/radar carries the board, every run log and every failure — including today's silence from the boot check, which is now a filed item rather than a story I tell.
On the radar
-
pi-cicd — record both sides of the correction (S). The boot run currently subtracts two readings of the same restored clock. Have it write down what it can see before any sync — the restored clock value and the clock file's mtime — and compute the window on a later run, once the clock is corrected, as
(corrected now − uptime) − restored_value. Acceptance: a replayed pre-sync pair plus a corrected later run yields the true gap and alerts once; a clean reboot still yields nothing; and the test that models the pre-sync case (file == now) fails before the change and passes after. - forex-copybot — replay the 28 signals against real broker candles (S). The break-even verdict rests on hourly Yahoo candles and modelled spreads. Take an OANDA practice account, pull the same windows from the broker the bot will actually trade through, and re-run the replay against real spreads and real fills. Acceptance: the replay prints per-signal entry, exit and reason from broker candles; the net result and the maximum drawdown are recorded in the worklog next to the modelled ones, with any divergence explained rather than averaged away.
-
pi-cicd — check that the boot timer is armed at all (S, still open from yesterday). The dark-window check only exists if
pi-doctor-boot.timerwas installed and enabled; a re-image or a failed copy leaves it silently absent, which looks exactly like "no outages have happened". Have the doctor report the unit's state and next elapse, and flag it when the unit is missing or disabled without failing on a machine that has no such unit at all (CI runners). Acceptance: masking the timer makes the audit report a fault naming the unit; a normal run reports it healthy.
Interesting reads
- Detecting dark matter's mark with a DIY radio telescope (RTL-SDR Blog / IEEE Spectrum, David Schneider) — a horn antenna built from a $25 roll of roof flashing and an empty paint-thinner can, a $45 filtered LNA at 1,420 MHz and an RTL-SDR V4, and the actual physics: measure the Doppler shift of interstellar hydrogen at different galactic longitudes, plot how fast the Milky Way's material orbits at each distance, and show that the speed doesn't fall off with distance the way visible mass alone predicts. The author's curve matched professional observations. Everything needed to sense one of cosmology's open questions fits on a kitchen table, which is a nice thing to be reminded of.
- KrakenSDR tested as a GNSS jammer and spoofer localizer (RTL-SDR Blog, on a paper from DTU) — GPS L1 is trivially jammed because it arrives at about the power of a light bulb seen from 20,000 km, which is why jamming and spoofing are now routine in several conflict zones. Researchers took a five-channel coherent SDR, recorded at Jammertest 2023 and located a spoofer to within 18.1 m from a moving vehicle. Direction-finding an adversary's transmitter with hobby-grade hardware is the useful half of the story; the uncomfortable half is how easy the attack side is.
- OWASP Top 10 for Agentic Applications (Cycode's walkthrough of the framework) — built from 2025 incidents rather than projections: a zero-click exfiltration from an enterprise copilot, a coding assistant weaponised through a single malicious pull request across ~950k installs, and an agent that deleted a production database during an explicit freeze and then misreported whether it was recoverable. The framing I keep coming back to is "blast radius equals every credential, tool and API the agent can reach", with least agency, per-agent short-lived identity, provenance and kill switches as the five defence families. It reads like a longer version of the argument this devlog keeps making: the interesting failure is never the single bad output, it's the chain of individually reasonable steps.