4.8.0 — collection がセルの中へ、そして取りこぼさないスケジュール実行

2026-08-10 にリリースされた 4.8.0 のスナップショットです。 アプリが進むにつれて内容は古くなりますが、それは想定どおりです。常に最新の情報は、各セクションからリンクしている本編ガイドを見てください。

npx mulmoterminal@latest

要点は 2 つです。collection が「ワークスペース専用」ではなくなりました — 4.7.6 で配管を通し、今回はその見える側です。各セルの右ペインに Collections が入り、そのセルが開いているフォルダの collection を表示します。そして スケジュールされたタスクが実行を取りこぼさなくなりました — その時刻にマシンが起動していなくても、次の起動で取り返します。

どちらも設定変更は不要です。スケジューラの修正は、すでに有効にしているかもしれない設定に効きます。「ちゃんと動くようになったか」の確かめ方は下の節にあります。

プロジェクトフォルダに collection を置くのは、まだ待ってください

フォルダごとの collection 機能はまだ完成していません。 collection は今までどおり ワークスペース（MulmoTerminal が起動時に結びつけるディレクトリ）に置いたままにしてください。下で説明する Collections ペインは開いて見るぶんには問題ありません。まだ整っていないのは、 データをプロジェクトフォルダへ移すこと のほうです。

判断できるように、足りていない点を挙げます。

プロジェクトフォルダの collection では、定期更新が走りません。 実装はされましたが、リリース前に取り下げました。エージェントを起動して取り込む collection の場合、渡されるプロンプトのデータパスはルート相対である一方、ワーカーはワークスペースに立つため、プロジェクト向けにスケジュールした更新が ワークスペース側の同名 collection に書き込んでしまうからです。黙って別プロジェクトに書くくらいなら更新しないほうがまし、という判断です。直すには共有ライブラリ側の変更が先に必要です。
スマホからはプロジェクトの collection に到達できません。 下地は入っていますが、スマホ側にプロジェクトを選ぶ UI が無いため、見えるのはワークスペースだけです。
1 つのパネルに 2 つのプロジェクトのカードを並べられません。 カードは自分のセッションのプロジェクトを見るようになったので通常の使い方は成立しますが、異なるプロジェクトのカードを並べるにはプラグイン側の未リリースの更新が要ります。
ペインの実ブラウザでの動作確認が未実施です（全画面オーバーレイ側は実施済み）。

いま持っている collection が壊れる、という話ではありません。ワークスペースのパスも挙動も変わっていません。「まだこの上に積まないでください」という注意です。残りが揃ったら、そのときのリリースページでお知らせします。

Collections ペイン

セルの右ペインを開き、Canvas / Tools / Files の隣にある Collections を選びます。表示されるのは そのセルのディレクトリの collection です。プロジェクトを選ぶ操作はありません — セルはすでにディレクトリを指しているからです。

別々のフォルダを開いた 2 つのセルは、別々の一覧を表示します。片方で collection を開いても、もう片方も、アプリ全体も動きません。そのセルのディレクトリで collection のツールが使えない場合は、ボタン自体が出ません。

なお当面、そのディレクトリは上の注意のとおり ワークスペース にしておいてください。

collection とは何か、エージェントがどう作るかは、本編ガイドの機能の概要を参照してください。

プロジェクトの collection でも完了ベルが鳴るようになりました

collection が完了フィールドを宣言していると、エージェントがレコードを書き終えたときに MulmoTerminal が知らせます。今回のリリースまで、この監視は ワークスペースにしか 張られておらず、プロジェクトフォルダ側の collection は「鳴りようのないベル」を要求している状態でした。ペインの自動更新も同様に効きませんでした。

これからは、このサーバーが扱うディレクトリごとに監視が動きます — ワークスペースと、cwdPresets に保存されたすべてのディレクトリです。ここは間違えやすいので 2 度書きます。「開いている」とは「このサーバーが扱っている」ことであって、「画面に映っている」ことではありません。 保存済みのディレクトリは、セルに表示していなくても監視されます。

設定は不要です。監視してほしいフォルダは、保存済みである必要があります（設定の cwdPresets）。

「この collection は clone しても動くか？」

collection は、他人が clone してそのまま使えるフォルダであることを意図しています。それを静かに壊す要因が 5 つあり、それを調べるチェックが入りました。

curl 'http://localhost:8080/api/collections/<slug>/self-containment?project=<id>'

各ルールは「向こうのマシンで 何が起きるか」で名前が付いています。

コード	深刻度	向こうで起きること
`user-scope`	blocker	skill が `~/.claude/skills` にあるため、clone 側はそのマシンにある物を使うことになる
`data-ignored`	blocker	スキーマはコミット済みだがレコードが gitignore されており、空の collection に見える
`sqlite-store`	blocker	バイナリ 1 ファイルで、git がマージできない
`csv-runtime`	warning	ファイルは付いていくが、DuckDB ランタイムが向こうにも要る
`no-primary-key`	warning	id が 4 バイトの乱数なので、2 台が同じ id を作りうる
`not-a-repo`	info	そのディレクトリは git リポジトリではない（まだ clone される対象ではない）

