Rebuild Dossier

rebuild-dossier

既存のアプリから、信頼できる再構築仕様書（固定されたCLAUDE.md、.claude/設定、ミューテーションテスト済みのテストスイート）をリバースエンジニアリングするMCP サーバーです。これにより、あらゆるコーディングエージェントが推測に頼らず、その仕様書に沿ってアプリを適切に再構築できます。

このツールはアプリを再構築しません。 再構築を別途行うコーディングエージェントが利用する仕様書、契約、テストを生成します。この境界は意図的に設けています。詳しくは、以下の理由をご覧ください。

実際のアプリで検証済みです。 中核となる一連の処理（取り込み、ケースの解決、仕様書の生成）は、実際の複雑なリポジトリを使い、2つのモデル層でそれぞれ独立した新規エージェントに引き継ぐ形で、エンドツーエンドにテストされています。さらに、ミューテーションテスト済みのテストスイートでも検証されています。 docs/v0-findings.mdでは、うまくいった点、問題が起きた点、未解決の点を説明しています。

クイックスタート

npm で利用できます：

npx rebuild-dossier@latest --help    # pulls and verifies the package, or:
npm install -g rebuild-dossier        # install the CLI globally

**Node 20.12+**が必要です（package.jsonのenginesで指定）。ソースから実行する場合は、リポジトリをクローンしてnpm installを実行し、npm startを使用してください。

次に、MCP サーバーとして追加します。Claude Codeで、再構築したいプロジェクトから次を実行してください：

claude mcp add rebuild-dossier -- npx -y rebuild-dossier@latest

（または、~/.claude.json／プロジェクトの.mcp.jsonに次を追加してください）：

{
  "mcpServers": {
    "rebuild-dossier": {
      "command": "npx",
      "args": ["-y", "rebuild-dossier@latest"]
    }
  }
}

続いて、セッション内で実行します。最初の呼び出しであるingest_repoは、セットアップ不要ですぐに実行できます。静的解析のみを行い、ブラウザー、Chromium、LLMの呼び出しは必要ありません。まずは任意のアプリで実行し、本格的なワークフローに進む前にサーバーが動作していることを確認してください：

ingest_repo({ path: "/path/to/some-app" })
get_case_queue({ repoPath: "/path/to/some-app", interactive: true })
# ...resolve whatever the queue surfaces...
generate_spec({ repoPath: "/path/to/some-app" })

これにより、some-app-rebuild/というクリーンな兄弟ディレクトリが作成されます。そのディレクトリにcdし、新規のClaude Codeセッションを開始してください（ほかのものは何も対象に含めないでください）。そのうえで、kickoff-prompt.txtの内容を貼り付けます。

役に立ちそうだと思ったら、スターを付けていただけると、ほかの開発者にも見つけてもらいやすくなります。

理由

先行研究（AgentModernize、arXiv:2605.17535）では、検証済みのフィードバックループがない場合、再構築パイプラインの動作同等性は**0%にとどまり、粗いフィードバックループを用いても9～19%**にしかならないことが示されています。このツールの狙いは、テストの実行前にインターフェース契約を固定し、まとめて再生成するのではなく、厳密に1つずつテストして再試行すれば、より良い結果が得られるというものです。

こうしたパイプラインで最もリスクが高いのは、バグを意図した仕様として気づかないまま検証してしまうことです。4つの証拠が同じ誤りに静かに同意していても、なぜそうなったのかを誰も説明していない可能性があります。そのため、このツールには譲れないルールが1つあります。曖昧さを自動解決するには、シグナルの一致に加えて、誰かが実際に判断を下したという肯定的なシグナルが必要です（明示されたコメント、バグを認めるTODO、または人間からの直接の回答）。誰も理由を述べておらず、コードと観測された動作が一致しているだけの場合は、シグナルが静かに一致していても、必ず質問として扱い、自動解決しません。見かけ上の信頼度がどれほど高くても同様です。

動作の仕組み

通常の Claude Code（または MCP 互換の任意の）セッション内から実行する、6 つの MCP ツールです。

