kotonoha 0.2.0 → 0.4.0

package/skills/japanese-prose/scripts/test_engine.py

@@ -5,6 +5,7 @@
 #   "ginza>=5.2.0,<5.3",
 #   "ja-ginza>=5.2.0,<5.3",
 #   "spacy>=3.8.0,<4",
+#   "markdown-it-py>=3,<5",
 # ]
 # ///
 """Behavioral tests for kotonoha's original GiNZA diagnostics."""
@@ -12,6 +13,9 @@
 from __future__ import annotations
 
 import json
+import hashlib
+import subprocess
+import sys
 import tempfile
 import unittest
 from pathlib import Path
@@ -20,6 +24,7 @@ from core import strip_markdown_inline
 from lint import analyze, compare_baseline
 from outline import extract as extract_outline
 from terms import extract as extract_terms
+from invariants import SEMANTIC_CHECKS, check as check_invariants
 
 
 SCRIPT_DIR = Path(__file__).resolve().parent
@@ -27,6 +32,70 @@ FIXTURES = SCRIPT_DIR / "fixtures"
 
 
 class DiagnosticTests(unittest.TestCase):
+    def analyze_text(self, text: str, reading_load: bool = False) -> dict:
+        with tempfile.TemporaryDirectory() as directory:
+            path = Path(directory) / "sample.md"
+            path.write_text(text, encoding="utf-8")
+            return analyze(path, "tech", reading_load)
+
+    def test_proofreading_detects_adjacent_duplicates(self) -> None:
+        for text, category in (
+            ("管理者が設定をを確認します。", "duplicate_particle"),
+            ("管理者がが設定を確認します。", "duplicate_particle"),
+            ("管理者にに通知します。", "duplicate_particle"),
+            ("設定設定を保存します。", "duplicate_word"),
+        ):
+            with self.subTest(text=text):
+                result = self.analyze_text(text)
+                self.assertIn(category, {item["category"] for item in result["findings"]})
+                self.assertNotIn(
+                    category,
+                    {item["category"] for item in self.analyze_text(text, True)["findings"]},
+                )
+
+    def test_proofreading_checks_brackets_and_paragraph_style(self) -> None:
+        for text, category in (
+            ("設定（管理者向け））を保存します。", "unbalanced_brackets"),
+            ("設定を保存します。変更はすぐに反映される。", "mixed_sentence_style"),
+        ):
+            with self.subTest(text=text):
+                self.assertIn(category, {
+                    item["category"] for item in self.analyze_text(text)["findings"]
+                })
+
+    def test_proofreading_preserves_names_code_and_deliberate_styles(self) -> None:
+        text = (
+            "ののさんは、ももを食べます。操作を確認してください。\n\n"
+            "「設定を保存する」と説明します。結果を確認します。\n\n"
+            "設定を保存する。\n\n設定を確認します。\n\n"
+            "`設定設定（`という識別子を使用します。\n\n"
+            "```text\n設定をを確認します（\n```\n"
+        )
+        categories = {item["category"] for item in self.analyze_text(text)["findings"]}
+        self.assertFalse(categories & {
+            "duplicate_particle", "duplicate_word", "unbalanced_brackets", "mixed_sentence_style",
+        })
+
+    def test_short_fences_and_fence_info_do_not_expose_code_as_prose(self) -> None:
+        for text in (
+            "````text\n```python\n設定設定（をを確認する。\n```\n````\n",
+            "```text\n```python\n設定設定（をを確認する。\n```\n",
+        ):
+            with self.subTest(text=text):
+                self.assertEqual(self.analyze_text(text)["findings"], [])
+
+    def test_questions_and_obligations_are_not_style_errors(self) -> None:
+        for text in (
+            "この結果だけでは、安全だと言えるでしょうか。",
+            "この結果だけでは、安全だと言えるだろうか。",
+            "管理者は確認しなくてはならない。",
+            "この場合は停止せざるを得ない。",
+        ):
+            with self.subTest(text=text):
+                categories = {item["category"] for item in self.analyze_text(text)["findings"]}
+                self.assertNotIn("formulaic_conclusion", categories)
+                self.assertNotIn("double_negative", categories)
+
     def test_unnatural_fixture_scores_below_natural_fixture(self) -> None:
         unnatural = analyze(FIXTURES / "unnatural.md", "tech", False)
         natural = analyze(FIXTURES / "natural.md", "tech", False)
