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.

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

@@ -0,0 +1,65 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+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
+- 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.

project-knowledge/03-context/process/communication.md

@@ -0,0 +1,60 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-17
+tags:
+  - process
+  - fidelity
+---
+# Communication Rules
+
+## Goal
+
+Make technical communication precise enough for manager updates, Jira notes, standups, and cross-team messages.
+
+---
+
+## Required Structure
+
+When the format fits, prefer:
+
+1. Context
+2. Observation
+3. Action
+
+---
+
+## Fidelity-Specific Rules
+
+- Always clarify authenticated vs non-authenticated when behavior depends on it.
+- Always separate external issues from regressions.
+- Always state reproducibility and scope.
+- Fidelity Teams consistently displays names in surname-first order.
+- Mattermost is a separate internal communication context; most people visible in Teams are not the same people David interacts with in Mattermost, with Jeff as the main exception.
+- Jeff is the main bridge into the Fidelity-side Teams context.
+- David works on the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
+- Do not write updates as if David is directly embedded in the Fidelity Teams collaboration loop unless the context explicitly says so.
+- When drafting a message David will send to a Fidelity-side contact, do not phrase it as if Jeff is the sender or as if the recipient already knows David through Jeff unless the user explicitly says that framing is desired.
+- Avoid wording like `Jeff mentioned...` in David-to-contact drafts when that would incorrectly imply a shared reporting chain or prior relationship.
+- Keep Jeff's internal process requests separate from David's external message drafts unless the user explicitly wants them surfaced to the recipient.
+- Do not include lines like `I want to document the steps for future cases` in David-to-contact drafts when that motivation is only internal workspace/process context.
+- 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 `project-knowledge/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"
+
+---
+
+## Historical Signals From Slack
+
+- 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.

project-knowledge/03-context/process/index.md

@@ -0,0 +1,31 @@
+---
+type: process-index
+project: fidelity
+status: active
+updated: 2026-04-17
+tags:
+  - process
+  - fidelity
+---
+
+# Process Index
+
+Project-facing process guides for Fidelity work.
+
+Agent operating rules live in `agent-memory/`, not in this project vault.
+
+---
+
+## Guides
+
+- [communication.md](./communication.md)
+  How to frame technical updates and external communication.
+
+- [communication-rules.md](./communication-rules.md)
+  Reusable standards for standups, Jira, and stakeholder updates.
+
+- [jira-story-rules.md](./jira-story-rules.md)
+  How to create or reference stories with the right scope and precision.
+
+- [pull-requests.md](./pull-requests.md)
+  PR template and framing notes for repositories such as `xflow-for-ios`.

project-knowledge/03-context/process/jira-story-rules.md

@@ -0,0 +1,39 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - process
+  - fidelity
+---
+# Jira Story Rules
+
+## Goal
+
+Keep Jira updates precise enough that the story reflects the real problem and remains easy to reference later.
+
+---
+
+## Stable Rules
+
+- Preserve Jira ID and explicit title whenever available.
+- Prefer story wording that describes the real contract or behavior gap, not only the first symptom.
+- Include authenticated-state or environment qualifiers when they materially affect scope.
+- Validate consumer behavior before finalizing scope when the issue depends on Fid4 or flagship.
+
+---
+
+## Story-Creation Guidance
+
+- Create or refine the story after the reproduction path is understood well enough to avoid mis-scoping.
+- Include points and scope only after the work has been framed clearly.
+- If the issue crosses SDK, adapter, FT modules, and consumer app boundaries, the story should say so.
+- If a bug is external or not yet confirmed as regression, avoid writing the ticket as if the root cause is already proven.
+
+---
+
+## Historical Signals From Slack
+
+- Historical Slack threads repeatedly show Jeff refining titles and descriptions before stories were created or shared.
+- Several story discussions centered on making the wording reflect deeper SwiftUI, lifecycle, or integration issues rather than surface symptoms alone.

project-knowledge/03-context/process/pull-requests.md

@@ -0,0 +1,43 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - process
+  - fidelity
+---
+# Pull Requests
+
+## xflow-for-ios PR Template
+
+The `xflow-for-ios` repo PR form uses this structure:
+
+- `## What`
+  - What does the PR do?
+  - Is it a bug fix, new feature, refactor, or something else?
+- `## Why`
+  - Why this PR is needed?
+- `## How`
+  - How is it doing what it does?
+  - How to test, how to integrate, any relevant compromises, etc.?
+- `### Changes details`
+  - bullet list such as `Detail one`, `Detail two`
+- `## Missed anything?`
+  - checklist including:
+    - explained the purpose of the PR
+    - self-reviewed the PR
+    - added or updated test cases
+    - informed of breaking changes, testing, and migrations if applicable
+    - updated documentation if applicable
+    - attached screenshots if applicable
+    - resolved SwiftLint warnings introduced by the commit
+
+## Current Small-Fix Example
+
+For the April 15, 2026 iOS validation fallback fix, the code change is a one-line update in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`:
+
+- before: only `validationDictionary?["validations"]`
+- after: `validationDictionary?["validations"] ?? validationDictionary?["birthDate"]`
+
+This should be framed as a small compatibility bug fix for AO-style payloads, not as a broader Android-parity refactor.