thesis-standardizer

Thesis Standardizer

目的

基本方針は、実際のプログラムを、根拠に基づく学部卒業論文に仕上げることです。

常に根拠に基づいて作業します。

1. テンプレートの規則
2. プロジェクトの事実
3. コード／データベース／API／テストの根拠
4. 章立て
5. 本文
6. 図表
7. Word／PDFの確認

ユーザーがラフな草稿を明示的に求め、根拠不足のリスクを了承している場合を除き、自由な文章から書き始めないでください。

完了に不可欠なゲート

このスキルでは、Superpowersスタイルのゲート構造を採用しています。規則は単なる注意事項ではなく、実行可能な停止条件です。

NO FINAL DOCX COMPLETION CLAIM WITHOUT FRESH AGGREGATE-GATE EVIDENCE

論文の.docxが完成、許容可能、修正済み、または提出可能だと伝える前に、次のことを行います。

1. 最終版の.docx、図のマップ、想定されるVisio OLEの数、見出しの最低数、必要な論文の長さを特定します。
2. 現在のファイルに対して scripts/check_final_thesis_docx.ps1 を実行します。以前の草稿は使用しないでください。一般的な学部のシステム系論文では、学校のテンプレートに別の指定がない限り、-MinContentUnits 12000 -MinCjkChars 10000を使用します。
3. 出力と終了コードを確認します。
4. いずれかのゲートで失敗した場合は、文書を修正するか、失敗したゲートを正確に報告します。完了したとは言わないでください。
5. 集約ゲートを通過した後に限り、検証の根拠を報告します。

次のような危険信号があれば、作業を止めてゲートを実行します。

• 「表の規則はすでにスキルに記載されています。」
• 「Wordで見る限り問題ありません。」
• 「三線表は合格したので、続きもおそらく大丈夫です。」
• 「前回のデモは合格しました。」
• 「小さな修正しかしていません。」
• 「Visio／OLEはこの表の変更とは関係ありません。」

メインライン：プログラムから論文へ

プロジェクト／リポジトリ／システムのソースを対象に、次の手順を実行します。

1. 学校指定の .docx テンプレートがある場合は、抽出します： scripts/extract_docx_template_profile.py <template.docx> --out paper-context/template-extract 次に、コンポーネント指向の再現計画を作成します： scripts/build_thesis_structure_plan.py --template-profile paper-context/template-extract/template-profile.json --spec thesis-ai-standard/templates/thesis-ai-spec.yaml --out paper-context/template-extract/thesis-structure-plan.yaml テンプレートがある場合は、執筆または最終的な書式設定を行う前に references/template-replication-workflow.md を読みます。
2. 論文の作業スペースを初期化／確認します： scripts/init_thesis_workspace.py <target-dir>
3. プロジェクトのエビデンスを構築します： scripts/build_project_evidence.py <project-dir> --out paper-context/evidence
4. 次のファイルを作成または更新します： thesis-ai-standard/templates/standard-profile.yaml thesis-ai-standard/templates/thesis-ai-spec.yaml thesis-ai-standard/templates/figure-registry.yaml
5. 第3章～第6章の執筆前に、図／スクリーンショットの計画を作成します： scripts/build_figure_plan.py thesis-ai-standard/templates/thesis-ai-spec.yaml --out paper-context/figure-plan 計画した図を figure-registry.yaml に統合するか、執筆用チェックリストとして断片をそのまま使用します。
6. 以下の章構成に従って、章ごとに執筆します。
7. 第4章では、データベース／データオブジェクトのセクションを執筆する前に、データベース設計用アセット一式を作成します： scripts/build_chapter4_database_assets.py <database-model.yaml> --out paper-context/database-design 業務データベースがなくても、YAML、JSON、JSONL、Markdown のレジストリ、ログ、生成されたエビデンスファイルなど、実際の構造化された設定／データアーティファクトがプロジェクトに存在する場合は、それらのアーティファクトからデータオブジェクトモデルを作成し、データオブジェクトモデルであることを明示したうえで、概要 E-R 図、単一エンティティ E-R 図、三線表の各アセットを生成します。物理的な業務データベースとは呼ばないでください。
8. 章で必要な場合に限り、必須の Visio 図、スクリーンショットのプレースホルダー、三線表を生成します。 最終 .docx の作成時に OfficeCLI または Word の自動化が利用できる場合は、構造図の .vsdx ファイルを Visio OLE オブジェクトとして埋め込みます。.png エクスポートはプレビュー用サムネイルにすぎません。埋め込み前にエクスポートしたプレビューのアスペクト比を確認し、共通の固定サイズの長方形ではなく、アスペクト比に合わせて OLE のサイズを調整します。
9. 最終チェックを実行します： scripts/check_thesis_workspace.py <workspace> 最終 .docx を作成した場合は、次も実行します：scripts/check_final_thesis_docx.ps1 <paper.docx> -FigureMap <visio-ole-figure-map.json> -ExpectedVisioOle <count> -MinContentUnits 12000 -MinCjkChars 10000 -RequireContinuationCaption。テンプレートプロファイルがある場合は、-TemplateProfile <template-profile.json> を追加します。この集約ゲートに失敗した場合は、文書を完成扱いにしないでください。

