Add daily logs and templates for Fidelity project

- Created daily log entries for April 13-16, 2026, capturing standup contexts, Mattermost syncs, and ongoing work items.
- Established a daily logs index for easy navigation of daily entries.
- Introduced templates for daily notes, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Developed maps for AI workspace core, current work, Fidelity domain, and work items to enhance workspace navigation.
- Implemented base configurations for daily notes, decisions, people, systems, work items, and workstreams to streamline data management.
- Added a placeholder for attachments to facilitate file organization.

vault/03-context/process/agent-memory-rules.md

@@ -0,0 +1,182 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags: [process, memory, agent]
+---
+
+# Agent Memory Rules
+
+## Goal
+
+Make workspace memory maintenance part of the agent's normal job, not a separate optional workflow.
+
+---
+
+## Default Agent Behavior
+
+For any meaningful prompt, the agent should decide whether the interaction changes project memory.
+
+This applies to:
+
+- direct user prompts
+- Mattermost sync results
+- translated notes
+- standup generation
+- manager-update drafting
+- debugging discussions
+- corrections to previous understanding
+
+The agent should not wait for a separate promotion command when the right update is already clear.
+
+---
+
+## What Counts As Memory-Worthy
+
+Capture information automatically when it is:
+
+- project-relevant
+- explicit enough to preserve safely
+- likely to matter in a future session
+- useful for standups, debugging, or supervisor communication
+
+Examples:
+
+- confirmed story creation, points, scope, or priority
+- confirmed reproduction constraints
+- newly clarified root cause framing
+- approved manager guidance that changes work direction
+- confirmed version, dependency, or rollout facts tied to current work
+- corrections to previously stored project context
+- repeated named people with stable roles or communication relevance
+- repeated named people with multi-channel, multi-year, or high-signal technical/process involvement even when the exact formal role is still unknown
+
+---
+
+## What The Agent Must Do
+
+When new memory-worthy information appears, the agent should:
+
+1. decide whether it is daily, current-state, durable, or decision-level context
+2. update the smallest correct set of files
+3. correct stale or conflicting existing statements
+4. answer the user using the refreshed context
+
+Do not ask the user what to promote unless the ambiguity is real and material.
+
+---
+
+## Tooling Self-Maintenance
+
+User corrections about how the workspace should behave are memory-worthy when they affect future output.
+
+If a correction applies to a command, prompt, skill, agent, or reusable rule, update the linked tool directly instead of only logging the correction.
+
+Examples:
+
+- A standup formatting correction should update `prompts/standup.md` and `.opencode/commands/standup.md`.
+- A Mattermost freshness correction should update the Mattermost command/plugin instructions.
+- A Copilot prompt-structure correction should update `prompts/copilot-prompt.md`, `.opencode/commands/copilot-prompt.md`, or the Copilot skill.
+- A Swift answer-quality correction should update the relevant iOS skill or `vault/03-context/ios/` guidance.
+
+Keep the daily log as evidence of what happened, but make the reusable behavior live in the file that controls that behavior.
+
+---
+
+## File Selection
+
+### `vault/06-daily/YYYY-MM-DD.md`
+
+Default destination for:
+
+- same-day progress
+- same-day findings
+- scoped reproduction notes
+- story and approval movement
+- context that is important now but may evolve later
+
+### `vault/01-current/current-work.md`
+
+Use when the fact changes the active work window, including:
+
+- current priorities
+- currently active story scope
+- current blockers or debugging constraints
+- manager direction that changes the next few days of work
+
+### `vault/02-work-items/*.md` and `vault/01-current/work-items.md`
+
+Use `vault/02-work-items/*.md` as the canonical memory for current Jira-linked work that should remain easy to reference across sessions, especially:
+
+- Jira IDs
+- approved or explicit titles
+- currently relevant status notes
+- current points or scope notes
+
+Use `vault/01-current/work-items.md` as the summary view of what is active now.
+
+These files should help standups and manager updates mention work items precisely.
+
+### `vault/03-context/project.md`
+
+Use for durable project knowledge that should survive beyond the current work window.
+
+### `vault/04-people/manager.md`
+
+Use only when a communication preference or manager expectation becomes stable enough to reuse repeatedly.
+
+### `vault/04-people/index.md` and `vault/04-people/*.md`
+
+Use these files for:
+
+- mapping roles to actual people
+- keeping named stakeholders recognizable across sessions
+- storing stable communication or responsibility context per person
+
+When the role is not explicit, store:
+
+- where the person tends to appear
+- what kinds of topics they influence
+- how they affect approvals, scope, debugging, or communication
+
+### `vault/05-decisions/*.md`
+
+Use for explicit confirmed decisions with ongoing impact.
+
+### `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, `vault/00-start/`, and `vault/03-context/process/`
+
+Use these when the new information changes how the workspace should operate:
+
+- command invocation behavior
+- reusable output format
+- default agent behavior
+- specialized skill workflow
+- persistent process or memory rules
+
+Do not create a separate note when an existing command, prompt, agent, or skill is the source of truth.
+
+---
+
+## What Not To Store
+
+Do not store:
+
+- tool failures
+- sync attempts
+- generic urgency messages
+- duplicate paraphrases of the same fact
+- weak guesses
+- operational chatter that does not change project understanding
+
+---
+
+## Correction Rule
+
+If new information supersedes old memory:
+
+- update the existing canonical file
+- do not leave stale and corrected versions side by side
+- preserve qualifiers if the fact is only partially confirmed
+
+The agent should behave like a senior engineer maintaining project notes, not like a chat assistant accumulating transcripts.

