Mirofy

出典を示し、見えなかったものも明らかにする、システムのダイアグラム。

これが製品のすべてです。ブラウザーで開く1つのHTMLファイルです。そこに使われている色はすべて、システム独自の語彙――バックエンド、データベース、クラウド、セキュリティ、メッセージバス、外部――だけを表します。それ以外の意味はありません。色が示すのは矢印の向きではなく、対象が何であるかです。
このファイルをそのまま開く ↗ — ノードをクリックすると根拠を確認でき、そこに到達するものをたどり、検索やプレゼンテーションができます。

---

概要

Mirofyにリポジトリを指定します。コードを読み取ってエビデンスグラフを構築し、そのグラフからモデルを作成し、モデルを1つのHTMLファイルにコンパイルします。ファイルは開いて、検索し、共有し、確認できます。

描画される関係はどれも、次の問いに答えられます。これを裏付ける根拠は何か？ それぞれに、出典となるファイル、行の範囲、コミットが記録されています。わかっていないことがあれば、空白を埋めるのではなく、ダイアグラムでそのことを明示します。

このリポジトリに対して実行すると、手描きでもモックアップでもない、次のものが得られます。

ここではすべてのボックスが同じ色です。それが重要なのです。この12個はすべて同じもの――マニフェストから導出されたパッケージ――なので、色で示すことは何もなく、実際に何も示していません。上の図に色が使われているのは、そのシステムに実際に6種類の要素があるからです。これらのボックスを見栄えよくするために色付けするツールは、見つけていない違いを作り出すことになります。
ライブ版を開く ↗ — ノードをクリックすると、その背後にあるファイル、行の範囲、コミットを確認できます。

## インストール

インストールは不要です — コマンドを1つ実行するだけで、図が開きます：

npx mirofy-cli map .    # YOUR repository, mapped, in one command
npx mirofy-cli demo     # a finished artifact, to see what this produces
npx mirofy-cli init     # a starter document of your own to edit
npx mirofy-cli render architecture architecture.json

代わりにエージェントに渡す場合 — 1行で、Claude Code、Cursor、Gemini CLI、Ampなど、ほか十数種類にスキルをインストールできます：

npx skills add Hasan-Laraib/Mirofy

続けて、このリポジトリのアーキテクチャを図示してと尋ねてください。エージェントは SKILL.mdを読み、同じCLIを実行します。

Claude Codeでは、プラグインにスキルとMCPサーバーの両方が含まれています：

/plugin marketplace add Hasan-Laraib/Mirofy
/plugin install mirofy@mirofy

どの方法も、同じパッケージを使います。エージェントが図を描くことはありません — 実行するのは、あなたが実行したはずのCLIです。そのため、エージェントの報告がCLIの報告と食い違うことはありません。

mapは指定したディレクトリで、スキャン、モデル化、コンパイル、レイアウト、レンダリングという一連のパイプラインを実行し、コードの隣にarchitecture.htmlを書き出します。map --out <dir>を指定すると、図と中間生成物はそちらに出力されるため、リポジトリには何も置かれません。指定しない場合、中間生成物は<target>/scanに出力されます。出力先のパスを指定した場合は、どちらよりもその指定が優先されます。ワークスペースを宣言していないリポジトリでも動作します。図示するパッケージがない場合は、ソースディレクトリとその間のインポートをモデル化します。

または独自のコードから呼び出す

mirofy-cli/apiは、同じパイプラインをライブラリとして利用できます。argvもprocess.exitも不要で、stderrを解析する必要もありません：

import { render, validate, map } from 'mirofy-cli/api';

const html = await render('architecture', diagram);   // one HTML string
const { ok, diagnostics } = await validate('architecture', diagram);
const { html, drawn, coveragePath } = await map('.');  // the whole pipeline

拒否されたドキュメントでは、.diagnosticsを持つMirofyRenderErrorがスローされます。これはレンダラー独自の構造化レポートで、各エントリにはcode、subject、その根拠となるevidence、対応する修正方法が含まれます。validateはスローする代わりに、そのレポートを返します。「このドキュメントは無効です」は回答の1つであり、100件のドキュメントをチェックするために、100個のtry／catchブロックを用意する必要はありません。