ルート全体を計画または実行する際は、references/thesis-module-workflow.md を読みます。

スキルの完全性

このスキルを編集した後、スキルの準備が整ったと表明する前に scripts/check_skill_integrity.py を実行します。このスクリプトは、フロントマター、参照されている scripts/ および references/ のファイル、集約ゲートの接続、バリアントワークフローへの到達可能性を確認します。

バリアント生成

ユーザーから複数の論文候補を求められた場合、または最適化戦略を比較したいとの要望があった場合は、references/variant-generation-workflow.md を使用してください。

デフォルトでは、互いに独立した次の3つのバリアントを作成します。

1. template-first：学校のテンプレートの再現と、テンプレート複製のゲートを優先します。
2. figure-enhanced：第3～6章の図の計画、Visio のソース、OLE 埋め込み、図マップのゲートを優先します。
3. narrative-enhanced：論文らしい文体、章間の一貫性、論文として十分な長さの文章の品質を優先します。

scripts/generate_thesis_variants.py を使ってバリアントの一覧表と、必要に応じて分離した実行環境を作成し、その後 scripts/compare_thesis_variants.py を使って比較の概要を生成してください。採用または統合した最終版の .docx には、改めて scripts/check_final_thesis_docx.ps1 を実行する必要があります。統合や編集後に、バリアントのゲートに関するエビデンスを引き継ぐことはできません。

章構成

• 第1章、序論：背景、意義、研究状況、研究内容、論文の構成を扱います。引用を多く含む章です。
• 第2章、関連技術：各技術の説明と、本システムでの活用方法を扱います。引用を多く含む章です。
• 第3章、システム分析：実現可能性、役割、要件、非機能要件、ユースケース図、主要な業務フローチャート、エビデンスで裏付けられる場合は要件・機能の分解図を扱います。
• 第4章、システム設計：機能アーキテクチャ図、全体アーキテクチャ図、裏付けがある場合は技術・デプロイアーキテクチャ図、E-R 概要、個別エンティティの E-R 図、データベース／データオブジェクトの三線表、設計の根拠を扱います。
• 第5章、システム実装：主要モジュールの実装、実装フローチャート、ログイン／エントリー画面、ホームページ、主要機能の実際のプログラム画面を扱います。実際の画面がない場合は needs_user_screenshot プレースホルダーを使用してください。この章はテストの章ではありません。
• 第6章、システムテスト：テスト環境、テスト手法、テストケース、ログ／レポート、実際のエビデンスがある場合はテスト結果の画面、結果表を扱います。通常のプログラム機能の画面をここに掲載しないでください。デフォルトでは第7章を別に設けず、結論に記載する内容が必要な場合は、第6章の末尾に、完了した作業、限界、今後の課題を簡潔にまとめた節を配置してください。学校のテンプレートまたはユーザーが明示的に求める場合に限り、独立した第7章を作成してください。

