hamza-ali-shahjahan/hamzaish

/tidy — クリーンアップステージ

すべてのリポジトリにはロットが蓄積します：移動済み・gitignoreされたファイルを指すリンク、コミットに紛れ込んだキー、どこからも参照されないアセット、インストール時に404になる依存関係。どれも日々は見えません——それが表面化するのは最悪のタイミング（読者の404、CIの失敗、キーの漏洩）です。/tidy は、それらを意図的に発見・除去するためのステージです。

これは ゲート ではなく ステージ です。高速なガード（check-changelog、check-assets）はプッシュのたびにブロックしますが、/tidy は、掃除するタイミングで実行する、広範かつ報告ファーストのスイープです。

実行方法

bun run tidy                      # 現在のリポジトリ → サマリー＋推奨される次のステップ
bun run tidy <path>               # 特定のリポジトリ
bun run tidy --all ~/Claude       # フォルダ内の全Gitリポジトリ → 一つの集計テーブル
bun run tidy --links              # 一つのカテゴリに絞って調査（--secrets --files --deps）

4種類のロットをスキャンし、最初に件数をカテゴリごとに表示するので、出力が壁のように押し寄せることはありません：

	検出対象
🔗 リンク	Markdown/HTML内の、存在しないファイルへのリンク、または gitignoreされた ターゲットにしか解決しないリンク（作者のディスクでは動くが、他の人には404になる）
🔑 シークレット	高確度でコミット済みのキーパターン（AWS、Stripe、GitHub、Google、Slack、秘密鍵ブロック）—— 確認用 にフラグを立て、自動判定はしない
🗑 デッドファイル	コミット済み画像・アセットで、どこからも参照されていないもの——安全に削除可能
📦 依存関係	package.json 上の依存関係で、npmで解決できないもの（@inngest/sdk のような死んだクラス）

フロー（報告 → 推奨 → 確認 → 修正）

1. 実行する。 サマリーテーブルを表示——カテゴリごと、リポジトリごとの件数。
2. 推奨する。 どのカテゴリが重要か、その理由を伝える（リンク切れは読者の404、フラグが立ったシークレットはローテーションが必要、解決不能な依存関係はすべてのインストールを壊す）。
3. 確認する。 オペレーターに何を掃除するか選ばせる。決して推測しない。
4. 確認を得て修正を計画、適用する。 bun run tidy --fix <repo> は正確な変更計画（どのリンクが解除されるか）を 何も書き込まずに 表示する；--apply を付けて再実行するとその編集を適用する。これにより、各変更を常に 先に見てから 実行できる。自動修正は意図的に限定的：テキストリンク の解除のみ（[text](bad) → text）。シークレット、依存関係、画像/HTMLリンク、ファイル削除は 決して自動適用しない——それぞれ手動で対応し、ガイダンスを表示する（キーのローテーション、適切なパッケージの選択など）。これらの修正には判断が伴い、単なる行編集ではないからだ。--all で広く調査し、各リポジトリに対して --fix を一つずつ実行する。

規律

• 常に報告ファースト。 ロットに触れる前に 見えるようにする ことに価値がある。
• ゲートにしてはいけない。 /tidy は遅い（ネットワーク経由の依存関係チェック）かつ広範囲——ステージに留め、プッシュブロッカーにしてはいけない。狭いガードがゲートを担当する。
• シークレットは確認グレード。 パターンマッチは 確認を促すもの であり、断定ではない——そして本当なら、修正はキーのローテーションであって、行削除ではない。
• フリーズされたディレクトリはスキップ（_archive/、node_modules/）——それらは整理対象ではない。
• エンジンはポータブル。 scripts/tidy.ts は任意のリポジトリパスに対して動作する——これにより、100以上のリポジトリを一つのコマンドでスイープできる。