FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Issueの作業記録を一つのUser Storyへ集約する
要件から検証までを同じ記録で追い、安全な作成経路で承認境界を守る
目的
要件、専門担当への引き継ぎ、技術分解、実装、検証が別々のIssueへ分散すると、作業の全体像と完了根拠を一続きに確認しにくくなる。
基本作業単位を1件のUser Storyに統一し、複数のStoryを束ねる上位項目の作成や関連付けには明示的な承認を残す運用を目指した。
実装
User StoryをIssue Type Taskで表し、要件、scope、依存関係、各担当の作業記録、実装内訳、検証結果、完了判断を同じIssueへ集約するモデルに改めた。独立した要件Issueや実装Issueを増やさず、1 Storyにつき一つの変更単位で追跡する。
複数のUser Storyをまとめる必要がある場合だけ上位項目を候補として提案し、新規作成や既存項目との関連付けは明示的な承認後に行うことにした。これにより、作業開始の承認と上位計画を広げる承認を分離した。
User Storyの作成はrepository内の専用helperへ限定した。helperはIssue Typeを固定し、parent、任意のrepository、未知の引数を受け付けない。本文はfile経由で渡し、現在のrepository内にある通常fileか、空でないか、symbolic linkでないかを確認する。
- 本文fileのcanonical pathが現在のrepository内に収まることを確認する。
.git、環境設定、credential、secret、token、秘密鍵に相当するpathを拒否する。- 汎用のIssue作成commandは自動許可せず、安全条件をruntimeで検査する専用helperだけを通常経路にする。
各roleのSkill、agent定義、組織rule、運用model、setup、handoff例も同じ記録モデルへ揃えた。作業の途中経過は意味のある区切りごとに同じUser Storyへ戻し、完了時には条件、作業記録、検証証拠を照合できる形にした。
## Product Requirements
- 要求事項が大きく複数の User Story を束ねる必要がある場合だけ Epic として管理すること
- Epic は Issue Type `Feature` とし、本文には長期的なgoalと成功状態だけを記載すること。作業計画、step、初期User Story一覧、変化しうるscope分解や依存順を本文へ固定しないこと
- Epicの新規作成と既存Epicへの関連付けは、候補、goal、関連理由をCEOへ提示し、明示承認後にだけ実行すること
- Product Manager は business requirement に不明点があれば User Story 作成前に CEO へ質問し、確認済みの前提と未確認の仮説を分けること
- 質問には質問背景、目的、回答選択肢、推奨回答案を含めること
- User Story は INVEST、つまり Independent、Negotiable、Valuable、Estimable、Small、Testable を満たす粒度と文面にすること
- User Story は Issue Type `Task` とし、requirements、specialist作業、technical breakdown、進捗、検証、reviewを1件のIssueへ集約すること図を描画しています…
確認したこと
確認結果
User Storyを基本作業単位とし、要件から完了判断までを同じIssueへ集約する記録モデルが運用文書と各roleの手順へ反映された。
専用helperはIssue Typeを固定し、parent指定、任意repository指定、path traversal、空fileを外部更新前に拒否した。
shell構文、実行権限、許可規則、設定fileのparse、旧運用表現の残存検索、差分検査が成功した。
cutoff時点で記録モデルと安全な作成経路は対象へ反映されていた。既存Issueの履歴移行や上位項目の新規作成・関連付けはこのActivityの範囲に含めていない。
完了とした根拠
User Storyへ作業記録を集約する規則と、安全条件を強制する作成helperが関連するSkill・agent定義・運用文書へ揃い、拒否ケースを含む検証に成功して対象へ反映されたことをもって完了とした。