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/systems/almx-toolbox.md

@@ -0,0 +1,40 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - ALMx Toolbox
+  - ALMx - Toolbox
+---
+
+# ALMx Toolbox
+
+## Role
+
+- Internal tool from the Fidelity app/bookmark set, likely tied to ALM/process workflows.
+
+---
+
+## Stable Patterns
+
+- Base note only; add confirmed responsibilities and common tasks gradually.
+
+---
+
+## Risks
+
+- The name suggests process tooling, but exact ownership and usage are still unknown.
+
+---
+
+## Related Context
+
+- `trackit.md`

workspaces/fidelity/project-knowledge/03-context/systems/artifactory.md

@@ -0,0 +1,54 @@
+---
+type: system
+project: fidelity
+status: active
+systems:
+  - xflowsdk
+  - xflowviewmaker
+  - fid4
+workstreams:
+  - consumer-integration
+people: []
+related:
+  - consumer-integration
+  - xflowsdk
+  - xflowviewmaker
+  - fid4
+  - iosinstaller
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - artifactory.fmr.com
+---
+
+# Artifactory
+
+## Role
+
+- Internal artifact distribution system used in the Fidelity release path.
+- Known to be part of XFlowSDK/XFlowViewMaker publication and consumer-build inspection workflows.
+
+---
+
+## Stable Patterns
+
+- Stores or exposes build artifacts that help verify what was published or shipped.
+- This is a base note; add repository names, navigation tips, and common artifact paths gradually.
+
+---
+
+## Risks
+
+- Artifact presence alone does not prove downstream consumer adoption.
+
+---
+
+## Related Context
+
+- `xflowsdk.md`
+- `xflowviewmaker.md`
+- `fid4.md`
+- `iosinstaller.md`
+- `../workstreams/consumer-integration.md`

workspaces/fidelity/project-knowledge/03-context/systems/cogstore.md

@@ -0,0 +1,42 @@
+---
+type: system
+project: fidelity
+status: active
+workstreams:
+  - ao-discourse
+  - xflow-debugging
+related:
+  - xflowsdk
+  - fid4
+  - pdiap-15765
+updated: 2026-04-16
+tags:
+  - system
+  - fidelity
+aliases:
+  - CogStore
+  - XFlow Home CCP CogStore
+---
+# CogStore
+
+## Role
+
+Cogstore is an important Fidelity platform used to manage and publish many flow configuration definitions, each with its own independent version history.
+
+---
+
+## Confirmed Context
+
+- In the Fidelity flow-config workflow, Cogstore is used to modify and publish individual flow definitions.
+- Cogstore tracks versions per flow definition rather than as one single platform-wide version.
+- Cogstore can be used to compare changes between flow-definition versions, similar to a Git-style diff.
+- Cogstore can be used to check which version of a specific flow definition is published in environments such as QA and Production, including who published it and when.
+- On April 16, 2026, David used Cogstore to confirm that the relevant flow-definition change tied to Rashmi's service-side update was present in QA as version `0.0.142`, while Production was still on `0.0.133`.
+
+---
+
+## Related Context
+
+- Jeff indicated on April 15, 2026 that Slate had been used by newer consumer services during the SwiftUI refactor, but is now believed to be decommissioned.
+- Because service/configuration changes can be environment-specific and versioned per flow, Cogstore should be checked before concluding that a payload/config change is live in Production.
+- Flow IDs are not guaranteed to exist in both Cogstore and Slate. When tracing a specific flow definition, confirm which configuration system actually owns that flow instead of assuming the same ID will appear in both places.

workspaces/fidelity/project-knowledge/03-context/systems/confluence.md

@@ -0,0 +1,39 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: [consumer-integration]
+people: []
+related: [jira]
+tags:
+  - system
+  - fidelity
+updated: 2026-04-20
+---
+
+# Confluence
+
+## Role
+
+- Internal documentation/wiki surface used across Fidelity workflows.
+- Commonly paired with Jira in the Fidelity-side delivery process, but Jira is the more central day-to-day work-tracking tool.
+
+---
+
+## Stable Patterns
+
+- Likely useful for process docs, onboarding docs, and cross-team references.
+- Base note only; add important spaces/pages gradually.
+
+---
+
+## Risks
+
+- Documentation can drift from current implementation reality.
+
+---
+
+## Related Context
+
+- `../workstreams/consumer-integration.md`

workspaces/fidelity/project-knowledge/03-context/systems/discourse.md

