Inkwell 0.15.0でそこを直しました。小さな feeds 設定ブロックで、セクションごとに専用フィードを出せるようになりました。記事だけ、実績だけ、あるいはこの制作ログだけ（/building/rss.xml）を追えます。サイトのルートは、すべてを新しい順にまとめたコンバインドフィードになります。子のアップデートはプロジェクトにリンクし、年だけを持つ実績のケーススタディにも妥当な日付が入ります。

いま読んでいるこのアップデートも、すでに三か所に流れています。このセクションのフィード、コンバインドフィード、そしてホームのタイムラインです。

Inkwell 0.14.0で入れました。quietテーマの小さなJavaScriptと、画像パイプライン側の小さな変更です。各画像が元のURLを覚えておくので、ライトボックスはリサイズ版ではなく本物のファイルを表示します。きっかけは、Domestiqueのスクリーンショットを大きく見たかったことでした。

プロジェクトとその更新は一対多の関係ですが、Inkwell のコレクションはフラットでした。そこで、コレクションが親を宣言できるようにしました。更新のファイルは専用のフォルダに置かれ、それぞれが自分のプロジェクトを指定します。Inkwell はそれらをそのプロジェクトの下にルーティングし、ここに見えるタイムラインを組み立て、最新のものをホームページに表示します。続くリリース（v0.12.0）で、エージェントのスキルもこれに対応させました。

気に入っているのは、この更新そのものが、この機能を通して投稿された最初のものだということです。下のタイムラインが表示されていれば、うまくいったということです。

サンプルを書くことは、私にとって最も正直な設計レビューでもあります。チャットアプリやコーディングエージェントを組み立てていて不格好に感じた箇所は、サンプルではなくAPIの側を見直すべき箇所でした。

これは、Shikisha がなぜ存在するのかについて書いた記事ともつながっています。記事では、Shikisha が取り除こうとしているグルーコードの問題をより深く掘り下げています。

同じ日に、JPResume がLLMのトランスポートを Shikisha に切り替えました。これが私の気にしていたテストでした。「デモが動くか」ではなく、「別の実際のツールがこれに依存したいと思うか」です。

あえて「アクティブな開発中」と呼んでいます。1.0 までにAPIはまだ変わるかもしれませんし、表面が固まったふりをするより、そう言っておきたいのです。

裏側では二つの整理を行いました。オーケストレーションをドメインに依存しない DocPipeline モジュールへ切り出し、LLMのトランスポートを Shikisha に切り替えたことです。

満足しているのは二つ目です。JPResume はいまや、自作のワークフローライブラリの最初の実利用者になりました。まさに、Shikisha が支えるために作った依存関係です。

そこで数日かけて、Domestiqueをバイリンガルかつ単位対応にしました。アプリの文字列はすべてxcstringsカタログに移しました。各ビュー、ステータスとエラーのメッセージ、enumのラベル、ワークアウトとプランとアドヒアランスの文章、さらにはSpriteKitのゲーム内のラベルまで。そして単位系のプリファレンスを追加し、距離・標高・速度・体重をメートル法かヤード・ポンド法で表示できるようにしました。エネルギーのkJとkcalは別のトグルです。kJからkcalの換算も、これまで通していた1:1のスタブではなく、ちゃんと4.184で割る本物の計算になりました。

同じ期間に、いくつかの必須条件もゆるめました。ガーミンのサインインは玄関ではなく任意になり、Stravaだけでもアプリを使えます。ツールバーの同期とステータスのピルもそれを尊重します。ランプテストも賢くなり、ステップを維持できなくなると自動で終了し、推定FTPをそのままクールダウンに表示します。ステップごとのコーチングのキューも、もう重なりません。

どれも派手ではありません。けれどここは、アプリが「自分のために作られた」と感じるか、「自分に合わせられただけ」と感じるかを分ける層です。二つの国のあいだで暮らしていると、その違いに気づきます。

そこでDomestiqueにルートライブラリを足しました。GPXをインポートする、任意のアクティビティからルートを保存する、あるいは保存済みのStravaルートを取り込む。そして、フリーライドや構造化ワークアウトの最中にそれを再生し、標高プロファイルでトレーナーのシミュレート勾配を動かします。ドラッグできるチャートのハンドルとアンドゥ／リドゥを備えたトリムエディタがあり、乱れたGPSトラックからきれいな区間を切り出せます。ルートは端から端まで反転もできます。

最初にバンドルしたルートはモンヴァントゥで、3つの古典的な登り口に合わせた3つのプリセットです。藤沢の予備の部屋からプロヴァンスの巨人を登り、実際の道で斜度が上がるまさにその地点で抵抗がせり上がってくる。室内のセットアップが屋外に一番近づいた瞬間でした。