mapの実行にはGitリポジトリが必要です。すべての事実はリビジョンにひも付いているため、コミットのないディレクトリには根拠として引用できるものがなく、その場合は後の処理で失敗するのではなく、その旨を伝えます。

読み取るもの

JavaScript および TypeScript のインポート · Python のインポート · Go のインポート · Java のインポート · Rust のインポート · Kotlin のインポート · package.json のワークスペース · Express および Next のルート · docker-compose。

対象はこれですべてであり、この一覧こそが重要です。それ以外はすべて スキップせずに報告します。coverage.md には、どのアダプターも開かなかったファイルが種類ごとにまとめてすべて記載され、読み取れなかったファイルのほうが読み取ったファイルより多い場合は、map も終了時にそのことを伝えます。Ruby リポジトリを指定すると、.rb ファイルをすべて読み取れなかったものとして示す、正直な空の結果が返されます。examples/ フォルダー内の JavaScript ファイルを2つだけ見て、それらしい小さな結果を断言することはありません。

Python は慣習ではなく、ファイルの存在に基づいて解決します。相対インポートはインポート元ファイルのディレクトリを基準に、絶対インポートはリポジトリのルートと、実際にパッケージを含むディレクトリを基準に解決します。指定子が2つのソースルートに一致する場合は、両方を示すギャップとして扱います。どちらが優先されるかは sys.path 次第であり、それはソース内ではなく設定で決まるからです。

Go は、go.mod が宣言するモジュールパスを基準に解決し、ツールチェーンと同じ方法で標準ライブラリかどうかを判定します。最初のパス要素にドットが含まれていればドメインであり、ドメインはどこかから取得されたモジュールを意味します。Java は、ディレクトリ構成ではなく、ファイルが宣言する package 文からインデックスを作成します。Maven の慣習では com.acme.store は src/main/java/com/acme/store の下に置かれますが、慣習が常に守られるとは限りません。一方、コンパイラーが読み取るのは宣言です。

Rust は、実際のファイルが見つかるまで use の末尾から順に取り除いていきます。use crate::a::b::C だけでは、a、b、C のどれがファイルなのか分からないためです。Cargo.toml からクレート名とソースルートを読み取ります。[lib] path の宣言も考慮します。src/ はあくまでデフォルトだからです。また、tests、benches、examples の直下にある各ディレクトリを Cargo が独立したクレートとしてコンパイルすることも把握しています。

Kotlin はファイル名ではなく、class、interface、object、typealias、fun interface などの宣言そのものから型インデックスを読み取ります。Kotlin のファイル名は、そのファイル内の型名と一致する必要がなく、複数の型を宣言できるためです。このインデックスは Java と共有されます。両者は同じ名前空間にコンパイルされ、互いに自由にインポートできるため、一方の拡張機能だけのインデックスを作ると、もう一方への実際の依存関係は、型が見つからないものとして報告されます。

どの言語でも、リポジトリ内にあるはずなのに存在しないものを指すインポートはギャップです。自分自身の公開済みコピーへの依存として扱われることはありません。

どの種類の図を選べばよいか分からない場合は、npx mirofy-cli guide "show an API request with a cache miss" を実行してください。図の種類が自動で選ばれます。

CLI として使う場合 — npm install -g mirofy-cli。インストールされるコマンドは mirofy です。npm が既存の minify に近すぎるとして単独の名前を拒否したため、パッケージ名には -cli が付いています。

ソースから使う場合 — インストールは不要です。インストールするものはありません。

git clone https://github.com/Hasan-Laraib/Mirofy.git
node Mirofy/packages/core/bin/mirofy.mjs demo

どのパッケージにも実行時依存関係がないため、npm install を実行していないチェックアウトでも動作します。

エージェントスキルとして使う場合 — バンドルをビルドし、エージェントが参照する場所にコピーします。

