Communication Rules

Goal

Make technical communication precise enough for manager updates, Jira notes, standups, and cross-team messages.

When the format fits, prefer:

Always clarify authenticated vs non-authenticated when behavior depends on it.
Always separate external issues from regressions.
Always state reproducibility and scope.
For standups, report the previous workday context, not blindly the prior calendar day.
On Mondays, use Friday's work context unless a later prior day has Mattermost activity.
If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity.
For standups, when a Jira item has multiple concrete updates, use one top-level JIRA-ID - Title bullet and indented markdown sub-bullets instead of repeating the same Jira line.
When a flow/page shorthand could be ambiguous, prefer the real flow identifier and page name from vault/03-context/workstreams/flow-page-references.md.
For standups that may also be sent to Teams, prefer plain audience-friendly wording over internal implementation shorthand; avoid terms like fallback unless the audience already has the necessary context.
When a release is waiting on approvals or pipeline movement, make the concurrent work explicit so the update does not imply idle waiting.
Avoid vague phrasing such as:
- "same behavior"
- "looks fixed"
- "working as expected"

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.