Add daily logs and templates for project fidelity

- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps.
- Established a daily logs index for easy navigation of daily notes.
- Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams.
- Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.

workspaces/fidelity/project-knowledge/03-context/process/communication-rules.md

@@ -0,0 +1,64 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-21
+tags: [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
+- Prefer `toggle` over `flag` in Fidelity-facing communication, unless naming a specific external tool concept such as LaunchDarkly feature flags
+- 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.