Inkwell 0.15.0 fixes that. A small feeds config block now gives each section its own feed, so you can follow just the writing, just the work, or just this building log at /building/rss.xml. The site root becomes a combined feed of everything, newest first. Child updates link back to their project, and work case studies that only carry a year still get a sensible date.

The update you are reading is already in all three: this section's feed, the combined feed, and the home timeline.

It shipped in Inkwell 0.14.0 as a small piece of quiet-theme JavaScript, plus one change in the image pipeline so each image remembers its original URL. The lightbox shows the true file, not a resized copy. The Domestique screenshots were the reason I finally wanted it.

A project and its updates are a one-to-many relationship, and Inkwell's collections were flat. So a collection can now declare a parent. Update files live in their own folder, each naming its project, and Inkwell routes them under that project, builds the timeline you see here, and surfaces the most recent ones on the home page. A follow-up release (v0.12.0) updated the agent skills to cover it.

The satisfying part is that this very update is the first thing posted through the feature. If the timeline below renders, it worked.

Writing the examples is also the most honest design review I get. Every place the chat app or the coding agent felt awkward to wire up was a place the API needed another look, not the example.

This also lines up with the post I wrote about why Shikisha exists, which goes deeper on the glue-code problem it is meant to remove.

The same day, JPResume switched its LLM transport over to Shikisha, which was the test I cared about: not "does the demo run" but "does another real tool want to depend on this."

I am calling it active development on purpose. The APIs may still move before 1.0, and I would rather say that than pretend the surface is settled.

Under the hood, two cleanups: I pulled the orchestration into a domain-agnostic DocPipeline module, and switched the LLM transport over to Shikisha.

That second one is the satisfying part. JPResume is now the first real consumer of my own workflow library, which is exactly the dependency I built Shikisha to support.

So over a few days I made Domestique bilingual and unit-aware. All the app's strings moved into an xcstrings catalog: the views, the status and error messages, the enum labels, the workout and plan and adherence prose, even the labels inside the SpriteKit game. Then a unit-system preference, so distance, elevation, speed, and weight render in metric or imperial, with a separate toggle for energy in kJ or kcal. The kJ to kcal conversion even does the real division by 4.184 now, instead of the 1:1 stub I had been getting away with.

The same stretch loosened some hard requirements. Garmin sign-in is now optional rather than the front door: you can run the app Strava-only, and the toolbar sync and status pill respect that. The ramp test got smarter too, auto-ending when I fail to hold the step and showing the estimated FTP right there in the cooldown, with per-step coaching cues that no longer overlap.

None of this is glamorous. It is the layer that decides whether the app feels built for me or merely adapted to me, and living between two countries, I notice the difference.

So Domestique grew a Routes library. Import a GPX, save a route from any activity, or pull one of your saved Strava routes, then play it back during a free ride or a structured workout while the elevation profile drives the trainer's simulated gradient. There is a trim editor with draggable chart handles and undo/redo for cutting a clean segment out of a messy GPS track, and you can reverse a route end to end.

The first route I bundled was Mont Ventoux, in three presets for its three classic ascents. Climbing the Géant de Provence from my spare room in Fujisawa, with the resistance ramping up exactly where the real road kicks, is the closest the indoor setup has come to feeling like the outdoor one.

So I wrote it a backend. One Go binary, domestiqued, with a serve | migrate | athlete | token CLI, a SQLite store with embedded migrations, bearer-token auth, and an admin console served right out of the binary. No CGO, no container, no managed cloud. It runs on a small box I control.

On the Swift side, a SyncClient does push and pull deltas in one click: activities and streams, goals and plans and adherence, even the workout game's lifetime stats and per-workout personal bests. Autosave is wired into every place the app changes something, coalesced so a flurry of edits collapses into at most a couple of background pushes. The data model is multi-athlete-ready, so the day I want to share this with a riding partner is a small step, not a rewrite.

It got away from me, in the good way. The rider hops on a trackpad swipe, leans into corners, stands out of the saddle on climbs and tucks on descents. There are day-night cycles, weather, themed environments, parallax birds, and a ghost of your personal-best ride to chase. The finish screen is a real telemetry readout: NP, IF, TSS, time in zone, a power curve, and a stack of career stats that persist across every session.

None of this makes me fitter than a plain target number would. But I finish more of my hard intervals when there is a hill on the screen and a personal best to beat, and that is the only metric that counts here. The pixel art and sound came later, through an Aseprite asset pipeline.

By the end the skeleton was standing. On the analytics side: an activity list with intensity filters, a detail view with the route on a MapKit map, a power and heart-rate chart, a mean-max power curve, and a dashboard of 28-day load with a 180-day PMC chart. On the training side: a hybrid plan engine (calendar anchors plus an adaptive interior, Friel-style phases with auto-recovery weeks), a library of built-in workouts, and a runtime that pushes ERG targets to an FTMS trainer over BLE while it records the ride.

The piece I wanted most was the loop closing: ride a structured workout, have the app score how closely I matched the prescription, and feed that back into what it recommends tomorrow. Everything since has been filling in that frame.

That sounds like a lot for one push, and it was, but it is mostly a faithful Swift port of the LangChain shape, so the design work was deciding what to keep rather than inventing from scratch.

The parts I most wanted were there from the first commit: streaming, tool calling, and streaming JSON output parsers with self-fixing wrappers. Those are exactly the pieces every previous project had been re-implementing by hand.

The rule I settled on is that every page exists in both languages. A page is translated where a .ja.md file exists and falls back to English where it does not, so adding a translation later never breaks a link.

Doing it in my own generator meant I could keep the URL story simple instead of bending the site around a plugin's assumptions.

Content became collections: each one declares where its markdown lives, its route, how it sorts, and which taxonomies it exposes, with per-collection routing instead of one hardcoded blog shape. The same release added author, nav, home, and the content new command for any collection.

The quiet theme shipped alongside it: Fraunces, Manrope, and JetBrains Mono, with portfolio and blog layouts. It is the look this whole site still runs on.

That is the version I wrote about on the blog. The point of JPResume was never to author a resume from nothing. It was to take the English one I already maintain and keep the Japanese 履歴書 and 職務経歴書 aligned with it.

Getting ingestion right is what closes the alignment gap, the thing that otherwise bites you at the worst moment, right before you apply.

PDF support landed here too, on both ends. Input parsing reads an existing resume via PDFKit, with Vision OCR for image-only PDFs, and output rendering produces the 履歴書 and 職務経歴書 with proper Japanese typography.

Separating the deterministic stages from the model stages early is what made everything after this manageable. I can stop at any pause point and look at the artifact before it becomes a document.