git clone https://github.com/Hasan-Laraib/Mirofy.git
cd Mirofy && npm install && npm run build:skill

cp -r dist/mirofy ~/.claude/skills/      # Claude Code
cp -r dist/mirofy ~/.agents/skills/      # Codex CLI, opencode

次に、こう依頼します：Use mirofy to map this repository's runtime architecture.

バンドルのサイズは 2.8 MB で、内部のスキル名が付けられています。代わりに packages/core をコピーすると、core という名前のスキルがインストールされます。そのスキルは自身のフロントマターで名前を mirofy と記しており、テストスイートまで一緒に含まれます。バンドルを書き出す前に、build:skill はリポジトリのない場所にコピーして図をレンダリングします。自分自身のチェックアウト内でしか動作しないものは、バンドルとは言えません。

実行時にダウンロードされるものはなく、外部に通信することもありません。更新確認もありません。自分について知らせるためにネットワークへ接続するツールは、ネットワークへ接続するツールだからです。

パイプラインを一つずつ

mirofy map は、次の5つのステップを順番に実行します。中間生成物だけが必要な場合は、 mirofy map . out.html --out ./scan を実行すると、エビデンスグラフ、モデル、ビュー、配置済みドキュメントがすべて、そのディレクトリに書き出されます。

各ステップを個別に実行したり、別の場所を指定したりするには、チェックアウトが必要です。 これらはリポジトリ独自の npm スクリプトであり、インストール済みパッケージが提供するコマンドではありません。

npm run scan                    # repository  → evidence graph
npm run model -- --from-graph --graph scan/evidence-graph.json
npm run compile                 # model       → a bounded view
npm run layout                  # view        → positioned document
node packages/core/bin/mirofy.mjs render architecture scan/diagram.json out.html --repo-root .

このリポジトリを対象に実行すると、223ファイルにわたる1,227件の事実を記録し、読み取れなかった17件のギャップを示します。さらに、19のコンポーネントと21の関係を導き出します。各項目には、その根拠となったファイルと行が記載されます。そして、除外した内容とその理由を記録しながら、12個の図を描画します。

これらの数値は記憶ではなく、検証済みです。以下のこのページの数値をご覧ください。

これらのコマンドで、このページの先頭にある図を再現できます。図はドキュメントとしてassets/にチェックインされています。インタラクティブな成果物はビルドされますが、保存されません。

リポジトリがない場合は、JSONドキュメントを作成するか、Mermaid図を変換できます。

node packages/core/bin/mirofy.mjs import mermaid design.mmd
node packages/core/bin/mirofy.mjs render architecture design.json out.html
node packages/core/bin/mirofy.mjs validate architecture design.json --json

得られるもの

任意のエッジを開くと、それがページに表示されている理由がわかります。関係、その来歴クラス、由来するファイルと行、検証対象のコミットが示されます。その下にあるのは、多くのツールが省略する半分の情報です。スキャナーが特定できなかった内容が、推測ではなく記録されています。
この記録は実在し、このリポジトリから取得したものです。ギャップも同様です。

以下の図について、誠実さを保つ根拠とともに、3つの主張を示します。

色が示すのはノードの種類だけであり、矢印の向きではありません。 ライトとダークの6種類のプリセットがあります。meridianでは、色相が同時に2つの役割を担わないよう、すべての矢印をグラファイト色にしています。 適合性テストの行4.16で実証 · この成果物を開く ↗

5種類の図、1つのスキーマ、1つのバリデーター。 architecture · workflow · sequence · dataflow · lifecycle — すべてを支えるのは、同じ型付き IR です。 適合性テストの行1.1で実証。ベースラインのフィクスチャから、5種類すべてを1回の処理で描画します · この成果物を開く ↗

