visiomaster

Visiomaster

概要

visiomaster は、図の画像を編集可能な Visio 成果物として再構築するためのスタンドアロンのスキルです。

次の用途に最適化されています：

• フローチャート
• 製品またはシステムのアーキテクチャ図
• 論文風のモジュール／フレームワーク図
• 編集可能な状態を保つべき、ボックスと矢印で構成されたプロセス図

次の用途には適していません：

• ポスター
• UI のスクリーンショット
• 装飾的なレイアウト
• 構造化された図の意味よりも視覚的なスタイリングが主な価値である、画像中心のスライド

基本的な位置付け

前半の工程では ppt-master の考え方を使用します：

• ソースの収集
• スタイルの抽出
• レイアウトの規律
• 画像の理解
• ビジュアル仕上げの基準

Visio では、ppt-master の未加工な SVG -> PPTX 出力経路を再利用しないでください。

Visio では、次の安定した経路を使用します：

image -> scene.json -> validate -> Visio COM render -> .vsdx/.svg/.png

基本ルールはシンプルです：

• 主要な構造は、編集可能なノード、ラベル、コネクタとして描き直します
• 小さなサムネイルやテクスチャの断片は、描き直すことで速度が大きく損なわれる場合に限り、ラスター画像のままでもかまいません
• ユーザーが明示的に画像の貼り付けを求めていない限り、元の画像全体を貼り付けて再構築の依頼を解決してはいけません

環境

このスキルは Windows を優先しており、次を前提とします：

• Microsoft Visio デスクトップ版がローカルにインストールされていること
• pywin32 を含む Python

現在のスレッドで既定の Python インタープリターを使用します。ユーザーまたはプロジェクトから特定の Python パスが指定されている場合はそれを使用し、指定がない場合は次を使用します：

python

ワークフロー

1. 対象範囲の確認

まず、ソースの依頼を次のいずれかに分類します：

• 編集可能なフローチャートの再現
• アーキテクチャ／モジュール図の再現
• 論文図の整理／描き直し
• 少数のラスターサブアセットを許容する、画像を活用した描き直し

図の大部分がボックス、矢印、ラベル、コンテナーで構成されている場合は、visiomaster を使用します。

画像を基にした厳密な複製では、厳格なレビューに対応できる状態だと主張する前に、必ずローカルのソース画像ファイルを確保してください：

• ユーザーがファイルシステム上のパスを指定した場合は、そのパスを metadata.source_image と、すべてのレビュー用 --original 入力に使用します。
• ユーザーがローカルパスなしで画像をアップロードまたは添付した場合は、最終成果物をレンダリングする前に、その画像を再構築ワークスペースの source/original.<ext> として保存／ステージングします。チャットの添付画像だけでは、厳格なレビュー用ソースとして不十分です。
• 現在のクライアントで添付画像を読み取り可能なバイト列として取得できず、画像をローカルにステージングできない場合は、作業がドラフト／手動プレビューであることを明示し、厳格なレビューまたは最終的な厳密納品の前にソースファイルのパスを求めてください。
• すべての厳密な複製では、レビューを重ねる間もステージング／ローカルのソースパスを固定してください。元のソース画像の代わりに、複製のスクリーンショット、画像ペア、OCR 出力、または添付画像の記憶を使用してはいけません。

ソースファイルのパスがある場合は、ヘルパースクリプトでステージングし、レビュー用マニフェストで安定した正規画像を使用できるようにします：

