docs: issue-38 の plan を確定仕様と開発履歴へ振り分ける

[takemi-ohama]

Summary

PR #111（マージ済み）の実装プランを、plan-to-spec に従って確定情報へ変換します。

Skill 本体の仕様書は作りません。docs/specifications/README.md に次の規約があるためです。

Skill の挙動仕様はここに置かない。Skill に関する詳細は対象 Skill の SKILL.md を参照する。

そこで plan の内容を、規約に合う 2 つの置き場へ振り分けました。

内容	置き場	理由
validate-runtime-plugins.sh に追加した版数・Skill 数の突き合わせ検査	docs/specifications/runtime-plugin-distribution.md	Skill の挙動ではなく配布・検証の仕様
設計判断の理由、調査結果、実測値	docs/development-history/03-2026-08-15.md	SKILL.md に書かない背景知識
Skill の挙動	変更なし（plugins/ndf-shared/skills/refactoring/）	規約により SKILL.md が正

変更内容

docs/specifications/runtime-plugin-distribution.md

「Build / Validation」に次を追加。

• 検証内容の表に「版数・Skill 数」の行
• .claude-plugin/marketplace.json と plugins/<family>-codex/.codex-plugin/plugin.json が build の生成対象外であり、drift 検査に掛からないこと。だから突き合わせ検査で担保すること
• description から Skill 数を読み取れない場合もエラーとすること（記述を消すと検査が素通りするのを防ぐため）

docs/development-history/03-2026-08-15.md（git mv で plan から変換）

SKILL.md に書かない、後から必要になる情報だけを残しました。

• 設計判断の理由: なぜ独立 Skill にしなかったか（発動条件が「コードを書くとき」以外に書けず、常に該当するトリガは発動判定として働かない）。なぜ言語別に分けたか。なぜ構造改善を必須工程にしたか
• 既存理論との対応: Rule of Representation / Data-Oriented Programming / Table-Driven Methods など 8 系統。data-oriented を名称に採用しなかった理由も記載
• 実測で確かめた事実: np.vectorize の公式注記、PHPStan 2.2 での外部化と静的解析の関係、TypeScript の never / satisfies の検出、array_column の分類
• CI が検査していなかった箇所: 同じ PR 内で 3 回落とした構造的な原因
• cross-review の収束判定の落とし穴: judge が誤って「収束」と判定した 3 事例と、その見分け方

plan ファイルは git mv で移動しました。草稿（issues/issue-38-coding-rule.md）と外部 AI の回答（issues/issue-38-chatgpt-response.md）は、issues/ が開発記録の置き場である運用に従い残します。

Test plan

• python3 scripts/check-markdown-links.py → valid（移動に伴う相対リンクを含む）
• bash scripts/validate-runtime-plugins.sh → passed
• python3 scripts/check-skill-frontmatter.py --strict → Skill 34 個 / エラー 0
• 開発履歴の記述と実装の照合: code-smells.md の「手を付ける範囲」、data-representation.md の「反復の実行方式」、lang-*.md 4 ファイル、development-workflow の構造改善行が実在すること

やらないこと

• refactoring Skill の挙動変更（本 PR はドキュメントのみ）
• Skill 仕様書の新規作成（規約により SKILL.md が正）