第1～3章は引用を主に扱う範囲です。文献による裏付けが本当に必要な主張でない限り、実装やテストに関する主張に引用を無理に付けないでください。 論文の文章を執筆または拡充する前に、references/thesis-voice-and-style.md を読んでください。エビデンスファイルは作業中の記憶と検証のために使い、最終的な論文本体ではシステムを直接説明してください。

図表のルーティング

• 図・スクリーンショットの計画：references/figure-and-screenshot-plan.md 第3〜6章の執筆前に build_figure_plan.py を実行します。一般的なシステム論文では、ユースケース図と機能図を1つずつ用意するだけでなく、根拠に基づく図を多数計画する必要があります。
• 編集可能な Visio を使った Word での納品：references/docx-production-rules.md を参照してください。 構造図の .vsdx を生成したら、scripts/check_figure_preview_aspects.py を実行し、続いて scripts/embed_visio_ole_with_officecli.py --fit-preview-aspect --max-width 14cm --max-height 18cm を優先して使用します。最終 .docx は scripts/check_docx_visio_ole.py と scripts/check_docx_duplicate_figure_previews.py の両方で検証します。Word 内の PNG プレビューは編集可能な Visio 図ではありません。また、最終 Word の図ブロックには、Visio OLE オブジェクトと以前の静的 PNG プレビューの両方を含めてはいけません。
• テンプレートの再現：references/template-replication-workflow.md を参照してください。 学校やテンプレートの .docx がある場合、見た目の類似性だけに頼ってはいけません。template-profile.json を抽出し、thesis-structure-plan.yaml を作成して、最終成果物を scripts/check_docx_component_order.py、scripts/check_docx_style_profile.py、scripts/check_docx_page_model.py、scripts/check_docx_caption_numbering.py、scripts/report_template_replication_diff.py で検証します。
• DOCX の必須ゲート：references/hard-gate-rule-catalog.md を参照してください。 最終的な論文 .docx は、コンポーネントの完全性、引用の対応関係、参考文献のハイパーリンク、キャプションの対応関係、構造の健全性の各チェックに合格する必要があります。-SkipHardGateChecks は、社内向けの粗いドラフトに限って使用し、納品物に対して使用してはいけません。
• ユースケース図：references/visio-use-case-workflow.md layout_use_case_diagram.py、check_use_case_layout.py、generate_visio_use_case_diagram.ps1 を実行します。
• 機能アーキテクチャ図：references/visio-function-architecture-workflow.md layout_function_architecture_diagram.py、check_function_architecture_layout.py、generate_visio_function_architecture_diagram.ps1 を実行します。
• E-R 図：references/visio-diagram-workflow.md layout_er_diagram.py、check_er_layout.py、generate_visio_er_diagram.ps1 を実行します。
• 第4章のデータベース関連アセット：references/chapter-4-database-workflow.md build_chapter4_database_assets.py を実行し、次に ER Visio の手順で概要図と単一エンティティの E-R JSON をレンダリングします。
• フローチャート：references/visio-flowchart-workflow.md layout_flowchart_diagram.py、check_flowchart_layout.py、generate_visio_flowchart_diagram.ps1 を実行します。
• 三線表とページまたぎの表：references/docx-production-rules.md を参照してから、scripts/create_three_line_table.py を使用します。 Word の Table Grid 表は三線表ではありません。最終 DOCX の出力では、scripts/check_docx_table_continuations.ps1 を実行します。表がページをまたぐ場合、学校やテンプレート、またはユーザーが求めるときは、ヘッダー行の繰り返し、行の分割の無効化、継続を示すキャプションの表示が必須です。

編集可能なソースを保持します。Visio 図は .vsdx、最終的な表はスクリプトと Word のソースを保持してください。 Word で納品する場合、本文に挿入した PNG はプレビュー画像にすぎません。.docx に Visio OLE オブジェクトが含まれ、scripts/check_docx_visio_ole.py で検証されていない限り、図を「Word で編集可能な Visio」と呼んではいけません。

厳守事項