python ${SKILL_DIR}\scripts\stage_source_image.py `
  --input <source.png> `
  --workspace <reconstruction_workspace> `
  --id <figure_id>

これにより、SHA-256 ハッシュを含む source/original.<ext> と source/source_manifest.json が書き込まれます。ステージングした画像パスを metadata.source_image と make_review_assets.py --original に使用します。

横長または情報量の多い図では、ページ全体を一度に作成し始めないでください。ソースに多数のモジュールや矢印、小さなラベルが含まれている場合、またはキャンバスが非常に横長の場合は、まず領域の計画を作成します：

• 目に見える領域には group_container を使用します
• 目に見えない論理的な作業領域には audit_region を使用します
• 意味のあるノードすべてに container_id を設定します
• ページ全体を組み立てる前に、各領域の目に見えるノード数を通常 12～18 個未満に抑えます
• 領域のシーンを統合する前に、共通のタイポグラフィと矢印のスタイルを決めます 完全一致する複製を作成する場合は、対象画像固有の、ソースに忠実なビジュアルインベントリを作成するまで、scene.json を書き出さないでください。このインベントリは、ソース画像を目視で確認する LLM によって作成します。OCR、ファイル名の手がかり、警告ログ、以前のシーン、バッチシーンジェネレーターを用いてはなりません。ソースに表示されている言語と表記を正確に保持する必要があります。中国語のラベルを英語に翻訳したり、数式を標準化したり、判読不能なテキストを創作したり、ソースに明示されていない限り、ソースのモジュールを汎用のニューラルネットワークブロックに置き換えたりしないでください。

最初のレンダリング前に、インベントリを metadata.source_visual_inventory に記録してください。最低限、次の内容を含める必要があります。

• analysis_basis：visual_llm_source_image のような短いメモ。
• language_profile と do_not_translate。
• unknown_text_policy：不鮮明な小さなテキストには mark_unreadable_do_not_invent を使用します。
• 領域ごとの source_bbox_px、必須の表示ラベル／数式、コンポーネントのモチーフ、エッジのモチーフ、ポート／境界／破線フレームに関する注記、不確実性に関する注記、テキストレイアウトの事実。

完全一致する複製のために最初の edges 配列を作成する前に、ソース画像をもとに独立した矢印インベントリの確認工程を実施してください。目的は、Visio PNG が存在する前にトポロジーを確定することです。矢印が密集した局所構造では、この工程は単なる記録作業ではなく、シーンの設計を決めるものです。

• ソースに表示されている矢印をすべて metadata.arrow_plan に記録します。
• 表示されている矢印または線分には、それぞれ独立した arrow_plan_id を割り当てます。局所的なサブグラフ全体や複数段の接続を、1 つのプラン項目でまとめて記述しないでください。
• 各項目には、id、from_visual_object、from_anchor_description、to_visual_object、to_anchor_description、route_shape、line_style、arrowhead、semantic_intent、source_bbox_px、must_not_cross、relative_position_facts、方向、終点／境界に関する事実、確度を含める必要があります。
• 通常のフローには semantic_intent: "data_flow"、破線の戻り経路には "feedback"／"loss_backprop"、フレーム端の矢印には "boundary_handoff"／"frame_output"、多対一の結合には "merge"／"fan_in"、一対多の分岐には "fork"／"fan_out"、外側の循環には "loop_update" を使用します。
• straight_horizontal、straight_vertical、orthogonal、rounded_orthogonal、smooth_curve、loop などの経路形状を使用します。主要な矢印を曖昧な auto のままにしないでください。
• edges を作成した後、ソースに表示されているすべてのエッジに arrow_plan_id を割り当てます。
• デフォルトでは、1 つの arrow_plan_id を割り当てられるシーンエッジは 1 つだけです。1 本のソース矢印を複数のシーン区間に分ける必要がある場合は、各区間エッジで same_source_arrow: true、segment_index、segment_count を宣言する必要があります。
• ソース矢印が判読不能な場合は、certainty: "uncertain" とし、終点を創作しないでください。

後でビジュアルレビューを行う際の、ソースの正解確認用チェックリストとして metadata.arrow_plan を扱ってください。レビュー担当者が「矢印がおかしい」のような大まかなコメントを書くのではなく、A001、A002 などが元の画像と一致しているかを判定できるようにします。

注意機構に似たモチーフでは、シーンのエッジを描く前に、そのビジュアル文法を分解してください。K/Q -> multiply -> score matrix -> value multiply -> value matrix -> Concat のように見えるソースの切り抜きは、1 本のエッジではありません。局所モチーフを記録したうえで、次の例のように、表示されている各接続を個別にインベントリ化してください。

• A101：K_w の右端 -> qk_mul の左端、水平、矢印ヘッドなし
• A102：Q_a の右上端 -> qk_mul の左下端、短い斜線／曲線、矢印ヘッドなし
• A103：qk_mul の右端 -> score matrix の左端、水平、終点に矢印ヘッド
• A104：V_w の右端 -> value multiply の左端、水平、矢印ヘッドなし
• A105：score matrix の右上隅 -> value multiply の左下端、斜線、矢印ヘッドなし
• A106：value multiply の右端 -> value matrix の左端、水平、終点に矢印ヘッド
• A107：value matrix の上端 -> Concat の下端、垂直、終点に矢印ヘッド ローカル図が attention_score_motif、value_weighting_motif、residual_add_norm_motif、concat_merge_motif などの既知のモチーフに一致する場合、まずそのモチーフの文法からローカルシーンを生成します。attention_score_motif では、Q/K は左側の乗算に入力され、Softmax はエッジの端点ではなくフローティングラベルであり、乗算の出力はスコア行列に入り、スコア行列は対角的に値の乗算に接続し、値の乗算は値行列に入り、値行列は垂直に Concat へ出力します。

論文スタイルの厳密な複製では、source_visual_inventory はモジュール名だけでなく、正確なレイアウトの事実を記録すべきです：

• テキストの配置：左 / 中央 / 右とベースラインの関係
• 意図された改行と折り返しなしの期待
• ラベルがプレーンテキスト、数式風、キャプション、注釈、または CJK+数式の混在のいずれであるか
• 下付き/上付き文字が表示され、保持する必要があるかどうか
• セリフ / サンセリフ / CJK / 数式フォントの意図と、判明している場合は表示されているソースフォント
• ソーステキストやバーに表示されるシャドウ / グロー / 強調が存在するかどうか
• 太字の Fig. 6. と通常の本文のようなキャプションのプレフィックス/本文の分割
• その領域のクロップ義務、たとえば caption、small_text、arrow_dense
• その領域のボックス/線/シャドウ/密度の事実：パディング、角の半径、ダッシュのリズム、線の太さ、ソフトシャドウの特性、そしてクロップが視覚的にタイトかルーズか

厳密な複製作業では、さらに以下をマークします：

• metadata.replica_review_mode: "strict_replica"
• 最初のレンダリングの前に metadata.replica_stage: "layout_topology"
• レイアウト/トポロジーがすでに視覚的に正しい場合にのみ metadata.replica_stage: "detail_polish"

新規能力評価とは、ソースインベントリからの新規シーンを意味します。古いシーンにパッチを当てて、その古いシーンが良くなったかどうかを確認することでスキルの変更を検証してはいけません。古いシーンと古いレビューは失敗モードを説明するかもしれませんが、スキルのワークフロー、スキーマ、レンダラー、またはコンポーネントを変更した後は、ソース画像インベントリから各テストシーンを再構築してください。完成したシーンをバッチエクスポートするのは問題ありませんが、1 つの Python スクリプトから複数のシーンをバッチ生成することは、スキルが通常のユーザーに対して機能することの有効な証明にはなりません。

2. scene.json を構築または改良する

scene.json は、視覚解析ステップと Visio レンダリングの間の契約です。

これを作成または編集する際は:

• references/scene-schema.md を読みます
• サポートされているコンポーネントの語彙として templates/visio_components.json を使用します
• templates/style_profiles.json を使用して paper_white または clean_white を選択します
• マッピングのガイダンスが必要な場合は references/visio-component-map.md を読みます
• 完全な複製を行う場合は、可能な限りソースピクセル単位で座標を作成し、レンダラーにそれらをインチにスケーリングさせます

スターター生成:

python ${SKILL_DIR}\scripts\image_to_scene.py --image <source.png> --output <scene.json>

このスクリプトは、ピクセルから実際の図の構造を推測しません。空白またはテンプレートのスターターシーンを書き出すだけです。正確な作業のための実際の初回パスの scene.json は、依然として LLM がソース画像から作成する必要があります。

正確な大規模図の再構築では、ソースピクセルから始めて、領域戦略を記録します:

python ${SKILL_DIR}\scripts\image_to_scene.py --image <source.png> --pixel-page --region-strategy region_first --output <scene.json>

レイアウトが標準的なプロセスフローに近い場合は、組み込みのサンプルからシードできます:

python ${SKILL_DIR}\scripts\image_to_scene.py --image <source.png> --template basic-flow --output <scene.json>

これはドラフト/ブートストラップの作成のみとして扱ってください。厳密な複製の証明としては有効ではありません。

GAN/TFR トレーニングサイクルの図、AI 生成の論文図、または Real/Generated TFR パネルを含む画像の場合は、正規のモジュールテンプレートからドラフト/ブートストラップパスをシードできます:

python ${SKILL_DIR}\scripts\image_to_scene.py --image <source.png> --template gan-tfr --output <scene.json>

テンプレートからシードされたシーンを、厳密な能力評価の最終的な証拠として使用しないでください。厳密な複製作業では、スキルを判断する前に、空白からのソース駆動型の作成パスでシーンを再構築してください。

ドラフト/ブートストラップまたはレガシーな GAN/TFR シーンの最初の Visio レンダリングの前に、決定論的なレシピパスを明示的に実行できます:

python ${SKILL_DIR}\scripts\scene_autofix.py <scene.json> --recipe gan-tfr --output <fixed.scene.json>

このレシピは、視覚的なチューニングの前に、脆弱なローカル文法をアップグレードします。分割された Real/Generated ボックスは tfr_panel になり、空の破線の損失フレームは loss_region になり、生の L_adv/L_rec テキストは math_text になり、分離/破損した外側のループは滑らかな loop_arrow になり、逆になった GAN 矢印は修正され、密集した逆伝播矢印はまとめられます。

scene_to_visio.py は、厳密/正確なシーンに対してこの自動修正を暗黙的に実行しなくなりました。明示的なブートストラップ/レンダリングヘルパーパスを意図的に使用したい場合にのみ --autofix-gan-tfr を使用し、ソースインベントリから新しい厳密複製シーンを再作成するまでは、書き出された <basename>.autofixed.scene.json を最終ではない書き換え済みシーンとして扱ってください。

3. シーンデータを検証する

Visio を操作する前に、構造と参照を検証します。

python ${SKILL_DIR}\scripts\scene_validate.py <scene.json>

検証に失敗した場合は、まずシーンを修正してください。レンダラー内で、壊れた ID や未対応の型を推測で補わないでください。

大規模または複雑な図の場合は、完全なレンダリングの前に複雑さの事前チェックを実行します。

python ${SKILL_DIR}\scripts\scene_complexity.py <scene.json>

複雑さレポートを使って、Visio でのレンダリング前に、大きな画像で発生しやすい問題を確認してください。領域数の不足、ノードの未配置、モジュールの過密、フォントスケールの不整合、テキストの収まりに関するリスク、重なりの可能性などです。

完全なレプリカを作成する場合、元の図で複数のフォントスタイルが視覚的に使われているなら、タイポグラフィの事前チェックを実行します。

python ${SKILL_DIR}\scripts\font_inventory.py --check "Times New Roman" --check "Cambria Math" --check "Calibri" --check "Microsoft YaHei UI"

すべてのラベルを同じフォントとして扱わないでください。レンダリング前に、視覚的なテキストを役割ごとに分類します。

• 論文のセリフ体ラベル：font_role: "paper_serif" と Times/Cambria 系の候補
• UI／製品ラベル：font_role: "ui_sans" と Calibri/Arial/Segoe 系の候補
• 数式／演算子：font_role: "math" または symbol_font_role: "math"
• 中国語のラベル：font_role: "cjk_sans" または cjk_serif

元のフォントが判明している場合、または強く推定できる場合は、ノードのスタイルに source_font_family を保存します。そのフォントがインストールされているのに、実際のレンダリングで異なるフォントが使われた場合、scene_audit.py は再構築が必要な問題として報告します。

多くのモジュールを含む複雑な論文の図では、モジュール単位の監査レポートも生成します。

python ${SKILL_DIR}\scripts\scene_audit.py <scene.json>

監査レポートを使い、各 group_container を個別の領域として確認します。子要素の数、ラベル、色、内部の矢印、入ってくる矢印、出ていく矢印、モジュール間の矢印が境界から始まっているか、内部コンポーネントから始まっているかを確認してください。未確認の監査項目は、最終エクスポート前に実際の欠陥として扱ってください。

完全なレプリカを作成する場合は、レンダリングした各反復の後に再構築ゲートを実行します。

python ${SKILL_DIR}\scripts\scene_validate.py <scene.json> --strict
python ${SKILL_DIR}\scripts\scene_audit.py <scene.json> --fail-on-rebuild

厳密モードでは、source_visual_inventory の欠落、region_plan の欠落、テンプレートを起点とする作成、レシピによって書き換えられた完全再現シーンは、非公式な警告ではなくゲートの失敗として扱われます。validate／audit がブロッキングとなる契約違反または [REBUILD] 項目を出力した場合は、座標の微調整を中止してください。さらに視覚的な調整を行う前に、適切な意味コンポーネント（loop_arrow、dashed_region、dashed_feedback_path、boundary_port など）を使って、そのローカルサブシステムを再構築してください。

厳密モードでは、metadata.arrow_plan の欠落、arrow_plan_id のバインドの欠落、ルート形状の違反もゲートの失敗です。元の図が固定の水平、垂直、境界、マージ、フォーク、フィードバック、またはループの文法を示している場合、長い矢印を中心間の auto ルーティングに頼ったまま、厳密なレプリカをレンダリングしないでください。

完全なレプリカの作成では、検証の合格は必要条件ですが、十分条件ではありません。PNG をレンダリングし、元の図と次の点を比較してください。

• ページのアスペクト比
• コンテナーの境界
• ローカルのトポロジー
• 特徴的な形状
• コネクターの文法
• 特徴マップの色付け
• 元の言語の保持、数式、小さなラベル、ポート、矢印の端点

厳密モードでは、急いで一度だけレンダリングするのではなく、次の 2 段階の制作サイクルで進めてください。

1. 1 回目のレンダリング／レビュー段階：レイアウト、領域のバウンディングボックス、コンテナーの境界、トポロジーの文法を確定する
2. 2 回目のレンダリング／レビュー段階：テキストのレイアウト、キャプションの挙動、影、ローカルの間隔、視覚的な仕上げを修正する

上位レベルのコンポーネントが、厳密なレビューを 2 回行っても視覚的に正しくならない場合は、小さなコンポーネントまたはプリミティブを使って、そのローカルサブシステムを再構築してください。頑固なパネルやテキストのまとまりに合わせてページ全体を微調整し続けないでください。

矢印が密集したローカル構造では、全体のシーンに統合する前にローカルの切り抜きを確認してください。

1. ローカルの元画像の切り抜きとモチーフ／矢印プランをもとに、attention_core.scene.json などのローカルシーンを作成する
2. 厳密な矢印プランのチェックを使って検証する
3. そのローカルシーンだけをレンダリングする
4. 元画像のローカル切り抜きとレプリカのローカル切り抜きを並べて比較する
5. 矢印プランのチェックリスト項目がすべて合格してから、全体のシーンに統合する

2 回目のレビューフェーズがすでに反映され、見た目にも問題がない場合を除き、最初のレンダリングだけで完全なレプリカを出荷しないでください。

4. Visio にレンダリングする

シーンを Visio の図面にレンダリングし、成果物をエクスポートします。

python ${SKILL_DIR}\scripts\scene_to_visio.py <scene.json> --output-dir <exports>

デフォルトの出力:

• .vsdx
• .svg
• .png

ユーザーが洗練された白基調の製品/プロセス向けスタイルを求める場合は、--style-profile clean_white を使用してください。論文用の図や学術的なモジュール図には、デフォルトの paper_white を使用してください。

Visio の自動化やエクスポートの挙動をデバッグする場合は、references/visio-export-flow.md を参照してください。

複雑なレプリカをレンダリングした後は、エクスポートした PNG をモジュールごとにソースと比較してください。画像全体の視覚的な類似性に頼らないでください。小さなトポロジーの誤りは、大きな図の中に隠れていることがよくあります。

正確なレプリカの場合、最初のレンダリングは高速で編集可能な再構成パスとして構いませんが、最初のレンダリングの後、最終納品の前に少なくとも 1 回のローカルソースレビューラウンドを行う必要があります:

• ローカル/ステージングされた元画像ファイルと、エクスポートしたレプリカ PNG を make_review_assets.py --write-review-bundle で使用します。
• レビュアーへの入力は、元のソース画像と現在のレプリカ画像です。この 2 つの完全な画像がすでに利用可能な場合、生成されたグローバルペアを送らないでください。グローバルペアは人間のナビゲーション/監査用の成果物にすぎず、通常は細部が縮小されてしまいます。
• ローカルのクロップアセットは、attention_core、arrow_dense、right_output、small_text、caption など、現在疑わしい領域に対してのみ生成してください。習慣的にすべてのクロップを生成したりレビューしたりしないでください。クロップを生成しても、人間もレビュアーもそれを検査しない場合、それは保存されたデバッグ用の成果物にすぎず、レビューの証拠にはなりません。
• オーバーレイアセットはデフォルトではオフです。オーバーレイは、グローバルな位置合わせのずれ、フレームオフセット、または領域 bbox の位置合わせを確認する場合にのみ生成してください。矢印のトポロジー、テキストの折り返し、演算子の端点、数式の忠実性にはオーバーレイを使用しないでください。それらはこうした欠陥を覆い隠す傾向があります。
• レビュー中は、ソース対レプリカの視覚的比較を、review_findings.json の中またはそばにある 2 つの明示的なチェックリストに変換してください: トポロジーチェックリストと視覚レイアウトチェックリストです。
• トポロジーチェックリストには、分岐、マージ、境界の横断、演算子の順序、矢印の端点、必要な経路など、ソースの事実を記録します。例: S3 -> vertical trunk -> S1/common path、S2/S3 -> hollow circle -> minus、Linear -> f̂ -> [] -> fused feature。
• 視覚レイアウトチェックリストには、重なり、ラベルの折り返し、括弧/テンソルの間隔、テキストを貫通する線の欠陥、特徴スタックの厚み、フォントの役割のずれ、色/角丸/影の不一致を記録します。
• 可能な場合、所見は失敗したチェックリスト項目を参照すべきです。特定の欠落した分岐、誤った着地点、または括弧の重なりが見えているのに、「右側の出力が間違っている」といった大まかなメモだけを書かないでください。
• 修正ラウンドでは、検証やノーオペゲートを再実行するだけでなく、同じクロップと同じチェックリスト項目を再確認する必要があります。

高忠実度の作業では、レビュアーは次の 2 つの画像のみを比較すべきです:

• 元のソース画像
• 現在のレプリカ PNG

元画像とレプリカがすでに利用可能な場合、レビュアーへのプロンプトとしてペア画像/オーバーレイ画像を与えないでください。ペア画像は 2 つの完全な画像と冗長であり、ダウンスケーリングによって小さなコネクタやテキストの欠陥を隠してしまうことがよくあります。

ターゲットを絞ったクロップは、現在のタスクが明示的にローカルであり、完全な画像では細部を判断するには小さすぎる場合にのみ、副次的なレビュアー入力として許可されます。その場合は、元の完全な画像、レプリカの完全な画像、およびローカルのソース対レプリカのクロップペアを必要最小限の数だけ送ってください。実際に検査したクロップを記録してください。レビュー契約は依然として 2 つの完全な画像を基準としています。

厳密/正確なレビューパッケージングの場合、make_review_assets.py --write-review-bundle を呼び出してマニフェスト/テンプレートを書き出します。デフォルトではグローバルペア、ローカルクロップ、オーバーレイは生成しません。次を使用してください:

• --include-global-pair は人間のナビゲーション/監査記録用にのみ使用します。
• --crops core arrow_dense caption は手動で選んだ名前付きクロップ用です。
• --region-crops all は、すべての metadata.region_plan クロップペアを意図的に希望する場合にのみ使用します。
• --include-overlays は位置合わせのずれのデバッグ用にのみ使用します。 レビュー担当には、2枚の画像と具体的な問題フォーマットを渡す必要があります。視覚的な差異、ソースでの見た目、レプリカでの見た目、忠実度への影響、注目領域、再生成後に期待される視覚的な変化を具体的に報告させます。スクリプトの出力は、ラウンドの証拠をまとめ、検証・エクスポートする目的にのみ使用し、品質の判断はあくまで視覚的に行います。

別のレビュー担当エージェントを使用する場合は、ソース画像、レプリカ画像、問題フォーマットだけを渡します。意図する修正、過去の結論、ペア／切り抜きパック、スクリプトの警告、類似度スコア、古いシーン JSON は渡さないでください。レビュー担当は視覚的な忠実度を検証し、それを基にメインエージェントが新しいシーンを再構築します。

固定のレビュープロンプト references/reviewer-two-image-prompt.md を使用します。

自然言語のレビュー記録だけで終わらせないでください。厳格な作業では、レビューのループで次を生成する必要があります。

1. make_review_assets.py --write-review-bundle による review_manifest.json
2. ビジュアルレビュー担当による review_findings.json
3. review_findings_to_repair_plan.py による scene_rebuild_brief.json
4. prepare_regeneration_packet.py による再生成パケット
5. round_noop_gate.py による no-op の証明

review_findings.json には、欠陥の指摘と、欠陥を見つけるために使用したレビューチェックリストの両方を含める必要があります。少なくとも次を含めてください。

• topology_checklist：ソースで視認できるトポロジー上の事実。各項目に id、注目領域、ソースの事実、レプリカの状態、pass／fail／uncertain の判定を含めます。
• visual_checklist：局所的なレイアウト／スタイルの事実。各項目に id、注目領域、ソースで期待される状態、レプリカの状態、pass／fail／uncertain の判定を含めます。
• 該当する場合、失敗したチェックリスト項目を参照する checklist_refs を記載した指摘。

ソースの切り抜きが不鮮明な場合は、事実を捏造せず uncertain を使用してください。不確かな項目がトポロジーまたは最終的な忠実度に影響する場合に限り、より高解像度のソースを求めるか、ユーザーに確認してください。

review_findings.json を書き込んだ後、再構築ブリーフを生成する前に、チェックリストのゲートを実行します。

python ${SKILL_DIR}\scripts\review_checklist_gate.py `
  <review_findings.json> `
  --manifest <review_manifest.json> `
  --require-failed-refs `
  --output-report <review_checklist_gate.json>

続いて、チェックリストの適用を有効にして再構築ブリーフを生成します。

python ${SKILL_DIR}\scripts\review_findings_to_repair_plan.py `
  <review_findings.json> `
  --scene <prior.scene.json> `
  --manifest <review_manifest.json> `
  --require-checklists `
  --output <scene_rebuild_brief.json>