@@ -113,5 +182,104 @@ class DiagnosticTests(unittest.TestCase):
         self.assertTrue(values.isdisjoint({"npm", "run", "build", "workspace", "core"}))
 
 
+class InvariantTests(unittest.TestCase):
+    def test_protected_changes_cannot_be_approved_by_semantic_review(self) -> None:
+        original = (
+            "---\nowner: admin\n---\n# 概要\n\n"
+            "REQ-001ではAcmeが3回、30秒で確認します。帯域は3MB/sです。[仕様](https://example.com/spec)\n\n"
+            "`MAX_RETRY_COUNT`を使用します。\n\n"
+            "| 項目 | 値 |\n| --- | --- |\n| 上限 | 3 |\n\n"
+            "````text\n```python\nprint('old')\n```\n````\n"
+        )
+        changes = (
+            ("3回、30秒", "30回、3秒", "numbers_in_order"),
+            ("30秒", "30分", "quantities_in_order"),
+            ("3MB/s", "3MB/min", "quantities_in_order"),
+            ("REQ-001", "REQ-002", "identifiers_in_order"),
+            ("https://example.com/spec", "https://example.com/new", "link_destinations"),
+            ("MAX_RETRY_COUNT", "RETRY_COUNT", "inline_code"),
+            ("| 上限 | 3 |", "| 上限 | 4 |", "protected_blocks"),
+            ("owner: admin", "owner: user", "frontmatter"),
+            ("# 概要", "## 概要", "heading_levels"),
+            ("Acme", "Other", "protected_terms"),
+            ("print('old')", "print('new')", "protected_blocks"),
+        )
+        with tempfile.TemporaryDirectory() as directory:
+            before, after, review = (Path(directory) / name for name in ("before.md", "after.md", "review.json"))
+            before.write_text(original, encoding="utf-8")
+            for old, new, category in changes:
+                with self.subTest(category=category):
+                    after.write_text(original.replace(old, new), encoding="utf-8")
+                    self.write_review(before, after, review)
+                    result = check_invariants(before, after, ["Acme"], review)
+                    self.assertEqual(result["status"], "blocked")
+                    self.assertIn(category, {
+                        item["category"] for item in result["mechanical_violations"]
+                    })
+
+    def write_review(self, before: Path, after: Path, review: Path) -> None:
+        review.write_text(json.dumps({
+            "before_sha256": hashlib.sha256(before.read_bytes()).hexdigest(),
+            "after_sha256": hashlib.sha256(after.read_bytes()).hexdigest(),
+            "reviewer": "test-reviewer",
+            "checks": {name: True for name in SEMANTIC_CHECKS},
+        }), encoding="utf-8")
+
+    def test_review_must_cover_exact_edits_and_all_semantic_checks(self) -> None:
+        with tempfile.TemporaryDirectory() as directory:
+            before, after, review = (Path(directory) / name for name in ("before.md", "after.md", "review.json"))
+            before.write_text("管理者だけが設定を確認します。", encoding="utf-8")
+            after.write_text("設定を確認できるのは管理者だけです。", encoding="utf-8")
+            self.assertEqual(check_invariants(before, before)["status"], "passed")
+            self.assertEqual(check_invariants(before, after)["status"], "review_required")
+            self.write_review(before, after, review)
+            self.assertEqual(check_invariants(before, after, review_path=review)["status"], "passed")
+            after.write_text("誰でも設定を確認できます。", encoding="utf-8")
+            self.assertEqual(check_invariants(before, after, review_path=review)["status"], "review_required")
+            self.write_review(before, after, review)
+            value = json.loads(review.read_text(encoding="utf-8"))
+            value["checks"]["scope"] = False
+            review.write_text(json.dumps(value), encoding="utf-8")
+            self.assertEqual(check_invariants(before, after, review_path=review)["status"], "review_required")
+
+    def test_invariant_cli_exit_codes_and_input_errors(self) -> None:
+        with tempfile.TemporaryDirectory() as directory:
+            before, after = (Path(directory) / name for name in ("before.md", "after.md"))
+            before.write_text("上限は3回です。", encoding="utf-8")
+            for text, code in (
+                ("上限は3回です。", 0),
+                ("上限は30回です。", 2),
+                ("3回を上限とします。", 3),
+            ):
+                with self.subTest(code=code):
+                    after.write_text(text, encoding="utf-8")
+                    process = subprocess.run(
+                        [sys.executable, str(SCRIPT_DIR / "invariants.py"), str(before), str(after), "--json"],
+                        capture_output=True, text=True,
+                    )
+                    self.assertEqual(process.returncode, code, process.stderr)
+                    self.assertIn("status", json.loads(process.stdout))
+            process = subprocess.run(
+                [sys.executable, str(SCRIPT_DIR / "invariants.py"), str(before), str(Path(directory) / "missing.md")],
+                capture_output=True, text=True,
+            )
+            self.assertEqual(process.returncode, 1)
+            self.assertIn("error:", process.stderr)
+
+    def test_units_across_line_breaks_and_boolean_review_types(self) -> None:
+        with tempfile.TemporaryDirectory() as directory:
+            before, after, review = (Path(directory) / name for name in ("before.md", "after.md", "review.json"))
+            before.write_text("上限は30\n秒です。", encoding="utf-8")
+            after.write_text("上限は30\n分です。", encoding="utf-8")
+            self.assertEqual(check_invariants(before, after)["status"], "blocked")
+            before.write_text("設定をを保存します。", encoding="utf-8")
+            after.write_text("設定を保存します。", encoding="utf-8")
+            self.write_review(before, after, review)
+            value = json.loads(review.read_text(encoding="utf-8"))
+            value["checks"]["negation"] = "true"
+            review.write_text(json.dumps(value), encoding="utf-8")
+            self.assertEqual(check_invariants(before, after, review_path=review)["status"], "review_required")
+
+
 if __name__ == "__main__":
     unittest.main()