@@ -0,0 +1,39 @@
+---
+type: system
+project: fidelity
+status: active
+systems: [fid4, xflowsdk]
+workstreams: [ao-discourse]
+people: []
+related: [ao-discourse, fid4, xflowsdk]
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+---
+
+# Discourse
+
+## Role
+
+- External issue/reporting surface that appears in Fidelity debugging and communication workflows.
+
+---
+
+## Stable Patterns
+
+- Often paired with Jira comments and follow-up communication when clarifying issue scope.
+- Base note only; add exact ownership boundaries and triage patterns gradually.
+
+---
+
+## Risks
+
+- External reports can be incomplete, non-reproducible, or not true regressions.
+
+---
+
+## Related Context
+
+- `../workstreams/ao-discourse.md`
+- `fid4.md`

workspaces/fidelity/project-knowledge/03-context/systems/fid4.md

@@ -0,0 +1,53 @@
+---
+type: system
+project: fidelity
+status: active
+workstreams: [consumer-integration, xflow-debugging, ao-discourse, xflow-swiftui-migration]
+related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore, consumer-integration]
+updated: 2026-04-17
+tags:
+  - system
+  - fidelity
+---
+# Fid4
+
+## Role
+
+Fid4 is the main Fidelity consumer iOS app and the most important environment for validating real integration behavior.
+
+---
+
+## Durable Context
+
+- Fid4 is the newer flagship-style app and is heavily SwiftUI-based.
+- Validation in Fid4 often reveals issues that do not appear in XFlowSDK isolation or sample apps.
+- Historical Slack context shows that some tickets were incorrectly scoped until behavior was checked in Fid4 or flagship.
+- Real consumer testing in Fid4 matters for modal presentation, validation messaging, and backend-driven flow behavior.
+- Fid4 currently consumes XFlow through XFlowViewMaker rather than depending on XFlowSDK directly.
+
+---
+
+## Validation Implications
+
+- If an issue depends on real flow behavior, do not assume XFlow-only validation is sufficient.
+- When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope.
+- Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint.
+- Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published.
+- Fidelity uses internal build-distribution tooling such as `iosinstaller` to inspect shipped consumer builds.
+- `iosinstaller` can provide App Store and internal build downloads and expose the build's `Podfile.lock`, which makes it a useful validation source when the repo itself does not track that lockfile.
+- The common update path is:
+  - modify the Podfile to the new XFlowViewMaker version
+  - run `tuist generate -n`
+  - run `pod install --repo-update`
+  - open and merge a PR
+  - wait for the consumer team to carry the change forward in their normal App Store release flow
+- `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles.
+- A useful app-store validation path is the Flagship app pipeline artifacts: `appstore/DistributionSummary.plist` records the framework versions installed in that build and can be used to confirm which XFlowViewMaker and XFlow versions were actually shipped.
+
+---
+
+## Historical Signals From Slack
+
+- Fid4 was repeatedly referenced as the right place to verify SwiftUI/XFlow bugs before finalizing scope.
+- Historical work included modal-on-modal presentation issues, goal/date validation behavior, and consumer-facing eventing questions.
+- Some XFlow tickets needed rework because the original spike or story had not been validated in flagship/Fid4.

workspaces/fidelity/project-knowledge/03-context/systems/fidelity-central.md

@@ -0,0 +1,38 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+---
+
+# Fidelity Central
+
+## Role
+
+- Internal Fidelity portal or central navigation surface.
+
+---
+
+## Stable Patterns
+
+- Likely acts as an entry point to other internal systems or reference material.
+- Base note only; add high-value navigation paths gradually.
+
+---
+
+## Risks
+
+- Portal names can hide multiple unrelated functions behind one entry point.
+
+---
+
+## Related Context
+
+- `myaccess.md`

workspaces/fidelity/project-knowledge/03-context/systems/ftframeworks.md

@@ -0,0 +1,48 @@
+---
+type: system
+project: fidelity
+status: active
+workstreams: [consumer-integration, xflow-swiftui-migration]
+related: [fid4, xflowsdk, xflowviewmaker, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
+updated: 2026-04-17
+tags:
+  - system
+  - fidelity
+---
+# FTFrameworks
+
+## Role
+
+FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTransfer, and related libraries that mediate how XFlow changes reach Fid4.
+
+---
+
+## Durable Context
+
+- FTFrameworks is often part of the real validation and release chain, not just a downstream detail.
+- Historical Slack context shows pinned FT module versions repeatedly blocking adoption of newer XFlow or XFlowViewMaker changes in Fid4.
+- Changes to XFlow often needed corresponding FTAccountOpen or FTTransfer updates before end-to-end testing was realistic.
+- `FTAccountOpen` and `FTTransfer` consume XFlow through XFlowViewMaker rather than directly from XFlowSDK.
+- For Account Opening flows, the current path is understood to go through `FTAccountOpen`.
+
+---
+
+## Validation And Release Implications
+
+- If Fid4 does not reflect the expected XFlow fix, check FT module versions before concluding the SDK change failed.
+- Version movement can require a chain such as:
+  - XFlowSDK
+  - XFlowViewMaker
+  - FTAccountOpen / FTTransfer
+  - Fid4
+- Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready.
+- FTFrameworks code-owner approval can also be a practical gate when the XFlowViewMaker update PR lives inside the shared `PR100660-ios-frameworks` monorepo.
+- In the current XFlowViewMaker propagation pattern, effective downstream constraints may be enforced in the podspec repo rather than the FTFrameworks source repo itself.
+- A successful Fid4 upgrade required removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs in the podspec repo, then rerunning `pod install --repo-update`.
+
+---
+
+## Historical Signals From Slack
+
+- FTAccountOpen and FTTransfer were repeatedly mentioned in version bump and release coordination work.
+- Historical messages also tied FTFrameworks to FTAuth and MFA-related stories, showing that dependency understanding matters when sizing or scoping work.

workspaces/fidelity/project-knowledge/03-context/systems/github-copilot.md

@@ -0,0 +1,47 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: [jeff-dewitte]
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-20
+---
+
+# GitHub Copilot
+
+## Role
+
+- GitHub Copilot is a broadly used AI tool in the Fidelity workflow, especially when product-side code access and richer implementation context are available on the Fidelity machine.
+
+---
+
+## Stable Patterns
+
+- Use this tool when the local Fidelity-side product context is richer than what can be summarized indirectly in chat.
+- It is useful for investigation, code-oriented debugging, and implementation support when David can provide concrete build, file, and runtime details from the Fidelity development environment.
+- Tool output should still be checked against local evidence, reproduction results, and confirmed project context.
+
+---
+
+## Current Example
+
+- During the April 20, 2026 REST / LaunchDarkly investigation, Jeff specifically suggested using GitHub Copilot with more detailed local context from David's side.
+
+---
+
+## Risks
+
+- Do not assume the tool output is authoritative without checking it against local evidence.
+- Keep the tool's Fidelity-side access level and data visibility labeled as contextual rather than assumed workspace-wide.
+
+---
+
+## Related Context
+
+- `workspaces/fidelity/project-knowledge/04-people/jeff-dewitte.md`
+- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`

