ideakit

ideakit

アイデアを1つのリポジトリで管理し、アイデアごとにフォルダーを1つ用意して、一度に考えるのはそのうちの1つだけにします。ideakitは、アイデアが浮かんだ瞬間に記録し、議論セッションを実行し、各アイデアの現在の状況を報告し、調査や検証の作業を担当するキットに振り分けます。また、ユーザーが回答を残すよう求めたときは、そのアイデア専用のログに回答をまとめます。

アイデアとは、考えてみたいテーマであり、実現を決めたプロジェクトではありません。製品になるアイデアもあります。大半はメモのままです。それがこの設計の意図です。

ジョットはさらに小さな単位です。フォルダーも、スラッグも、決意も伴わない考えです。ジョットパッドにはいつでもどんなテーマでも書き留められ、何度も戻ってくるジョットにはフォルダーが作られます。

モードは8つです。jotは、まとまっていない考えをパッドに書き留めます。promoteは、何度も戻ってくるジョットを独立したアイデアにします。captureは、アイデアを書き留めて終了します。sessionは、考えるためのモードです。statusは状況を報告し、何も書き込みません。researchとvalidateは、質問を外部に送り（validateはユーザー経由で、ユーザーがvalidatekitを開始します）、回答を持ち帰ります。closeは結論を記録します。

jot、promote、capture、closeは独自に書き込みます。それ以外のモードは書き込みを提案し、断られたら受け入れます。 保存は既定ではなく、要求に応じて行うを参照してください。

モードの選択

言い回しではなく、意図に基づいて判断します。

• 「これを書き留めて」「ふと思いついたこと」「これをジョットパッドに追加して」はjotです。記録して終了します。
• 「あのジョットを昇格して」「これはフォルダーを作る価値がある」「j-042をアイデアにして」はpromoteです。
• 「アイデアがある」「これを記録して」「これを書き留めて」はcaptureです。記録して終了します。
• 「Xについて考えよう」「Xについてブレインストーミングしよう」「Xのアイデアを再開しよう」はsessionです。
• 「アイデアは今どうなっている？」「次は何について考えればいい？」「Xについてどこまで話したっけ？」はstatusです。
• 「ほかに誰がこれを作っている？」「これにはどのライブラリが必要？」「この分野のコストはどれくらい？」はresearchです。
• 「これはビジネスになる？」「これにお金を払う人はいる？」「これを作るべき？」はvalidateです。
• 「これはやめる」「これは作る」「これは保留にする」はcloseです。

状況を知りたい、または考えたいという依頼なのに、アイデアが指定されていない場合は、必ずstatusかsessionを選び、両者のどちらかを推測してはいけません。 statusはすべてのアイデアを報告し、sessionはどのアイデアを開くか尋ねます。状況を知りたい場合はstatusを実行します。考えたい場合はsessionを実行し、対象のアイデアを尋ねます。

依頼がcaptureとsessionのどちらか本当に曖昧な場合は、まずcaptureを実行します。記録したアイデアについてはいつでも次にセッションを行えますが、記録されていないアイデアでセッションをしても何も残りません。

依頼がcaptureとjotのどちらか本当に曖昧な場合は、jotを実行します。 ジョットにはフォルダーも永続的なスラッグも必要なく、価値が生まれた時点でpromoteによって昇格できます。「アイデア」という言葉が判断の決め手です。ユーザーがその考えをアイデアと呼んだ場合は、captureを使います。

アイデアリポジトリ

すべての状態は、ユーザーの作業リポジトリの外にある1つのリポジトリに保存されます。場所は、$IDEAKIT_HOMEで別の場所が指定されていない限り~/ideasです。

~/ideas/                            ← one git repo; $IDEAKIT_HOME overrides
  INDEX.md                          ← the router
  jotpad/
    INDEX.md                        ← the jot router
    YYYY-MM-DD.md                   ← that day's jots, append-only
  topics/<slug>/
    IDEA.md                         ← a stable head plus an ## Open block
    NOTES.md                        ← the dated log, append-only
    SOURCES.md                      ← collected links, created lazily
    docs/plans/                     ← a plan skill writes here
    docs/research/                  ← research answers, kept on request
    docs/validation/                ← validation write-ups, kept on request
    docs/sessions/                  ← full session records, on request only
    docs/adr/                       ← decision records
    assets/                         ← diagrams and screenshots

