Glitch Toolkit

glitch

拒否しなくなったチェックは、今も成功として扱われます。 これが検出しようとする不具合です。

2026年9月8日、このパッケージが切り出されたリポジトリでは、無料公開されている有料書籍の1章を保護するテストがあり、サンプルが指定された箇所で終わり、その先の内容が漏れないことを確認していました。テストは成功していました。しかし、書籍が載っていないページを検索し、当然見つかるはずのない箇所を探して成功していたのです。何も壊れていませんでした。伏せ字処理は正常に機能していました。警報器は切断されていたのに、ランプは緑色のままでした。

どんなガードレールも、いずれ同じように劣化します。しかも、その劣化は気づかれないまま進みます。拒否しなくなったガードレールは、拒否すべきものが何もないガードレールと見分けがつかないからです。

glitch はリポジトリに6つのガードレールを設置し、求められるたびに、それぞれが本来拒否すべきケースでテストします。何も拒否しなくなったものがあれば、静かに成功するのではなく、ここではっきり失敗します。

pip install glitch-toolkit

glitch install     # put the artifacts in this repository
glitch status      # what is installed, what is not
glitch check --all # verify every step

依存関係はなく、ネットワークへの呼び出しもなく、テレメトリーもありません。指定したディレクトリの外には何も書き込みません。

実際にチェックする内容

ファイルが存在するだけでは、ステップは完了しません。各チェックでは次の3つを実行し、どれが失敗したかを報告します。

1. 成果物を見つける
2. 実行し、正常に動作することを確認する
3. 意図的に壊したケースで実行し、拒否することを確認する

3つ目がなければ、ファイルに効力が残っているかどうかにかかわらず、コピーした瞬間にチェックは成功します。そして、どの読者に対しても、いつまでも成功し続けてしまいます。tests/test_cli.py があるのは、チェッカーがこのケースで失敗することを証明するためです。このテストの SABOTAGE では、実行できて終了コードが0になり、何も拒否しない成果物を設置します。

install がしないこと

CLAUDE.md、FLEET.md、FLOOR.md、PLAN.md は書き込みません。6つのステップのうち4つは、ユーザー自身のファイルを対象にチェックします。その4つでは、ファイルそのものが成果だからです。有効なルールファイル、担当コミッターが1人いるデスクの表、2回測定されたフロア、ほかの人が承認した計画です。それらを書き込むコマンドを用意すれば、手順は「インストーラーを実行した」に置き換わってしまいます。同じ理由から、FLOOR.md と PLAN.md のテンプレートは意図的にチェックに合格できない状態で提供しています。

上書きはしません。リポジトリにすでにある成果物はそのまま残し、保持したことを報告します。それ以外を希望する場合は --force を指定します。

指定したディレクトリの外には何も書き込まず、ネットワークへの呼び出しも行わず、標準ライブラリ以外の依存関係もありません。

インストールせずに実行する

cli.py は1つのファイルであり、今後も1つのファイルのままです。リポジトリにコピーすれば、パス上に何もなくても、インストール手順なしで status と check を実行できます。この性質は意図したものであり、使用する検索パスを確認するテストもあります。パッケージの残りの部分が必要なのは install だけです。その必要性は、奇妙な失敗を起こすのではなく、明確に伝えます。

MCP サーバー（読み取り専用）

uvx --from 'glitch-toolkit[mcp]' glitch-mcp --repo .

追加機能は、システムの Python ではなく、隔離された環境にインストールしてください。 チェッカーには依存関係がなく、それは保証されています。[mcp] 追加機能はその正反対です。mcp>=2.0 は pydantic、starlette、cryptography、opentelemetry など、さらに十数個のパッケージを取り込み、それらを満たすために pip は既存のパッケージを喜んでアップグレードします。2026年9月8日にグローバルインタープリターに対して実行したところ、pydantic 1.10 が 2.13 に、starlette 0.46 が 1.6 に置き換えられ、同じマシン上にある無関係な FastAPI アプリケーションが壊れました。uvx は使い捨ての環境を構築し、ほかには何も変更しないため、レジストリーのエントリーはこの方法で起動します。

仮想環境を使っても同様に問題ありません。

