feat: Organize context files and enhance documentation for clarity and structure
This commit is contained in:
35
ai/context/process/communication.md
Normal file
35
ai/context/process/communication.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Communication Rules
|
||||
|
||||
## Goal
|
||||
|
||||
Make technical communication precise enough for manager updates, Jira notes, standups, and cross-team messages.
|
||||
|
||||
---
|
||||
|
||||
## Required Structure
|
||||
|
||||
When the format fits, prefer:
|
||||
|
||||
1. Context
|
||||
2. Observation
|
||||
3. Action
|
||||
|
||||
---
|
||||
|
||||
## Fidelity-Specific Rules
|
||||
|
||||
- Always clarify authenticated vs non-authenticated when behavior depends on it.
|
||||
- Always separate external issues from regressions.
|
||||
- Always state reproducibility and scope.
|
||||
- Avoid vague phrasing such as:
|
||||
- "same behavior"
|
||||
- "looks fixed"
|
||||
- "working as expected"
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Jeff repeatedly requested polished, explicit wording for PR descriptions, story descriptions, and cross-team messages.
|
||||
- Historical Slack threads show that message quality changed how quickly stories were approved or understood.
|
||||
- Explicit language mattered most when communicating root cause, ownership boundaries, or whether a report was a confirmed regression.
|
||||
33
ai/context/process/context-maintenance.md
Normal file
33
ai/context/process/context-maintenance.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Context Maintenance
|
||||
|
||||
## Goal
|
||||
|
||||
Keep this workspace useful as living memory instead of a pile of disconnected notes.
|
||||
|
||||
---
|
||||
|
||||
## Stable Rules
|
||||
|
||||
- Update canonical context when a durable fact changes.
|
||||
- Prefer correcting stale context over appending contradictory notes.
|
||||
- Use the smallest correct destination:
|
||||
- `ai/logs/YYYY-MM-DD.md` for daily progress and evolving findings
|
||||
- `ai/state/current.md` for near-term active work
|
||||
- `ai/state/work-items.md` for Jira-linked active work
|
||||
- `ai/context/` for durable project knowledge
|
||||
- `ai/context/people/` for named person context
|
||||
|
||||
---
|
||||
|
||||
## Ingestion Rules
|
||||
|
||||
- Treat Mattermost, Slack history, and direct prompts as potential memory sources.
|
||||
- Do not promote failed syncs or tooling errors as project facts.
|
||||
- Promote repeated durable patterns from historical archives into stable context when confidence is high.
|
||||
- Keep old status-only details archive-only unless they still change current understanding.
|
||||
|
||||
---
|
||||
|
||||
## Curation Rule
|
||||
|
||||
- If a new stable context file is added, keep `project.md` and `index.md` aligned so future sessions can discover it quickly.
|
||||
12
ai/context/process/index.md
Normal file
12
ai/context/process/index.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# Process Index
|
||||
|
||||
## Stable Process Guides
|
||||
|
||||
- [communication.md](./communication.md)
|
||||
How to frame technical updates and external communication.
|
||||
|
||||
- [jira-story-rules.md](./jira-story-rules.md)
|
||||
How to create or reference stories with the right scope and precision.
|
||||
|
||||
- [context-maintenance.md](./context-maintenance.md)
|
||||
How this workspace should be kept current as living memory.
|
||||
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