feat: Organize context files and enhance documentation for clarity and structure
This commit is contained in:
30
ai/context/process/jira-story-rules.md
Normal file
30
ai/context/process/jira-story-rules.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Jira Story Rules
|
||||
|
||||
## Goal
|
||||
|
||||
Keep Jira updates precise enough that the story reflects the real problem and remains easy to reference later.
|
||||
|
||||
---
|
||||
|
||||
## Stable Rules
|
||||
|
||||
- Preserve Jira ID and explicit title whenever available.
|
||||
- Prefer story wording that describes the real contract or behavior gap, not only the first symptom.
|
||||
- Include authenticated-state or environment qualifiers when they materially affect scope.
|
||||
- Validate consumer behavior before finalizing scope when the issue depends on Fid4 or flagship.
|
||||
|
||||
---
|
||||
|
||||
## Story-Creation Guidance
|
||||
|
||||
- Create or refine the story after the reproduction path is understood well enough to avoid mis-scoping.
|
||||
- Include points and scope only after the work has been framed clearly.
|
||||
- If the issue crosses SDK, adapter, FT modules, and consumer app boundaries, the story should say so.
|
||||
- If a bug is external or not yet confirmed as regression, avoid writing the ticket as if the root cause is already proven.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Historical Slack threads repeatedly show Jeff refining titles and descriptions before stories were created or shared.
|
||||
- Several story discussions centered on making the wording reflect deeper SwiftUI, lifecycle, or integration issues rather than surface symptoms alone.
|
||||
Reference in New Issue
Block a user