- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
40 lines
1.3 KiB
Markdown
40 lines
1.3 KiB
Markdown
---
|
|
type: process
|
|
project: fidelity
|
|
status: active
|
|
updated: 2026-04-16
|
|
tags:
|
|
- process
|
|
- fidelity
|
|
---
|
|
# 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.
|