最初に$IDEAKIT_HOMEを解決し、絶対パスを使用します。 どのモードも作業ディレクトリを変更しません。作業リポジトリからモードを実行しても、そのリポジトリ内のファイルには触れないため、ホストリポジトリ固有の規約がideakitの書き込みに適用されることはありません。これにより、作業の途中で浮かんだアイデアを、そのままアイデアリポジトリに記録できます。

初回使用時にリポジトリを作成し、その中でgit initを実行します。自動的にコミットしてはいけません。 セッションの最後にコミットを提案し、断られたら受け入れます。

ルーター

INDEX.md にはアイデアごとに別名を含めた1行があり、何かを開かなくても、漠然とした依頼を振り分けられます。

| Idea | Slug | Also called | Summary | Open question | Status | Last touched |
|------|------|-------------|---------|---------------|--------|--------------|
| Agent memory substrate | `agent-memory` | memory layer, agent recall, context store | A shared store an agent writes facts to and reads back across sessions | Does retrieval beat a bigger window | active | 2026-08-19 |

ステータスは active、building、parked、closed のいずれかです。building は実装が別のリポジトリで進行中であることを意味し、セルにはそのリポジトリが記載されます：`building` · owner/repo。parked はユーザーが中断したことを意味します。closed は、そのアイデアの NOTES.md に結論が記録されていることを意味します。

ルーターのセルに関する制約：Summary と Open question はそれぞれ1行です。 それぞれ、アイデアが「何か」と、何が未解決かを示します。理由や立場、未完成の議論はどちらにも含めません。Markdown の表は全体を読まれるため、以下の分離ルールはルーターを選択的に読むだけでは守れません。ルーターに保持を許す内容を制限することで守ります。これなら、アイデアが10個あっても、振り分けに必要なのは10行だけで、余計な情報が入り込むこともありません。

1つのアイデアフォルダーだけを読み、2つは読まない

これが最も重要なルールです。 INDEX.md を読み、依頼をちょうど1つのスラッグに対応付けます。その後、topics/<slug>/ だけを読みます。topics/ 全体を一括検索したり、コンテキストを求めてリポジトリを grep したりしてはいけません。topics/ の一覧を表示するのは問題ありません。ディレクトリの一覧表示は、その中身を読むことではないためです。

このルールを支える理由は2つあります。アイデア同士は互いに影響します。同じウィンドウに2つのテーマを表示すると、一方についての未完成の考えがもう一方に漏れ込み、気づかないうちに後者が前者の枠組みを引き継いでしまいます。また、コストの増え方も望ましくありません。アイデアが30個なら、振り分けに必要なのはルーターの約30行ですが、すべてを開くと数万トークンになります。

範囲を限定した例外が1つあります。 ユーザーが依頼の中で別のアイデアに言及した場合に限り、2つ目のトピックフォルダーを開きます（「これはエージェントのメモリーに関するアイデアとつながっていますか？」など）。そのフォルダーは、このセッションでは読み取り専用とし、つながりについては主となるアイデアの NOTES.md のみに記録します。1セッションにつき、ログの記録先は1つです。関連性が明らかに見えてもユーザーが尋ねていない場合は、1文でそのつながりを伝え、フォルダーは開かないでください。

このルールは、パッドのどちら側でも適用されます。 トピックモードでは jotpad/ 以下のファイルを開かず、jotpad モードでは topics/ 以下のフォルダーを開きません。jot セッションで読み取り範囲を制限する方法については「Jotpad」を、両方に触れる唯一のモードについてはpromoteを参照してください。

3つのトピックファイル

IDEA.md は、2つの部分からなる最新の説明です。 冒頭では、アイデアの内容、対象者、そして意味を持つために必要な条件を説明します。その下の ## Open ブロックには、未解決の質問と、次に取り得る行動を列挙します。

セッションによってアイデアの「内容」が変わった場合は、冒頭を書き直します。例外なく、毎回のセッションで新しい ## Open ブロックを作成し、対応する記録とともに保存してください。この分割により、確認可能な制約ができます。## Open ブロックは、最後の NOTES.md エントリーと一致します。 また、結論が出なかったセッションで、変更がないのに冒頭が何度も書き換えられるのを防ぎます。

