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/04-people/README.md

@@ -0,0 +1,27 @@
+---
+type: people-index
+project: fidelity
+updated: 2026-04-16
+tags:
+  - people
+  - map
+---
+# People Context
+
+Store reusable human context here.
+
+Use this directory for:
+
+- who is who
+- current role ownership
+- communication preferences
+- recurring stakeholders
+- stable relationship between people and project work
+
+Guidelines:
+
+- use one file per named person when that person matters repeatedly
+- keep `manager.md` as the role mapping for the current active manager
+- keep `index.md` as the quick roster for the active project
+- do not put secrets here
+- do not invent roles; use qualifiers when uncertain

vault/04-people/aylwing-olivas.md

@@ -0,0 +1,34 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Aylwing Olivas
+
+## Role
+
+Repeated Fidelity collaborator visible across multiple historical Slack channels.
+
+---
+
+## Known Context
+
+- Appears in technical discussions about XFlow, SwiftUI limitations, navigation architecture, and dependency risk
+- Surfaces cross-team constraints such as security or token access issues affecting pipeline work
+- Frequently adds architectural framing rather than only status updates
+- Often reframes implementation problems at the architecture/system-design level rather than the ticket level
+- Repeatedly advised on state machines, navigation architecture, off-screen rendering, and long-term maintainability tradeoffs
+- Common escalation point when the team needs a technical sounding board or higher-level design critique
+
+---
+
+## Guidance
+
+- Treat Aylwing as a useful source for higher-level technical framing and dependency risk context
+- Treat Aylwing as a strong reviewer for architecture direction, refactor scope, and risk framing
+- If future context clarifies the formal team or title, update this file directly

vault/04-people/bruce-meeks.md

@@ -0,0 +1,31 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Bruce Meeks
+
+## Role
+
+Repeated Fidelity collaborator in XFlow-related work.
+
+---
+
+## Known Context
+
+- Reviewed and approved XFlow work repeatedly in historical threads
+- Sometimes covered XFlow iOS issues while others were unavailable
+- Later context suggests Bruce primarily worked on Android while still remaining a useful cross-platform contact
+- Relevant in release coordination, PR review, and parity discussions between iOS and Android
+
+---
+
+## Guidance
+
+- Treat Bruce as a useful source for cross-platform context and historical PR/review state
+- If future context clarifies the formal role/team, update this file directly

vault/04-people/david-delagneau.md

@@ -0,0 +1,33 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# David Delagneau
+
+## Role
+
+Repeated Fidelity collaborator in historical Slack threads.
+
+---
+
+## Known Context
+
+- Appears heavily in pipeline, Jenkins, SonarQube, test-reporting, and release-process work
+- Later historical activity also includes Sparta SDK proof-of-concept implementation and framework setup work
+- Often provides implementation updates, process notes, and operational debugging context to Jeff
+- Frequently handled CI/CD, Jenkins, reporting, and repo/setup tasks while Norman focused on SDK and consumer debugging
+- Later archive activity shows him taking lead on SpartaSDK setup, JSON decoding, and repo/bootstrap work
+
+---
+
+## Guidance
+
+- Treat David as a relevant source for CI/CD, release-process, and framework-setup context
+- Treat David as especially relevant for Jenkins, SonarQube, Pod/repo setup, and Sparta SDK bootstrapping context
+- If future context clarifies the formal role or team, update this file directly

vault/04-people/derian-cordoba.md

@@ -0,0 +1,33 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Derian Cordoba
+
+## Role
+
+Historical Fidelity collaborator in project support discussions.
+
+---
+
+## Known Context
+
+- Appears in historical pipeline, Jenkins, and documentation conversations
+- Helped document pipeline work and supported notification/credential troubleshooting
+- Collaboration signal is real but current formal role remains unclear from the archive
+- Often paired with David on CI/CD and notification-related work
+- Showed up when the team needed operational documentation, release-process notes, or pipeline triage support
+
+---
+
+## Guidance
+
+- Treat Derian as a relevant collaborator for historical pipeline/debugging context
+- Treat Derian as most relevant for historical CI/CD coordination and documentation support
+- If future context clarifies the formal role or team, update this file directly

