fidelity-ai-workspace/vault/03-context/process/communication-rules.md

type, project, status, updated, tags

type	project	status	updated	tags
process	fidelity	active	2026-04-16	process communication

Communication Rules

Purpose

These rules keep standups, Jira notes, and Mattermost messages aligned with the actual state of the work.

---

Rules

• Prefer explicit scope over short vague statements
• Always mention auth state when it changes reproducibility
• Separate external report from regression
• Say whether behavior was confirmed in main when that comparison exists
• End with the next action when writing status updates
• Distinguish clearly between the current issue, unrelated preexisting bugs, workarounds, and follow-up work
• Prefer evidence-backed statements over intuition when communicating status
• Include branch, build, environment, account, flow, or entry-point details when they materially affect reproduction or ownership
• When reporting several updates for the same Jira item, group them under one top-level JIRA-ID - Title bullet with indented markdown sub-bullets
• Use real flow identifiers and page names when shorthand could be ambiguous
• Route ownership explicitly when the issue belongs to a consumer app, service/configuration, or another framework instead of XFlow
• Do not present a fix as ready if it introduces a new bug or unresolved regression
• Administrative/project-tracking updates should be prompt when others are visibly waiting on them

---

English Quality Rules

• Write in natural, professional US English that sounds like a fluent engineer wrote it
• Prefer direct phrasing over literal or translated-sounding wording
• Avoid unnecessary softeners or filler such as "actually," "I think" or "for now" unless they add real scope or uncertainty
• If the message was originally rough or written by a non-native speaker, rewrite it fully instead of preserving awkward phrasing
• If a sentence can be misunderstood by a manager, stakeholder, or consumer team, rewrite it before sending

---

Repeated Senior Communication Lessons

• Test in the closest real consumer environment first when consumer-specific behavior is under investigation, but use the sample app to rule ownership in or out quickly
• Before escalating or concluding root cause, reduce uncertainty with available evidence: screenshots, videos, logs, code comparison, version checks, and parity checks across web/UIKit/SwiftUI/Fid4
• Keep one issue per update unless a second issue is explicitly called out as separate scope
• If blocked, communicate what was tried, what was ruled out, and the exact remaining question
• Use Context, Observation, Action framing when possible so status is easy to forward without rewriting

---

Avoid

• "same behavior"
• "looks good"
• "seems fixed"
• "working now"
• "it should be fine"
• "for some reason"
• "I think it's fixed" when evidence exists or is needed

Use concrete statements instead.