AnchorSpec 初期公開
- Summary
- 意図・仕様・差分・実装・検証を分けて扱い、Specを信頼できる唯一の情報源として維持する基本モデルを公開しました。
- Reason
- AIとの長期開発では、会話だけに前提を置くと意図や判断理由が薄れていきます。開発状態を役割ごとに分離し、人とAIが同じ基準を参照できる土台が必要でした。
Protocol Evolution
変更履歴
ここに記録するのは、Gitのコミット一覧ではありません。 AnchorSpecが何を課題と捉え、どの責務を追加し、何を手放してきたのか。 プロトコルの進化と、その背景にある設計判断をたどるための履歴です。
01
Evolution Timeline
プロトコルの進化史
- 01v2.1
- 02v2.2
Strand / Splice 導入
- Summary
- 競合しうる複数の仕様案をStrandとして保持し、過去の材料を再解釈して新しいStrandを作るSpliceを導入しました。
- Reason
- 異なる設計案を早い段階で一つに混ぜると、選択肢と判断の経緯が失われます。並行案を残したまま比較し、新しい解釈を明示的に作るための仕組みとして設計されました。
- 03v2.3
Selection 導入
- Summary
- 複数のStrandから現在採用する仕様系統を選び、採用しなかった代替案と選択理由も残すSelectionを導入しました。
- Reason
- 仕様案を保存するだけでは、どの案を実装の基準にするかが曖昧になります。現在の判断を明示しながら、将来再検討できる履歴を失わないために追加されました。
- 04v2.3
Parameter Layer 導入
- Summary
- ThreadやOperationそのものとは別に、実行環境、制約、検証条件などの解釈・運用条件を保持する補助レイヤーを導入しました。
- Reason
- 運用条件が会話やツール設定へ埋もれると、同じ仕様でも結果が変わります。状態と、その状態をどう扱うかという条件を分離し、見えない依存関係を減らす必要がありました。
- 05設計変更
Strand / Splice / Selection をDeprecated化
Deprecated- Summary
- 並列仕様の管理をAnchorSpec本体の責務から外し、プロジェクト戦略または外部ツールで扱う方針へ変更しました。
- Reason
- 並列分岐の管理までプロトコル内部へ含めると、核となる意図・仕様・差分・検証のモデルが複雑になります。AnchorSpecの責務を、開発状態の一貫性維持へ集中させるための整理です。
- 06現行モデル
Verification Transition Table 導入
- Summary
- Verifyで見つかった不一致を、種類に応じてGapまたはImplGapへ記録する状態遷移を明示しました。
- Reason
- Verifyが検出と修正を同時に行うと、問題の記録や人間の判断を飛ばして仕様が変わる危険があります。検出後の行き先を表として固定し、Verifyを『直す操作』ではなく『見つける操作』として守るためです。
- 07現行モデル
Build Plan モデル導入
- Summary
- Frozen Specを実装へ移す前に、対象、依存関係、制約、検証条件を確認するBuild Planフェーズを導入しました。
- Reason
- AIが仕様を受け取ってすぐ実装へ進むと、対象範囲や禁止事項の解釈違いが後から表面化します。Build Planを人間が確認できる発注確認書として置き、実装前に合意するためです。
- 08現行モデル
External Markdown 方式へ移行
- Summary
- 意図、仕様、差分、実装文脈、検証結果を、特定のAIサービス内ではなく外部Markdownファイルで管理する方式へ移行しました。
- Reason
- 開発記録がチャットや特定プラットフォームだけに残ると、別のAIやツールへ引き継げません。人が読めて差分管理できるMarkdownを外部の正本とし、可搬性と長期保存性を高めるためです。
About this history
日付よりも、判断の連続性を残す
正確な公開日が確認できない項目は、推測の日付を記載せず、バージョンまたは設計時期で示しています。 今後の変更も、機能名だけでなく「なぜ変えたのか」を中心に追加していきます。