workspaces/fidelity/project-knowledge/03-context/systems/index.md

@@ -0,0 +1,98 @@
+---
+type: system-index
+project: fidelity
+status: active
+updated: 2026-04-20
+tags:
+  - system
+  - fidelity
+---
+# Systems Index
+
+## Core Components
+
+- [fid4.md](./fid4.md)
+  Consumer app and the most important real-world validation environment.
+
+- [xflowsdk.md](./xflowsdk.md)
+  Backend-driven flow engine and the center of most Fidelity behavior analysis.
+
+- [xflowviewmaker.md](./xflowviewmaker.md)
+  Adapter layer historically involved in version bumps, release coupling, and removal evaluation.
+
+- [ftframeworks.md](./ftframeworks.md)
+  Consumer-side feature modules that often mediate whether XFlow changes can be validated in Fid4.
+
+- [CogStore](./cogstore.md)
+  Flow-configuration publishing and version-comparison platform used to verify what is live in QA/Production.
+
+---
+
+## Internal Apps And Tools
+
+- [iosinstaller.md](./iosinstaller.md)
+  Internal build-inspection app that can expose App Store/internal builds and their `Podfile.lock`.
+
+- [artifactory.md](./artifactory.md)
+  Artifact distribution surface used in release and build-validation workflows.
+
+- [splunk.md](./splunk.md)
+  Internal logging/observability tool for debugging distributed behavior.
+
+- [discourse.md](./discourse.md)
+  External issue/reporting surface that often feeds Fidelity triage and communication.
+
+- [confluence.md](./confluence.md)
+  Internal documentation/wiki surface.
+
+- [jira.md](./jira.md)
+  Primary work-tracking system for stories, sprint state, and planning.
+
+- [miro.md](./miro.md)
+  Shared whiteboarding/collaboration tool.
+
+- [myaccess.md](./myaccess.md)
+  Internal access/authentication-related tool.
+
+- [trackit.md](./trackit.md)
+  Internal tracking tool from the Fidelity toolset.
+
+- [fidelity-central.md](./fidelity-central.md)
+  Internal portal/entry-point app.
+
+- [wukong.md](./wukong.md)
+  Internal test-data-related tool.
+
+- [xq1-portfolio-summary.md](./xq1-portfolio-summary.md)
+  Internal XQ1 environment summary page/tool.
+
+- [vault.md](./vault.md)
+  Internal Fidelity tool named Vault.
+
+- [vault-preprod.md](./vault-preprod.md)
+  Pre-production variant of the internal Vault tool.
+
+- [slate.md](./slate.md)
+  Internal tool from the current Fidelity bookmark/tool set.
+
+- [almx-toolbox.md](./almx-toolbox.md)
+  Internal ALM/process-related tool.
+
+- [nexus-fidelity.md](./nexus-fidelity.md)
+  Internal Fidelity tool identified from the current bookmark/tool set.
+
+- [launchdarkly.md](./launchdarkly.md)
+  Feature-flag platform used broadly across the Fidelity workflow for rollout and environment-controlled behavior.
+
+- [github-copilot.md](./github-copilot.md)
+  Fidelity-side AI tool used broadly when richer product-side context is available on the development machine.
+
+---
+
+## Guidance
+
+- Start with `xflowsdk.md` for backend-driven behavior questions.
+- Start with `fid4.md` or `ftframeworks.md` for consumer validation and release flow questions.
+- Open `xflowviewmaker.md` when the question involves version bumps, transitional architecture, or pipeline friction.
+- Open `cogstore.md` when the question involves published flow-definition versions, config diffs, or whether a service/config change is live in QA vs Production.
+- Open `iosinstaller.md`, `artifactory.md`, or the [Fidelity Apps Map](../../07-maps/fidelity-apps.md) when the question is about internal tools, build inspection, or where to look next.