package/skills/presentation-planner/SKILL.md

@@ -36,6 +36,20 @@ Read `references/responsibility-boundary.md` before acting. This skill owns:
 - Selection and adaptation of a packaged design specification
 - A deterministic handoff contract for the host's PPTX skill
 
+When a presentation request still lacks a defined decision question,
+evidence-backed findings, or option analysis, load kotonoha's sibling
+`consulting-analyst` skill first. Consume its `synthesis-handoff.md` rather
+than inventing business conclusions during storyline design. Preserve its
+evidence IDs, confidence, counterevidence, decision criteria, and conditions
+that would change the recommendation. If the sibling skill is absent, ask for
+the decision question and evidence or label conclusions as unverified.
+
+If the handoff status is `Incomplete`, either return decision-critical gaps
+for further analysis or show the incomplete status, evidence gaps, confidence,
+and conditional wording in the presentation plan. Return to analysis when
+new evidence, a different audience decision, changed criteria, or a
+contradiction would change the conclusion.
+
 This skill must not:
 
 - Create, edit, unzip, or inspect `.pptx` binaries

package/skills/tech-writer/SKILL.md

@@ -6,19 +6,21 @@ description: >-
   notes/CHANGELOG, user manuals/how-to guides, code comments/docstrings,
   requirements definitions, system designs, test plans, operations runbooks,
   migration plans, security designs/threat models, technical proposals,
-  RFI/RFP procurement documents, and Qiita/Zenn articles. Use for requests
+  Blueprints, White Papers, RFI/RFP procurement documents, and Qiita/Zenn
+  articles. Use for requests
   like "write a README", "draft a design doc", "define system requirements",
   "write a system design", "create a test plan", "write an operations
   runbook", "plan a migration", "create a threat model", "write a technical
-  proposal", "draft an RFI", "create an RFP", "write this PR description",
-  "clean up my commit
+  proposal", "create a Blueprint", "write a White Paper", "draft an RFI",
+  "create an RFP", "write this PR description", "clean up my commit
   message", "make this how-to guide clearer", "write API docs", "summarize
   the release notes", "write a Zenn article", "write this up for Qiita", as
   well as
   Japanese-language equivalents (「READMEを書いて」「設計ドキュメントを作って」
   「要件定義書を作って」「システム設計書を書いて」「テスト計画書を作って」
   「運用設計書を書いて」「移行計画を作って」「脅威モデルを作って」
-  「技術提案書を書いて」「RFIを作って」「RFPを作って」「PRの説明文を書いて」
+  「技術提案書を書いて」「Blueprintを作って」「ホワイトペーパーを書いて」
+  「RFIを作って」「RFPを作って」「PRの説明文を書いて」
   「コミットメッセージを整えて」「手順書を分かりやすくして」
   「APIドキュメントを整備して」「リリースノートをまとめて」
   「Zennの記事を書いて」「Qiitaに投稿する記事を書いて」). Especially useful when