vault/03-context/process/ai-to-ai-prompting.md

@@ -0,0 +1,78 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - process
+  - fidelity
+---
+# AI-To-AI Prompting
+
+## Goal
+
+Generate prompts that can be sent to another AI assistant on the Fidelity development machine, especially GitHub Copilot.
+
+---
+
+## Operating Assumption
+
+This workspace does not contain the product codebase. The target AI has access to the Fidelity codebase on another machine.
+
+Therefore prompts must:
+
+- include only the relevant project context from this workspace
+- tell the target AI what files/modules to inspect
+- ask for a concrete output
+- specify constraints and non-goals
+- avoid pretending the target AI already has this workspace memory
+
+---
+
+## Prompt Structure
+
+Use this structure by default:
+
+1. Role
+2. Project context
+3. Current task
+4. Relevant ticket/context
+5. Files/modules to inspect
+6. Constraints
+7. Expected output
+8. Validation requirements
+
+---
+
+## Prompt Quality Rules
+
+- Prefer precise task framing over long background dumps.
+- Include Jira ID and title when the work maps to a ticket.
+- Include current constraints such as REST feature flag, GraphQL fallback, auth state, backend-driven behavior, and consumer validation when relevant.
+- Ask the target AI to inspect code before proposing changes.
+- Ask for a plan first when the implementation scope is uncertain.
+- Ask for code changes only when the desired write scope is clear.
+- Include "Do not assume REST is active by default" for REST migration tasks.
+- Include "Separate external issue from regression" for AO/Discourse issues.
+- Include "Validate against Fid4/consumer path when needed" for XFlow integration tasks.
+
+---
+
+## Bad Prompt Pattern
+
+"Fix this issue in XFlow."
+
+Why bad:
+
+- no entry point
+- no auth state
+- no expected behavior
+- no ticket context
+- no validation path
+- no scope boundary
+
+---
+
+## Good Prompt Pattern
+
+"You are working in the Fidelity iOS codebase. Inspect the XFlowSDK and XFlowViewMaker integration path for `PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`. First identify where XFlow currently exposes SwiftUI through `UIHostingController`, where XFlowViewMaker consumes it, and what feature flag protects the migration path. Do not change code yet. Return a concise plan with affected files, risks, consumer validation needs in Fid4/FTTransfer, and any questions that block implementation."

vault/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.

vault/03-context/process/communication.md

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

vault/03-context/process/context-maintenance.md

