walden-history

Walden History

このスキルは、Walden リポジトリの過去を語るために使用します。ある機能がどのように進化したか、ポートフォリオがどのような物語を語るか、各承認の後にどれだけの手戻りが続いたか、そして置き換えられた仕様を適切に廃止する方法です。walden スキルは現在を起草して実行しますが、このスキルは時間を読み取ります。可能な場合はユーザーの希望する言語で返信してください。

使用する場面

• ユーザーがある機能がどのように進化したかを尋ねたとき — そのタイムライン、年代記、または契約の履歴
• ユーザーが製品の物語を求めたとき: 時代、置き換え、現役の作業と廃止された作業
• ユーザーがある承認の後にどれだけの手戻りが続いたかを尋ねたとき、または変更量の分析を求めたとき
• ユーザーが置き換えられた仕様を廃止することを決断したとき

前提条件

履歴にコミットされた .walden/ ドキュメントを含む git リポジトリ。walden CLI は任意であり、現在の状態を相互確認するためにのみ使用します。以下の再構成はすべて git だけで機能します。.walden/ を gitignore しているリポジトリには記録すべき仕様履歴がありません — それをでっち上げるのではなく、そのまま明言してください。

根拠のルール

すべての歴史的記述は、2 つのラベルのいずれかを必ず 1 つだけ伴い、そのラベルは飾りではありません — それはその記述の証拠クラスです:

• [sealed] — 特定のコミットにおける記録済みの値に対する文字列比較。そのコミットにおいて、design.source_requirements_fingerprint が requirements.approved_fingerprint と等しく、tasks.source_design_fingerprint が design.approved_fingerprint と等しく、証拠レコードのチェーンフィールドが、それが名指すドキュメントのシールと等しいとき、チェーンの整合性は sealed です。あるコミットにおける不整合なシールは所見です — それらを明示的に報告し、決して滑らかに覆い隠さないでください。
• [inferred] — コミットメッセージ、 authorship、時間的因果関係、およびすべての「なぜなら」。推論は正当な語りです。ラベルのない推論は作話です。

4 つの厳格なルール:

1. 履歴の内容は git show <sha>:<path> で取得してください — 決して記憶からではなく。この会話でコマンドを実行していないなら、そのドキュメントが何を述べていたかをあなたは知りません。
2. すべての歴史的主張を、それが導出されたコミット識別子に紐付けてください。sha のない主張は主張ではありません。それは印象です。
3. 内容の検証はカーネルの領域です: 記録済みのフィンガープリント同士を比較するのはあなたの担当です。本文からフィンガープリントを再計算するには walden CLI の正規化ルールが必要です。内容をシールに対して検証するよう求められたら、まさにそのとおりに述べ、そのコミットをチェックアウトして walden validate を実行することを提案してください。
4. Git の authorship は来歴の代理指標です: 「committed by」と書き、決して「approved by」とは書かないでください。Walden はまだ承認者の身元を記録しておらず、年代記はそれをでっち上げてはなりません。

レシピ: 機能クロニクル

1 つの機能のタイムラインを再構成します。ドキュメントごと (requirements.md、design.md、tasks.md) に、古いものから順に作業します:

# Revision list for one document (oldest first)
git log --follow --reverse --format='%h|%aI|%an|%s' -- .walden/specs/<feature>/requirements.md

# Frontmatter as of one revision (flat key: value — trivially parseable)
git show <sha>:.walden/specs/<feature>/requirements.md | sed -n '2,/^---$/p'

イベント導出テーブルを使用して、連続するリビジョン間のフロントマターの遷移からイベントを導出します — コミットメッセージだけから導出してはいけません:

連続するリビジョン間で観測された遷移	イベント
status: draft → in-review	レビュー開始
status: in-review → approved、approved_at 設定	承認
status: approved → draft、フィンガープリント消去	リコンシリエーション
approved_fingerprint が出現、ステータスは approved のまま	シール (採用バックフィル)
承認済みドキュメントで source_*_fingerprint が出現または変更	チェーン修復
本文が変更され、新しい approved_fingerprint + approved_at	再承認サイクル
walden_schema_version が出現	フォーマット移行スタンプ

次に、証拠台帳自身の履歴も同じように読み取ります:

git log --reverse --format='%h|%aI' -- .walden/evidence/<feature>.json
git show <sha>:.walden/evidence/<feature>.json

レコードの出現は最初の証明です。result の反転は検証履歴です。リビジョン間の profile の差異は、語る価値のある環境の変化です。タイムラインの締めくくりとして廃止ルックアップを行います: その機能が .walden/RETIRED.md にエントリを持っている場合、廃止コミット、記録された理由、および後継機能を報告します。

