Files

david.delagneau dbc1894e27 Add project-knowledge structure and templates

- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People."
- Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views.
- Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation.
- Updated scripts and prompts to reflect the new project-knowledge directory structure.
- Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps.
- Ensured all references in workflows and scripts point to the new project-knowledge paths.

2026-04-17 15:52:08 -06:00

2.8 KiB

Raw Blame History

type, project, status, updated, tags

type

project

status

updated

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.

2.8 KiB Raw Blame History