@@ -0,0 +1,46 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - process
+  - fidelity
+---
+# Context Maintenance
+
+## Goal
+
+Keep this workspace useful as living memory instead of a pile of disconnected notes.
+
+---
+
+## Stable Rules
+
+- Update canonical context when a durable fact changes.
+- Prefer correcting stale context over appending contradictory notes.
+- Use the smallest correct destination:
+  - `vault/06-daily/YYYY-MM-DD.md` for daily progress and evolving findings
+  - `vault/01-current/current-work.md` for near-term active work
+  - `vault/02-work-items/*.md` for canonical Jira-linked active work
+  - `vault/01-current/work-items.md` for the compact active-work summary
+  - `vault/03-context/` for durable project knowledge
+  - `vault/04-people/` for named person context
+  - `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, `vault/00-start/`, or `vault/03-context/process/` for reusable behavior rules that control how the workspace responds
+
+---
+
+## Ingestion Rules
+
+- Treat Mattermost, Slack history, and direct prompts as potential memory sources.
+- Do not promote failed syncs or tooling errors as project facts.
+- Promote repeated durable patterns from historical archives into stable context when confidence is high.
+- Keep old status-only details archive-only unless they still change current understanding.
+- Treat user corrections about command output, prompt structure, memory handling, or agent behavior as inputs to the operational surface, not just as daily notes.
+
+---
+
+## Curation Rule
+
+- If a new stable context file is added, keep `project.md` and `index.md` aligned so future sessions can discover it quickly.
+- If a new rule affects a slash command or reusable prompt, update that command or prompt directly so the behavior changes on the next run.

vault/03-context/process/index.md

@@ -0,0 +1,39 @@
+---
+type: process-index
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - process
+  - fidelity
+---
+# Process Index
+
+## Stable Process Guides
+
+- [communication.md](./communication.md)
+  How to frame technical updates and external communication.
+
+- [ai-to-ai-prompting.md](./ai-to-ai-prompting.md)
+  How to generate prompts for GitHub Copilot or another AI on the Fidelity development machine.
+
+- [jira-story-rules.md](./jira-story-rules.md)
+  How to create or reference stories with the right scope and precision.
+
+- [context-maintenance.md](./context-maintenance.md)
+  How this workspace should be kept current as living memory.
+
+- [workspace-model.md](./workspace-model.md)
+  How the companion AI workspace separates runtime, evidence, and canonical memory.
+
+- [agent-memory-rules.md](./agent-memory-rules.md)
+  Default memory-maintenance behavior for agents.
+
+- [memory-promotion-rules.md](./memory-promotion-rules.md)
+  How evidence becomes daily, current, work-item, stable-context, people, or decision memory.
+
+- [communication-rules.md](./communication-rules.md)
+  Reusable communication standards for standups, Jira, and stakeholder updates.
+
+- [pull-requests.md](./pull-requests.md)
+  PR template and framing notes for repositories such as `xflow-for-ios`.

vault/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.

vault/03-context/process/memory-promotion-rules.md

@@ -0,0 +1,146 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags: [process, memory, promotion]
+---
+
+# Memory Promotion Rules
+
+## Goal
+
+Keep workspace memory current automatically without asking the user what to promote after every successful sync.
+
+---
+
+## Default Rule
+
+When new Mattermost context is explicit, project-relevant, and high-confidence, promote it automatically.
+
+Do not ask for promotion confirmation by default.
+
+If a fact is ambiguous, skip it or keep it only in the daily log with appropriate qualifiers.
+
+---
+
+## File Selection
+
+### Promote to `vault/06-daily/YYYY-MM-DD.md`
+
+Use the daily log for:
+
+- concrete same-day work updates
+- story creation, sizing, approval, and scope updates
+- manager-approved wording or root-cause framing tied to current work
+- confirmed version checks tied to active work
+- reproduction findings that are useful now but may still evolve
+
+Daily logs are the default destination for most promoted Mattermost facts.
+
+### Promote to `vault/01-current/current-work.md`
+
+Use current state only for facts that materially affect active work over the next few days, such as:
+
+- approved active story scope
+- confirmed current debugging constraints
+- current reproduction conditions that change how the work is approached
+- near-term priorities confirmed by manager communication
+
+Do not copy every daily update into current state.
+
+### Promote to `vault/02-work-items/*.md` and `vault/01-current/work-items.md`
+
+Use `vault/02-work-items/*.md` for:
+
+- explicit Jira IDs
+- approved or explicit story titles
+- current story points
+- current scope notes
+- active status notes that still matter for future updates
+
+If a Jira item is likely to appear again in standups or manager updates, it belongs here.
+
+Use `vault/01-current/work-items.md` as the compact summary of which ticket files are active.
+
+### Promote to `vault/03-context/project.md`
+
+Use project context only for durable project knowledge that should survive beyond the current work window, such as:
+
+- stable architecture constraints
+- recurring debugging truths
+- persistent testing limitations
+- enduring behavior of REST, GraphQL, XFlow, auth, or entry points
+
+Do not promote story-specific daily movement into project context unless it changes durable project understanding.
+
+### Promote to `vault/05-decisions/*.md`
+
+Use decisions only for explicit confirmed decisions with medium or long-term impact.
+
+### Promote to `vault/04-people/index.md` and `vault/04-people/*.md`
+
+Use these files when:
+
+- a person's identity matters repeatedly
+- a role becomes associated with a specific person
+- a stakeholder's communication or approval patterns affect future work
+- a human appears across multiple channels or years with repeated technical, process, or approval signal
+- the archive makes the collaboration pattern clear even if the formal title is still unknown
+
+Prefer:
+
+- `manager.md` for role mapping
+- `index.md` for active roster
+- one file per person for person-specific context
+
+If exact role confidence is low, store the person's repeated project relationship instead of inventing a title.
+
+---
+
+## Do Not Promote
+
+Do not record these as project memory:
+
+- tooling activity
+- sync status
+- missing dependencies
+- empty inbox situations
+- reminders or urgency without project substance
+- unapproved drafts
+- generic chat noise
+
+---
+
+## Confidence Rules
+
+Auto-promote when the signal is high-confidence, for example:
+
+- the manager explicitly approves something
+- a Jira story number, title, points, or scope is explicitly confirmed
+- a version is stated directly and tied to the active project
+- a reproduction condition is clearly stated with scope qualifiers
+
+If confidence is mixed:
+
+- prefer the daily log
+- preserve qualifiers such as "appears", "currently", or "for authenticated users"
+- avoid promoting to stable project context
+
+---
+
+## Example Policy
+
+Given Mattermost updates like:
+
+- PDIAP-15836 created and sized at 8 points
+- the manager approved a story title
+- REST-removal scope was approved
+- XFlowViewMaker 0.5.0 is already in Fid4
+- AO DOB validation issue appears auth-only in TeenIdentityCheck
+
+Automatic behavior should be:
+
+- add all of them to today's log if they are relevant to today's work
+- promote only the currently actionable subset to `vault/01-current/current-work.md`
+- keep story-specific details out of `vault/03-context/project.md` unless they reveal a durable project rule

vault/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.

vault/03-context/process/workspace-model.md

@@ -0,0 +1,57 @@
+---
+type: process
+project: fidelity
+status: active
+updated: 2026-04-16
+tags: [process, workspace, memory]
+---
+
+# Workspace Model
+
+## Purpose
+
+This repository is a support workspace, not the implementation repository.
+
+It now has two layers:
+
+- `core/` contains reusable project-independent operating rules
+- `profiles/<project>/` contains project-specific configuration and assumptions
+
+---
+
+## What belongs here
+
+- daily logs
+- communication context
+- manager update drafts
+- stable project knowledge
+- debugging summaries
+- reusable command, prompt, skill, and agent rules that make the workspace behave consistently
+- project profiles that configure the reusable core for a specific project
+- optional navigation notes and portable Obsidian configuration
+
+---
+
+## What does not belong here
+
+- product source code
+- assumptions about code changes not yet verified
+- statements that imply work was executed from this machine unless explicitly true
+- Obsidian local layout, plugin cache, or runtime state
+
+---
+
+## Operational Surface
+
+When the user corrects a recurring behavior, the workspace should update the file that controls that behavior:
+
+- `core/` for reusable project-independent behavior
+- `profiles/<project>/` for project-specific assumptions
+- `vault/.obsidian/` only for portable vault configuration, not project memory
+- `.opencode/commands/` for slash commands
+- `prompts/` for reusable drafting templates
+- `.opencode/agents/` and `ai/AGENTS.md` for default agent behavior
+- `.opencode/skills/` for specialized workflows
+- `vault/00-start/` and `vault/03-context/process/` for durable process rules
+
+Daily logs can preserve evidence, but they should not be the only place where a reusable behavior rule lives.