vault/04-people/erik-reynolds.md

@@ -0,0 +1,34 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Erik Reynolds
+
+## Role
+
+Historical Fidelity collaborator in XFlow-related discussions.
+
+---
+
+## Known Context
+
+- Appears in discussions about XFlow manager behavior, consumer-vs-framework boundaries, and migration constraints
+- Raises implementation and sizing concerns in architecture-heavy conversations
+- Often comments on where responsibility lies between XFlow and consuming teams
+- Deep archive signal suggests strong familiarity with XFlow and Apex internals, especially ownership boundaries and migration tradeoffs
+- Often challenged weak assumptions about architecture, sizing, and framework responsibilities
+- Useful source when deciding whether a problem belongs in XFlow, Apex, or the consumer app
+
+---
+
+## Guidance
+
+- Treat Erik as a relevant source when historical context touches XFlow ownership boundaries or migration difficulty
+- Treat Erik as a high-signal source for framework architecture and responsibility boundaries
+- If future context clarifies the formal role or team, update this file directly

vault/04-people/gurram-santosh.md

@@ -0,0 +1,35 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Gurram Santosh
+
+## Role
+
+Project-related contact involved in issue discussions.
+
+The exact formal role is not yet confirmed in workspace memory.
+
+---
+
+## Known Context
+
+- Repeatedly appears in AO-related testing, screenshot validation, and issue verification conversations
+- Often serves as a consumer-side validator or reporter when the team needs confirmation that a fix worked in their environment
+- Relevant when tracking whether an issue still reproduces, whether a release build contains a fix, or whether additional consumer validation is needed
+
+---
+
+## Guidance
+
+If future communication makes Santosh's role explicit, update this file with:
+
+- team or function
+- relationship to Fidelity work
+- whether the person is a reporter, tester, partner, or stakeholder

vault/04-people/index.md

@@ -0,0 +1,61 @@
+---
+type: people-index
+project: fidelity
+updated: 2026-04-16
+tags:
+  - people
+  - map
+---
+# People Index
+
+## Active Roles
+
+- Manager: [jeff-dewitte.md](./jeff-dewitte.md)
+
+## Known People
+
+- [jeff-dewitte.md](./jeff-dewitte.md)
+  Current direct manager for the active Fidelity project; repeated communication gatekeeper and scope shaper in historical XFlow work.
+
+- [norman-arauz.md](./norman-arauz.md)
+  Frequent XFlow collaborator in historical Slack threads; primary implementer/investigator across SwiftUI, AO/Fid4 bugs, and release work.
+
+- [david-delagneau.md](./david-delagneau.md)
+  Repeated historical collaborator on pipeline, CI/CD, and Sparta/SwiftUI proof-of-concept work, especially around Jenkins, reporting, and framework setup.
+
+- [bruce-meeks.md](./bruce-meeks.md)
+  Repeated XFlow collaborator who often reviewed PRs, covered iOS work during absences, and later shifted primarily toward Android.
+
+- [jason-mandozzi.md](./jason-mandozzi.md)
+  Repeated collaborator tied to XFlowViewMaker, FTPlanning/Fid4 integration, release support, and major architectural transitions.
+
+- [aylwing-olivas.md](./aylwing-olivas.md)
+  Repeated historical collaborator who surfaces architectural concerns, SwiftUI constraints, and cross-team dependency risks.
+
+- [erik-reynolds.md](./erik-reynolds.md)
+  Historical collaborator focused on XFlow manager behavior, integration boundaries, migration effort sizing, and framework responsibility boundaries.
+
+- [gurram-santosh.md](./gurram-santosh.md)
+  AO-related contact who often validates fixes or confirms whether issues still reproduce in consumer environments.
+
+- [raj-sundararaj.md](./raj-sundararaj.md)
+  Repeated collaborator involved in AO issue triage, release coordination, and backlog/story management around XFlow work.
+
+- [quy-mai.md](./quy-mai.md)
+  Scrum/contact point who repeatedly managed backlog state, points, and closure expectations for Fidelity work.
+
+- [tim-longfield.md](./tim-longfield.md)
+  FTPlanning-side contact relevant when issues crossed from XFlow into consumer-framework ownership.
+
+- [derian-cordoba.md](./derian-cordoba.md)
+  Historical collaborator in pipeline and documentation work, especially around CI/CD support and operational notes.
+
+## Usage
+
+When a person appears repeatedly in project communication, create or update their file here so the agent can reuse:
+
+- name
+- role
+- relationship to the project
+- communication expectations
+- important context about how they influence work