@@ -41,8 +43,8 @@ with the shortest path. Covers README, design docs/ADRs, API reference, PR
 descriptions/commit messages/issue reports, release notes/CHANGELOG, user
 manuals/how-to guides, code comments/docstrings, requirements definitions,
 system designs, test plans, operations runbooks, migration plans, security
-designs/threat models, technical proposals, RFI/RFP procurement documents,
-and Qiita/Zenn articles.
+designs/threat models, technical proposals, Blueprints, White Papers,
+RFI/RFP procurement documents, and Qiita/Zenn articles.
 
 Default format: Markdown for every doctype in this skill, except a git
 commit message body (plain text by convention — light "-" bullets are
@@ -54,18 +56,35 @@ reference files.
 
 ## Division of labor
 
-Document quality splits into two layers: "is the structure right" and "is
-the prose natural and readable". This skill owns the first layer (structure,
-document type conventions, completeness, reader fit). The bundled
-`japanese-prose` skill owns the second layer (sentence-level naturalness,
-reading load, terminology, and repeated-pattern analysis). Kotonoha packages
-both layers: tech-writer locks down the structure and orchestrates the §5
-handoff to japanese-prose during `write` mode before the final rubber-duck
-review.
+Document creation can span three layers: "is the reasoning defensible", "is
+the structure right", and "is the prose natural and readable". The bundled
+`consulting-analyst` skill owns problem decomposition, hypotheses, evidence,
+option evaluation, and synthesis when those are not yet settled. This skill
+owns structure, document type conventions, completeness, and reader fit. The
+bundled `japanese-prose` skill owns sentence-level naturalness, reading load,
+terminology, and repeated-pattern analysis.
+
+When a request for a Blueprint, White Paper, proposal, or decision document
+still lacks a defensible analysis, load the sibling `consulting-analyst`
+skill first and consume its `synthesis-handoff.md`. Do not silently invent
+the missing analysis inside document prose. If the sibling skill is absent,
+ask for the decision question and evidence or label analytical conclusions as
+unverified. Preserve issue, hypothesis, source, evidence, criterion, weight,
+score, confidence, counterevidence, and uncertainty records. Return the work
+to analysis when new evidence, a new decision question, changed criteria, or
+a contradictory conclusion requires analytical judgment.
+
+If the handoff status is `Incomplete`, either return the decision-critical
+gaps to `consulting-analyst` or preserve that status, the evidence gaps, the
+confidence, and conditional wording visibly in the document. Never turn an
+incomplete handoff into an unqualified recommendation. Tech-writer then locks
+down the document structure and orchestrates the §5 handoff to
+japanese-prose during `write` mode before the final rubber-duck review.
 
 - Rule of thumb: "does removing a heading still make sense?" tests structure