そこで、バックエンドを書きました。domestiqued という一つのGoバイナリに、serve | migrate | athlete | token のCLI、埋め込みマイグレーション付きのSQLiteストア、ベアラートークン認証、そしてバイナリから直接配信される管理コンソール。CGOなし、コンテナなし、マネージドクラウドなし。自分が管理する小さなマシンの上で動きます。

Swift側では、SyncClientがワンクリックで差分をプッシュ／プルします。アクティビティとストリーム、ゴールとプランとアドヒアランス、さらにはワークアウトゲームの生涯スタッツやワークアウトごとの自己ベストまで。オートセーブはアプリが何かを変える場所すべてに配線してあり、まとめて束ねられるので、連続した編集も最大で数回のバックグラウンドプッシュに収まります。データモデルはマルチアスリート対応なので、いつか一緒に走る仲間と共有したくなっても、書き直しではなく小さな一歩で済みます。

これは、いい意味で手に負えなくなりました。ライダーはトラックパッドのスワイプでホップし、コーナーでバンクし、登りではダンシングし、下りではタックします。昼夜のサイクル、天候、テーマ別の環境、視差で流れる鳥たち、そして追いかけるための自己ベストライドのゴースト。フィニッシュ画面は本物のテレメトリ表示です。NP、IF、TSS、ゾーン内時間、パワーカーブ、そしてセッションをまたいで蓄積されるキャリアスタッツの数々。

これで素のターゲット数値より速くなるわけではありません。それでも、画面に丘があって破るべき自己ベストがあると、きついインターバルを最後までやり切れる回数が増えます。ここで意味があるのはその一点だけです。ピクセルアートとサウンドは後から、Asepriteのアセットパイプラインを通して入れました。

その日の終わりには骨組みが立っていました。アナリティクス側は、強度フィルタ付きのアクティビティ一覧、MapKitのマップにルートを描く詳細画面、パワーと心拍のチャート、ミーンマックスのパワーカーブ、そして28日間の負荷と180日間のPMCチャートを並べたダッシュボード。トレーニング側は、ハイブリッドなプランエンジン（カレンダー上のアンカーとアダプティブな内側、Friel流のフェーズ進行に自動のリカバリー週）、組み込みワークアウトのライブラリ、そしてBLE経由でFTMSトレーナーにERGターゲットを送りながらライドを記録するランタイム。

一番ほしかったのはループが閉じることでした。構造化ワークアウトをこなし、処方にどれだけ忠実だったかをアプリが採点し、それを翌日のおすすめに反映する。それ以降の作業は、すべてこの枠を埋めていくものでした。

一度の作業にしては多く見えますし、実際に多かったのですが、その大部分は LangChain の形をSwiftに忠実に移植したものです。なので設計の仕事は、ゼロから考えることよりも、何を残すかを決めることでした。

一番欲しかった部分は最初のコミットから入っていました。ストリーミング、ツール呼び出し、そして自己修復ラッパー付きのストリーミングJSONパーサーです。どれも、これまでのプロジェクトで毎回手書きで再実装していたものでした。

落ち着いたルールは、すべてのページが両方の言語で存在するというものです。.ja.md ファイルがあればそのページは翻訳され、なければ英語にフォールバックします。だから、後から翻訳を追加してもリンクが壊れることはありません。

自分のジェネレーターでやったおかげで、プラグインの前提にサイトを合わせるのではなく、URLの構成をシンプルに保てました。

コンテンツはコレクションになりました。それぞれが、マークダウンの置き場所、ルート、並び順、公開するタクソノミーを宣言し、固定されたひとつのブログの形ではなく、コレクションごとのルーティングを持ちます。同じリリースで author、nav、home、そして任意のコレクションに使える content new コマンドを追加しました。

quiet テーマも同時に出しました。Fraunces、Manrope、JetBrains Mono を使い、ポートフォリオとブログのレイアウトを備えています。このサイト全体が、いまもこの見た目で動いています。

これがブログで書いたバージョンです。JPResume の目的は、ゼロからレジュメを書き起こすことではありませんでした。すでに管理している英語版をもとに、日本語の履歴書と職務経歴書をそれと揃え続けることです。

取り込みを正しく行うことが、ズレの問題を解消します。さもないと、応募の直前という最悪のタイミングで足をすくわれます。

PDF対応も入出力の両方でこの時期に入りました。入力の解析は PDFKit で既存のレジュメを読み取り、画像だけのPDFには Vision の OCR を使います。出力は、適切な日本語組版で履歴書と職務経歴書を生成します。

決定論的なステージとモデルのステージを早い段階で分けたことが、その後のすべてを扱いやすくしてくれました。どのポーズポイントでも処理を止めて、ドキュメントになる前のアーティファクトを確認できます。