いずれかのコマンドが失敗した場合は、再生成に進まず、レビューの指摘またはチェックリストを修正してください。

矢印が密集した領域では、レビュー用チェックリストを領域単位ではなく矢印単位にする必要があります。arrow_plan_id ごとに1つのチェック項目を設けます。例：

• [ ] A101 K_w -> qk_mul がソースと一致する
• [ ] A102 Q_a -> qk_mul がソースと一致する
• [ ] A103 qk_mul -> score grid がソースと一致する
• [ ] A104 V_w -> value_mul がソースと一致する
• [ ] A105 score grid -> value_mul がソースと一致する
• [ ] A106 value_mul -> value grid がソースと一致する
• [ ] A107 value grid -> Concat がソースと一致する

ブロッキングとなるレビュー指摘には、正確な矢印 id と不一致の分類を記載してください。分類は unbound_source_arrows、multi_edge_plan_misuse、source_anchor_mismatch、route_shape_mismatch、motif_rule_violation のいずれかです。

新しいラウンドでシーンが改善したと主張する場合、no-op ゲートの実行は必須です。次の場合、ゲートは失敗します。

• シーンの差分がメタデータのみである
• 変更されたのが弱いスタイルフィールドのみである
• レンダリングされた PNG のピクセル差分がゼロである