-  (this skill's job). "Does rereading a single sentence change its meaning?"
-  tests prose (not this skill's job).
+  (this skill's job). "Does the recommendation follow from evidence?" tests
+  analysis (`consulting-analyst`). "Does rereading a single sentence change
+  its meaning?" tests prose (`japanese-prose`).
 - Code comments/docstrings document code itself, but the same
   structure-and-completeness framing still applies.
 
@@ -110,7 +129,13 @@ hand the user a checklist to fill in. Instead:
    For a supplier response, structure the document against the supplied
    RFP's requirement IDs, requested proposal contents, pricing format, and
    contract deviations, then apply the general principles in
-   `references/style-constitution.md`.
+   `references/style-constitution.md`. For a bare "Blueprint" request, ask
+   whether the reader needs an integrated future state and transformation
+   path (`blueprint`), implementation-level system detail (`system-design`),
+   or approval for one investment (`technical-proposal`). For a bare "White
+   Paper" request, ask whether the goal is an evidence-led publication
+   (`white-paper`) or an internal approval request (`technical-proposal`);
+   do not treat a sales brochure as an evidence-led White Paper.
 2. Open the matching reference file and note its target reader and any
    "settle before writing" items. Combined with the general musts below,
    this is your information checklist — but never show it to the user as a
@@ -129,7 +154,10 @@ hand the user a checklist to fill in. Instead:
    approved requirements baseline for a system design, exit criteria for a
    test plan, RTO/RPO for an operations runbook, rollback conditions for a
    migration plan, assets and trust boundaries for a threat model, market
-   unknowns for an RFI, or evaluation rules for an RFP).
+   unknowns for an RFI, evaluation rules for an RFP, planning horizon,
+   approval authority, and baseline evidence for a Blueprint, or the central
+   claim, evidence standard, and publisher or sponsor conflicts for a White
+   Paper).
 5. **A "don't know" / "not applicable" / "no ticket for this" answer
    satisfies a must — it is not a reason to keep asking.** Ask that must
    at most once; if the answer is a non-answer, record it as a stated
@@ -162,6 +190,8 @@ hand the user a checklist to fill in. Instead:
 | Migration plan / 移行計画書 | migration-plan | `references/doctypes/migration-plan.md` |
 | Security design / Threat model / セキュリティ設計書 | security-design | `references/doctypes/security-design.md` |
 | Internal technical proposal | technical-proposal | `references/doctypes/technical-proposal.md` |
+| Blueprint / 将来構想・変革設計図 | blueprint | `references/doctypes/blueprint.md` |
+| White Paper / ホワイトペーパー | white-paper | `references/doctypes/white-paper.md` |
 | Request for information / RFI | rfi | `references/doctypes/rfi.md` |
 | Request for proposal / RFP | rfp | `references/doctypes/rfp.md` |
 | Zenn article | zenn | `references/doctypes/zenn.md` |
@@ -176,8 +206,8 @@ one-question-at-a-time intake for reader and outcome.
 For documents likely to run long — design docs/ADRs, user manuals with
 multiple steps, API references covering several endpoints, requirements
 definitions, system designs, test plans, operations runbooks, migration
-plans, security designs, technical proposals, RFI/RFP documents, or anything
-the user calls
+plans, security designs, technical proposals, Blueprints, White Papers,
+RFI/RFP documents, or anything the user calls
 "long"/"detailed"/"comprehensive" — draft a table of contents (heading
 outline) before writing any body prose.
 
@@ -207,7 +237,8 @@ document and needs the outline step below.
 For living, multi-section documents (README, design doc, API reference,
 release notes, user manual, requirements definition, system design, test
 plan, operations runbook, migration plan, security design, technical
-proposal, RFI/RFP, Zenn/Qiita article), write under the 8 rules
+proposal, Blueprint, White Paper, RFI/RFP, Zenn/Qiita article), write under
+the 8 rules
 in `references/style-constitution.md`. Summary: state "what this is" and
 "the outcome for the reader" in the first three lines; make headings
 labels that preview content (not "Overview", but "Overview of what");
@@ -225,7 +256,10 @@ For every Markdown doctype, surround `**strong emphasis**` with half-width
 spaces when the delimiters would otherwise touch prose. For example, write
 `これは **強調** になる`, not `これは**強調**にならない`. Spaces are not
 required at line boundaries or next to punctuation, and must not be placed
-inside the `**` delimiters.
+inside the `**` delimiters. Use ASCII spaces (`U+0020`), never full-width
+spaces (`U+3000`), tabs, or non-breaking spaces, immediately before and after
+emphasis embedded in prose. Write `これは **「重要」** と説明する`, not
+`これは　**「重要」**　と説明する`.
 
 For atomic artifacts (commit messages, PR descriptions, issue reports,
 code comments/docstrings, a single entry appended to an existing
@@ -373,8 +407,8 @@ for `write` mode; do not run it for `review` or `score` mode.
 See each reference file for detail. The items below are for living,
 multi-section documents (README, design doc, API reference, release notes,
 user manual, requirements definition, system design, test plan, operations
-runbook, migration plan, security design, technical proposal, RFI/RFP,
-Zenn/Qiita article). Atomic
+runbook, migration plan, security design, technical proposal, Blueprint,
+White Paper, RFI/RFP, Zenn/Qiita article). Atomic
 artifacts (commit message, PR
 description, issue report, code comment/docstring, a single appended
 release-notes entry) are already covered by their own doctype checklist

package/skills/tech-writer/assets/templates/blueprint.md