NOTES.md は追記専用のログです。 保存するセッションごとに ## YYYY-MM-DD 見出しを1つ設け、決定したこと、却下したこととその理由、そしてセッション終了時に残った未解決の質問を記録します。以前のエントリーには手を加えず、考えが変わった場合は新しい日付のエントリーを追加します。ログが記録の本体で、IDEA.md はそのキャッシュです。両者に食い違いがある場合は、NOTES.md をもとに IDEA.md を書き直してください。

SOURCES.md にはリンクをまとめます。 リンクごとに1行を使い、読んだ日付と、何を明らかにするリンクかを1行で記します。作成するのは最初に使うときであり、記録を取り込むときではありません。検索の前に確認してください。

jotpad

jotpad/ は、フォルダーを持たない考えを置く場所です。 どんな題材でも、スラッグは不要で、何かに決める必要もありません。フォルダーを作るのは決断であり、浮かんだその夜にフォルダーを作るほどの価値がある考えは、ほとんどありません。考えはここで待ちます。

jotpad/INDEX.md は jot のルーターで、jot ごとに 1 行あります。

| Jot | Id | Summary | Entries | State |
|-----|----|---------|---------|-------|
| Cheap OCR for receipts | `j-042` | A phone photo of a receipt turned into a line-item table, run locally | 2026-08-24, 2026-09-02 | live |

状態は live、promoted、dropped のいずれかです。promoted のセルには、移行先のスラッグを記載します。`promoted` · `agent-memory` のようになります。dropped の行は残します。同じ考えが新しい jot として再び現れないようにするためです。Summary セルは 1 行で、アイデアルーターと同じ長さの上限を設けます。この表も全体が読み込まれるためです。

jotpad/YYYY-MM-DD.md には、その日の jot がそれぞれ 1 ブロックずつ記載されます。

## j-042 · Cheap OCR for receipts

Two to six lines in the user's own words: what the thought is, and what set it off.

日付付きファイルは NOTES.md と同様に追記専用です。 一度書いたブロックは編集せず、新しいブロックは今日のファイルにのみ追加します。状態の変更はすべて jotpad/INDEX.md に記録します。これにより、パッドには確認する場所も修正する場所も 1 つだけになり、考えが浮かんだ日付は、その後の経過にかかわらず残ります。

ID は恒久的なもので、再利用しません。 jotpad/INDEX.md と今日のファイルのうち、ID が大きい方を確認し、その値に 1 を加えて採番します。今日のファイルも確認することで、行がまだ書かれていないブロックの ID が、次の jot に割り当てられるのを防ぎます。ユーザーが後日 jot に戻った場合、その日のファイルに同じ ID の新しいブロックを追加し、行にその日付を加えます。同じ日に再び戻った場合は、今日のファイルに同じ ID のブロックをもう 1 つ追加し、Entries セルはそのままにします。このセルは日数を数えるためです。3 回のエントリーが昇格の目安です。ユーザーが別々の日に 3 回戻ってきたということであり、それこそがフォルダーを作る理由だからです。

jot を破棄する操作は、1 セルの編集だけです。 ユーザーが jot は何でもないと言ったら、状態を dropped にし、それ以外は何も書きません。モードも判定エントリーも必要ありません。jot は、そうしたものを必要とするほどの主張をしていないためです。

分離ガードはパッドにも適用されます。 jot の実行では、上限のあるルーターである jotpad/INDEX.md と INDEX.md を読み、追記する今日の日付付きファイルも読みます。jot に関する話し合いでは、これらに加えて、その jot の行に記載された日付付きファイルのみを読みます。topics/ 内のフォルダーを開くことはなく、トピック用のモードが jotpad/ 内のファイルを開くこともありません。promote だけがこの境界を越え、1 つの jot を読み、1 つのトピックフォルダーに書き込みます。

日付付きファイルには無関係な jot も並んで記載されるため、1 つのスレッドを読むと、隣の jot もコンテキストに入ります。このコストは許容されており、範囲も限定されています。パッドは定義上、まとまっていない考えを置く場所です。そうした考えから保護する価値があるほど重要なスレッドなら、promote に値するスレッドです。

ルーターはキャッシュなので修復します

修復は 2 つのレベルで行い、各モードは自分に見える範囲だけを修復します。