vault/04-people/jason-mandozzi.md

@@ -0,0 +1,31 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Jason Mandozzi
+
+## Role
+
+Repeated Fidelity collaborator in XFlow and consumer-integration work.
+
+---
+
+## Known Context
+
+- Closely associated with XFlowViewMaker, Fid4/FTPlanning integration, and release/version work
+- Frequently authored or owned implementation branches later reviewed by others
+- Showed up repeatedly in architecture, eventing, navigation, and consumer-facing integration discussions
+- Often served as an important source of context on historical implementation choices inside XFlow and related consumer flows
+
+---
+
+## Guidance
+
+- Treat Jason as a high-signal source for XFlowViewMaker and consumer integration history
+- If future context clarifies the formal role/team, update this file directly

vault/04-people/jeff-dewitte.md

@@ -0,0 +1,74 @@
+---
+type: person
+project: fidelity
+role: manager
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Jeff DeWitte
+
+## Role
+
+Current direct manager for the active Fidelity project.
+
+---
+
+## Historical Collaboration Pattern
+
+- Repeatedly acted as reporting manager, reviewer, and communication gatekeeper across multi-year XFlow work
+- Frequently rewrote PR descriptions, Jira updates, and cross-team messages before they were sent
+- Regularly redirected work based on release risk, consumer pressure, or manager/stakeholder expectations
+- Often pushed for explicit distinction between framework bugs, consumer bugs, service issues, and scope creep
+
+---
+
+## Communication Requirements
+
+- Native US English
+- Prefers clear, concise updates
+- Needs accurate scope, not vague reassurance
+- Frequently asks for precise reproducibility, auth context, and regression scope
+
+---
+
+## What Good Updates Include
+
+1. Context
+2. Observation
+3. Action
+
+Good updates usually clarify:
+
+- what issue or task is being discussed
+- whether the behavior is reproducible
+- whether auth state matters
+- whether this looks like an external issue or a regression
+- what the next step is
+
+---
+
+## Influence On Work
+
+- Story titles, points, and scope discussions with Jeff are often worth remembering
+- Jeff approvals can change what belongs in current state or work-item memory
+- Jeff feedback is often a signal to tighten wording before communicating externally
+- Jeff often asks for evidence, reproduction detail, and exact next action before approving external communication
+- If a draft is still ambiguous, Jeff may prefer to rewrite it directly so the external version is unambiguous and does not generate avoidable follow-up
+
+---
+
+## Repeated Coaching / Expectations
+
+- Test in the closest real consumer environment first when the issue is consumer-specific; use sample app mainly to rule ownership in or out
+- Do not open or socialize a PR as "ready" until the issue is fully resolved and no obvious follow-up bug has been introduced
+- Separate current-ticket scope from unrelated preexisting bugs; do not blur them in standups or status updates
+- Be explicit about environment, branch/build/version, account, flow entry point, and repro steps before concluding where a bug belongs
+- When blocked, keep reducing uncertainty with other available evidence sources instead of waiting passively
+- Fast admin/process actions matter: update Jira/status/comments promptly when others are visibly waiting on them
+- Prefer evidence-heavy communication: screenshots, videos, exact error text, branch/version, and direct comparisons to main/web/UIKit/Fid4 when relevant
+- Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
+- When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow
+- For cross-team status messages, make the sequence of events extremely explicit so the reader can tell what was the original issue, what changed, what XFlow changed, and what remains a separate service-side issue