workspaces/fidelity/project-knowledge/03-context/systems/iosinstaller.md

@@ -0,0 +1,50 @@
+---
+type: system
+project: fidelity
+status: active
+systems:
+  - fid4
+  - artifactory
+workstreams:
+  - consumer-integration
+people: []
+related:
+  - consumer-integration
+  - fid4
+  - artifactory
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - Artifactory IOS Build Installer
+---
+
+# iOSInstaller
+
+## Role
+
+- Internal Fidelity app used to inspect distributed mobile builds.
+- Current known use: download App Store/internal builds and inspect the build's `Podfile.lock`.
+
+---
+
+## Stable Patterns
+
+- Useful when the repo does not keep `Podfile.lock` in Git but you still need to inspect what dependencies a shipped build used.
+- Can support version-validation and reproduction work for Fid4 / flagship investigations.
+- This is a base note; capture exact access patterns, URLs, and screenshots gradually as they become important.
+
+---
+
+## Risks
+
+- Build snapshots alone may still be insufficient for exact reproduction if the private podspec repo changed after the build was produced.
+
+---
+
+## Related Context
+
+- `fid4.md`
+- `artifactory.md`
+- `../workstreams/consumer-integration.md`

workspaces/fidelity/project-knowledge/03-context/systems/jira.md

@@ -0,0 +1,39 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: [consumer-integration]
+people: [quy-mai]
+related: [confluence, miro, ../process/jira-story-rules.md, ../process/sprint-cadence.md]
+tags:
+  - system
+  - fidelity
+  - jira
+  - tracking
+updated: 2026-04-20
+---
+
+# Jira
+
+## Role
+
+- Primary work-tracking system used in Fidelity.
+- Central system for stories, sprint organization, status tracking, and planning flow.
+
+---
+
+## Stable Patterns
+
+- Fidelity-side Scrum work is organized in Jira.
+- Sprint naming uses labels like `PDIAP 26Q1.1`, `PDIAP 26Q2.1`, and `PDIAP 26Q2.2`.
+- Jira is part of the day-to-day delivery flow alongside DSE/daily syncs, sprint review, sprint planning, and retrospectives.
+- Story IDs and approved titles should remain explicit because they are reused in standups, planning, and stakeholder communication.
+
+---
+
+## Related Context
+
+- Sprint cadence and ceremonies: `../process/sprint-cadence.md`
+- Story framing guidance: `../process/jira-story-rules.md`
+- Scrum coordination context: `../../04-people/quy-mai.md`