• 学校および指導教員のルールは、デフォルト設定より優先されます。
• プロジェクトの機能、API、データベースフィールド、テスト、スクリーンショット、実験、引用、DOI 値、学校のルールを捏造してはいけません。
• 根拠が不足している場合は、あるように装わず、不足している資料を列挙してください。
• 第4章のデータベース／データオブジェクト設計を黙って省略してはいけません。スキーマ／エンティティ／マイグレーション／SQL の根拠がある場合は、概要 E-R 図、単一エンティティ E-R 図、データベースの三線表を作成してください。業務データベースの根拠はないものの、プロジェクトに実際の構造化設定または根拠資料がある場合は、それらの資料に基づいて、データオブジェクトの E-R モデルと三線表を作成し、データオブジェクトであることを明確に示してください。どちらもない場合は、第4章の執筆に着手する前に根拠の不足を明記してください。
• デフォルトでは、実装を第4章に含めないでください。一般的なシステム論文では、第4章を設計、第5章を実装、第6章をテストとします。学校のテンプレートまたはユーザーが独立した結論の章を明示的に求めていない限り、第7章を作成しないでください。
• 一般的なシステム論文で図の計画を過度に少なくしないでください。第3～6章全体で計画されている図が8点未満の場合は、対象範囲が小さい理由または根拠資料が不足している理由を説明してください。
• 第5章のプログラム画面を捏造してはいけません。第5章は実装の章であり、実装済みの機能について実際に動作するプログラムのスクリーンショットを掲載してください。アプリを実行できない場合、またはスクリーンショットが提供されていない場合は、figure-registry.yaml に needs_user_screenshot エントリーを作成し、根拠の不足として列挙してください。
• 三線表とは、上罫線、見出し下罫線、下罫線のみを使用する表です。縦罫線、内部の格子罫線、Word の Table Grid スタイルは使用しません。.docx を生成した場合は、scripts/check_docx_three_line_tables.py で最終 DOCX の表を検証してください。
• 三線表の検証では、明らかな左右の格子罫線だけでなく、表レベルの罫線と継承された insideH／insideV セル罫線がある場合も失敗としなければなりません。
• ページをまたぐ表を Word のデフォルト設定任せにしてはいけません。見出し行を繰り返す設定にし、行がページをまたいで分割されないようにしてください。続きのキャプションが必要な場合は、目に見える 续表 x.x／表 x.x（续） のキャプションを追加してください。scripts/check_docx_table_continuations.ps1 で検証し、目視確認だけに頼らないでください。
• 最終論文の .docx は、三線表の罫線、継続表のページ割り、見出しレベル、論文としての文体、Visio OLE の埋め込み、プレビューの重複検出、図のアスペクト比、文書の構成要素と順序、引用の整合性、参考文献のハイパーリンク、キャプションの整合性、DOCX の構造的な健全性を含む統合ゲート scripts/check_final_thesis_docx.ps1 に合格しなければなりません。統合ゲートに失敗した場合は、文書を修正するか、作業が阻まれていることを報告してください。
• [1] などの本文中の参考文献マーカーは、単なるテキストではなく、Ctrl キーを押しながらクリックすると該当する参考文献エントリーのブックマークに移動する、実際の Word 内部ハイパーリンクでなければなりません。生成または修復した DOCX では、scripts/apply_docx_reference_hyperlinks.py <paper.docx> を実行し、scripts/check_docx_reference_hyperlinks.py <paper.docx> で検証してください。引用テキストの整合性だけを根拠に、参考文献の処理が完了したと主張してはいけません。
• 相关研究[1]表明 のように本文に埋め込まれた引用マーカーにも、ハイパーリンクと上付き文字の修正が必要です。参考文献一覧に引用番号が存在するからといって、プレーンテキストのマーカーを許容してはいけません。
• テンプレートプロファイルが指定されている場合、統合ゲートではテンプレートのスタイル、ページモデル、複製差分のチェックも実行しなければなりません。目視確認だけを根拠に、テンプレートを再現したと主張してはいけません。
• 学校から別の目標が示されていない限り、一般的な学部のシステム設計論文は、中国語コンテンツ単位で約 12000 単位としてください。scripts/check_docx_thesis_quality.py または統合ゲートのオプション -MinContentUnits 12000 -MinCjkChars 10000 で検証してください。4000 語程度のデモを論文の分量であるかのように納品してはいけません。
• 最終論文の本文は、監査報告書やアシスタントの作業記録ではなく、学生が執筆した論文として読める文体にしてください。根拠資料は作業領域のファイルや報告書に保管し、本文に 证据、当前材料、根据源码、README、PRD、不编造、占位、待补 のような表現を記載しないでください。scripts/check_docx_thesis_voice.py または統合ゲートで検証してください。
• 成功したゲート実行後に最終 .docx を変更した場合、ゲートの結果は古くなります。完了を主張する前に、再度 scripts/check_final_thesis_docx.ps1 を実行してください。
• 最終 .docx の納品時に、OLE の埋め込みが不可能であることを明示して報告する場合を除き、構造図を静的な PNG のみで表現してはいけません。scripts/embed_visio_ole_with_officecli.py --fit-preview-aspect の使用を推奨し、その後 scripts/check_docx_visio_ole.py と scripts/check_docx_duplicate_figure_previews.py で検証してください。
• Visio の o:OLEObject タグがあるだけでは不十分です。check_docx_visio_ole.py では、word/embeddings/ 内にある外部参照ではないリレーションシップのターゲットも確認しなければなりません。ペイロードが存在しない場合は、納品の妨げとなります。
• すべての Visio OLE オブジェクトを 14cm x 8cm のような固定サイズに無理に合わせないでください。プレビューのアスペクト比を維持してください。scripts/check_figure_preview_aspects.py で極端に平坦または縦長の図が報告された場合は、最終納品前に元の図を再レイアウトするか、分割してください。
• 生成したフローチャートの .vsdx 図では、Visio の自動ルーティングだけに頼らないでください。layout_flowchart_diagram.py を実行して各エッジに直交する経路点を設定した後、check_flowchart_layout.py を実行し、レンダリングまたは埋め込み前に connectorCrossings: 0 を確認してください。
• 生成した E-R の .vsdx 図では、layout_er_diagram.py の実行後に check_er_layout.py を実行し、overlapPairs: 0 と connectorCrossings: 0 の両方を確認してください。概要 E-R 図が混み合う場合は、概要図にはエンティティとリレーションシップのみを配置し、属性は単一エンティティ E-R 図と三線表に記載してください。
• 単一エンティティ E-R 図では、すべての接続に共通の中心点を使わず、境界上に分散した接続点を使用してください。スキーマコメントにある簡潔な中国語のフィールド名を優先し、列挙値や暗号化の詳細など、実装に関する括弧書きは取り除いてください。
• すべての図、表、数式、スクリーンショットについて、figure-registry.yaml にソースファイル、該当する場合はエクスポートファイル、初出箇所、ステータスを記録してください。
• 論文の本文に AI ワークフローに関する表現を含めないでください。
• 最終 .docx の安定性を保つため、ユーザーがレイアウト上のリスクを許容しない限り、文書全体を Markdown に変換する往復処理は避けてください。Markdown から Word／Pandoc で出力した場合も、納品物として扱う前に check_docx_three_line_tables.py、check_docx_visio_ole.py、Office／OpenXML の検証、図のアスペクト比チェックに合格しなければなりません。

最小限の読み込み

thesis-ai-standard/ が存在する場合は、まず以下を読み、追加の詳細が必要でない限り、それ以上は読み込まないでください。

1. thesis-ai-standard/templates/standard-profile.yaml
2. thesis-ai-standard/templates/thesis-ai-spec.yaml
3. thesis-ai-standard/templates/figure-registry.yaml
4. paper-context/evidence/（存在する場合）
5. paper-context/template-extract/template-rule-overrides.yaml（存在する場合）
6. paper-context/template-extract/template-profile.json（存在する場合）
7. paper-context/template-extract/thesis-structure-plan.yaml（存在する場合）
8. paper-context/database-design/（存在する場合）
9. paper-context/figure-plan/（存在する場合）

参照ファイルの詳細は、現在のタスクに必要な場合にのみ確認してください。