• あるモードがトピックのフォルダーを開いて変更した場合は、変更したエントリーと同じ保存確認で、そのトピックのルーター行の書き換えを提案します。 capture と close は確認を求めずに行を書き込みます。
• ルーターに登録されていないフォルダーは、開かずに報告します。 ルーターにないフォルダーの登録には、その内部にある 5 つのフィールドが必要ですが、事務的な作業のためにフォルダーを読むとガードに違反します。そのため status はフォルダー名を示し、登録するにはそのフォルダーに対して session を実行するよう伝えます。
• jot のルーターは確認を求めずに修復します。 セルに記載されるのは ID、エントリーの日付、状態であり、思考ではなく事務処理の情報です。jot の状態を記録する唯一の場所はその jot の行なので、モードが状態を変更するたびに行を書き換えます。

書き込みが途中で止まった場合の修復

複数ファイルへの書き込みは、常に決まった順序で実行されます。まず記録、次にキャッシュです。トピックフォルダーでは、NOTES.md、IDEA.md、ルーターの行の順です。パッドでは、日付付きブロック、次に jot ルーターの行の順です。そのため、途中で止まった場合、記録がキャッシュより先行した状態になり、逆になることはありません。また、それぞれのケースには修復方法が1つあります。

• IDEA.md が最後の NOTES.md のエントリと一致しません。 次にフォルダーを開くモードで、ログに基づく書き換えが個別の保存確認で提示されます。
• トピックフォルダーにルーターの行がありません。 capture または promote が途中で止まった痕跡です。status では未登録として報告され、対象に対して session を実行すると行が書き込まれます。
• 今日のファイル内のブロックに jot ルーターの行がありません。 次の jot の実行時に、今日のファイル内で ID が検出され、ほかの jot ルーター修復と同様に、確認なしで不足している行が書き込まれます。

スラッグは変更されません

スラッグは短い小文字の kebab-case で、アイデアの中心となる名詞から作成します。フォルダーは後からどのモードでも名前を変更しないため、capture はスラッグを提案し、何かを作成する前にユーザーに確認します。まれなケースに対応する名前変更の仕組みを設けるのではなく、作成時に一度だけコストをかけます。ルーターの Idea 列には現在の人間向けの名前を記載し、いつでも変更できるようにします。

成果物はトピックフォルダー内に保存します

成果物のルートはリポジトリのルートではなく、トピックフォルダーです。 docs/ 配下のパスを記述するスキルでは、サブパスとファイル名の規則を維持したまま、代わりに topics/<slug>/docs/ 配下へ書き込みます。docs/plans/0001-plan-sso-2026-07-23.md は topics/<slug>/docs/plans/0001-plan-sso-2026-07-23.md になります。

これはルートの置き換えなので、このファイルの作成後に追加されたものも含め、すべてのスキルに適用されます。リポジトリのルートに docs/ ディレクトリはなく、今後作成されることもありません。

ファイル名は NNNN-<type>-<slug>-YYYY-MM-DD.md の形式にします。先頭に4桁の通し番号、末尾に成果物の作成日を付けます。通し番号はトピックフォルダー内のディレクトリごとに数えます。作業中のワークツリー、このワークツリー以外で git worktree list が示すすべてのワークツリー、およびトピックフォルダーが git リポジトリ内にある場合は origin/HEAD を対象に、そのディレクトリ内で最も大きい先頭の通し番号を取得し、1を加えます。最初の番号は 0001 です。並行するワークツリーで同じ通し番号が使われないよう、3つすべてを調べてください。リモートがない場合など、取得元で失敗した場合はその取得元をスキップします。git がない場合は、ディレクトリ内のファイルだけを一覧表示します。ファイルを後から編集しても、ファイル名全体は変更しないでください。

保存はデフォルトではなく、明示的な要求です

成果物は議論です。ファイルは、議論の結果として必要になったときにユーザーが求めるものです。 多くのセッションは探究して終わります。誰も望んでいない項目ばかりのリポジトリは、薄いリポジトリよりも悪いものです。後の status の実行では、すべての行がユーザーの意図したものとして扱われるからです。

そのため、すべての書き込みは次の確認を通します。

1. それでも書き込み内容を作成します。 NOTES.md の項目、## Open ブロック、ルーターの行をすべて下書きします。
2. 保存先となる絶対パスの下に、下書きをコードブロックで表示します。
3. 保存、編集、破棄のいずれかを尋ねます。 「いいえ」という回答を受け入れ、何も書き込みません。