vault/04-people/manager.md

@@ -0,0 +1,40 @@
+---
+type: person
+project: fidelity
+role: manager
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Manager
+
+## Current Holder
+
+- Name: Jeff DeWitte
+- Profile: [jeff-dewitte.md](./jeff-dewitte.md)
+
+---
+
+## Role
+
+Direct supervisor or primary reporting manager for the active project.
+
+---
+
+## Usage
+
+This file maps the current project role to the actual person.
+
+If the active manager changes in a future project, update this file to point to the new person while preserving their person-specific profile separately.
+
+---
+
+## Default Communication Requirements
+
+- Clear written English
+- Concise updates
+- Explicit scope
+- No vague reassurance
+- Useful next action when relevant

vault/04-people/norman-arauz.md

@@ -0,0 +1,32 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Norman Arauz
+
+## Role
+
+Frequent Fidelity/XFlow engineer collaborator in historical Slack threads.
+
+---
+
+## Known Context
+
+- Repeated day-to-day implementer/investigator across XFlow SwiftUI, AO/Fid4 bugs, version bumps, analytics, and pipeline debugging
+- Often coordinated with Jeff on scope, descriptions, approvals, and manager-ready wording
+- Frequently investigated consumer-reported issues directly in Fid4 and sample-app parity checks
+- Often produced detailed technical findings first, then asked Jeff to polish or approve external wording
+- Exact formal role may need confirmation if used outside workspace memory
+
+---
+
+## Guidance
+
+- Treat Norman as a strong source for historical implementation detail, reproduction findings, and release-process context
+- If later communication clarifies the formal team/title, update this file directly

vault/04-people/quy-mai.md

@@ -0,0 +1,31 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Quy Mai
+
+## Role
+
+Confirmed Scrum Master / contact point repeatedly involved in backlog and process management.
+
+---
+
+## Known Context
+
+- Repeatedly asked for clearer Jira/state management, points, and backlog hygiene
+- Often confirmed whether work should remain in backlog, be canceled, or be reframed as separate stories
+- Relevant for sprint structure, story cleanup, and expectation-setting around what counts as production or release-priority work
+
+---
+
+## Guidance
+
+- Treat Quy as an important source for process expectations, backlog cleanup, and story framing
+- When drafting notes or prompts, refer to Quy as Scrum Master rather than a generic stakeholder
+- If future context clarifies the formal title/team, update this file directly

vault/04-people/raj-sundararaj.md

@@ -0,0 +1,30 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Raj Sundararaj
+
+## Role
+
+Repeated Fidelity collaborator involved in project coordination and active issue triage.
+
+---
+
+## Known Context
+
+- Repeatedly surfaced or assigned XFlow/AO issues and asked for current status
+- Involved in release coordination, validation follow-up, and backlog movement
+- Relevant when the team needed to align issue ownership, repro state, or urgency with consumer-side expectations
+
+---
+
+## Guidance
+
+- Treat Raj as a useful contact for issue routing, AO coordination, and release follow-up
+- If future context clarifies the formal role/team, update this file directly

vault/04-people/tim-longfield.md

@@ -0,0 +1,30 @@
+---
+type: person
+project: fidelity
+role: collaborator
+status: active
+updated: 2026-04-16
+tags:
+  - person
+  - fidelity
+---
+# Tim Longfield
+
+## Role
+
+FTPlanning-side collaborator relevant to cross-framework issue ownership.
+
+---
+
+## Known Context
+
+- Appeared when issues first thought to be XFlow bugs were traced into FTPlanning
+- Relevant contact for whether a transfer/add-money bug belonged to FTPlanning instead of XFlow
+- Useful when a consumer-side framework fix was needed before XFlow could close validation work
+
+---
+
+## Guidance
+
+- Treat Tim as a relevant contact for FTPlanning-owned fixes and cross-team validation
+- If future context clarifies the formal role/team, update this file directly