scene_rebuild_brief.json がある場合は、round_noop_gate.py --rebuild-brief ... に渡してください。これにより、そのラウンドの注目領域と、該当しそうなシーン id の証拠がレポートに保持されます。

構造化レビュー形式には references/review-contract.md を、現在のレンダラー有効フィールドの許可リストには references/renderer-effective-fields.json を使用してください。再作成時は、メモ、領域計画の編集、レビュー用アセット、またはメタデータの変更だけを根拠に進捗を主張しないでください。

レビューに失敗した後、次のシーン全体を作成する際は、固定の再生成プロンプト references/full-scene-regeneration-prompt.md を使用します。

次の LLM によるシーン全体の再生成に進む前に、scripts/prepare_regeneration_packet.py を使用して scene_rebuild_brief.json をラウンド固有の引き継ぎパケットとプロンプトファイルに変換します。 パケットの手順でレビュー担当者の画像パスを2つとも復元できない場合は、作業を中断し、不完全な再構築情報のまま進めずにレビュー用バンドルを修正してください。 複数回の視覚レビューで、複製図が元画像に忠実な図ではなく、意味を保った描き直しのように見えると指摘されたら、コンポーネント単位の微調整をやめ、シーンを再調整してください。

• 元画像の実際の外枠、タイトル付き領域ボックス、入力／コア／出力のバウンディングボックス、主要なバスラインを、元画像のピクセル座標で記録します。
• これらの対応関係を metadata.region_plan と、source_bbox_px ／ source_aspect_ratio を持つ領域ノードに記録します。
• 小さなラベルを描く前に、領域内のノード密度を元画像に近づけます。
• 自分用にデバッグ用の比較画像や切り抜きを生成する場合は、選択した対象領域だけを比較し、まず領域のバウンディングボックスを調整します。
• 領域のバウンディングボックスが一致してから、フォント、シャドウ、グラデーション、矢印の先端、個々のラベルを調整します。

この手順を、学生／エキスパートモード、画像全体を対象にしたテンプレート選択機能、自動テンプレートマッチングシステムで置き換えないでください。再利用可能なテンプレートやサンプルは、構文の参考または初回作成時のたたき台に限ります。高忠実度の結果を得るには、必ず元画像の視覚分析、元画像のピクセル座標に基づくシーン作成、レンダリングした PNG の確認、視覚レビュー担当者の指摘を経る必要があります。

内部で繰り返されるレイヤーモジュールについては、レンダリング前に元画像の切り抜きから視覚表現を選びます。

• 色付きの 2D ストリップには、block_style_mode: "colored_paper_strip" と、元画像に合わせた block_fills を指定した layer_sequence を使用します。
• 元画像のストリップに色が付いている場合は、block_fill_policy: "preserve" または preserve_block_fills: true で色を保持します。色付きのシーケンスで ignore_block_fills: true のままにしないでください。

シーンの作成と再作成は分けてください。

• 作成：元画像と元画像の視覚的な要素の一覧に基づき、最初の有効なシーンを作成します。
• 再作成：元画像と複製画像のレビュー結果を取り込み、新しい完全なシーンを生成して再レンダリングし、no-op ゲートで変更を検証します。

レビュー後、問題点として領域の意味的な誤りやトポロジー／コンポーネントの表現規則の変更が指摘された場合は、以前のシーンにパッチを当てないでください。元画像と指摘に基づき、そのシーンまたは局所サブシステムを再構築します。トポロジーがすでに正しい状態で、チェックリストの限定的な不備だけが問題の場合は、小規模な対象修正でもかまいません。ただし、その場合も同じ領域の元画像の切り抜き、更新したレビュー結果／チェックリストのステータス、no-op ゲートによる裏付けが必要です。以前のシーンは失敗の証拠として参照できますが、元画像の事実より優先してはなりません。

• 白い 2D の縦ストリップには、block_style_mode: "paper_vertical_strip" を使用します。シーンに古い block_fills が残っている場合は、block_fill_policy: "white" を設定します。
• 白い 3D または高さのある縦長ブロックには、block_style_mode: "paper_vertical_cuboid" または white_3d を使用します。block_fills があるという理由だけで、色付きストリップに変換しないでください。
• 密度の高いゲート／射影／QKV モジュールでは、領域のバウンディングボックスを確定した後に density_mode: "source_dense"（または dense: true）を設定します。テキストや矢印の問題を隠すために、モジュール全体を拡大しないでください。
• 元画像にすでにモジュールを囲む枠があり、繰り返しのバーだけが見えている場合は、2つ目の内枠を描く代わりに layer_sequence.frame_visible: false を設定します。
• 元画像のレイヤーシーケンスで隣接するストリップ間に矢印が見える場合は、ばらばらの端部として配置せず、draw_internal_arrows: true でコンポーネント内に保持します。

視覚レビューで演算子、数式、CJK ラベル、回転したレイヤーラベルの折り返しが指摘された場合は、レンダラー／スキーマまたはシーンボックスの不具合として扱います。折り返しを隠すためにモジュール全体を拡大しないでください。テキストボックスのポリシー、数式／演算子コンポーネント、局所的なフォントサイズ、または元画像座標に基づくラベルボックスを修正します。

f̂ のようなハット付き変数には math_text、表示されている [] の連結括弧には concat_operator、複数の入力から1つにまとめる波括弧には brace_merge を使用します。元画像に意味を持つ演算子／マージ記号がある場合、それらをばらばらのテキスト文字や汎用の四角形として表現しないでください。 a_RGB、P_SAR、q_hrrp、f_fused、S_i のように、単語のような下付き文字を含むコンパクトな数式ラベルには、下付き文字に大文字や複数文字のトークンが含まれる場合、フラグメント形式の下付き文字レンダリングを使用する math_text / math_vector を優先してください。コンパクトな Unicode 表記が安全に使えるのは、数字と実際の Unicode 下付き文字だけです。RGB、SAR、IR、fused を上付き文字のように見える代替グリフでレンダリングしないでください。目視レビューで文字が縦にばらけている、fuse d のように分割されている、または上付き文字のように浮き上がっていると報告された場合は、レンダラー／スキーマ側の負債とみなし、座標を微調整する前にコンポーネントまたはローカルのテキストボックスを修正してください。