先に作成しておけば、「はい」と答える手間が少なくなります。何も添えずに「これを保存しますか？」と尋ねると、的外れな理由で断られてしまいます。

この確認は、ルーターの行も含め、すべてのファイルに適用されます。 INDEX.md には要約と未解決の質問が含まれます。これらは事務的な記録ではなく思考の内容なので、その行は説明する項目と一緒に扱います。ユーザーが保存しなかったセッションではアイデアに手を加えていないため、Last touched はそのままにします。

jot、promote、capture、close は対象外です。それぞれのモードでは、依頼そのものが書き込みだからです。 「これを書き留めて」「これにフォルダーを作って」「これを書き留めて」「これはやめておく」といった依頼はすでに明示されており、モードの出力はファイルそのものです。それを提案に変えると、ユーザーが今頼んだことを改めて確認することになります。promote では、作成前にスラッグを確認しますが、これは別の質問です。書き込むかどうかではなく、どの恒久的な名前で保存するかを尋ねます。

ユーザーはいつでも「保存して」と言えます。 その時点で項目を書き込み、そのまま続けます。こちらから保存を提案するのは、セッションの途中で、議論がまとまり、内容を再構築するのに実作業が必要になる場合に限って、一度だけです。

コストを率直に述べます。 session はステータスレポートから始まり、status は未解決の質問を抱えるアイデアのうち、最も長く更新されていないものを先頭に表示します。どちらも NOTES.md を読み込みます。保存されていないセッションがあると、読み取られる内容がユーザーの実際の考えと一致しなくなります。そのため、何も書き込まない実行では、引き継ぎ時に毎回そのことを伝え、記録が薄いだけなのに、静かな月だったかのように見せないようにします。

モード

モードの本文は modes/ 以下に、それぞれ1つのファイルとして格納されています。モードの選択に従って該当するファイルを読み、その指示に従ってください。この行より上のすべての内容と、以下の共通セクションはすべてのモードに適用されるため、モードのファイルでは繰り返しません。

• モード jot → modes/jot.md を読み、その指示に従ってください。
• モード promote → modes/promote.md を読み、その指示に従ってください。
• モード capture → modes/capture.md を読み、その指示に従ってください。
• モード session → modes/session.md を読み、その指示に従ってください。
• モード status → modes/status.md を読み、その指示に従ってください。
• モード research → modes/research.md を読み、その指示に従ってください。
• モード validate → modes/validate.md を読み、その指示に従ってください。
• モード close → modes/close.md を読み、その指示に従ってください。

ディスパッチのルール

research は質問を同じ階層のスキルに送ります。validatekit は呼び出し専用のため、validate はそれができません。そのため、ユーザーが実行して回答を持ち帰ります。以下のルールは、その回答にも同じように適用されます。すべてのディスパッチには、次の4つのルールを適用します。

• 同じ階層のスキルには、その場で回答してもらいます。 researchkit と validatekit はどちらも、会話内で回答し、何も保存しないことをデフォルトとしています。ideakit も同様です。ユーザーに代わって、保存するかどうかの問いに回答しないでください。
• 同じ階層のスキルによる引き継ぎ案内は省き、ideakit 自身の案内を表示します。 ディスパッチはサブステップであり、次のステップを示す行が2つあっても誰の役にも立ちません。
• 回答後に成果物を提案し、前には提案しません。 残しておくかどうかを一度だけ尋ねます。はいの場合は、同じ階層のスキルが会話内で回答した内容から、topics/<slug>/docs/… に自分でファイルを書き込みます。同じ階層のスキル独自のサブパスとファイル名の規則を維持してください。同じ階層のスキルを再実行して保存すると、ファイルは作業ディレクトリに置かれます。同じ階層のスキルは自身のルートを文書化しており、ホストには従わないためです。ディスパッチの前に尋ねると、回答を残す価値があるかユーザーが判断する前に尋ねることになります。
• 保存された内容だけを反映します。 はいの場合は、質問、回答、成果物のパスを記した日付入りの NOTES.md エントリーと、IDEA.md およびルーターの更新を提案します。いいえの場合、回答は会話内に残し、ログは変更しません。

アイデア自体のログには、ユーザーが残したものすべてを記す、信頼できる唯一のスレッドを保持します。後のセッションでは1つのファイルを読むだけで、保存された回答をすべて確認できます。

