Communication Rules

Purpose

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

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

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

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

Use concrete statements instead.