テンソル状の特徴マップでは、切り抜き画像を見て、元画像が厚みのある 3D 直方体の積層、薄い前面シートの積層、傾斜したシートの積層、斜めのスラブの積層のどれに当たるかを判断してください。多くの細い特徴シートと弱い遠近感が見られる切り抜き画像には tensor_stack.stack_render_mode: "thin_feature_slabs" を使用してください。厚みがあり、黒い縁取りのある直方体ブロックが明確に見える場合に限り、feature_cuboids を使用してください。テンソルが平坦すぎる、またはブロック状すぎるという指摘が繰り返される場合、それは座標の問題ではなく、コンポーネントモードの誤りです。

最終的な concat 記号には、元画像にコンパクトで太い [] の括弧がある場合、glyph_mode: "source_bracket" を指定した concat_operator を使用してください。operator_node は円形またはテキストの演算子に限って使用してください。小さな括弧状の融合記号を白い四角形や大きすぎる Concat ボックスにしないでください。

Top-k／確率パネルには、元画像の切り抜きに応じて bar_value_label と bar_value_anchor: "bar_area"、"row"、または "after_bar" を指定した probability_bar_list を使用してください。バーが行のテキストに重なる場合は、bar_max_fraction を小さくするか、ラベルを after_bar に移動してください。元画像に明確にそう描かれていない限り、行のテキストを独立したオーバーレイとして配置したり、オフセットでバーの中に押し込んだりしないでください。 厳密な複製モードでは、パネル内部の設定をデフォルトのままにしないでください。パディング、軸の位置、バーの開始位置、行の配置、ベースラインのオフセット、影の有無（または null）を明示してください。

不具合が報告されたら、編集前に分類してください。

• コンポーネントの問題：選択したコンポーネントファミリーが切り抜き画像に合っていない
• トポロジーの問題：分岐／合流／境界が誤った接続文法で表現されている
• テキストの問題：役割、ベースライン、回転、数式の付加、または縮小動作が誤っている
• スタイルの問題：構造が正しい状態で、パディング、角丸、密度、線幅、破線のリズム、グラデーション、または影が誤っている

正確な複製には、次の修正順序を一貫して使用してください。

1. コンポーネントの選択
2. トポロジーとアンカー
3. 数式テキストと回転テキスト
4. コンテナ／タイトル／コンテンツの比率
5. 影、グラデーション、線幅、破線のリズム

ローカルなサブシステムが微調整を 2 回行っても誤ったままなら、座標を少しずつ動かすのはやめ、適切なコンポーネントまたはレンダラールールでそのサブシステムを作り直してください。

厳密な複製モードでは、次の不具合をブロッキング不具合として扱ってください。

• 縦書きの帯状テキストが崩れている、または圧縮されている
• 下付き文字／ハット／ギリシャ文字の数式グリフが誤っている、または欠落している
• 表示されているテキストを線が横切っている
• モジュール間の長いフローが、依然として中心から中心へ接続されている
• 長い論文フローの区間が斜めのままになっている
• concat／演算子の構文が誤ったコンポーネントファミリーでレンダリングされている
• 繰り返し現れる帯、パネル、またはテンソルの形状が、明示的なシーン仕様ではなく、依然として隠れたデフォルト設定に依存している

モジュール間のフローでは、大きなモジュール同士をデフォルトで中心から中心へ接続しないでください。境界ポート、バス、幹線、接合点、または明示的な側面アンカーを使用してください。数式のようなテキストは、フォントが十分似ているからという理由で text_block のままにしないでください。math_text、formula_text_block、またはランベースの数式フラグメントを使用してください。

環境エンコーダーやその他の先細りした論文図のモジュールでは、元画像が全高の三分割ブロックではなく、くびれ／切り欠きのある形状であれば、shape_mode: "opposing_trapezoids" を指定した dual_wing_encoder、または custom_polygon を使用してください。プラス／合計ノード付近の波かっこによる集約には、元画像のくびれが狭い場合、汎用的な波状の波かっこではなく、brace_shape: "tight_curly" と waist_width_in を指定した brace_merge を使用してください。

コンポーネント戦略

バージョン 1 では、すべての Visio マスターを公開しようとするのではなく、意図的に小規模で制御された語彙を使用します。

サポートされるノードファミリー：

• page_background
• process_box
• rounded_process
• stacked_process
• stacked_token
• notched_block
• feature_map_banded
• feature_map_grid
• merge_bus
• decision_diamond
• terminator
• group_container
• dashed_region
• loss_region
• audit_region
• text_pill
• ellipse_node
• polygon_node
• trapezoid_node
• cuboid_node
• tensor_stack
• modality_spine
• math_vector
• math_text
• feature_vector_stack
• tfr_panel
• operator_node
• multi_port_junction
• concat_operator
• brace_merge
• boundary_port
• boundary_fanout
• wave_signal
• classifier_head
• layer_sequence
• text_block
• caption_block
• grid_matrix
• token_grid
• bracket
• junction_point
• image_tile
• legend_block

サポートされるエッジファミリー：

• arrow_connector
• dynamic_connector
• lane_arrow
• curved_arrow
• loop_arrow
• dashed_feedback_path
• line_segment
• join_connector
• fork_connector
• boundary_arrow
• residual_connector
• residual_loop

重要な理由：

• scene.json を安定した状態に保てます
• システム全体がローカライズされた Visio ステンシル名に早い段階で依存するのを避けられます
• プリミティブなジオメトリのレンダリングから始め、後からシーンスキーマを壊すことなく、実際のステンシル／マッピングを追加できます

実行ルール