ファイル1つ。サーバー不要で、ネットワークから取得するものもありません。
図、エビデンス、検索、あらゆる操作はすべてこのファイルに含まれています。インターネットへのアクセスが必要になるのはウェブフォントだけですが、その読み込みを待つことはなく、なくても動作します。フォントがなくても、システムの等幅フォントにフォールバックします。
_{毎回、scripts/check-readme-claims.mjsで検証されます。このスクリプトは、初回描画を妨げたり図の内容を変えたりする可能性のある参照が見つかるとビルドを失敗させます。また、この文が成果物の実際の取得内容を誇張した場合にも、同様に明確に失敗します。}

30種類すべてを公開中 ↗ — 5種類の図 × 6種類のプリセット。コミットごとに再ビルドされます。

### 実際に使われているビューアー

モックアップではありません。以下の各フレームは、実際にリリースされたビューアーをキャプチャしたもので、scripts/build-screenshots.mjs が実際のクリック操作で動かしています。このスクリプトは、コントロールの名前が変更されたり、パネルが開かなくなったりすると、古い画像を再利用せずに失敗し、何も起こらなかった機能のスクリーンショットも保存しません。

何でも見つけられます。 api と入力すると、10個のノードが2個に絞り込まれます。キャプチャではリストが実際に縮小したことを検証します。フィルターがかかっていないリストのスクリーンショットは、検索のスクリーンショットではありません。	ノードに出所を尋ねられます。 conformance、source-backed。固定されたコミットにある packages/conformance/package.json を引用しています。この例は、このリポジトリからキャプチャしています。作成済みのサンプルには引用がなく、証拠を欠いたパスポートでは、主張を示す代わりに証拠が表示されないことを示すことになるためです。
何が何に到達するかをたどれます。 Worker の上流には、6個のノード、6個のリンク、5ホップがあります。これらを明るく表示し、経路外の要素はすべて暗く表示します。キャプチャでは、最も深く到達するノードを選ぶため、画像には1本の矢印ではなく、経路が表示されます。	システム全体の役割を比較できます。 Semantic Lensは、ノードを1つずつではなく、すべてのノードの出所と種類に一度に答えます。

---

図表ツールにはない機能

推測をしません

スキャナーが解析できないファイルは、黙って除外されず、記録された欠落になります。すべての事実には6つの出所クラスのいずれかがラベル付けされるため、source-backed と inferred が同じように見えることはありません。

証拠だけでは判断できない場合も、同じルールが適用されます。派生コンポーネントの種類は package です。スキャナーが把握しているのはマニフェストが存在することまでで、それが「バックエンド」かどうかはわかりません。Node組み込みモジュールのインポート878件は、数えて名前を示しますが、図には描かず、黙って除外することもありません。Pythonでは、計算された importlib.import_module(name) は行番号付きの欠落として扱われ、解析前にドックストリングが空白に置き換えられます。そうしないと、インポート例が並ぶドックストリングが、コードには存在しないエッジとして、説明文を出典にして追加されてしまいます。検証用の固定コミットがない引用は表示せずに破棄します。誰にも確認できない引用は、引用がないよりも悪いためです。map は origin リモートからコミットを読み取ります。読み取り可能なリモートがない場合は、--repo-url と --revision を指定します。

パスポートに表示するソースは最大3件です。43件のリンクはパスポートではないためです。その場合は 「43件の引用元のうち3件を表示」 と示すため、表示上の上限が証拠に関する主張と誤解されることはありません。

システムについての質問に答えます

mirofy explain callers api     # what points at api
mirofy explain impact api      # what is downstream of it
mirofy explain find payment    # id, label, kind or metadata match
mirofy explain gaps            # what the scan could not read

回答にはすべて、結果を変える可能性のある未読ファイルが示されます。スキャナーがすべてを読み取ったなら「PaymentServiceを呼び出すものはありません」は役立ちますが、6つのファイルの解析に失敗しているなら無責任です。そのため、結果が空の場合は見つからないという意味であり、存在しないという意味ではありません。

impact が示すのは、あくまで到達可能性です。それ以上のことは主張しません。何が接続されているかはグラフに関する事実ですが、変更によってそれが壊れるかどうかは実行中のシステムについての判断であり、Mirofyにはそれを裏付ける証拠がありません。