引き継ぎ

このセクションは手順を述べる文体で書きます。1文につき1つの指示とし、能動態、現在形を使い、比喩は使いません。

変更内容。 記録したエントリー、保存した成果物、設定したステータスを示します。変更しなかったものも示します。ユーザーが断った保存、報告したものの開かなかったフォルダー、短縮版で実行したディスパッチ、理由なしでは記録を拒んだ判定などです。

実行時に何も記録されなかった場合。 1行で述べます。このセッションではリポジトリに記録を残していません。表現を和らげず、議論を保存したと示唆しないでください。ユーザーから頼まれた場合に限り、もう一度だけ保存を提案します。

保存先。 トピックフォルダーのパスを示します。あるモードで jot を書き込んだ場合は、jot ファイルのパスと jot ID を示します。あるモードで成果物を書き込んだ場合は、そのパスを示します。この実行でリポジトリを作成した場合は、リポジトリのパスを示します。

次のステップ。 状態に応じて、次のアクションを1つに絞ります。

上から順に、最初に一致するルールを適用します。

• 実行によって live jot に3件目以降のエントリーが追加された → その jot に対して promote を実行します。
• 実行によってそれ以外の jot が書き込まれた → 次のステップはないと伝えます。その jot に関するセッションを提案しないでください。
• jot がたった今アイデアになった → 新しい slug で session を実行します。
• セッションが未解決の質問で停止した → その質問について session を再実行します。
• 未解決の質問に外部の事実が必要 → research を実行します。
• アイデアがビジネスで、判定がまだない → validate を実行します。
• アイデアが作業に移せる程度に固まった → プロジェクトリポジトリで、プラン用スキル（インストールされている場合は plankit）を使って計画します。
• 未解決の項目がない → close を実行し、該当する判定を示します。
• アイデアがたった今終了した → 次のステップはないと伝えます。後続の手順を作り出さないでください。
• 実行が validate で、ユーザーが validatekit の実行を選んだ → アイデアのパスを指定して /validatekit を実行し、その後 ideakit に判定を残すよう依頼します。

続けて、アイデアリポジトリへのコミットを提案します。はいという返事なしに実行しないでください。何も記録しなかった実行では、コミットを提案しないでください。

status の実行では、異なる形で終了します。 出力全体が引き継ぎとなり、ダッシュボードがすでに次のアクションを示しています。何も変更されなかったと伝えます。次のアクションを繰り返して表示せず、コミットも提案しないでください。

注意事項

• 分離ガードは、ここにあるほかのすべてのルールに優先します。 スラッグを1つ解決し、フォルダーを1つ開きます。status はすべてのアイデアについて報告し、どのアイデアも開きません。これは例外ではなく、ガードが機能している状態です。
• 何を残すかはユーザーが決めます。 書き込み内容を作成して提示し、待ちます。jot、promote、capture、close は例外で、それ以外に例外はありません。
• capture と jot はどちらもそこで止めます。 これらは、考えが都合の悪いタイミングで浮かんだときに、何も失わないようにするためのものです。どちらもセッションにしてしまうと、かえって考えが取りこぼされます。
• メモ帳には何でも書けますが、フォルダーは必要な条件を満たして得られるものです。 jot には件名もスラッグも、既存のアイデアとの関連性も必要ありません。promote が関門であり、考えに戻ってくることが、関門を開く条件です。
• スラッグの名前は絶対に変更せず、jot の ID は絶対に再利用しないでください。 作成時にスラッグを確認し、その後は変更しません。名前を変更した場合は、ルーターの Idea 列に記録します。
• このリポジトリにはコードを含めません。 ideakit はアプリケーションコードを一切書かず、イシューも作成しません。実際の作業になるアイデアはプロジェクトリポジトリに移し、そこでイシューを作成します。
• アイデアのリポジトリだけを単独でコミットしないでください。
• 書き込み可能なファイルシステムがない場合（ブラウザベースのエージェントなど）、保存の申し出は印刷に切り替わります。その旨を明確に伝え、NOTES.md のエントリーと成果物があればそれもコードブロックで出力して、ユーザーが保存できるようにし、保存先のパスも伝えてください。実際には行っていない書き込みを報告してはいけません。ファイルシステムが読み取り可能であれば、status は引き続き実行します。