1. スクリーンショットの埋め込みより、編集可能な再構成を優先します。
2. まず階層を再現します。コンテナー、主要ノード、主要コネクター、次に副次的なラベルの順に作成します。
3. 装飾的な細部にこだわる前に、元画像の情報設計を保ちます。
4. scene.json の座標はページ左上基準に保ち、Visio 座標への変換はレンダラーに任せます。
5. 元図に不可欠ではない写真または地図タイルが1つ含まれている場合は、ページ全体をラスタライズせず、そのアセットだけを切り分けます。
6. 形状が曖昧な場合は、最も近い対応コンポーネントを使い、近似したことを記録します。
7. 矢印には route と明示的な points を使います。元図で実際に斜め線が使われている場合を除き、斜め線に頼らないでください。
8. 回転した紙面ラベルには、プロセス形状内のテキストを回転させる代わりに、angle_deg を指定した text_block を使います。
9. 畳み込みカーネル、受容野、マスク、その他の規則的なセル図には grid_matrix を使います。正方形を1つずつ手作業で作成しないでください。
10. ]、[、U、逆向きの U などのモダリティグループ記号には bracket を使います。極端に細いプロセスボックスで代用しないでください。
11. 2対1、3対1、または1対多の矢印では、結合・分岐位置に小さな junction_point を置き、ソースをジャンクションに接続してから、ジャンクションを宛先に接続します。
12. 矢印を group_container に直接接続しないでください。コンテナーは領域を囲むためだけに使います。引き出し線が必要な場合は、近くに junction_point を置くか、境界上に明示的なノードを使います。
13. 中央に結合アームがあるブラケットでは、tick_positions: [0, 0.5, 1] を指定します。通常の2アームのブラケットでは、モダリティ結合記号を正しく表現できません。
14. コンテナーをまたぐフローでは、エッジを role: boundary_anchor を指定した junction_point ノード経由に分割します。allow_cross_container: true を設定するのは、アンカー間の短いブリッジだけにしてください。
15. 密集したミニモジュール図では、すべてのコネクターを hv、vh、または明示的に整列した点で軸に沿わせます。コネクターが、端点ではないノードを横切らないようにします。 15a. 論文図の正確なフロールートに明示的な点が指定されていても、わずかに斜めに描画される場合は、orthogonalize_points: true を設定するか、不足している曲がり点を追加します。元図にはっきりと斜めの引き出し線や分岐線がない限り、allow_diagonal: true は使わないでください。
16. 作成後に scene_validate.py を実行します。Visio でレンダリングする前に、ルート品質の警告は見た目だけの提案ではなく欠陥として扱います。
17. 繰り返しずらして重ねた特徴ブロックには stacked_process を使います。各レイヤーが実際の意味ノードでない限り、見えているレイヤーをそれぞれ独立したプロセスノードとして作成しないでください。
18. AM-ResNet などのモジュール内部では、目測の y 座標に頼らず、align_to_container または align_group で意図した整列を指定します。
19. 視覚的な短い線やバス区間にすぎないソース線には、from_point／to_point を指定した line_segment を使います。Visio で図形に接続できるからといって、コンポーネントで終端させないでください。
20. 1:1または完全な複製を求められた場合は、metadata.fidelity: "exact" を設定し、metadata.source_image または metadata.source_aspect_ratio を含めます。検証に合格しただけで納品せず、レンダリングした PNG を元画像と比較し、縦横比、モジュールの位置、特殊な形状、コネクターの意味が一致するまで修正します。
21. 元図に特徴的な視覚表現がある場合、ランダムな特徴マップ、汎用的な CNN の四角形、近似的な分類器配線を作り込まないでください。編集可能性より局所的な見た目の忠実さを優先し、grid_matrix、line_segment、点の端点、または切り分けた小さなラスタアセットで視覚表現を明示的に記述します。
22. 正確な複製では、ピクセル座標での作成を優先します。page.units: "px"、page.width、page.height、page.target_width_in を設定すると、レンダラーがノードとエッジ点をインチ単位に正規化します。
23. CNN または切り欠きのあるモジュールには notched_block、単純な縞状・列状の特徴マップには feature_map_banded、色付きの行と陰影付きの列を持つ AM-ResNet／ヒートマップ風の特徴マップには feature_map_grid、目に見えるバス／スパイン結合には merge_bus、残差ループまたはスキップ接続には residual_connector を使います。
24. scripts/enumerate_visio_masters.py は、ローカルの Visio マスター名を調べる場合にのみ使います。大規模なマスターカタログをシーンにハードコードしないでください。Office のローカル言語やステンシルの有無は環境によって異なります。
25. 論文のモジュール図では、汎用ボックスよりも意味を持つプリミティブを優先します。+／x／テンソル演算子には operator_node、フレームの入出力アンカーには boundary_port、破線フレーム境界から出る矢印には boundary_fanout、波形入力には wave_signal、AvgPool／Linear ブロックには classifier_head、ソースから結合点までの区間には join_connector、分岐には fork_connector を使います。
26. 矢印を破線フレームの辺に接続する必要がある場合、フレームには接続しないでください。フレーム境界上に小さな boundary_port を置き、内部フローをそのポートに接続してから、短いブリッジ区間またはコネクターで次のモジュールに接続します。
27. 元図で出力矢印がコンテナー境界から始まっている場合、classifier_head の内部ファンアウトは使わないでください。classifier_head.output_mode: "boundary" を設定するか、fanout_count を省略し、boundary_fanout で分岐を描画します。
28. AvgPool -> Linear などの短い内部矢印には、internal_arrow_size: "tiny" を指定した classifier_head.orientation: "vertical" を使うか、通常のエッジに arrow_size: "small" を設定します。Visio の既定の矢印先端は、ごく短い線分を占めて矢印先端だけの三角形に見えることがあります。
29. 演算子記号には、ellipse_node と別個のテキストを組み合わせる代わりに、symbol を指定した operator_node を1つ使います。レンダラーが円の中に +、×、⊗ を中央揃えします。
30. フレーム境界から、垂直位置の異なる対象コンポーネントに矢印を引く場合は、feature_map:[email protected] のようなサイド比率の端点を使い、水平の経路を保ちます。元図に斜め線がない限り、中心から中心への斜めエッジを許容しないでください。
31. 元図で破線フレーム自体が次のモジュールに出力している場合は、boundary_port から boundary_arrow を使い、最後のコンポーネントからフレームに向かう内部 line_segment は描画しないでください。元図に明示されていない限り、コンポーネントからフレーム、さらにコンポーネントへ続く長い線は通常誤りです。
32. 通常の1対1矢印では、元図の線がまっすぐな場合、route: "horizontal" または route: "vertical" を優先します。斜め矢印は、ファンイン／ファンアウト、引き出し線、または元図に明示された斜線に限ります。
33. 複雑な図では scripts/scene_audit.py を実行し、納品前にモジュールごとに生成されたチェックリストを確認します。目的は、もっともらしいが誤っている詳細、たとえば破線フレームの欠落、子要素数の誤り、隠れたフレーム間矢印、演算子の位置ずれ、境界出力の誤りを見つけることです。
34. 元図に目に見える破線のモジュールフレームがない場合は、残差ブロック、アテンションブロック、分類器ヘッド、特徴抽出チェーンなどの論理領域を囲む不可視の audit_region ノードを追加します。これらの領域は描画されませんが、scene_audit.py で図をモジュール単位に確認できます。
35. RGB／IR／SAR 入力を含むマルチモーダルな論文パイプラインでは、各モダリティレーンを個別のレーンとして保ちます。image_tile 入力、text_pill または process_box の有効性フラグ、共有垂直バスの modality_spine、融合モジュールへの明示的な水平コネクターを使います。
36. 繰り返しの P_RGB／P_IR／P_SAR サイドポートを備えた、縦向きの灰色の共有応答または可用性マスクのバーには modality_spine を使います。各ポートが独立したトポロジーを持つ場合を除き、バーを単純な長方形と無関係な小ボックスの組み合わせで表現しないでください。
37. モダリティ関連の影響因子、積み重ねた特徴テンソル、小さな青／オレンジの奥行き付きブロックなど、編集可能な3D論文ブロックには cuboid_node を使います。目に見える面がグリッドまたはヒートマップの場合に限り、feature_map_grid を使います。
38. Quality Head、extractor head、集約モジュールなどのくさび形／台形の論文ブロックには trapezoid_node を使います。狭い辺または先端が元図の方向と一致するように、orientation と pointed を設定します。
39. trapezoid_node、cuboid_node、notched_block、その他の意味プリミティブでは表現できない形状に限り、polygon_node を使います。元画像のピクセル座標で作成する場合は、正規化した点を指定します。
40. q = [q_RGB, q_IR, q_SAR]^T などの式／ベクトル注釈には、単なる複数行の text_block ではなく math_vector を使います。これにより、括弧、要素、任意の接頭辞が編集可能な図形／テキストとして揃います。数式ラベルをコネクターの端点にしないでください。 40a. g_tf、g_hrrp、f_fused、P_RGB、q_IR、s1、f1、L_adv などの小さな変数や数式ラベルには、math_render_mode: "fragments" と text_fit: "math_label" を指定した math_text を使います。下付き文字に大文字または単語のようなトークンが含まれる場合は特にそうしてください。視覚的に元図と一致する数字または真の小文字下付きラベルに限り、compact_unicode を使えます。Visio が g_ / tf、f_fu / sed、上付き文字のような RGB に折り返す可能性がある生テキストのままにしないでください。
41. 幅の広い複数パネルの図では、目に見えるフレームを group_container で描画する場合でも、タイトルのある各パネルに audit_region ノードを作成します。これにより、scene_audit.py で入力、出力、パネル間矢印をパネルごとに確認できます。
42. 大きな元画像では、レンダリング前に metadata.region_strategy: "region_first" または "tiled_subscenes" を使います。また、グローバル／入力／中核／出力／矢印の密集部／小さなテキスト／境界の各領域について、source_bbox_px と対象の bbox／コンテナーを含む metadata.region_plan エントリを追加します。ページ全体の縮尺では複雑すぎて把握できない図の場合、各領域をローカルなサブシーンとして作成して検証し、その後、同じスタイルトークンを使って領域ノードを全体シーンにコピーします。
43. 領域ごとにフォントサイズを独自に決めないでください。フレームタイトル、本文ラベル、小ラベル、演算子記号、数式ラベル、エッジラベル用に少数のスケールを定義し、再利用します。scene_validate.py が同じ種類のフォントにばらつきがあると報告した場合は、レンダリング前にスタイルを統一します。
44. 切り抜いたサブ領域から再構成する場合、分析中のみ切り抜き基準の座標を使います。最終組み立て前にページ全体のピクセル座標系に変換し、継ぎ目で矢印やラベルがずれないようにします。
45. シーンに表示ノードがおおむね30以上、エッジが35以上、または極端に横長のアスペクト比がある場合は、ページ全体を Visio に出力する前に scene_complexity.py を使います。テキストの収まり、重なり、ノードの未網羅、密集領域に関する警告は、修正すべき欠陥として扱います。
46. 表示ノードが18を超える領域は、通常、一度の再構成で信頼性を保つには密集しすぎています。入力スタック、特徴抽出器、融合、分類器、出力ヘッドなど、より小さな不可視の audit_region 領域に分割します。
47. 大きな図では、全体のレンダリング後にテキストボックスを少し動かして整列だけを修正しないでください。まず align_group、align_to_container、明示的な container_id、サイド比率の端点で領域ごとの整列を徹底し、その後に最終位置を調整します。
48. ページ全体を組み立てるときは、真のモジュール間フローに限って領域間エッジを使います。内部矢印はソース領域内に保ち、コネクターが領域から出る場合は境界ポートまたはジャンクションアンカーを使います。
49. 近接するブロック間の短い論文フロー経路、特に立方体／特徴ブロックから extractor または GAP／GMP ブロックへの経路には、route: "horizontal" または "vertical" を指定した lane_arrow を使います。小さな端点の x／y ずれを隠すために、route: "straight" と allow_diagonal: true を指定した arrow_connector を使わないでください。
50. 生成した図の矢印がわずかに傾いて見える場合は、端点がほぼ揃っているだけの straight エッジがシーンにないか確認します。それらを lane_arrow に変換するか、ルート軸を固定するか、from_point／to_point を正確に揃えます。 50a. 元のコネクターが軸に沿っているものの、90度の曲がりが目に見えて丸くなっている場合は、route: "rounded_orthogonal"、orthogonalize_points: true、明示的な corner_radius_px／corner_radius_in を指定した rounded_orthogonal_connector を使います。この場合に smooth／Catmull-Rom 曲線を使わないでください。滑らかな曲線は直線レーンの形状を変え、波形や端点のずれを生みやすくなります。
51. Quality Head、Environment Response extractor、Aggregation Quality-aware などの論文図のくさび形ブロックには、ユーザーが速度のための小さなラスタタイルを明示的に許可している場合を除き、編集可能な trapezoid_node／polygon_node を優先します。ラスタタイルは、忠実度と速度のトレードオフとして記録します。
52. 大きな外側の曲線矢印を含む GAN／学習サイクル図では、サンプリングした points と矢印先端付近の明示的な end_tangent_point を備えた loop_arrow または curved_arrow を1つ使います。ループを複数の line_segment の弧と切り離された短い矢印先端に分割しないでください。目に見える途切れや接線方向の誤りが生じます。
53. Forward Reconstruction -> Discriminator Evaluation などの目に見える破線注釈ボックスには、dashed_region と別個の text_block ラベルを使います。空の破線 process_box を擬似フレームとして使わないでください。
54. 破線の再構成／敵対／逆伝播経路には、明示的な直交点を指定した dashed_feedback_path を使います。警告を抑えるためだけに、損失／逆伝播矢印に allow_diagonal: true を設定しないでください。
55. 破線フィードバック経路が目に見える破線領域から出る場合は、allow_cross_container: true と明示的な点を使って、交差位置を正確に指定します。元図の矢印がフレームの辺から始まっている場合は、領域中央から接続する代わりに boundary_port を追加します。
56. scene_audit.py --fail-on-rebuild が [REBUILD] を報告した場合は、ボックスやテキストの位置をずらしてもう1回試すのはやめてください。まず誤った局所文法を置き換え、再構築ゲートに合格してから位置を調整します。
57. 1回修正を試みた後も同じ [REBUILD] 項目が残る場合は、その局所サブシステムを破棄し、最小限のローカルシーンから描き直します。これは外側ループ、破線フィードバック経路、破線注釈フレームでは必須です。
58. Visio の PNG 出力で切り抜きを制御するには、最下部のノードとして page_background を使います。擬似 process_box の背景は、ルート交差チェックと監査出力を汚染するため使わないでください。
59. GAN／TFR ループ図の最低限の納品基準は、学習ループに受動的な楕円を使わないこと、ループの矢印先端を切り離さないこと、空の破線プロセスボックスを使わないこと、破線／損失／逆伝播ルートを単純な arrow_connector として描かないこと、破線フィードバック経路がテキストラベルを横切らないことです。
60. GAN／TFR 図では、生成／再構成された TFR サンプルを Discriminator に入力します。ソースで明示的に Discriminator の出力とされていない限り、Discriminator -> Generated のエッジは逆向きとみなします。
61. 外側の更新ループには、curve_mode: "smooth"、十分にサンプリングされた点、semantic_role: "outer_update_loop"、更新ラベルに対応付けられた label_id／loop_label_id を指定した loop_arrow を使います。そうでない場合、ループは装飾的な境界線のように見えます。
62. 破線の評価／損失フレームは、見た目がすっきりするように保ちます。dashed_feedback_path は境界点または boundary_port から dashed_region／loss_region を出るようにし、領域内部を通る余分な水平／垂直スタブを描画しないでください。
63. 複数の垂直破線矢印が Discriminator に入る GAN の下部損失／逆伝播システムには、無関係な複数の垂直矢印ではなく、bundle_id を指定した共有 merge_bus／junction_point を使います。
64. L_adv や L_rec などの損失式には、生のアンダースコア付き text_block 文字列ではなく math_text を使います。生のアンダースコアは、論文図を正確に複製する場合の再構築欠陥です。
65. Real／Generated TFR パネルには、最初のコンポーネントとして tfr_panel を使います。元図に固有の理由がない限り、パネルを角丸ボックス、タイトルラベル、グリッド、入力ラベル、別個の内部矢印に分割しないでください。
66. レンダリングが全体的には近いものの、1回の作業後も局所的な詳細が改善しない場合は、scene_audit.py --fail-on-rebuild を実行し、見た目を調整する前にすべての [REBUILD] 項目を修正します。
67. GAN／TFR の元画像では、--template gan-tfr は下書き／初期作成に限って使います。テンプレートを基に作成したシーンを、厳密な複製能力の有効な証拠として扱わないでください。
68. 下書き／初期作成または旧式の GAN／TFR シーンをレンダリングする前に、必要であれば scene_autofix.py --recipe gan-tfr を1回実行できます。レシピが局所文法を書き換えた場合は、古いファイルから続けるのではなく、修正後のシーンを検証・監査します。厳密／完全な作業では、暗黙のレンダリング時自動修正に頼らないでください。--autofix-gan-tfr は明示的な補助経路としてのみ使い、その後、元画像のインベントリから厳密なシーンを新規作成します。
69. タイトルと数式が1つの局所サブシステムに属する敵対／評価の破線領域には loss_region を使います。フレームに数式の意味がない場合、または元図で個別の子ノードが必要な場合に限り、dashed_region を使います。
70. loss_region と対象ブロックが水平方向に重なる場合は、短い垂直境界スタブを経由し、target:top@ratio または target:bottom@ratio に接続してフィードバックを引き回します。損失フレームの角から target:left/right に接続しないでください。通常、「破線ボックスに余計な矢印が付いた」誤った表現になります。
71. 平滑化後も外側ループの矢印先端が折れ曲がって見える場合は、無関係なノードを動かす前に、意味上の形状（end_tangent_point、サンプリング点、または局所ループサブシステム）を変更します。矢印先端の接線はコンポーネントの文法の一部であり、最終的な見た目の調整ではありません。
72. レンダリング前に GAN／TFR の損失テキストを正規化します。Ladv、Lrec、L adv、L rec は、出力前に L_adv／L_rec または明示的な math_text フラグメントに変換します。
73. loss_region のタイトルには、title_position: "inside" またはヘッダーの切り欠きレイアウトを優先します。長いタイトルを破線フレームが横切らないようにします。まずタイトル行を分割するか、領域を広げます。
74. 完全な複製または GAN／TFR のレンダリングでは、最終手順として scene_to_visio.py を盲目的に実行しないでください。まず再構築ゲートを実行するか、[REBUILD] 項目が残っている場合にレンダラー内蔵のゲートで出力を停止させます。
75. 破線フィードバック経路が孤立した短い矢印断片のように見える場合、見た目の問題ではなく意味上のルートの失敗として扱います。その断片を残さず、1つの dashed_feedback_path またはバス／ポート経路として再構築します。
76. 完全な複製用のエッジを作成する前に、元画像の目視検査から metadata.arrow_plan を作成します。次に、ソースで見える各エッジを arrow_plan_id で対応付けます。レンダリング前に scene_validate.py --strict を実行し、矢印の欠落、斜め方向へのずれ、境界端点の誤り、分断されたフィードバック経路、壊れたループ矢印を早期に検出します。 76a. 完全な複製では、タイポグラフィの確認も行います。ノードを確定する前に、元図がセリフ体、サンセリフ体、数式用、等幅、CJK、または混在した書体のどれを使っているかを特定します。すべてのテキストノードが誤って汎用の既定フォントを継承しないようにします。
77. 正確なフォントファミリーが不確かな場合は、単一で壊れやすいフォント名の代わりに font_family_candidates と font_role を使います。レンダラーは、インストールされている候補のうち、最初に見つかった近似フォントを選択します。
78. 元のフォントがわかっている場合は、font_family／font_family_candidates に加えて source_font_family も設定します。これにより、フォントがローカルに存在していてもシーンが誤ったファミリーでレンダリングされるケースを監査で検出できます。
79. 図で Calibri／Aptos／Arial／Times／Cambria／中国語フォントが使われているように見える場合は、scripts/font_inventory.py を実行します。元のフォントが存在しない場合は候補リストを使い、インストールされている場合は元のフォントを直接使います。
80. 演算子や数式フラグメントには、元図のスタイルに応じて Cambria Math、Cambria、Times New Roman などの数式対応フォントを使います。元図が明らかに別のフォントを使っている場合を除き、+、×、⊗、下付き文字付きの数式をランダムな UI フォントで描画しないでください。
81. 中国語、または中国語と英語が混在する図には、font_role: "cjk_sans" または cjk_serif を使います。そうしないと Visio が黙ってグリフを置き換え、テキストの寸法がずれる可能性があります。
82. 座標を調整する前に、scene_audit.py の出力にある Typography Review セクションを確認します。フォントのフォールバックでテキスト幅が変わり、以前は揃っていたレイアウトが崩れて見えることがあります。
83. 特徴スラブが繰り返し現れる論文図では、多数の独立した cuboid_node 形状の代わりに tensor_stack を使います。薄い平行四辺形のステーション／出力特徴には stack_render_mode: "slanted_sheets"／paper_sheets、厚みのある3Dスラブには oblique_slabs、平らな前面スタックには thin_sheets を使います。layers、layer_dx_in、layer_dy_in、depth_x_in、depth_y_in、skew_x_in を調整し、1つの意味的なテンソルノードとして保ちながら、見た目のスタックを一致させます。
84. 読み取り可能な数値を含む色付きシーケンス／インデックスタイルには token_grid を使います。元のセルが正方形の場合は square_cells: true を設定し、セルを bbox に合わせて引き伸ばす代わりに grid_align_x／grid_align_y で位置を揃えます。セルごとのテキストがなく、共有線で連続する行列に限り grid_matrix を使います。パディング付きのプレフィックスバッチや top-k 確率行を、無関係な大量の process_box ノードとしてモデル化しないでください。
85. Linear／ReLU／LayerNorm／Dropout／Q／K／V のバーが繰り返し並ぶタイトル付きモジュールには、orientation: "horizontal" または "horizontal_bars" を指定した layer_sequence を使います。元図のレイヤーバーが背の高い2Dの角丸白帯の場合は、block_style_mode: "paper_vertical_strip" を使います。元図に上面／側面が目に見える場合に限り、3D／直方体モードを使います。元図に分類器固有の内部矢印やファンアウトがある場合に限り classifier_head を使い、それ以外では layer_sequence のほうが、シーンのずれを抑えながら視覚的なレイヤー構造を保てます。 85a. LocalEchoGRU や浅いバックボーンレイヤーのように、内部が横長の角丸行として積み重なるコンテナーには、orientation: "vertical_stack" と block_text_angle_deg: 0 を指定した layer_sequence を使います。これらを横並びの縦棒として表現しないでください。 85b. コンパクトなソースベクトル、有効性フラグ、小さなモダリティ行、薄いトークンスタックには、ソースのセル数と間隔に合わせた feature_vector_stack または token_grid を使います。切り抜き画像内で個別のセルやポートが見える場合に、これらを1つの大きなプロセスボックスで近似しないでください。 85c. 複数の矢印が目に見えるスパインを共有する多対1または1対多の論文図の結合点には、multi_port_junction、merge_bus、または明示的な junction_point ポートを使います。元図に見える刻みがない場合は、length_in: 0 を指定した明示的な辞書形式のポートを使い、融合／かっこ境界に余分な短いスタブが生じるのを防ぎます。バス、ジャンクション、境界ポート、領域計画上の正当な理由なしに、長くまばらな矢印がモジュールを飛び越えないようにします。 85d. 確率パネルでは probability_bar_list を意味単位として保ち、切り抜き画像の確認後に bar_max_fraction、bar_value_anchor、行の幅を調整します。青いバーがテキストを明らかに横切る状態では、合格とみなせません。 85e. 図のキャプション、ページヘッダー、太字と標準のテキストが混在するラベルには、順序付きの run を備えた caption_block を使います。元図でスタイルが視覚的に重要な場合、1つの型なしテキストブロックにまとめないでください。
86. 元画像のピクセル座標で完全な複製を作成する場合は、tensor_stack、token_grid、layer_sequence の内部寸法にも元画像のピクセル単位を使います。ノード位置はピクセル単位なのに内部間隔がインチ単位では、局所的に目立つ歪みが生じます。
87. 視覚的な確認では、繰り返しのスラブ、トークングリッド、数式、内部レイヤーシーケンスが、これらの意味コンポーネントで表現されているかを明示的に確認します。ばらばらなボックスと線で代用されている場合、その問題は座標調整ではなく、シーン構成またはコンポーネント使用の負債として分類します。
88. 視覚的な確認では、テキストと数式の折り返しがないか、局所的な切り抜きを確認します。GELU、LayerNorm、CJK ラベル、下付き変数の表示崩れは、検証／監査に合格していても、重大または重要な視覚的欠陥です。モジュール全体を拡大して問題を隠すのではなく、役割別フォント、text_fit、局所的なフォントスケールの縮小、または math_text で修正します。
89. f_tf、g_hrrp、f_fused、S_i などのラベルには、見えている変数だけをベースにし、残りを下付き文字にする math_text または math_label_box を使います。視覚確認で f_t^f のような表示、文字の分離、fuse d のような間隔が報告された場合は、数式描画の失敗として分類します。
90. 複雑な図の各反復では、確認した画像、主な視覚的差異、複数画像に共通する問題、スキルの変更、改善／変化なし／後退した図、未解決の失敗を記録します。全体のコンタクトシートはナビゲーションに役立つ場合がありますが、細部の合否を判断する有効な証拠ではありません。細部の確認には、全体を並べた画像より、全体画像2枚と対象を絞った局所切り抜きを優先します。

参考資料

• references/scene-schema.md：scene.json のフィールドと座標ルール
• references/visio-component-map.md：サポートされるコンポーネントとレンダラーの意図
• references/visio-export-flow.md：Windows ＋ Visio のエクスポート手順と現在の制限事項
• templates/style_profiles.json：paper_white と clean_white のレンダリングプロファイル
• templates/examples/basic_flow.scene.json：スターターサンプル
• templates/examples/multimodal_paper_components.scene.json：マルチモーダルのスパイン、直方体、台形、ポリゴンのスモークテスト用サンプル
• templates/examples/gan_loop_feedback.scene.json：滑らかなループ矢印、破線領域、破線のフィードバック経路のスモークテスト用サンプル
• templates/examples/gan_tfr_full.scene.json：tfr_panel、loss_region、math_text、滑らかな loop_arrow、バンドルされた逆伝播矢印を使用する、正規の初回 GAN/TFR テンプレート
• scripts/scene_complexity.py：Visio でレンダリングする前に、大規模または高密度の図を確認するための事前チェックレポート
• scripts/font_inventory.py：ローカルの Windows フォント一覧と、優先する役割別フォールバックの確認
• scripts/stage_source_image.py：ソース画像を source/original.<ext> にコピーし、安定した厳密レビュー用マニフェストに使うハッシュを記録します
• scripts/review_checklist_gate.py：再構築計画の前に topology_checklist、visual_checklist、ローカルのソース画像パス、checklist_refs を検証します
• scripts/scene_autofix.py：Visio でレンダリングする前に実行する、決定論的な GAN/TFR のローカル文法アップグレード処理
• docs/updates/2026-05-19-multimodal-paper-figure.md：複雑なマルチモーダル論文図の詳細な分析と、関連するコンポーネントのアップグレード

現在の制約

バージョン 1 は、意図的に保守的な設計です。

• コネクタは、完全な接着対応コネクタに先立ち、自動スナップ、直角ルーティング、明示的なポイントに対応しています
• 中核となるフローチャート図形は、利用可能な場合はローカルの Visio マスターを使用し、制御されたフォールバックを適用します
• エクスポートは、SVG の生データを Visio に変換するのではなく、シーンのレンダリング後に Visio で処理します

再利用可能な初回リリースとして、これが適切なトレードオフです。