エージェントも質問できます

MCP 経由で同じクエリを利用できます。ツールは 11 個で、エンジンも同じです。CLI と食い違う可能性のある別実装ではありません。assert と timeline もあります。「この変更は許可されているか」「ここでは何が動いているか」は編集中にエージェントが尋ねる質問であり、答えを得るためにシェルを呼び出さなければならないエージェントは、そもそも質問しません。

{ "mcpServers": { "mirofy": { "command": "npx", "args": ["-y", "mirofy-cli", "mcp"] } } }

任意の MCP クライアントを接続できます。クライアントの起動ディレクトリを基準に ./scan を読み込みます。これは map --out ./scan が最後に書き出した内容です。--model と --graph で上書きできます。クローンは不要で、事前のインストールも必要ありません。

不完全であるという警告は、JSON だけでなく、エージェントが読む文章にも含まれています。ほとんどのクライアントはテキストをモデルに渡し、残りは破棄します。

アーキテクチャルールをチェックします。結果は 2 つではなく 3 つです

mirofy assert     # reads architecture-rules.json

pass、fail、そして unproven です。未読ファイルのあるスキャンで違反が見つからなかったルールは、成立すると実証されたわけではないため、合格にはなりません。未解決の箇所を緑のチェックに変えることは、このプロジェクトが防ごうとしている唯一の失敗です。

解消されないギャップもあります。たとえば、ベースパスが変数である動的インポートは、推測せずに解決することはできません。こうしたギャップは、理由を引用し、文書化した根拠を添えて、パスごとに承認できます。動的インポートに対して書かれた承認は、そのファイルの解析に失敗した時点で適用されなくなります。また、1 つの承認を根拠に合格したルールは、そのことを明示します。

[ok  ] no-cycles — No violation. 8 unread file(s) are acknowledged as unable
       to hide one; this rests on that judgement, not on a complete scan.

2 passed, 0 failed, 0 unproven of 2
2 of those rule(s) rest on acknowledged gaps, not on evidence.

何が動いているかを知らせます

mirofy timeline                                # cited-file churn, newest first
mirofy drift --base a.json --head b.json       # what two scans say differently

ドリフトレポートは、変化した事実だけを報告します。スコアも、リスクラベルも、マージの推奨もありません。すべてのプルリクエストで実行され、プルリクエストが失敗することはありません。

---

できれば公開したくない数値

ベンチマークで尋ねるのは、ただ 1 つです。モデルに文書で書かれたブリーフを渡したとき、モデルが作成する図が初回で実用可能になるのはどれくらいの頻度でしょうか。

現時点では、Claude Code が作成した 8 件のブリーフで 2 件です。

node scripts/benchmark.mjs --author "<your command>" --model "<id>" --keep benchmarks/corpus/mine
node scripts/benchmark.mjs --replay benchmarks/corpus/mine

良い数値ではありませんが、これが実際の数値です。それでも公開する価値がある理由は 3 つあります。

実用可能とは、受け入れられることではなく、問題がないことです。 警告は、図をもう一度確認する必要があると知らせるものです。まさに初回成功率から除外すべき状態です。このセットには、エラーなしで検証に合格した文書がさらに 2 件ありますが、これらも数には含めていません。

新しいコーパスではなく、保存済みのコーパスに対して測定しています。 --keep はモデルの出力を保存し、--replay はモデルを再度呼び出さずに、保存済みの同じ文書でツールを再実行します。この 2 つを分けなければ、再実行するたびに文書とツールの両方が変わり、変化の原因をどちらにも帰属できてしまいます。そのため、何が問題なのか誰にも分からないまま、成功率は何週間もゼロのままでした。リプレイでは、作成者が違うと主張することすらできません。モデルは保存済みのマニフェストから読み込まれ、異なる場合は --model が拒否されます。