python -m venv .venv && .venv/bin/pip install 'glitch-toolkit[mcp]'

エージェントには、glitch_status、glitch_check、glitch_ledger_tail の3つのツールとしてチェックを提供し、すべての質問と回答を .claude/toolkit/ledger/ledger.jsonl に追記します。

何もゲートしません。 どのようなアクションも一時停止、ブロック、拒否、横取りすることはできません。データベース接続も、認証情報も、ネットワーク呼び出しもありません。これが、意図的にそうしている最初のバージョンのすべてです。エージェントと本番データベースの間に立つサーバーは重要なソフトウェアです。誠実な手順は、まず読み取り専用で実行し、台帳を読んで、拒否する権限を与える前に、何を拒否していたはずかを確認することです。その記録が存在する前に作られたゲートは、権限を伴う推測にすぎません。

チェックはリポジトリーに何も書き込みません。サーバーがこの点を破るのは、台帳に追記する箇所だけです。--no-ledger を指定すれば、残しておく価値がある唯一のものを犠牲にして、それさえも無効にできます。

Claude Code では、.mcp.json を使います。

{
  "mcpServers": {
    "glitch": { "command": "glitch-mcp", "args": ["--repo", "."] }
  }
}

台帳

追記専用の JSONL です。自分が書いたばかりの行を書き換えることはありません。新しい記録に置き換えられた記録も、そのまま両方残ります。測定されていないフィールドは 0 ではなく null になります。最後の行が途中までしか書き込まれていない場合は、修復するとファイルを書き換えることになるため、修復せずにスキップして、その件数を記録します。

テスト

python tests/run_all.py      # all three suites, 40 tests

サーバーのテストスイートは、[mcp] 追加機能がなくても問題なくスキップされます。ランナーはそれを合格ではなく SKIPPED として報告します。「確認しなかった」という意味の緑の表示こそ、ゲートチェックの実践が捕捉しようとしている、まさにその失敗だからです。

チェックの由来

ここにあるすべてのチェックは、何かがうまくいかなかったことをきっかけに作られています。CORPUS.md には、その一覧、何が起きたか、どのような代償があったか、そして現在どのチェックがそれを捕捉するかが記載されています。

ここにあるチェックではまだ捕捉できない事例も記載されています。このパッケージのバージョン番号をそれぞれ1つずつ進める原因となった2つの事例も含まれます。解決済みの失敗だけを記録するコーパスでは、このパッケージが扱う問題そのものを繰り返すことになります。

ライセンス

Apache License 2.0 です。LICENSE と NOTICE を参照してください。特許ライセンスが付与されるため、MIT ではなくこちらを選びました。

このリポジトリー内のすべてのものが、このライセンスの対象です。商用利用、変更、再配布が可能です。

上記のリンクが絶対リンクになっているのは意図的です。この README は PyPI 上でもパッケージの説明として使われます。相対リンクは pypi.org を基準に解決され、404 を返すためです。

このリポジトリーの由来

このリポジトリーは公開済みのミラーです。このパッケージは、プライベートなモノレポ内で、書籍 Building Your Store Or Your SaaS With Claude とともに開発されています。このパッケージはその書籍の実践方法をインストールしてチェックするもので、サブツリーとしてここにプッシュされています。書籍、それを販売するショップ、そしてそのリポジトリーのほかの部分はオープンソースではなく、ここにはありません。このパッケージに属するものが、このリポジトリーから隠されているわけではありません。

Issue とプルリクエストは、向こうではなくここにお願いします。誰でも読めるのは、この部分だからです。

ステータス

バージョン 0.1.1 です。インストールでき、チェックするプラクティスは、本書で推奨している6つです。0.1.0が最初のリリースで、0.1.1ではこの説明を変更し、継続的インテグレーションを追加しました。コードの動作に変更はありません。

現時点では、何も制限しません。glitch-mcpは報告と記録を行いますが、エージェントの行動を妨げることはできません。これは意図的なものです。その理由はmcp_server.pyに記載されています。エージェントと本番データベースの間に立つサーバーは、拒否する権限を得る前に、その判断を裏付ける証拠を積み重ねるべきです。