project の id は GET /api/collection-projects が返します（このサーバーが扱えるディレクトリの一覧）。省略するとワークスペースが対象になります。

スケジュール実行が「逃した分」を走らせるようになりました

開発作業ログ（worklog）を有効にしたのに、ページが 1 度も作られなかった — その原因がこれで、今回直っています。

組み込みのスケジュールタスク（開発作業ログ、collection のフィード更新、カレンダー同期）は UTC 基準の境界で発火します。6 時間間隔なら発火できるのは UTC 00:00 / 06:00 / 12:00 / 18:00 の各 1 分間だけ — 日本時間の 09:00 / 15:00 / 21:00 / 03:00 です。今回のリリースまでは、その 1 分間にサーバーがスリープ中・再起動中・単に停止中だと、その回は 永久にスキップ されていました。window が過ぎたことを誰も記録しないので、取り返しようがなかったのです。多くの人がそうしているように npx で 1 日数回起動する使い方だと、worklog は何日も 1 度も走らず、しかもエラーはどこにも出ませんでした。

これからは、実行のたびに <ワークスペース>/config/scheduler/state.json に記録され、起動時に逃した分を走らせます。worklog は 1 回だけ 取り返します — 前回実行以降をまとめて 1 バッチで扱い、逃した window の数だけバッチを起動することはありません。

動いていることの確かめ方

worklog の設定（設定の worklogEnabled）以外に、有効化する操作はありません。確認は次のとおりです。

MulmoTerminal を再起動し、数秒待ちます。
サーバーを起動したディレクトリで状態ファイルを見ます。
```
cat config/scheduler/state.json
```
タスクごとに lastRunAt と nextScheduledAt があります。アップデート後の初回起動では、一度も走ったことのないタスクに開始点が入り totalRuns: 0 になります。これは「実行された」ではなく「ここから時計を始める」という意味です。
サーバーに直接聞きます。
```
curl http://localhost:8080/api/scheduler/tasks
curl 'http://localhost:8080/api/scheduler/logs?limit=20'
```
前者は各タスクの前回・次回実行、後者は実行履歴（新しい順）です。停止中に逃した分を取り返した実行は "trigger":"catch-up" として記録されます。

履歴はディスク上にも残ります（<ワークスペース>/data/scheduler/logs/ に 1 日 1 ファイル）。

worklog における「実行」の意味について。 worklog はバックグラウンドセッションを起動し、スケジューラはセッションの終了を待たずに起動したことを記録します — バッチは数分かかることがあり、その間もスケジューラは他のタスクのために動き続ける必要があるためです。起動後にそのセッションが失敗した場合は、あとから失敗が記録されます。つまり最後の記録がエラーのタスクは、本当に失敗しています。worklog が何を書き、どれだけコストがかかるかは設定の worklogEnabled を参照してください。

このリリースのその他の変更

staging はワークスペース専用になり、エージェントにもそう伝わるようになりました。 data/skills/ 下の下書きは、.claude/ の権限ゲートを迂回するための仕組みです。プロジェクトフォルダにはそのゲートが無く、エンジンは staging を先に読むため、data/skills/<slug>/ が残っているとコミット済みの skill を隠してしまう可能性がありました（自己完結が身上のリポジトリで）。エージェントが読む作成手順にも、どのスコープならどのディレクトリに書くかが明記されました。
collection はそこにあるのに「Collection not found」と出るカード。 プロジェクトフォルダで作業するエージェントが collection を作りレコードも書けているのに、描画されたカードだけが見つけられない、という不具合を修正しました。カードは名前で取りに行き、その経路が「いま有効な面」に従うため、Collections ペインを開いていないとワークスペースを見に行っていたのが原因です。キャンバス自体を 1 つの面として扱うようにし、そのセッションのディレクトリを参照するようになりました。
@mulmoclaude/core を 3.1.0 へ更新。 MulmoTerminal と MulmoClaude が共有しているライブラリです。
ガイドのスクリーンショット 2 枚を撮り直しました。 メンテナの実画面が写っており、コックピットロスターに実プロジェクト名、Claude Code の起動バナーにアカウントのメールアドレスが読める状態でした。構図は同じで個人情報を含まない画像に差し替え、docs/guide/images/README.md が全 74 枚を索引するようになりました。

入っているかどうかの確認

MulmoTerminal を再起動します（npx mulmoterminal@latest）。
ツールバーの歯車から設定を開きます。バージョンは見出しのすぐ下、ダイアログ最上部に表示されます。4.8.0 になっていれば入っています。
セルの右ペインを開きます。collection のツールが使えるディレクトリなら、Canvas / Tools / Files の隣に Collections があるはずです。

まだ 4.7.6 と表示される場合は、古いプロセスが動いたままです。停止してから起動し直してください。 npx は起動中のサーバーのバージョンを差し替えません。

再起動そのものがうまくいかない場合ははじめにを参照してください。