数値が変化した理由を説明できます。 レイアウトエンジンへの直近の変更により、同じ 8 件の文書で成功率は 0 件から 2 件になり、構成エラーの合計は 121 件から 34 件になりました。これは、「ラベルを短くするかサイズを広げてください」という診断が、レンダラーの選んだ枠に収めるために、システムの一部の名前を変更するよう作成者に求めていたためです。現在はレンダラーが枠を広げます。

これを他の場所で公開されている数値と比較する場合は、何を測定したかを確認してください。バリデーターを呼び出して自分の出力を修正できるエージェントを対象とし、最後に人がレビューする成功率は、何もヒントを与えずにモデルへ 1 回だけ出力させる測定とは異なります。どちらが優れているということではなく、測定が異なるのです。私たちの測定は後者です。

---

アーティファクトの内部

• Node Finder、Semantic Lens、Semantic Radar — 一度に読み取れないほど大きな図を検索、絞り込み、俯瞰できます
• Route Probe — 有向パスを解決し、経路をホップごとにたどって確認できます
• Semantic Passport — ノードをクリックすると、その型、タグ、引用された根拠が表示されます。固定されたコミットに裏付けられているものには、Verified Source Beacon も表示されます
• 他のすべてと分けて描画される自分のコード — 自分が書いたモジュールは実線、サードパーティ製パッケージは破線です。色ではありません。色覚に配慮したプリセットでは、7つの色相を7つのセマンティックロールですでに使い切っているため、8つ目を追加しても、一部の読者にしか見分けられない区別になってしまいます
• ガイド付きビュー、プレゼンテーションモード、モーションガバナー、?embed=1
• クリップボードに直接コピーできる3種類のエクスポート：
  • Export → Share Card — 現在のテーマとプリセットを使った1200×630のPNG
  • Export → Route Share Card — Route Probeが解決した正確な経路
  • Export → Reach Share Card — 到達可能性クエリが返した集合

カードには、読者が実際に行った操作が表示されます。どのカードも検証済みとは主張せず、結果が何も返されなかったクエリから生成されることもありません。

npm run gallery      # every type in every preset → preview/index.html
npm run build:site   # the same, plus this repo's self-model → site/

2つ目は、すべてのコミットでCIが hasan-laraib.github.io/Mirofy に公開するものです。コミットされるものはありません。サイトは説明対象のコミット時点のコードからビルドされるため、古い状態をひそかに説明し続けることはありません。

別の場所で使う

インタラクティブファイルは約720 KBですが、それに見合う価値があります。ただし、その機能はREADME、プルリクエスト、Notionページではどれも維持されません。いずれもスクリプトが取り除かれるためです。そこで：

# 19 KB standalone SVG: no scripts, no stylesheet needed
node packages/core/bin/mirofy.mjs render architecture in.json out.svg --format svg-static

# or open it in an editor you already own — from a checkout; the export
# package is not bundled into the published CLI
npm run export -- drawio     architecture in.json
npm run export -- excalidraw architecture in.json

共有先	方法
README、プルリクエスト、Notion、Confluence	svg-static
Figma、Canva、Illustrator、Sketch	svg-static — スタイルが属性として記述されるため、色もそのまま反映されます
diagrams.net・draw.io VS Code extension	drawio — 実際の図形とコネクタ
Excalidraw・Obsidian・VS Code	excalidraw — 接続された矢印と、移動可能なボックス

SVGにはスタイルが二重に含まれています。スタイルシートと各要素の両方です。SVGではスタイルシートが属性より優先されるため、ブラウザーはCSSから描画し、属性はCSSが無視される場合にのみ使われます。Figma、Canva、Illustratorでは、まさにこのとおりです。属性がなければ、図の形状は正しくインポートされても、色は失われます。

どちらのエディター向けエクスポートでも、失われたものを正確に示します。免責事項を決まり文句で並べるのではなく、実際のドキュメントに基づいて算出します。作成したツールでしか編集できない図は、図を人質に取っているようなものです。

証明されていること

適合性マトリックスには105行あります。85行はブラウザーなしで証明済みです。さらに19行はヘッドレスChrome（MIROFY_CHROME）を必要とし、合計104行です。