ツール	機能
ingest_repo(path)	静的解析のみを行い、LLM の呼び出しはありません。ルート、package.json、ビルド設定（AST 経由で解析し、実行はしません）、既存のテスト、構造上の問題を検出する仕組み（例：サーバー側の検証を伴わない、クライアント側のみの認証情報チェック）を調べます。これにより、誰もコメントしていない場合でも、実際の曖昧さを明らかにします。
crawl_site(url)	到達可能なルートをヘッドレス Playwright でクロールします。応答がないと誤認されて長時間のクロールが中断されないよう、進捗通知を行います。
flag_known_bug(description)	自由記述の内容を、そのまま保存します。該当するものがあれば常に自動解決より優先される、システム内で最も低コストかつ信頼性の高いシグナルです。
get_case_queue() / resolve_case(id, decision)	曖昧さのキューです。クライアントが対応している場合は、MCP のエリシテーションを通じて未解決の質問を提示します。resolve_case はスクリプトからの代替手段として常に利用できます。
generate_spec()	ケースキューが空の場合にのみ呼び出せます。クリーンな兄弟ディレクトリ <repo>-rebuild/ に CLAUDE.md、.claude/rules/、.claude/settings.json（規律を機械的に強制するフック。以下を参照）、spec/contracts/*.md、tests/visible/ と tests/held-out/、および kickoff-prompt.txt を書き込みます。元のリポジトリには決して書き込みません。テストを確定する前に、実際のミューテーションチェックを実行します。元のコードを意図的に壊し、生成された各テストが実際にそれを検出することを確認し、検出できないテストの評価を下げます。

crawl_site には Chromium が必要です（以下の手順 2 で npx playwright install chromium を実行してください）。Smithery 経由でインストールした場合も含め、サーバーには同梱されていないため、最初に一度インストールしてください。インストールしないとツールは失敗します。

書き留めるだけでなく、機械的に強制されるガードレール

2 つのモデル階層を使った比較実行では、能力の低いモデルでも CLAUDE.md を読み、「現在失敗しているものだけを構築し、一括で再生成しない」と理解したうえで、それでも平然と違反することがわかりました。何もチェックしていなかったためです。まさにこの理由から、このツールでは 2 つのルールを文章だけでなく、実際のフックで強制するようになりました。

• spec/ はロックされています。 spec/ 以下への書き込みはブロックされます。
• テストのないコントラクトは、予定より先に構築されません。 generate_spec は、対象テストのないすべてのルート／コントラクトを記載した spec/untested-contracts.json を書き込み、その一覧にあるものへの書き込みをブロックします。

どちらのルールも、生成される 1 つのガードスクリプト .claude/hooks/rebuild-guard.mjs にまとめられ、Edit、Write、MultiEdit、NotebookEdit、および Bash の PreToolUse フックとして実行されます。このスクリプトはシンボリックリンク、.. セグメント、そして（macOS／Windows では）大文字・小文字の違いを解決してから照合します。また、書き込みを行う形式のシェルコマンド（リダイレクト、ヒアドキュメント、tee、sed -i、rm／mv／cp、git の書き込みサブコマンド、書き込みを行うインタープリターのワンライナー）を解析し、自身のスクリプトと settings.json もロックします。入力、ブロックリスト、またはスクリプト自体が欠落しているか、読み取り不能の場合は、フェイルクローズします。既知の制限として、シェル解析はヒューリスティックであるため、エージェントが以前に作成したスクリプト経由の書き込みは検出されません。（0.2.10 より前のリリースでは、シェル上でクラッシュして何もブロックしない、未テストのコントラクト用フックが同梱されていました。アップグレードしてください。）

PostToolUse フックは編集のたびに可視テストスイートを実行し、.claude/.hook-heartbeat.json にハートビートを記録します。これにより、後からフックが実際に有効だったか確認できます。

運用ガイド

ライフサイクル全体を順番に説明します。各手順では、呼び出しシグネチャだけでなく実際の動作を説明します。

1. リポジトリを取り込む

ingest_repo({ path: "/absolute/path/to/some-app" })

静的解析のみです。LLM の呼び出しも、コードの実行もありません。package.json、ルートファイル（現時点では Express と Next.js App Router に対応。詳細は対象範囲を参照）、ビルド設定（Tailwind／Vite／Next。AST 経由で解析し、実行はしません）、既存のテストを解析し、コメントや TODO の兆候に加えて、構造上の問題もスキャンします（例：サーバー側で検証されていないハードコードされたクライアント側の認証情報チェック。誰もコメントを残さない類の問題だからこそ、コメントの有無に頼らず、専用の検出機能が必要です）。すべては<repo>/.dossier/に保存されます。これはこのツール独自の一時状態で、元のリポジトリ内に置かれ、共有もアップロードもされません。次のような概要が返されます。

{
  "routes": 8,
  "existingTests": 0,
  "signals": 3,
  "buildConfig": ["tailwind", "next"],
  "openCases": 3,
  "savedTo": "/absolute/path/to/some-app/.dossier/evidence.json"
}

ここでのopenCasesには、すでに照合結果が反映されています。自動解決されなかったコメントや TODO の兆候、構造上の問題は、ケースキューのエントリとして自動的に登録されます。

routesが0の場合、アプリにルートがないと判断する前に、monorepoHintフィールドを確認してください。ingest_repoには、モノレポのルートラッパーではなく、実際のアプリのディレクトリを指定する必要があります（apps/*／packages/*が隣接するpackage.json。Turborepo／Nx／ワークスペース構成でよく見られ、workspacesフィールドを宣言していない場合も含みます）。ヒントには、apps/／packages/以下で見つかった実際の候補ディレクトリが一覧表示されるため、自分でアプリを探す必要はありません。候補のいずれかを指定して、ingest_repoを再実行してください。

クライアントが MCP elicitation に対応している場合は、手動での再実行を省略できます。interactive: trueを渡すと、候補があるモノレポのルートが検出された際に、ingest_repoが実際のアプリを尋ね、そのまま取り込みます。自動で推測することはありません。これは、get_case_queueのインタラクティブモードが、ユーザーの確認なしに何かを解決せず、必ず尋ねるのと同じです。辞退した場合、クライアントが非対応の場合、または実際の候補以外を回答した場合は、上記のヒントのみがそのまま提示されます。

2. （任意）稼働中のサイトをクロールする

crawl_site({ url: "http://localhost:3000", repoPath: "/absolute/path/to/some-app" })

アプリが実際にどこかで稼働している場合にのみ役立ちます。ヘッドレスの Playwright でアクセス可能なルートをクロールし、定期的に進捗通知を送信します。長時間のクロールは多くの MCP クライアントで自動的にバックグラウンド化されます。通知なしで数分かかる呼び出しを行うと、クライアントが応答なしと判断して終了させるおそれがあります。

ブラウザーが必要なのはこの手順だけです。crawl_siteはヘッドレス Chromium を操作しますが、サーバーには（Smithery 経由の場合も含めて）同梱されていないため、先に一度npx playwright install chromiumを実行しないとツールは失敗します。この手順を省略しても、残りのワークフローは引き続き利用できます。ingest_repo、resolve_case、generate_specにはブラウザーは必要ありません。

3. （任意。ただし手順 4 の前に実行してください）すでに不具合だとわかっているものに印を付ける

flag_known_bug({
  repoPath: "/absolute/path/to/some-app",
  description: "The login gate secret check runs entirely client-side and is bypassable"
})

システム全体で最も低コストかつ最も信頼できるシグナルです。人間による直接の指摘は、常に推論より優先されます。一致する内容は、他のすべてのシグナルがその動作を意図的なものと示していても、自動解決を上書きします。キューを解決する前に実行してください。表示される内容が変わるためです（他の根拠がまったくなくても、それだけでケースを作成できます。この点が重要な理由はdocs/v0-findings.mdを参照してください）。

照合は各オープンケースのファイルパスと主張文に対する単純なトークンの重複判定であり、あいまい検索や意味検索ではありません。そのため、コードベースに似た名前のコンポーネントが複数あると、1 つのバグの説明が意図した以上のオープンケースに一致し、それらを自動解決してしまう場合があります。検証済みの例では、「the login gate」に関する 1 件のバグ報告が、レビュー前に Madeline の重複に近いゲートコンポーネント 3 件すべてに一致し、1 回の呼び出しでクローズされました。resolve_caseは、現在のステータスにかかわらず、ケースの判断を上書きします。意図した結果ではない場合は、広く巻き込まれたケースにも直接実行してください。処理されたケースがすべて同じ判断に該当していたと思い込まないでください。

4. ケースキューを解決する

get_case_queue({ repoPath: "/absolute/path/to/some-app", interactive: true })

interactive: true を指定すると、MCP のエリシテーションを介して未解決のケースを1件ずつ処理します。クライアントが対応している場合は、証拠を並べて表示する実際の対話型プロンプトがクライアントに表示されます。対応していない場合（またはスクリプトを使っている場合）は、代わりにケースを1件ずつ解決してください。

resolve_case({ repoPath: "/absolute/path/to/some-app", id: "case:...", decision: "intentional", note: "..." })

この手順に近道はありません。 設計上、未解決のケースが残っている間は generate_spec を実行できません。注意書き付きで再構築エージェントに渡せる部分的な仕様や作成途中の仕様は存在しません。フェーズ1〜2こそが、そもそも spec/ を生成する処理です。

5. 仕様を生成する

generate_spec({ repoPath: "/absolute/path/to/some-app" })

キューが空になった後にのみ呼び出せます。CLAUDE.md、.claude/（ルール、フック、spec-auditor サブエージェント、および verify-against-spec スキル。すべてひな形ではなく、このプロジェクトの実際の契約とテストから生成されます）、spec/（契約、確定した決定事項、test-dependencies.json、untested-contracts.json）、および tests/ を、元のリポジトリではなく、クリーンな兄弟ディレクトリ some-app-rebuild/ に書き込みます。さらに2つの .claude/ 成果物は、必要な場合に限って生成されます。test-verifier サブエージェントは、保留中のテストを保護する必要がある場合にのみ生成されます。parallel-test-fix ワークフローは、生成されたテストが共有ルートファイルに基づいて、同時に修正する価値のある2つ以上の独立したクラスターに分かれる場合にのみ生成されます。上記の検証済みの例のように、同じルートを対象とするテストが数件ある小さなアプリには、どちらも生成されません。これはバグではありません。実際の用途が何もないツールを再構築エージェントに渡さないよう、ジェネレーターが判断しているのです。この手順では実際のミューテーションチェックも実行します。元のコードをスクラッチコピー上で意図的に壊し（比較演算子を反転する、null チェックを削除する、ループ境界を1つずらすなど）、生成された各テストが実際にそれを検出することを確認します。検出できなかったテストは、信頼できるものとして出荷するのではなく、tests/weak/ に移されます。次の結果が返されます。

{
  "outputDir": "/absolute/path/to/some-app-rebuild",
  "mutationsChecked": 8,
  "weakTests": [],
  "unrunnableTests": []
}

weakTests と unrunnableTests はどちらも tests/visible/ ではなく同じ tests/weak/ ディレクトリに格納されますが、その理由は区別しておく価値があります。弱いテストは正常に実行されたものの、ミューテーションによって壊された箇所を何も検出できませんでした。実行不能なテストは、元の変更されていないコードに対してすら一度も成功していません（import の破損、環境変数の不足、リポジトリだけでは用意できないインフラなど）。この区別がなかった頃は、実行不能なテストも、テスト対象のコードにミューテーションが施されているかどうかにかかわらず同じように「失敗」するため、100％有効なテストと見分けがつきませんでした。どちらもエラーではありません。特定のテストが tests/visible/ に置かれるに値しなかったことと、その理由を、このツールが正直に伝えているのです。

生成されたすべてのテストが tests/weak/ に格納され、mutationsChecked: 0 となった場合は、構造的な問題があると決めつける前に warning フィールドを確認してください。はるかによくある原因は、対象リポジトリで npm install が実行されていないことです。そのため、ミューテーションチェック用のスクラッチコピーに対象アプリが実際に必要とする依存関係（next、@prisma/client など）が一切なく、生成されたテストはそれらを import することすらできません。generate_spec はこれを直接チェックして、そのように通知するため、すべてのテストが実行不能になるという不可解な結果の原因を自分で調べる必要はありません。

オプション：ビジョンによるページコンテンツの分類

Next.js を対象にする場合、ページルートには、上記の API ルートテストに加えて、実際に Playwright でキャプチャしたテスト（スクリーンショットと DOM テキストのアサーション）が追加されます。キャプチャしたテキストに完全一致のアサーション（static）を使うか、緩やかな形式チェック（dynamic）を使うかは、デフォルトでは小規模な正規表現分類器で判定します。ほとんどの場合は信頼できますが、実際のアプリで両方向の誤判定が起こることが確認されています（ハードコードされたドロップダウンの説明をライブデータと判定し、ライブデータベースのカンマ区切りの件数を固定値と判定しました）。

generate_spec の呼び出し前に GROQ_API_KEY と REBUILD_DOSSIER_ENABLE_VISION_CLASSIFICATION=1 の両方を設定すると、キャプチャした各ページのスクリーンショットと（シークレットを除去した）ソースコードが、代わりに Groq のビジョンモデルに送信されます。これにより、レンダリングされた文字列の見た目だけから推測するのではなく、値の実際の出所（ソース内のリテラル配列か、fetch／useState の呼び出しか）を確認できます。両方の変数が必要なのは意図的です。無関係なツールで設定されたままの GROQ_API_KEY によって、この対象リポジトリのコードがサードパーティーに知らないうちに送信されることがあってはなりません。どちらの変数も設定しない場合（デフォルト）は動作に一切変更がなく、generate_spec がすでに行う処理以外のネットワーク呼び出しもありません（唯一の例外は、初回実行時にミューテーションチェックで使う固定バージョンの vitest ランナーを ~/.cache/rebuild-dossier/ に一度だけダウンロードすることです）。

これは追加コストが実際に発生し、無料ではありません。キャプチャしたページごとに Groq API を 1 回呼び出すほか、ページ間に意図的に約 20 秒の間隔を設けます（Groq の無料枠は 1 分あたりのトークン上限が厳しく、連続してリクエストを送るとすぐに使い切ってしまうためです）。その実行で追加される正確な時間は、generate_spec 自身の応答に記載されます。レート制限、ネットワークの問題、無効な応答など、何らかの理由でページをこの方法で分類できない場合、そのページに限って正規表現分類器にフォールバックし、pageVisionFallbacks に報告します。黙って処理が抜けたり、実行が失敗したりすることはありません。Groq の無料枠（クレジットカード不要、console.groq.com から利用可能）で試すには十分です。

6. 引き継ぐ

cd /absolute/path/to/some-app-rebuild
mv tests/held-out ../held-out-sealed   # keep the acceptance suite out of the agent's reach
claude                                 # a genuinely fresh, top-level session

結果に意味があるかどうかは、次の 3 点で決まります。

1. パッケージディレクトリで開いた、トップレベルの Claude Code セッションとして実行してください。 ガードレールは .claude/settings.json の Claude Code フックです。別のセッションの Agent ツール経由で開始したセッション（サブエージェント）ではフックが読み込まれず、そのことを知らせるものもありません。ほかのエージェント（opencode、oh-my-pi、Codex）でもパッケージは使えますが、これらのフックがなければ、ガードレールは文章だけのものになります。
2. エージェントの作業が終わるまで tests/held-out/ にアクセスできないようにし、その後、自分で一度だけ実行してください。 mv ../held-out-sealed tests/held-out && npx vitest run tests/held-out。失敗するホールドアウトテストを読んだり、再実行したりできるエージェントは、エラー出力から期待される答えをコピーできます。このプロジェクト自身の評価でも、実際にそれが起きました。
3. 終了後にフックが動作していたことを確認してください。 cat .claude/.hook-heartbeat.json を実行し、count がゼロより大きいことを確認します。ファイルがなければ、フックは一度も実行されていません。

kickoff-prompt.txt の内容をそのまま貼り付けてください。そのセッションのコンテキストには、ほかに何も含めないでください。ディレクトリは意図的に完全な自己完結型になっています（仕組みを参照）。そのため、再構築エージェントが読むものも、方針を逸脱するきっかけも、クリーンに構築する代わりに既存のものを編集する余地もありません。実際のアプリに対して実行したときに何が起こるか、どこで行き詰まったかの詳細を含め、docs/v0-findings.md を読んでください。

他のツール（oh-my-pi、opencode など）からの接続

実行方法は2通りあり、どちらも完全にローカルです。ホスト型／共有インスタンスはなく、必要もありません。

stdio（デフォルト） — 各ツールがサーバーのコピーをローカルサブプロセスとして起動します。これは、すべての MCP クライアント（Claude Code、oh-my-pi、opencode）がローカル MCP サーバーを追加する標準的な方法です。このリポジトリのディレクトリから npx tsx src/index.ts（またはビルド済みの node dist/index.js）を指定します。追加のセットアップや認証は不要で、このセクションの内容は適用されません。

HTTP（任意） — 各ツールがそれぞれ独自のサーバーを起動する代わりに、複数のツール／セッションが接続する、localhost 上の単一の永続サーバーです。oh-my-pi と opencode（または複数の Claude Code セッション）で稼働中のインスタンスを共有したい場合に便利です。引き続き完全にローカルで、実際に接続するホスト名（localhost）を MCP_ALLOWED_HOSTS に含めるだけで済みます。自分のマシン以外にも意図的に公開する場合を除き、実際のドメインは必要ありません。

npm run build
PORT=8080 \
MCP_AUTH_TOKEN=$(openssl rand -hex 32) \
MCP_ALLOWED_HOSTS=localhost,127.0.0.1 \
REBUILD_DOSSIER_ALLOWED_PATHS=/absolute/path/to/your/projects \
npm run start:http:prod

3つすべての環境変数が必須です。サーバーは意図的に、これらがないと起動を拒否します。MCP_AUTH_TOKEN はすべての /mcp リクエストを（ベアラー認証で）制限し、MCP_ALLOWED_HOSTS は DNS リバインディングを防ぎます。また、REBUILD_DOSSIER_ALLOWED_PATHS（カンマ区切りの絶対ディレクトリ）は、ingest_repo／generate_spec などが操作を許可される唯一のパスです。再構築したいリポジトリを格納している親ディレクトリを設定してください。

oh-my-pi（.omp/mcp.json または ~/.omp/agent/mcp.json）：

{
  "mcpServers": {
    "rebuild-dossier": {
      "type": "http",
      "url": "http://localhost:8080/mcp",
      "headers": { "Authorization": "Bearer ${REBUILD_DOSSIER_TOKEN}" }
    }
  }
}

opencode（opencode.json）：

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "rebuild-dossier": {
      "type": "remote",
      "url": "http://localhost:8080/mcp",
      "enabled": true,
      "oauth": false,
      "headers": { "Authorization": "Bearer {env:REBUILD_DOSSIER_TOKEN}" }
    }
  }
}

oauth: false は、401 時に opencode が自動で OAuth を検出する動作を無効にします。このサーバーがサポートするのは上記の静的なベアラートークンのみで、実際の OAuth フローには対応していません。参照されている環境変数（両方の例の REBUILD_DOSSIER_TOKEN）には、上記の MCP_AUTH_TOKEN と同じ値を設定してください。

開発

npm test        # full suite
npm run typecheck

小規模で単一目的の関数を使用し、全体を通して TDD を実施します（対象の実装より先にテストを記述します。調整ロジック自体も例外ではありません。これはテストを生成するツールであるため、その正確性も機能と同じくらい重要です）。

現在の対象範囲と、意図的にまだ実装していないもの

v0 の対象は、コアの一連の処理を実証することであり、機能を完全にそろえることではありません。意図的に後回しにしており、ひそかに省略するのではなく、実際のバックログとして管理しています。

• API 形式の曖昧さ（バリデーションルールやエラーレスポンスの形式）に対する調整は、まだ実際にテストできていません。これまで検証した、形状が異なる唯一の実アプリ（catchandtrade）には、調整すべきコメント／TODO シグナルがたまたま一つもありませんでした。そのため、この具体的な疑問については、どちらの答えもまだありません。docs/v0-findings.md を参照してください。
• 動画／画面録画の取り込みと、動画 LLM によるフラグ付き区間のレビュー。
• 証拠ソースとしての Original-CLAUDE.md／自動メモリー。
• ヘッドレスクローラーでは到達できない、認証が必要な／複数アカウントのフローを対象とする、ライブ Chrome MCP キャプチャ。
• アセットマニフェストの抽出（バイナリファイルをバイト単位でそのままコピーし、ハッシュマニフェストを作成する、固定された契約層）— 実際の設計はありますが、まだ実装されていません。
• ハンドラー全体を何もしないようにするミューテーター（現在の3つ — 比較の反転、null チェックの削除、オフバイワン — では「この分岐は一度も実行されなかった」というミュータントを生成できません）。

実際の検証で見つかり修正されたバグ、モデル層ごとの比較、未解決の課題について、率直にまとめた全容は docs/v0-findings.md を参照してください。

コントリビュート

コントリビュートをご検討いただきありがとうございます！これは学術／研究プロジェクトです。変更は論文で説明されている設計に沿ったものにしてください。セットアップ、テスト、PR のガイドラインについては CONTRIBUTING.md を参照してください。初めての方も歓迎します — good first issue のラベルが付いた課題を探すか、課題を作成して、何が最も役立つか尋ねてください。

代替手段との違いについては、rebuild-dossier の比較を参照してください。

ライセンス

MIT

⭐ rebuild-dossier がよりクリーンな再構築のリリースに役立ったなら、スターを付けると、他の開発者にも見つけてもらいやすくなります。