FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Consolidating issue work records in one User Story
Following requirements through verification in one record while preserving approval boundaries with a safe creation path
Purpose
When requirements, specialist handoffs, technical breakdown, implementation, and verification are scattered across separate issues, it becomes difficult to review the full work and its completion evidence as one sequence.
The goal was to use one User Story as the basic unit of work while retaining explicit approval for creating or linking a higher-level item that groups multiple Stories.
Implementation
A User Story became an issue with Type Task, consolidating its requirements, scope, dependencies, specialist work records, implementation breakdown, verification results, and completion decision in one place. The model avoids separate requirement and implementation issues and tracks each Story as one change unit.
A higher-level item is proposed only when multiple User Stories need to be grouped. Creating it or linking an existing item requires explicit approval, separating approval to begin the work from approval to expand its higher-level plan.
User Story creation was limited to a repository-local helper. The helper fixes the issue type and does not accept a parent, an arbitrary repository, or unknown arguments. It receives the body through a file and checks that the file is regular, non-empty, not a symbolic link, and contained within the current repository.
- Confirm that the canonical body-file path remains inside the current repository.
- Reject paths associated with
.git, environment configuration, credentials, secrets, tokens, or private keys. - Keep generic issue creation outside the automatic allow path and use only the helper that checks safety conditions at runtime.
Role Skills, agent definitions, organization rules, the operating model, setup guidance, and handoff examples were aligned with the same record model. Progress returns to the same User Story at meaningful milestones, leaving completion criteria, work records, and verification evidence available for a final cross-check.
## 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へ集約することRendering diagram…
What was confirmed
Verification results
The record model that treats a User Story as the basic work unit and consolidates requirements through completion was applied across operating guidance and role procedures.
The dedicated helper fixed the issue type and rejected parent selection, arbitrary repository selection, path traversal, and an empty file before any external update.
Shell syntax, executable permission, allow rules, configuration parsing, searches for obsolete operating language, and the diff check passed.
At the cutoff, the record model and safe creation path had been applied to the target. Migration of existing issue histories and creation or linking of higher-level items were outside this Activity.
Basis for completion
The work was complete when the rule for consolidating work records in a User Story and the safety-enforcing creation helper were aligned across related Skills, agent definitions, and operating guidance; rejection cases and other checks passed; and the result was applied to the target.