2341 日目（曇り一時雨）扇風機を部屋の隅に片付ける

0:05 風呂から出る。Vostro を開く。

2026-09-23：Drupal PSA、緊急度と影響度、jev-lint、Policy as Code

■

ベランダにつけてるすだれがちぎれたので直していた。 百均の結束バンドを連結するという雑オペレーションで固定していたけど、年に2回ほどちぎれてしまう。 ChatGPTに相談したら、4ミリのナイロンロープとカラビナがいいんじゃない？と言われたので、そのとおりにホームセンターで買い物してきて、作図されたとおりに施工した。ChatGPTによる設計図。 人間による施工。カラビナじゃなくてCカン？ねじねじつきCカン？名前もわからない金具で取り付けた。 人間が設計してAIに作らせる、というバイブコーディングと逆の、バイブス施工。 これで壊れても、自分で考えたものではなくて、ChatGPTがあてずっぽうに出し…

2026-09-23 Wed : 伊達政宗の兜は本物ですか？

#TOYAmade 今描いてる話の作画が終わりがけになったの…

(画像省略)……やつが、できた！野球が延長すると、ネームが捗る～ということで第三区間の山頂が見えてきたぞ～えっほ、えっほ (全124文字) -- Posted by toyama

LAN DISK L HDL1-LE04というNASを買って、なんか色々調べた覚え書き

一度購入記事を書いて公開したけど、メーカーのサポートにmacOS 26 TahoeでのTime Machineはサポートされていない、という記載が有ったのを後で見つけたので、それに合わせて記事を大幅に書き換えました。 HDL1-LE04というNASを買った。 HDL1-LE HDL1-LE04 [2.5GbE対応 1ドライブ ネットワークHDD 4TB]アイオーデータAmazon 買い換えた理由は、これまで使っていたNASではAFP(Apple File Protocol)経由でしかTime Machineをサポートしていないが、macOS 27 Golden GateではAFP経由のTime…

Webmentionクラブ

2026-09-23

日記: 2026-09-23

やったこと・トピック バイト 気づいたら終わってた ドキュメント修正を進めた なかなか終わらん 今日の一言 大学卒業するまでに海外旅行行きたい

複数のサンドボックスで開発コンテキストを共有するctx-syncを作った

複数のsandboxを同時に立ち上げて開発していると、それぞれの作業環境が独立しているのは便利な一方で、別のsandboxが何をしているのか分からなくなる。 例えば、一つのsandboxで調査して設計方針を決め、別のsandboxで実装を始めるとする。新しい側には前の会話がなく、なぜその方針になったかも、何が未解決なのかも分からない。結果として同じ調査をやり直したり、すでに決めたことを再検討したりする。別のworkerが編集中のファイルに気づかず、作業がぶつかることもある。 会話履歴はsandbox間で共有されないので、毎回人間が背景を説明し直すことになる。かといって、会話を丸ごとコピーするのは量が多く、次のworkerに必要な情報を探しにくい。 そこで、共有する情報を会話ではなく、開発コンテキストに限定することにした。決定事項、現在の作業、変更したファイル、次の人への注意点が分かれば、次のsandboxは同じ前提から始められる。これを実現するCLIツールとして ctx-sync を作った。 アイデア：会話ではなく、作業に必要な事実を共有する 最初に考えたのは、別のsandboxへ会話をそのまま渡すことではない。会話には試行錯誤や一時的な仮説、デバッグログなどが大量に含まれる。これを全部同期しても、新しいworkerが読むには重いし、共有する必要のない情報まで混ざる。 共有情報を次の三層に分けた。 共有する情報 例 Project 目的、現在の構成、採用済みの設計判断 Coordination workerの状態、作業内容、変更ファイル、引き継ぎ事項 Local 会話、推論、試しただけの案、一時的なデバッグメモ 共有するのは「なぜこの設計に決まったか」「今どこまで終わっているか」「次の人が注意すること」。推論過程や会話ログそのものは各sandboxのローカルに置き、他のworkerが行動するのに必要な事実だけを残す。 実装：GitHub GistをGitリポジトリとして使う この共有状態をどこへ置くか。プロジェクトのGitリポジトリへ全部入れると、workerごとの一時的な進捗まで通常のソース管理へ混ざる。独自サーバーを立てると、認証や運用が必要になる。 そこで共有先にはGitHub Gistを使うことにした。GistはGitリポジトリとしてcloneできるので、特別なサーバーを用意せず、既存のGit認証を使って複数のマシンやsandboxから同期できる。 ctx-syncはRust製のctx-sync CLIで、プロジェクト側にはGistを特定する.ctx-sync.tomlを置く。ローカルのcloneやworker identityはプロジェクトディレクトリの外へ保存し、既定ではmacOSのApplication SupportまたはLinuxの~/.local/state/ctx-syncを使う。 Gist側は次のようなファイル構成になっている。 00-meta.json 10-project.md 20-architecture.md 30-decision---.md 40-worker-.md 設計判断は一つずつ別ファイルにして、古い判断を書き換えるのではなく、新しい判断を追加して置き換える。各workerは自分の40-worker-*.mdだけを更新する。この分離により、複数のworkerが同時に進めていても、別のworkerの作業状態を上書きしにくくしている。 作業開始と引き継ぎ 新しいsandboxで作業を始めるときは、ctx-sync agent startを実行する。 ctx-sync agent start -> 必要ならこのcheckoutをGistへattach -> worker identityを登録 -> 最新の共有contextをpull -> architecture、決定事項、作業中worker、注意点を表示 新規プロジェクトなら、最初にGistを作ってworkerを登録する。 ctx-sync init --project example --create-gist --secret ctx-sync register sandbox-a ctx-sync agent start 生成された.ctx-sync.tomlをプロジェクトへcommitしておけば、別のworktreeやsandboxから同じGistを見つけられる。参加する側はfresh checkoutでctx-sync agent start --name sandbox-bを実行すればよい。