@@ -0,0 +1,187 @@
+# <Blueprint名>
+
+<対象読者、実現する将来像、この文書を使って合意する事項を3文以内で記載する。>
+
+- オーナー: <組織・役割>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 対象期間: <YYYY-MM-DD〜YYYY-MM-DD、または3年間など>
+- 対象範囲: <事業・組織・業務・データ・技術など>
+- ステータス: Draft / In Review / Approved / Rejected / Deferred / Superseded
+- 承認者・会議体: <名称>
+- 現行版: <版番号>
+- 置き換える文書: <文書名・版、または該当なし>
+- Analysis status: Completed / Incomplete / Not performed
+- Evidence gaps: <不足する証拠、影響する判断、収集担当・期限、またはなし>
+- 分析ハンドオフ: <synthesis-handoff.mdの所在、またはなし>
+
+`Analysis status`は文書の承認ステータスとは別に記録する。`Incomplete`の場合は、不足する証拠と確からしさを明示し、影響する結論・推奨事項を条件付きで記載する。判断を妨げる不足は`consulting-analyst`へ戻すか、この文書に残す。`Not performed`の場合は、分析未実施の範囲と理由を記載し、分析済みとして扱わない。
+
+## <このBlueprintで実現する成果>
+
+<対象期間の終了時に、誰が何を実現できる状態になるかを記載する。>
+
+| 成果ID | 期待する成果 | 現状値 | 目標値 | 測定方法 | 判定時期 | オーナー |
+|---|---|---:|---:|---|---|---|
+| OUT-001 | <成果> | <値> | <値> | <方法> | <時期> | <役割> |
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <対象となる組織、能力、業務、データ、システム、地域>
+
+### 対象外
+
+- <このBlueprintでは扱わない事項と、その扱い先>
+
+### 前提条件と制約
+
+| ID | 種別 | 内容 | 根拠 | 変更時の影響 |
+|---|---|---|---|---|
+| CON-001 | 前提 / 制約 | <内容> | <資料・決定> | <影響> |
+
+## 変革を必要とする背景
+
+<外部環境、利用者ニーズ、経営課題、技術的負債、規制など、将来像が必要な理由を事実と解釈に分けて記載する。>
+
+| ドライバーID | ドライバー | 根拠 | 対応しない場合の影響 |
+|---|---|---|---|
+| DRV-001 | <変化・課題> | <データ・資料> | <影響> |
+
+## 設計原則
+
+| 原則ID | 原則 | 判断への適用方法 | 例外を認める条件 |
+|---|---|---|---|
+| PRN-001 | <原則> | <選択・優先順位への反映> | <条件と承認者> |
+
+## 現在地を示すベースライン
+
+### 現在の能力と成熟度
+
+| 能力ID | 能力 | 現状 | 成熟度 | 根拠 | 主な課題 |
+|---|---|---|---|---|---|
+| CAP-001 | <能力> | <現在の状態> | 1〜5 | <評価資料> | <課題> |
+
+### 現在の構成
+
+<業務、組織、データ、アプリケーション、基盤、セキュリティ、運用のうち、対象範囲に必要な現在の構成を示す。>
+
+```mermaid
+flowchart LR
+    A[<現在の利用者・業務>] --> B[<現在の能力・システム>]
+    B --> C[<現在の成果・制約>]
+```
+
+## 目標とする能力と将来像
+
+### 目標能力
+
+| 能力ID | 目標能力 | 提供する価値 | 対象者 | 成熟度目標 | 成功条件 |
+|---|---|---|---|---|---|
+| CAP-001 | <能力> | <価値> | <対象者> | 1〜5 | <測定可能な条件> |
+
+### 将来のOperating Model
+
+| 観点 | 将来の状態 | 主な変更 | 意思決定者 |
+|---|---|---|---|
+| 組織・役割 | <状態> | <変更> | <役割> |
+| 業務プロセス | <状態> | <変更> | <役割> |
+| ガバナンス | <状態> | <変更> | <役割> |
+| 人材・スキル | <状態> | <変更> | <役割> |
+
+### 将来のデータ・技術構成
+
+<技術が対象外の場合は、その理由と別文書を記載する。>
+
+```mermaid
+flowchart LR
+    A[<利用者・チャネル>] --> B[<目標能力>]
+    B --> C[<データ・サービス・基盤>]
+    C --> D[<測定可能な成果>]
+```
+
+| 構成要素 | 責任 | 原則・標準 | 詳細設計の所在 |
+|---|---|---|---|
+| <要素> | <責任> | <適用する原則> | <文書・未作成> |
+
+### セキュリティ・リスク・運用の将来像
+
+- セキュリティ: <信頼境界、責任分担、主要統制>
+- リスク管理: <識別、受容、軽減、報告の方法>
+- 運用: <所有権、監視、継続性、改善サイクル>
+
+## 現在地と将来像の差分
+
+| Gap ID | 関連能力 | 現在地 | 将来像 | 必要な変更 | 優先度 |
+|---|---|---|---|---|---|
+| GAP-001 | CAP-001 | <状態> | <状態> | <変更> | High / Medium / Low |
+
+## 変革ワークストリーム
+
+| WS ID | ワークストリーム | 解消するGap | 成果物 | オーナー | 依存関係 | 完了条件 |
+|---|---|---|---|---|---|---|
+| WS-001 | <名称> | GAP-001 | <成果物> | <役割> | <WS・外部条件> | <条件> |
+
+## 移行段階とロードマップ
+
+<日付だけでなく、各段階へ進む条件と完了条件を記載する。>
+
+| フェーズ | 目的 | 対象ワークストリーム | 開始条件 | 完了条件 | 目標時期 |
+|---|---|---|---|---|---|
+| Phase 1 | <目的> | WS-001 | <条件> | <測定可能な条件> | <時期> |
+
+### 移行中の共存と廃止
+
+- 共存が必要な状態: <旧新の併存、データ同期、二重運用>
+- 切り替え条件: <判断指標・承認者>
+- 廃止対象と条件: <業務・システム・契約・データ>
+- ロールバックまたは方針見直し条件: <条件>
+
+## ガバナンスと意思決定
+
+| 判断事項 | 決定者 | 提案者 | 相談先 | 報告先 | 判断時期 |
+|---|---|---|---|---|---|
+| <判断事項> | <役割> | <役割> | <役割> | <役割> | <時期> |
+
+### 例外と変更管理
+
+- 原則の例外申請: <手順・承認者>
+- Blueprint変更: <提案、影響分析、承認、版管理>
+- 下位文書との不整合: <検出・解消方法>
+
+## 成果の測定とレビュー
+
+| 指標ID | 関連成果 | 指標 | 目標 | データ源 | 頻度 | 未達時の対応 |
+|---|---|---|---:|---|---|---|
+| KPI-001 | OUT-001 | <指標> | <値> | <データ源> | <頻度> | <見直し・是正> |
+
+## リスクと未解決事項
+
+| ID | 種別 | 内容 | 影響 | 対応 | オーナー | 期限 |
+|---|---|---|---|---|---|---|
+| RSK-001 | リスク / 未解決事項 | <内容> | <影響> | <対応> | <役割> | <日付> |
+
+## トレーサビリティ
+
+分析ハンドオフがある場合は、関連するQ / HYP / FND / EVD / GAP / INT / CRT IDsを保持する。INTは介入、CRTは選択肢の評価基準を表す。該当しないリンクは理由付き`N/A`とし、ハンドオフがない場合は分析IDを無理に作らない。
+
+| 論点 Q IDs | 仮説 HYP IDs | 発見 FND IDs | 証拠 EVD IDs | ドライバー | 設計原則 | 目標能力 | Gap | 介入 INT IDs | 評価基準 CRT IDs | ワークストリーム | 指標 |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| <関連Q IDs、またはN/A> | <関連HYP IDs、またはN/A> | <関連FND IDs、またはN/A> | <関連EVD IDs、またはN/A> | DRV-001 | PRN-001 | CAP-001 | GAP-001 | <関連INT IDs、またはN/A> | <関連CRT IDs、またはN/A> | WS-001 | KPI-001 |
+
+## 承認と変更履歴
+
+### 承認
+
+ヘッダーのステータスと、次の承認結果を一致させる。承認結果が`Rejected`または`Deferred`の場合、ステータスを`Approved`にしない。
+
+| 役割 | 氏名・会議体 | 判断 | 日付 | 条件 |
+|---|---|---|---|---|
+| <役割> | <名称> | Approved / Rejected / Deferred | <YYYY-MM-DD> | <条件> |
+
+### 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更者 | 承認者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <氏名> | <氏名・会議体> |