npm run check    # lint, types, 1,000+ tests, golden parity, conformance, size, audit

各行にはテストが指定されており、タイトルは一字一句一致していなければなりません。証明ファイルが通っていても、そのテスト自体の名前が変更されている行は、合格ではなく未証明として扱われます。1行（6.10、決定的なZIPパッケージング）は未証明であり、ひそかに除外せず、そのまま未証明として数えています。

スキップは合格ではありません。 ブラウザーが実際に実行されない限り、ブラウザーを必要とする行は証明済みの合計に含まれません。

このページの数値も確認されています。

node scripts/check-readme-claims.mjs

マトリックスを数え、MCP サーバーが提供するツール一覧を読み取り、アーティファクトをレンダリングしてサイズを測定し、ベンチマークを再実行します。レビューで、ここの3つの数値が同時に誤っていると判明したことを受けて、これを実施しています。どれも意図的に誤っていたわけではなく、記載した時点では正しかったものの、リポジトリに残された数値でした。主張の検証を説くページが、未確認の主張を載せるべきではありません。

証拠と来歴

決して混同しない6つのクラスです。

class	意味
authored	人間が記述したもの
source-backed	引用されたファイルと行範囲から読み取ったもの
statically-derived	コードを実行せずに算出したもの
config-derived	マニフェストから読み取ったもの — コードではなく設定
runtime-observed	実際の実行で確認したもの
inferred	推測であり、推測であると明記したもの

ソース引用は、描画前に実際のローカルチェックアウト内で、固定された40文字のコミットに対して検証されます。そのリビジョンに存在しないパスは、リンク切れではなくエラーになります。

複数のリポジトリを一度に宣言でき、引用にはどのリポジトリに属するかが示されます。正しいリポジトリではなく、単にあるリポジトリに対して検証することが、別のリポジトリのパスをこのリポジトリの証拠として通してしまう原因です。

パッケージ

パッケージ	役割
scanner	リポジトリを読み取り、事実と不足情報を抽出するアダプター
evidence	追記専用の証拠グラフ、クエリ、誠実なカバレッジ
model	システムモデル：安定したID、証拠参照、人間によるオーバーライド
compile	ビューコンパイラーとプランナーとの接続点
explain	グラフクエリ、アーキテクチャルール、ドリフト、タイムライン
mcp	エージェントのコンテキストとしてのモデル
import	Mermaidを型付きドキュメントに変換
export	draw.ioとExcalidrawへのエスケープ手段
layout	制約レイアウト：意図から座標へ（開発時）
judge	オプトイン：System Oneモデルに不足情報について質問し、その記録を保持
core	レンダラー、スキーマ、バリデーター、CLI
viewer	1つのテンプレートに組み込まれたインタラクティブビューアー
benchmark	保存されたコーパスを使った、初回パスでの使用可能率
conformance	マトリックスと、各行で指定されたテスト

すべてのパッケージにおいて、ランタイム依存関係はゼロです。成果物には、このプロジェクト自身以外は何も含まれません。

packages/core/assets/template.htmlはpackages/viewer/から生成されます。直接編集しないでください。ソースを編集してnpm run build:templateを実行してください。npm run check:templateはソースから再ビルドし、コミット済みのファイルに差異があれば失敗します。

帰属表示

すべての成果物には、何によって作られたかが記載されます。ビューアーのフッターは閉じることができます。図はあなたのものであり、閉じられないバナーは他人のドキュメントへの押しつけになります。シェアカードには恒久的な表示を付けます。カードは文脈から離れて共有され、出所を示すものが何もない場所に届くためです。

ツール名のみを記載し、図についての主張はせず、URLも含めません。共有されるすべての成果物に埋め込まれたリンクは、リンク先のアドレスよりも長く残ってしまうからです。

MIT。packages/core/LICENSEには、インポートしたレンダリングコアに必要な第三者の著作権表示がそのまま保持されています。ルートのLICENSEは、このプロジェクト独自の成果物を対象としています。