出力: 時系列テーブル — イベントごとに 1 行、列はコミット、日付、イベント、ラベル ([sealed]/[inferred]) — に続いて、ナラティブを記述します。ナラティブは解釈を行ってもかまいませんが、行を引用しなければなりません。

レシピ: プロダクトストーリー

ポートフォリオの時代区分。このレシピには厳格なスコープ規則があります: ポートフォリオ全体のパスは廃止インデックスと git log メタデータのみを読み取ります — すべての機能を深く再構成してはいけません。深掘りは、機能クロニクルを通じて、名前を指定した機能ごとに行います。

# First appearance of each feature (creation event)
git log --reverse --format='%h %aI' -- .walden/specs/<feature> | head -1

# All feature directories ever deleted (retirement candidates for the integrity check)
git log --diff-filter=D --format= --name-only -- '.walden/specs/*/requirements.md' | sort -u

組み立て方: 作成日は機能を世代にクラスタリングします。.walden/RETIRED.md のエントリは、明示的な後継関係でそれらを締めくくります。国勢調査 (存続 / 廃止 / 進行中) はストーリーの現在形です。時代は日付だけでなく、後継チェーンによってグループ化します — 日付は [inferred] を示唆し、インデックスエントリは [sealed by convention] を明示します。

レシピ: リワークレポート

リワーク分析の原材料: 各ドキュメントがその承認 後 にどうなったか。

1. 機能クロニクルの承認抽出を実行して、ドキュメントごとの承認イベントを取得します。
2. 履歴を承認間セグメントに分割し、各セグメントについて何が変わったかを要約します:

git diff <approvalShaA>..<approvalShaB> -- .walden/specs/<feature>/<doc>

3. リコンシリエーションイベント (approved → draft) は、ドラフト内のコンテンツの進化とは別に報告します — リコンサイルは契約の再開であり、ドラフトの変動は著作です。
4. メトリクスブロックで締めくくります。数値をナラティブより先に:

rework metrics — <feature>
  re-approval cycles: requirements=N design=N tasks=N
  reconciliations: N
  first approval → last recorded change: N days

廃止セレモニー

このスキルの唯一の書き込みパスです。廃止された仕様は削除され — 履歴は git に残ります — 廃止インデックスに記録されます。これにより、ゲートは存続するポートフォリオのみを判定し、ナラティブはその章を保ち続けます。

前提条件: ユーザーが、現在の会話の中で廃止する機能とその後継関係を指定していること。正確なリストと後継をユーザーに確認し、明示的な承認を待ちます — 沈黙や以前のつぶやきを同意と見なしてはいけません。

ステップ、1 つのコミットで:

git rm -r .walden/specs/<feature>            # per retired feature
# append one index entry per feature to .walden/RETIRED.md (create it on first use)
git add .walden/RETIRED.md
git commit -m "chore: retire <scope> (superseded by <successor>)"

決してプッシュしないでください。コミット後、walden validate を提案します — 存続するポートフォリオが今やポートフォリオ全体です。

廃止インデックスの規約

.walden/RETIRED.md は constitution.md と lessons.md の隣、specs/ の外に置かれるため、walden コマンドがそれを判定することは決してありません。廃止された機能ごとに 1 行 — 単一のパターンで解析可能、パターンなしでも読める:

# Retired Specifications

History lives in git: `git show <retirement-commit>^:.walden/specs/<name>/requirements.md`
restores any document exactly as sealed.

- <feature-name> — retired <short-sha> — superseded by <feature-or-era> — <reason>

整合性チェック

インデックスと git 履歴は一致していなければなりません。すべての不一致を報告します:

• スペックディレクトリがまだ存在するインデックスエントリ — 記録されたが実行されなかった廃止。
• インデックスエントリのない削除された機能 (--diff-filter=D の一覧から) — 記録されていない廃止。削除コミットでインデックス行をバックフィルすることを提案します。
• 不正な形式のインデックス行 — 行番号を明示します。

出力基準

• タイムラインはテーブル形式で、1 行につき 1 つのコミットアンカー、ラベルはインラインで記載します。テーブルの後にナラティブを置き、その行を引用します。
• 本文中では短縮 SHA、コマンドでは完全なパスを使用します。
• 履歴が欠落している場合（スカッシュマージ、シャロークローン、gitignore された .walden/）、何が失われたかを明記し、git が保持したものだけを語ります — 決して補間してはいけません。
• すべてのリワークレポートでは、ナラティブの前に数値を示します。