workspaces/fidelity/project-knowledge/03-context/systems/launchdarkly.md

@@ -0,0 +1,47 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-20
+---
+
+# LaunchDarkly
+
+## Role
+
+- LaunchDarkly is the feature-flag platform used broadly in the Fidelity workflow.
+- It is part of the normal delivery path for controlled rollout, environment-specific behavior, and gradual activation of changes.
+
+---
+
+## Stable Patterns
+
+- LaunchDarkly can affect behavior by environment, context, targeting, timing, and cached flag state.
+- When a bug appears only on certain builds or devices, LaunchDarkly evaluation is a valid investigation path even if local simulator checks look correct.
+- Missing direct dashboard access does not remove LaunchDarkly from consideration; code-side evidence, payload inspection, and runtime evaluation still matter.
+
+---
+
+## Current Example
+
+- During the April 20, 2026 REST migration investigation, LaunchDarkly was a central part of the debugging path because the behavior differed between local validation and consumer real-device reports.
+
+---
+
+## Risks
+
+- Do not assume a simulator result fully represents real-device LaunchDarkly behavior.
+- Do not treat missing direct Flagship dashboard access as proof that LaunchDarkly is not involved; indirect evidence still matters.
+
+---
+
+## Related Context
+
+- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`

workspaces/fidelity/project-knowledge/03-context/systems/miro.md

@@ -0,0 +1,38 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+---
+
+# Miro
+
+## Role
+
+- Shared whiteboarding/collaboration tool.
+
+---
+
+## Stable Patterns
+
+- Useful for diagrams, architecture sketches, or discussion artifacts when they matter to project context.
+- Base note only; add recurring boards or workflows gradually.
+
+---
+
+## Risks
+
+- Whiteboards can become stale quickly if not linked back to canonical notes.
+
+---
+
+## Related Context
+
+- `confluence.md`

workspaces/fidelity/project-knowledge/03-context/systems/myaccess.md

@@ -0,0 +1,40 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - My Access
+---
+
+# MyAccess
+
+## Role
+
+- Internal access/authentication-related tool.
+
+---
+
+## Stable Patterns
+
+- Likely relevant when environment access or role-based permissions affect day-to-day work.
+- Base note only; add common use cases gradually.
+
+---
+
+## Risks
+
+- Access assumptions can become stale as roles/projects change.
+
+---
+
+## Related Context
+
+- `../process/communication.md`

workspaces/fidelity/project-knowledge/03-context/systems/nexus-fidelity.md

@@ -0,0 +1,40 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - "Nexus : Fidelity"
+  - Nexus
+---
+
+# Nexus Fidelity
+
+## Role
+
+- Internal Fidelity app/tool identified from the current bookmark set.
+
+---
+
+## Stable Patterns
+
+- Base note only; add confirmed purpose and relation to release/build flows gradually.
+
+---
+
+## Risks
+
+- Do not assume this is the same as other artifact or repository tools without confirmation.
+
+---
+
+## Related Context
+
+- `artifactory.md`

workspaces/fidelity/project-knowledge/03-context/systems/slate.md

@@ -0,0 +1,39 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - "Slate : Cognitive Mini App Designer"
+---
+
+# Slate
+
+## Role
+
+- Internal tool currently identified from the Fidelity app/bookmark set.
+
+---
+
+## Stable Patterns
+
+- Base note only; add confirmed purpose, ownership, and recurring workflows gradually.
+
+---
+
+## Risks
+
+- Do not infer too much from name alone.
+
+---
+
+## Related Context
+
+- `miro.md`

workspaces/fidelity/project-knowledge/03-context/systems/splunk.md

@@ -0,0 +1,39 @@
+---
+type: system
+project: fidelity
+status: active
+systems: [fid4, xflowsdk]
+workstreams: [xflow-debugging]
+people: []
+related: [xflow-debugging, fid4, xflowsdk]
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+---
+
+# Splunk
+
+## Role
+
+- Internal observability/logging tool used for debugging production-like or distributed behavior.
+
+---
+
+## Stable Patterns
+
+- Likely useful for validation and issue triage when app behavior differs from local expectations.
+- Base note only; add saved searches, index names, and practical debugging patterns later.
+
+---
+
+## Risks
+
+- Logs can be misleading without auth-state, environment, and version context.
+
+---
+
+## Related Context
+
+- `../workstreams/xflow-debugging.md`
+- `fid4.md`

workspaces/fidelity/project-knowledge/03-context/systems/trackit.md

@@ -0,0 +1,39 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - Track It
+---
+
+# TrackIT
+
+## Role
+
+- Internal tracking tool referenced from the Fidelity app/tool set.
+
+---
+
+## Stable Patterns
+
+- Base note only; capture exact purpose and recurring workflows gradually.
+
+---
+
+## Risks
+
+- Name alone is not enough to infer ownership or authoritative data.
+
+---
+
+## Related Context
+
+- `confluence.md`

workspaces/fidelity/project-knowledge/03-context/systems/vault-preprod.md

@@ -0,0 +1,41 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related:
+  - vault
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - Vault preprod
+---
+
+# Vault Preprod
+
+## Role
+
+- Pre-production variant of the internal Fidelity Vault app/tool.
+
+---
+
+## Stable Patterns
+
+- Keep this separate from production Vault context when documenting behavior.
+- Base note only; add environment-specific usage gradually.
+
+---
+
+## Risks
+
+- Easy to mix up with production Vault or with the `workspaces/fidelity/project-knowledge/` documentation directory.
+
+---
+
+## Related Context
+
+- `vault.md`

workspaces/fidelity/project-knowledge/03-context/systems/vault.md

@@ -0,0 +1,38 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+---
+
+# Vault
+
+## Role
+
+- Internal Fidelity app/tool named Vault.
+
+---
+
+## Stable Patterns
+
+- Base note only; this refers to the Fidelity system named Vault, not the `workspaces/fidelity/project-knowledge/` documentation directory.
+- Add real purpose and usage patterns gradually as they become clear.
+
+---
+
+## Risks
+
+- Name collision with Obsidian/project-knowledge terminology can cause confusion in notes and communication.
+
+---
+
+## Related Context
+
+- `vault-preprod.md`

workspaces/fidelity/project-knowledge/03-context/systems/wukong.md

@@ -0,0 +1,41 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - Wukong3.0
+  - Find test data easier
+---
+
+# Wukong
+
+## Role
+
+- Internal tool associated with test-data workflows.
+
+---
+
+## Stable Patterns
+
+- Recent bookmark evidence suggests it helps find or generate test data more easily.
+- Base note only; add exact supported workflows gradually.
+
+---
+
+## Risks
+
+- Test-data tooling often has environment-specific constraints and policy caveats.
+
+---
+
+## Related Context
+
+- `fid4.md`

workspaces/fidelity/project-knowledge/03-context/systems/xflowsdk.md

@@ -0,0 +1,59 @@
+---
+type: system
+project: fidelity
+status: active
+workstreams: [rest-migration, ao-discourse, xflow-debugging, xflow-swiftui-migration, consumer-integration]
+related: [fid4, xflowviewmaker, ftframeworks, cogstore, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
+updated: 2026-04-17
+tags:
+  - system
+  - fidelity
+---
+# XFlowSDK
+
+## Role
+
+XFlowSDK is the backend-driven UI engine that renders Fidelity flows from service-provided configuration.
+
+---
+
+## Durable Context
+
+- XFlow behavior depends on backend rules, entry point, and authentication state.
+- SwiftUI migration work introduced recurring behavior questions that were not just visual; many were contract or lifecycle issues.
+- XFlowSDK is developed in the dedicated repository `pr100660-xflow-for-ios`.
+- Historical Slack patterns show recurring topics around:
+  - component type expansion in SwiftUI
+  - Next-button visibility rules
+  - markdown link handling and analytics
+  - modal presentation and dismissal sequencing
+  - consumer-vs-framework ownership boundaries
+
+---
+
+## Release Mechanics
+
+- XFlowSDK publishing currently uses the Jenkins pipeline `xflow-for-ios-publish`.
+- The publish flow builds the XCFramework, publishes it to internal Fidelity Artifactory at `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`.
+- Once published, the new SDK version can be adopted downstream through `pod install` or `pod update`, but consumer validation still depends on XFlowViewMaker and Fid4 propagation.
+
+---
+
+## Debugging Implications
+
+- Do not treat XFlow output as static UI; backend configuration can change the result.
+- When behavior differs across environments, check whether the issue is:
+  - service/configuration driven
+  - auth-state driven
+  - entry-point driven
+  - consumer-integration driven
+- Some apparent XFlow regressions historically turned out to be consumer, pipeline, or environment issues.
+
+---
+
+## Historical Signals From Slack
+
+- SwiftUI behavior repeatedly needed parity work beyond UIKit assumptions.
+- Next-button visibility logic required using the full set of service parameters, not only label text.
+- Modal, delegate, and lifecycle sequencing became recurring themes in pure SwiftUI environments.
+- XFlow work often had to be validated through consumer repositories, not only inside the SDK.

workspaces/fidelity/project-knowledge/03-context/systems/xflowviewmaker.md

@@ -0,0 +1,60 @@
+---
+type: system
+project: fidelity
+status: active
+workstreams: [consumer-integration, xflow-swiftui-migration]
+related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-12284]
+updated: 2026-05-08
+tags:
+  - system
+  - fidelity
+---
+# XFlowViewMaker
+
+## Role
+
+XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework integration. It is under evaluation for reduction or removal.
+
+---
+
+## Durable Context
+
+- Historical release work often required bumping XFlowViewMaker alongside XFlowSDK before consumer validation was possible.
+- XFlowViewMaker was a recurring source of coupling between XFlow changes and Fid4 or flagship rollout.
+- Historical Slack evidence shows that version bumps through XFlowViewMaker were often blocked by external pipeline or dependency issues rather than pure feature regressions.
+- XFlowViewMaker currently lives in the monorepo `PR100660-ios-frameworks` under `Adapters/XFlowViewMaker`.
+
+---
+
+## Release Mechanics
+
+- When XFlowSDK releases a new version, XFlowViewMaker usually needs a follow-up dependency bump before Fid4 can consume the change.
+- The common release flow is:
+  - update the XFlowViewMaker podspec to the new XFlowSDK version
+  - run `tuist generate -n`
+  - run `pod install`
+  - open a PR
+  - wait for required approvals, including protected-branch/code-owner approval when applicable
+  - merge, often through automerge once approvals are complete
+  - let the Jenkins pipeline `publish-XFlowViewMaker` publish the adapter release
+- `publish-XFlowViewMaker` usually auto-detects the next version and commonly increments the minor version automatically.
+- The publish flow distributes the new adapter version through Artifactory/podspec channels and updates the XFlowViewMaker version on `main`.
+
+---
+
+## Integration Implications
+
+- When a fix exists in XFlowSDK but is not visible in consumer validation, check whether XFlowViewMaker or downstream pinned versions are blocking adoption.
+- If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it.
+- Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as `FTAccountOpen` and `FTTransfer`.
+- Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
+- For the current `PDIAP-12284` / `PDIAP-15836` migration planning, XFlowViewMaker is the preferred candidate owner for global host-mode resolution if product-code inspection confirms it can access the existing feature-flag abstraction cleanly. This avoids Fid4-owned per-flow mapping and keeps XFlowSDK decoupled from app-specific LaunchDarkly/Flagship clients.
+- The desired host-mode behavior for that migration is SwiftUI host by default, SwiftUI host when feature configuration is missing or unknown, and `UIHostingController` only when an explicit temporary fallback flag requests it.
+
+---
+
+## Historical Signals From Slack
+
+- XFlowViewMaker version bumps into flagship frequently surfaced `PreviewMacros.SwiftUI`, Apex, or pipeline compatibility issues.
+- Historical context shows growing pressure to reduce XFlowViewMaker-specific indirection and move toward simpler consumer paths.
+- Slack history also shows that tutorials and release steps around XFlowViewMaker were easy to misunderstand, which made version propagation a repeated risk.

workspaces/fidelity/project-knowledge/03-context/systems/xq1-portfolio-summary.md

@@ -0,0 +1,40 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-17
+aliases:
+  - XQ1
+---
+
+# XQ1 Portfolio Summary
+
+## Role
+
+- Internal Fidelity app/page related to the XQ1 environment.
+
+---
+
+## Stable Patterns
+
+- Likely useful for environment-level validation or summary checks.
+- Base note only; add exact role in debugging/release validation gradually.
+
+---
+
+## Risks
+
+- Environment pages can be read as status signals without proving app-level behavior.
+
+---
+
+## Related Context
+
+- `fid4.md`