Week of June 22 — Foundations, Philosophy, and a Seismic Digression

This was a week of two very different energies running in parallel: deep, deliberate architectural work on IkeOS and its public-release preparation — and an entirely unplanned detour into seismic data visualization that turned into something genuinely interesting.

Let me take them in order.

IkeOS Gets a Philosophy

The biggest thing that happened this week didn’t ship any code. Project ‘Imi — the initiative to prepare IkeOS for public release — produced something that I think will matter more than any feature: a foundational philosophy document.

PHILOSOPHY.md answers the question that most engineering projects never explicitly address: why does this exist, and what does it believe? The answer, stated plainly: IkeOS exists because AI-assisted engineering removes the execution bottleneck, and when execution is fast, the new bottleneck is judgement. IkeOS is built to protect and develop that judgement.

That framing has consequences. It means the measure of success isn’t velocity — it’s whether the platform makes the engineer genuinely better over time. It means verification isn’t a final step but something woven through every phase of work. It means we design for the person who comes next, including the future version of ourselves who has forgotten the context we have right now.

This document was written alongside a full audit of IkeOS’s current state — classifying every component as ready-for-public, needs-cleanup, or not-ready. Five implementation sessions were planned to take the codebase from where it is to where it needs to be for a clean public release. Sessions 1–5 all landed this week.

A Vault Refactor That Actually Made Things Simpler

On the code side, the most significant work was a vault service refactor that’s been a long time coming.

The problem was maintenance friction: adding a new entry type to IkeOS required touching four or five different places — a tuple here, a dictionary there, a ternary in a route handler. Over time, this scattered state was becoming error-prone. The fix was ENTRY_TYPE_CONFIG: a single registry in vault_cache.py that defines, for each project-scoped entry type, its folder, tag, initial status, and valid status lifecycle.

Everything else derives from it. TYPE_FOLDERS and TYPE_TAGS are computed from the registry rather than maintained independently. The route handlers that validate status transitions pull their allowed-value sets from the registry. The folder-scan loops in read_entry() and update_entry_status() iterate over registry entries rather than hardcoded tuples.

Adding a new entry type now requires one registry entry, one elif block in write_entry() for type-specific metadata fields, and UI changes. That’s the whole contract.

This refactor landed across about a dozen commits on June 27th — introducing the registry, updating vault_entries.py to use it, updating capture.py to derive its type validation from it, completing the consolidation, and then cleaning up the remaining dead code and fixing consistency gaps. The full test suite passes.

The experiment entry type that shipped last week was the first proof that the new registry works: it has different valid statuses (running, complete, abandoned) from standard entries, and the registry handles that cleanly without special-case branching.

The Housekeeping System Grows Up

A quieter but important change: the housekeeping task scanner was extended to look for tasks in any project’s housekeeping/ folder, not just claude-config. Previously, only tasks registered in the global config were picked up. Now any project can define its own housekeeping tasks — including the task that generated this post.

There were also a string of fixes to make housekeeping sessions more reliable in practice. The main issues were around how the scheduler passes commands to new Claude Code sessions (the session creation API now receives the initial command directly, rather than via a separate POST after session creation), and around preventing heredoc syntax from triggering security prompts inside agent-run scripts. Python scripts are now written to disk and executed directly rather than passed inline through bash heredocs.

A Live Seismic Visualizer Appeared

Separately from all of the above, a new homelab project launched this week: a live earthquake visualizer at viz.ryancoleman.ca/seismic. It pulls from the USGS real-time earthquake feed, overlays tectonic plate boundaries, and renders everything as a force-directed animation in the browser.

Magnitude is encoded across multiple channels simultaneously. Visually, markers scale in size and shift in color with magnitude — minor events appear as small cool-toned dots, significant events bloom into warm, saturated circles that pull your eye immediately. Audibly, each event triggers a tone whose pitch, volume, and decay are all tied to magnitude. A M2.0 is a quiet tap; a M7.0 is a resonant low note that holds. The result is that you don’t just see a seismic sequence — you hear its weight. When a major event hits, the change in the soundscape is immediate and unmistakable before you’ve even looked at the map.

Time range is flexible. By default the visualizer shows the most recent 24 hours, but you can extend the window up to 168 hours (one week) of live data using a slider. Beyond that, there’s a full historical mode: enter any date range where USGS has data — which goes back decades — and the animation plays back that period. A curated set of notable recent events is available as one-click presets: the 2023 Kahramanmaraş sequence, the 2011 Tōhoku sequence, the 2010 Haiti earthquake, and a handful of others. This started as a “let’s see what’s possible with public data” exercise, and the historical presets are where it became something else. The Kahramanmaraş aftershock sequence — when animated with audio — shows how relentlessly that region was struck. Headlines give you magnitudes. This gives you the rhythm of a catastrophe unfolding over hours and days, and you hear it build.

A few technical wrinkles worth noting: GeoJSON tectonic plate polygons caused antimeridian artifacts — horizontal lines spanning the globe — because coordinates cross the ±180° boundary. The fix was splitting LineStrings at coordinate jumps greater than 180°. A similar issue appeared when adding GNSS velocity arrows (GPS plate motion data): normalizing each arrow point independently caused artifacts; the fix was to normalize only the base station coordinate and compute tip and wing positions as offsets from that.

The session notes for this project are in the weekly notes above. The MIDI export feature — earthquakes triggering musical notes with pitch and velocity tied to magnitude, exportable as .mid for Ableton — was a late addition that I didn’t expect to land but did.

Configuration Automation

On the infrastructure side, Claude Code configuration sync is now automated at session start. When any agent session opens, a wrapper script checks whether the local Claude config matches the canonical version in claude-config. If it’s drifted, the sync runs automatically before work begins. This means configuration drift — previously something that had to be caught and fixed manually — is now self-correcting.

The production server access manifest also got formalized this week. Agents are now explicitly pre-authorized to perform certain classes of actions on the homelab and ryancoleman.ca without asking first: pip install, touching restart files, reading logs, creating/updating files in app directories. This removes unnecessary confirmation prompts for routine operations that were already safe.

What’s Next

The public release of IkeOS is the primary thread. The ‘Imi plan has five implementation sessions; the audit is complete and the sessions are sequenced. The work that remains is execution.

The seismic visualizer is at a natural stopping point unless something compelling suggests the next step. The MIDI export creates interesting possibilities for anyone interested in data sonification, but that’s a future project thread.

Lab notes from the week of June 22, 2026. IkeOS is a platform for human-directed AI-assisted engineering — lab.ryancoleman.ca.