feat: Organize context files and enhance documentation for clarity and structure

This commit is contained in:
2026-04-10 08:57:00 -06:00
parent 26f54ed302
commit ae9e69bd4b
38 changed files with 620 additions and 71 deletions

View 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.

View 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.

View 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.

View 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.