david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add project-knowledge structure and templates

Browse Source 
- 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.
This commit is contained in:
David Delagneau
2026-04-17 15:52:08 -06:00
parent 11fdb17fcb
commit dbc1894e27
175 changed files with 1163 additions and 914 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
project-knowledge/.obsidian/app.json vendored Normal file
View File

@@ -0,0 +1,10 @@
{
"attachmentFolderPath": "attachments",
"newFileLocation": "current",
"userIgnoreFilters": [
"**/.venv/",
"**/generated/",
"**/__pycache__/",
"**/*.pyc"
]
}

1
project-knowledge/.obsidian/appearance.json vendored Normal file
View File

@@ -0,0 +1 @@
{}

39
project-knowledge/.obsidian/bookmarks.json vendored Normal file
View File

@@ -0,0 +1,39 @@
{
"items": [
{
"type": "file",
"path": "00-start/start-here.md",
"title": "Start Here"
},
{
"type": "file",
"path": "00-start/onboarding.md",
"title": "Onboarding"
},
{
"type": "file",
"path": "01-current/current-work.md",
"title": "Current Work"
},
{
"type": "folder",
"path": "02-work-items",
"title": "Work Items"
},
{
"type": "folder",
"path": "04-people",
"title": "People"
},
{
"type": "file",
"path": "08-bases/work-items.base",
"title": "Work Items Base"
},
{
"type": "file",
"path": "08-bases/people.base",
"title": "People Base"
}
]
}

33
project-knowledge/.obsidian/core-plugins.json vendored Normal file
View File

@@ -0,0 +1,33 @@
{
"file-explorer": true,
"global-search": true,
"switcher": true,
"graph": true,
"backlink": true,
"canvas": true,
"outgoing-link": true,
"tag-pane": true,
"footnotes": false,
"properties": true,
"page-preview": true,
"daily-notes": true,
"templates": true,
"note-composer": true,
"command-palette": true,
"slash-command": false,
"editor-status": true,
"bookmarks": true,
"markdown-importer": false,
"zk-prefixer": false,
"random-note": false,
"outline": true,
"word-count": true,
"slides": false,
"audio-recorder": false,
"workspaces": false,
"file-recovery": true,
"publish": false,
"sync": false,
"bases": true,
"webviewer": false
}

5
project-knowledge/.obsidian/daily-notes.json vendored Normal file
View File

@@ -0,0 +1,5 @@
{
"format": "YYYY-MM-DD",
"folder": "06-daily",
"template": "09-templates/daily.md"
}

65
project-knowledge/.obsidian/graph.json vendored Normal file
View File

@@ -0,0 +1,65 @@
{
"collapse-filter": true,
"search": "-path:generated -path:.venv -path:08-bases -path:09-templates -file:index -file:README -file:AGENTS -file:SKILL",
"showTags": false,
"showAttachments": false,
"hideUnresolved": false,
"showOrphans": false,
"collapse-color-groups": true,
"colorGroups": [
{
"query": "tag:#onboarding",
"color": {
"a": 1,
"rgb": 14701138
}
},
{
"query": "tag:#map",
"color": {
"a": 1,
"rgb": 6732650
}
},
{
"query": "path:02-work-items",
"color": {
"a": 1,
"rgb": 16753920
}
},
{
"query": "path:04-people",
"color": {
"a": 1,
"rgb": 10053324
}
},
{
"query": "path:05-decisions",
"color": {
"a": 1,
"rgb": 16733525
}
},
{
"query": "path:03-context/systems OR path:03-context/workstreams",
"color": {
"a": 1,
"rgb": 5793266
}
}
],
"collapse-display": true,
"showArrow": false,
"textFadeMultiplier": 0,
"nodeSizeMultiplier": 1,
"lineSizeMultiplier": 1,
"collapse-forces": true,
"centerStrength": 0.518713248970312,
"repelStrength": 10,
"linkStrength": 1,
"linkDistance": 250,
"scale": 5.865886234269105,
"close": true
}

3
project-knowledge/.obsidian/templates.json vendored Normal file
View File

@@ -0,0 +1,3 @@
{
"folder": "09-templates"
}

7
project-knowledge/.obsidian/types.json vendored Normal file
View File

@@ -0,0 +1,7 @@
{
"types": {
"aliases": "multitext",
"cssclasses": "multitext",
"tags": "tags"
}
}

51
project-knowledge/00-start/glossary.md Normal file
View File

@@ -0,0 +1,51 @@
---
type: glossary
audience: new-member
tags:
- onboarding
- glossary
---
# Glossary
Common terms used in the Fidelity project knowledge vault.
---
## Workspace Terms
- `project-knowledge`: this Obsidian vault; transferable Fidelity project knowledge.
- `agent-memory`: agent operating rules outside this vault.
- `operational memory`: curated file-based memory that helps future sessions reason accurately.
- `daily log`: same-day evidence and evolving findings in `project-knowledge/06-daily/`.
- `state`: near-term active work and priorities in `project-knowledge/01-current/`.
- `work item`: canonical memory for a ticket, story, task, or investigation in `project-knowledge/02-work-items/`.
- `stable context`: durable project knowledge under `project-knowledge/03-context/`.
- `inbox`: raw or lightly processed communication evidence under `ai/inbox/`.
- `promotion`: moving high-confidence evidence into canonical memory.
- `memory interface`: project-agnostic scripts under `scripts/memory/` that create, search, query, and validate project knowledge without coupling the workspace to Obsidian.
---
## Fidelity Terms
- `Fid4`: main Fidelity consumer iOS app and key validation environment.
- `XFlowSDK`: backend-driven UI engine that renders flows from service-provided configuration.
- `XFlowViewMaker`: adapter layer historically involved in integration and release propagation.
- `FTFrameworks`: feature modules such as account opening or transfer flows that can mediate XFlow adoption.
- `AO`: account opening context; many reports require careful reproduction and scope validation.
- `Discourse`: external issue/report source; treat reports as external until confirmed.
- `REST migration`: migration away from GraphQL/Apollo toward REST, with REST behind a feature flag unless confirmed otherwise.
- `authenticated flow`: behavior reproduced while signed in; often differs from non-authenticated behavior.
- `entry point`: the path used to reach a flow, which can affect backend-driven behavior.
- `Cogstore`: flow-configuration publishing and version-comparison platform.
---
## Communication Terms
- `external report`: issue reported externally before regression status is confirmed.
- `regression`: behavior confirmed to be newly broken relative to a known baseline.
- `scope`: the exact affected flow, platform, auth state, environment, and ownership boundary.
- `reproducibility`: whether the behavior can be repeated with known steps and context.
- `manager-ready`: concise, explicit, natural professional English that can be sent without rewriting.

93
project-knowledge/00-start/onboarding.md Normal file
View File

@@ -0,0 +1,93 @@
---
type: onboarding
audience: new-member
project: fidelity
updated: 2026-04-17
tags:
- onboarding
- map
---
# New Member Onboarding
Use this guide when someone new needs to understand the Fidelity project context quickly.
This vault is project knowledge, not the product codebase and not the agent implementation manual.
---
## First 30 Minutes
Read these in order:
1. [Start Here](start-here.md)
2. [Current Work Map](../07-maps/current-work.md)
3. [Fidelity Domain Map](../07-maps/fidelity-domain.md)
4. [Work Items Map](../07-maps/work-items.md)
5. [People Map](../07-maps/people.md)
Goal:
- understand where current work lives
- identify active tickets
- understand the main systems and people
- avoid treating raw logs or inbox evidence as confirmed durable truth
---
## First 60 Minutes
Read:
1. [Project Context](../03-context/project.md)
2. [XFlowSDK](../03-context/systems/xflowsdk.md)
3. [Fid4](../03-context/systems/fid4.md)
4. [REST Migration](../03-context/workstreams/rest-migration.md)
5. [AO And Discourse](../03-context/workstreams/ao-discourse.md)
6. [Communication](../03-context/process/communication.md)
Goal:
- understand why auth state, entry point, and backend configuration matter
- distinguish external reports from regressions
- understand why communication precision is part of the engineering workflow
---
## First 120 Minutes
Read:
1. [Systems Index](../03-context/systems/index.md)
2. [Workstreams Index](../03-context/workstreams/index.md)
3. [iOS Context](../03-context/ios/index.md)
4. [Jira Story Rules](../03-context/process/jira-story-rules.md)
5. [Pull Requests](../03-context/process/pull-requests.md)
Goal:
- understand how Fidelity project knowledge is organized
- know where to find durable systems, workstreams, people, decisions, and active tickets
- know the communication standards expected for standups, Jira, PRs, and manager updates
---
## Daily Workflow
1. Start from [Current Work Map](../07-maps/current-work.md).
2. Check [Current Work](../01-current/current-work.md).
3. Open the active work item from [Work Items Map](../07-maps/work-items.md).
4. Review the latest relevant note from [Daily Notes Index](../06-daily/index.md).
5. Use [Communication](../03-context/process/communication.md) before writing standups, Jira comments, or manager updates.
---
## Rules Of Thumb
- `project-knowledge/06-daily/` is dated work evidence.
- `project-knowledge/01-current/` is what matters now.
- `project-knowledge/02-work-items/` is canonical ticket memory.
- `project-knowledge/03-context/` is durable project knowledge.
- `project-knowledge/04-people/` is collaborator and role memory.
- `project-knowledge/05-decisions/` is durable decision history.
- `ai/inbox/` and generated files are raw evidence, not promoted memory.

93
project-knowledge/00-start/start-here.md Normal file
View File

@@ -0,0 +1,93 @@
---
type: map
audience: project-reader
project: fidelity
updated: 2026-04-17
tags:
- map
- onboarding
---
# Start Here
Use this note as the entry point when opening `project-knowledge/` as the Obsidian vault.
This vault is the Fidelity project second brain. It is meant to be useful to the engineer, a new teammate, or an AI agent consuming project context. Agent implementation rules live outside this vault in `agent-memory/`.
---
## New Members
Read these first:
1. [New Member Onboarding](onboarding.md)
2. [Glossary](glossary.md)
3. [Current Work Map](../07-maps/current-work.md)
4. [Fidelity Domain Map](../07-maps/fidelity-domain.md)
5. [Fidelity Apps Map](../07-maps/fidelity-apps.md)
6. [People Map](../07-maps/people.md)
---
## Current Work
- [Current State](../01-current/current-work.md)
- [Active Work Items](../01-current/work-items.md)
- [Work Item Index](../02-work-items/index.md)
- [Daily Notes Index](../06-daily/index.md)
---
## Stable Context
- [Project Context](../03-context/project.md)
- [Context Index](../03-context/index.md)
- [Systems Index](../03-context/systems/index.md)
- [Workstreams Index](../03-context/workstreams/index.md)
- [People Index](../04-people/index.md)
- [Manager Mapping](../04-people/manager.md)
- [Decisions](../05-decisions/rest-vs-graphql.md)
---
## Project-Facing Process
- [Communication](../03-context/process/communication.md)
- [Communication Rules](../03-context/process/communication-rules.md)
- [Jira Story Rules](../03-context/process/jira-story-rules.md)
- [Pull Requests](../03-context/process/pull-requests.md)
---
## Maps
- [Knowledge Maps](../07-maps/index.md)
- [Current Work](../07-maps/current-work.md)
- [Fidelity Domain](../07-maps/fidelity-domain.md)
- [Fidelity Apps](../07-maps/fidelity-apps.md)
- [Work Items](../07-maps/work-items.md)
- [People](../07-maps/people.md)
---
## Daily Notes
Daily notes live in:
```text
project-knowledge/06-daily/
```
Use the latest dated note for recent evidence, but promote durable facts into `01-current/`, `02-work-items/`, or `03-context/` when they should survive beyond the day.
---
## Evidence Boundary
Inbox and generated files are evidence, not durable memory by default.
- `ai/inbox/`
- `scripts/mattermost/generated/`
- `scripts/slack/generated/`
Promote only high-confidence, project-relevant facts into this vault.

91
project-knowledge/01-current/current-work.md Normal file
View File

@@ -0,0 +1,91 @@
---
type: current
project: fidelity
status: active
updated: 2026-04-17
tags:
- current-work
- fidelity
---
# Current Work
## Focus
- Keep Fidelity context current from daily work performed on another machine
- Track REST migration findings
- Debug Discourse and AO issues
- Prepare better updates for the current manager or stakeholder through Mattermost
- Follow up on active tickets through `project-knowledge/02-work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
- Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike
- After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later
- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by carrying the already-published XFlowViewMaker update through the Fid4 PR and downstream consumer path
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
- Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
- Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
- Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance
- The ApexKitV3 risk write-up for Quy has been published and sent; use that research as the current high-level framing for dependency-removal risk
- Investigate the current XFlow dependency surface on `ApexKitV3`, including the `23` build errors on removal and the remaining `13` errors when swapping to `ApexKitSwiftUI`
- The process-oriented rollout document for the UIKit-removal spike is approved and ready to publish for spike closure
- The rollout document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt
- The rollout document uses a global feature-flag rollout model with broad XQ1 validation before production enablement
- The rollout document should use the new flag name `xflow-swiftui-container-enabled` and note that the flag will be added later during implementation
- Re-check the authenticated AO validation issue with scenario-specific evidence: the `HybridYouthAccountOpening` / `TeenIdentityCheck` path currently points to an iOS-only decoding gap, while a separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` case reproduces on both platforms
- The immediate Youth issue was fixed on the service side for the Youth-flow `TeenIdentityCheck` path after the payload moved from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK-side fallback PR should still ship in the next release
- Jeff later decided the iOS fallback PR should be treated as the primary fix path for the Youth issue rather than relying on a separate service rollout; the QA-side service change has since been rolled back and Fid4 validation still passed with the PR in place
- When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future `birthDate` payloads, not as a fix for the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue
- The Youth / `TeenIdentityCheck` issue was iOS-only; do not describe it as reproducing on both platforms
- The service-side payload update and the XFlowSDK fallback PR address the same Youth / `TeenIdentityCheck` issue; do not split them into separate Youth issues when summarizing scope
- The `PDIAP-15765` compatibility fix is now merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up has also been approved, published, and unblocked in Fid4 through a podspec-repo change, and the current downstream step is the open Fid4 PR/update path
- A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both `main` and `release/4.30`; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
- Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up
---
## Active Concerns
- Authenticated vs non-authenticated behavior
- Reproducibility across entry points
- Backend-driven inconsistencies in XFlow
- Distinguishing external issues from true regressions
- Preserving accurate context when summarizing work from another machine
- Validating dismissal sequencing changes across SwiftUI flows
- Keeping REST deprecation scope explicit while GraphQL fallback still exists
- Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
- Closing `PDIAP-14859` cleanly with the right links, blocker relationship, and feature-flag wording
- Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope
- Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance
- When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers
- Swift 6 migration risk is now time-sensitive because external dependency removal could break XFlow before the planned `26Q3` work
- The write-up for Quy should remain the reference framing for moderate effort, medium risk, and required consumer validation while deeper implementation details are still being researched
---
## Communication Priorities
- Standups should reflect the latest technical state, not generic progress
- Standups should prefer updates directly tied to active work items over one-off memory refreshes or side questions
- Standups should include story titles whenever a reported update maps to a Jira item
- Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
- When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
- When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
- For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
- When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work
- If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
- Standups should omit items not tied to a story unless they are real blockers
- If a new request is important work but not directly tied to a Jira item, include it as a standalone bullet instead of forcing it under a story
- Manager updates should be short, precise, and natural in English
- Mattermost messages should make scope and next action explicit
- When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault
- Standups should be written as David's external progress report and should not mention Jeff by name
- Standups should never mention Mattermost because it is internal-only communication
---
## Notes
- REST remains behind a feature flag
- Validate against main before calling something a regression
- This workspace is the context source for communication, not the source of product code changes

35
project-knowledge/01-current/work-items.md Normal file
View File

@@ -0,0 +1,35 @@
---
type: current-work-items
project: fidelity
status: active
updated: 2026-04-17
tags:
- current-work
- work-item
- fidelity
---
# Active Work Items
Use this file as the quick summary for active Jira-linked work.
Detailed ticket memory now lives under `project-knowledge/02-work-items/`.
Update the per-ticket files first when scope, status, sequencing, or communication framing changes materially.
## Current
- `PDIAP-14859` - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
Detail: `project-knowledge/02-work-items/pdiap-14859.md`
Current note: the impact write-up is published, and the rollout document is approved for publication; update it to use the new flag name `xflow-swiftui-container-enabled` with a note that it will be added later during implementation, then publish and close out the spike with `Spike Results:` links.
- `PDIAP-15838` - Remove Apollo for iOS
Detail: `project-knowledge/02-work-items/pdiap-15838.md`
Current note: approved at `8` points and next to work on; keep it separate from the UIKit-removal spike.
- `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
Detail: `project-knowledge/02-work-items/pdiap-15836.md`
Current note: approved at `8` points, rooted in the AccountLink dismissal sequencing investigation, and sequenced after `PDIAP-15838`.
- `PDIAP-15765` - AO DOB field error not showing investigation
Detail: `project-knowledge/02-work-items/pdiap-15765.md`
Current note: the small XFlowSDK iOS `birthDate` compatibility fix was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up is now approved and published. A downstream Fid4 dependency conflict was resolved through a podspec-repo update removing the XFlowViewMaker version reference from the latest `FTAccountOpen` and `FTTransfer` podspecs, and the current step is the open Fid4 PR so the change can propagate through the real app path.

25
project-knowledge/02-work-items/README.md Normal file
View File

@@ -0,0 +1,25 @@
# Work Items
## Goal
Keep active Jira-linked work in one canonical place so standups, manager updates, and memory syncs can reference each ticket precisely.
---
## Structure
- `index.md`
Active index and quick status view.
- `<jira-id>.md`
Canonical file for a specific ticket.
---
## Update Rules
- Use one file per active or recently relevant Jira item.
- Keep titles exact when approved or explicitly confirmed.
- If the title is not confirmed, store the Jira ID and current framing without inventing a final title.
- Update the ticket file when scope, sequencing, points, status, rollout implications, or reproducibility meaningfully change.
- Keep `project-knowledge/01-current/work-items.md` as a short bridge summary, not the primary source of detailed ticket context.

39
project-knowledge/02-work-items/index.md Normal file
View File

@@ -0,0 +1,39 @@
---
type: work-item-index
project: fidelity
updated: 2026-04-16
tags:
- work-item
- map
---
# Work Item Index
## Goal
Provide a quick view of active and recently relevant Jira-linked work while keeping the full detail in one file per ticket.
---
## Active
- [pdiap-14859.md](./pdiap-14859.md)
`PDIAP-14859` `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation` spike wrap-up work around dual UIKit/SwiftUI support, dynamic `UIHostingController` removal, consumer rollout planning, and linking the final result documents.
- [pdiap-15838.md](./pdiap-15838.md)
`PDIAP-15838` next story to work on; approved scope removes Apollo and GraphQL-specific iOS transport code while leaving REST.
- [pdiap-15836.md](./pdiap-15836.md)
`PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; comes after `PDIAP-15838`.
## Active / Reopened
- [pdiap-15765.md](./pdiap-15765.md)
`PDIAP-15765` authenticated-only DOB issue in `HybridYouthAccountOpening` / `TeenIdentityCheck`; reopened around the iOS-only handling gap while the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario stays out of scope.
---
## Usage
- Read this file first for active ticket context.
- Open the specific ticket file when you need exact scope, sequencing, or communication wording.
- Update the per-ticket file first when ticket context changes materially.

67
project-knowledge/02-work-items/pdiap-14859.md Normal file
View File

@@ -0,0 +1,67 @@
---
type: work-item
project: fidelity
status: active
ticket: PDIAP-14859
title: "Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation"
systems: [xflowsdk, xflowviewmaker, fid4, ftframeworks]
workstreams: [xflow-swiftui-migration, consumer-integration]
people: [jeff-dewitte, quy-mai]
related: [pdiap-15836]
updated: 2026-04-16
tags:
- work-item
- fidelity
- xflow
- swiftui
---
# PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
## Status
- Active
- Rollout draft prepared and sent to Jeff for review on April 13, 2026
- Rollout document approved for publication; publish and close out the spike next
---
## Current Framing
- Approved title: `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
- This work is currently framed in the workspace as a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
- The remaining deliverable is process-oriented, not just technical implementation.
---
## Current Scope
- Define a consumer-facing rollout plan for the broader UIKit-removal work.
- Preserve both UIKit and SwiftUI paths appropriately while introducing the new path safely.
- Cover risky entry points such as `FTTransfer`, while keeping the latest spike finding explicit that consumer-side changes there may no longer be strictly required after the SwiftUI dismissal behavior is applied correctly.
- Include validation expectations in `XQ1`.
- Use a global feature-flag rollout model rather than entry-point-based enablement.
- Include consumer communication expectations.
- Include a 30-day production period with no reported bugs before final removal.
- Include a follow-up release to remove the feature flag and old code after rollout confidence is achieved.
---
## Notes
- The feature-flag and rollout planning guidance applies to the broader UIKit-removal spike, not only to dismissal-sequencing work.
- Jeff suggested sending the process-oriented rollout document to Quy for feedback when ready.
- The draft shared with Jeff already reflects the global feature flag, broad `XQ1` validation, and consumer-facing rollout flow guidance.
- Additional review feedback from April 13: rename the proposed flag to `xflow-swiftui-enabled`, make consumer contact and `XQ1` validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification.
- On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section.
- April 15 clarification: do not reuse the existing SwiftUI LaunchDarkly flag for this rollout.
- The new flag name for this work should be `xflow-swiftui-container-enabled`.
- The document should note that the flag is `to be added in the future as part of implementation`.
- Late April 14 guidance: the document was approved late in the day; the next step is to publish it, then close out the spike by commenting `Spike Results:` with the relevant document links and the new follow-up story link.
- The new follow-up story should also be marked as a blocker for the reopened UIKit-removal story.
---
## Related Work
- Related consumer rollout thinking should stay aligned with `PDIAP-15836`.
- `PDIAP-15838` should not be framed as part of this UIKit-removal spike.

80
project-knowledge/02-work-items/pdiap-15765.md Normal file
View File

@@ -0,0 +1,80 @@
---
type: work-item
project: fidelity
status: active
ticket: PDIAP-15765
title: "AO DOB field error not showing investigation"
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4, cogstore]
workstreams: [ao-discourse, xflow-debugging, consumer-integration]
people: [jeff-dewitte, gurram-santosh, raj-sundararaj]
related: [pdiap-15838]
updated: 2026-04-17
tags:
- work-item
- fidelity
- ao
- xflow
---
# PDIAP-15765 - AO DOB field error not showing investigation
## Status
- Active closeout
- Small XFlowSDK compatibility fix merged and released in XFlow `2.8.48`
- XFlowViewMaker was updated to the new XFlow version, approved, and published after the required code-owner approval
- The downstream Fid4 update is in progress through an open consumer PR
---
## Context
- This ticket is tied to an AO DOB validation issue.
- The issue was confirmed for authenticated users in the `HybridYouthAccountOpening` flow on the `TeenIdentityCheck` page.
---
## Confirmed Findings
- The issue reproduces only for authenticated users based on the currently stored evidence.
- The Youth / `TeenIdentityCheck` scenario is the iOS-only issue; do not describe it as reproducing on Android.
- Root cause was documented.
- The original external report was incomplete.
- For the config discussion, `CheckIdentity` was already correct. The `TeenIdentityCheck` issue had two config gaps inside `validation-rules`: the root key should be `validations`, and the age gate also needs `eighteenOrAbove` there when that rule is required.
- Follow-up validation on April 13 showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
- A `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario reproduces on both iOS and Android.
- A `HybridYouthAccountOpening` / `TeenIdentityCheck` scenario works on Android but fails on iOS.
- Current evidence suggests Android is more flexible in how it decodes rule variations, while iOS is stricter about the expected `validation-rules` structure.
- Later validation on April 15 showed the original `HybridYouthAccountOpening` / `TeenIdentityCheck` issue no longer reproduces once the payload uses `validations` instead of `birthDate`.
- A minimal XFlowSDK fix was still prepared on April 15 so the iOS `.apxDateSelect` path also falls back to `birthDate` for a future release.
- Jeff confirmed on April 15 that this minimal iOS fallback is the right fix direction for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
- On April 16, Jeff decided the iOS PR should be the primary fix path for the Youth / `TeenIdentityCheck` issue rather than relying on a separate service rollout.
- Later on April 16, the PR received final approval, was merged, and the XFlow release was cut as version `2.8.48`.
---
## Current Guidance
- Treat the iOS-only `HybridYouthAccountOpening` / `TeenIdentityCheck` discrepancy as the main client-side issue currently aligned with the story.
- Keep the cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario separate until it is clear whether it is a service/config issue, a distinct bug, or an unreported rule-processing difference.
- Keep the authenticated-user qualifier whenever this ticket is mentioned.
- Do not describe it as a generic validation issue without the `TeenIdentityCheck` and auth context.
- The originally reported Youth issue was fixed for the Youth-flow `TeenIdentityCheck` path by the service-side payload update from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK fallback PR should still be released so iOS handles the older `birthDate` format more safely.
- That service-side Youth fix was later rolled back in QA so the iOS PR can remain the single fix path; local Fid4 validation with the PR still confirmed the `birthDate` validation works correctly.
- Jeff provided historical context that these fallback paths exist largely to accommodate older AO payload conventions; when the issue is AO-specific, iOS-only, and caused by a service-vs-SDK key mismatch, this kind of iOS fallback is the usual fix.
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is different from the original Youth report: the rule content itself does not include `ageRange` or `eighteenOrAbove`, so that path still points to a service-side update rather than the same iOS parsing gap.
- David compared `HybridBrokerageAccountOpening` / `JointIdentityCheck` in Cogstore and found the relevant rule content is the same in QA and Production despite different flow-definition versions, so that separate issue should also exist in Production.
- The small iOS PR should be described as a compatibility safeguard for future older-format payloads and should not be framed as applying to the `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
- The service-side `birthDate` -> `validations` change and the small iOS PR both relate to the same Youth / `TeenIdentityCheck` issue; they should not be described as separate Youth issues.
---
## Next Step
- The XFlowViewMaker approval and publish step are now complete.
- Resolve the Fid4 dependency conflict through the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
- The podspec-repo PR was sent to Tauf and approved.
- After that merge, `pod install --repo-update` in Fid4 worked because the published podspecs no longer restricted the XFlowViewMaker version.
- A Fid4 PR with the latest versions is now open; continue with the consumer PR/review path now that dependency resolution is unblocked.
- After the Fid4 PR merges, treat the app release as the final downstream step before broader user visibility.
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
- Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.

55
project-knowledge/02-work-items/pdiap-15836.md Normal file
View File

@@ -0,0 +1,55 @@
---
type: work-item
project: fidelity
status: active
ticket: PDIAP-15836
title: "Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment"
systems: [xflowsdk, xflowviewmaker, ftframeworks]
workstreams: [xflow-swiftui-migration, consumer-integration]
people: [jeff-dewitte]
related: [pdiap-14859]
updated: 2026-04-16
tags:
- work-item
- fidelity
- xflow
- swiftui
---
# PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
## Status
- Approved
- Sequenced after `PDIAP-15838`
- Sized at `8` points
---
## Context
- This story came out of the `AccountLink` root cause investigation.
- It is tied to the dismissal sequencing problem found after UIKit removal in SwiftUI-only paths.
- The root cause document was updated and the revised wording was approved.
---
## Approved Scope
- Modernize dismissal delegate lifecycle sequencing for pure SwiftUI flows.
- Cover the missing lifecycle contract where delegate callbacks can happen before the view is fully removed.
- Validate the change across affected SwiftUI flows rather than only in one narrow reproduction.
---
## Sequencing And Dependencies
- This story should come after `PDIAP-15838`.
- It is aligned with epic `26Q2 - Updating XFlowSDK to Decouple and Fix ApexKit Dependencies (Split Part 2)`.
- If possible, it should use the same consumer-impact feature flag strategy as the broader UIKit-removal rollout.
---
## Communication Notes
- Keep the scope framed as lifecycle sequencing in a pure SwiftUI environment, not only as a symptom like multiple modal presentation.
- If mentioned externally, keep it separate from `PDIAP-15838`.

54
project-knowledge/02-work-items/pdiap-15838.md Normal file
View File

@@ -0,0 +1,54 @@
---
type: work-item
project: fidelity
status: active
ticket: PDIAP-15838
title: "Remove Apollo for iOS"
systems: [xflowsdk]
workstreams: [rest-migration]
people: [jeff-dewitte]
related: []
updated: 2026-04-16
tags:
- work-item
- fidelity
- rest
- graphql
---
# PDIAP-15838 - Remove Apollo for iOS
## Status
- Approved
- Next story to work on
- Sized at `8` points
---
## Context
- This ticket covers the REST migration cleanup on iOS.
- The approved title is `Remove Apollo for iOS`.
---
## Approved Scope
- Remove Apollo from iOS.
- Remove GraphQL-specific networking code.
- Remove related tests and mocks.
- Remove transport feature flags so REST remains.
---
## Current Guidance
- Do not frame this ticket as directly tied to the UIKit-removal spike.
- Do not imply it is dependent on or part of dismissal-sequencing work.
- Keep the migration framing explicit: REST remains behind a feature flag until otherwise confirmed, and GraphQL fallback context still matters when describing the overall migration.
---
## Sequencing
- This is the next story to work on before `PDIAP-15836`.

82
project-knowledge/03-context/index.md Normal file
View File

@@ -0,0 +1,82 @@
---
type: context-index
project: fidelity
updated: 2026-04-17
tags:
- context
- map
---
# Context Index
## Goal
Keep stable Fidelity context organized by domain so engineers and AI agents can load the right information quickly.
---
## Structure
### `project.md`
High-level overview of the workspace, current Fidelity scope, and where durable context lives.
### `systems/`
Stable context about core product components and how they relate:
- [systems/fid4.md](./systems/fid4.md)
- [systems/xflowsdk.md](./systems/xflowsdk.md)
- [systems/xflowviewmaker.md](./systems/xflowviewmaker.md)
- [systems/ftframeworks.md](./systems/ftframeworks.md)
- [systems/index.md](./systems/index.md)
- [../07-maps/fidelity-apps.md](../07-maps/fidelity-apps.md) for internal Fidelity app/tool navigation
### `ios/`
Swift and iOS best-practice context for programming questions:
- [ios/index.md](./ios/index.md)
- [ios/current-practices.md](./ios/current-practices.md)
- [ios/project-swift-guidance.md](./ios/project-swift-guidance.md)
- [ios/cocoapods-dependency-management.md](./ios/cocoapods-dependency-management.md)
### `workstreams/`
Durable context about recurring streams of work and investigation:
- [workstreams/rest-migration.md](./workstreams/rest-migration.md)
- [workstreams/ao-discourse.md](./workstreams/ao-discourse.md)
- [workstreams/xflow-debugging.md](./workstreams/xflow-debugging.md)
- [workstreams/xflow-swiftui-migration.md](./workstreams/xflow-swiftui-migration.md)
- [workstreams/consumer-integration.md](./workstreams/consumer-integration.md)
- [workstreams/flow-page-references.md](./workstreams/flow-page-references.md)
### `process/`
Project-facing rules and expectations for how work should be communicated:
- [process/communication.md](./process/communication.md)
- [process/communication-rules.md](./process/communication-rules.md)
- [process/jira-story-rules.md](./process/jira-story-rules.md)
- [process/pull-requests.md](./process/pull-requests.md)
### `people/`
Named people, role mapping, and collaboration context:
- [people/index.md](../04-people/index.md)
- [people/manager.md](../04-people/manager.md)
### `decisions/`
Confirmed technical or product decisions with ongoing impact.
---
## Usage
- Load `project.md` and this index first.
- Open `systems/` when the question is about architecture, ownership, or integration.
- Open `ios/` when the question is about Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging.
- Open `workstreams/` when the question is about current priorities, debugging themes, or historical project patterns.
- Open `process/` when drafting messages, standups, Jira notes, or PR descriptions.

78
project-knowledge/03-context/ios/cocoapods-dependency-management.md Normal file
View File

@@ -0,0 +1,78 @@
---
type: guidance
project: fidelity
status: active
updated: 2026-04-17
tags:
- ios
- cocoapods
- dependencies
- fidelity
---
# CocoaPods Dependency Management
## Goal
Help the agent reason correctly about CocoaPods behavior, private podspec repos, and release propagation in the Fidelity iOS ecosystem.
---
## Why This Matters Here
- CocoaPods is a core part of how XFlowSDK changes reach XFlowViewMaker, FTFrameworks, and Fid4.
- Many apparent SDK or consumer issues are actually dependency-resolution or published-podspec issues.
- The workspace should treat CocoaPods knowledge as part of normal investigation and release reasoning, not as an edge case.
---
## Fidelity-Specific Context
- XFlowSDK releases publish artifacts and podspec updates that downstream consumers adopt through CocoaPods.
- XFlowViewMaker, FTAccountOpen, FTTransfer, and Fid4 propagation all depend on correct podspec and resolver behavior.
- The effective dependency constraint can come from the published podspec repo layer, not only from the source repo that developers inspect first.
- Fid4 currently does not keep `Podfile.lock` in Git, which weakens reproducibility and makes published podspec changes more operationally significant.
---
## Agent Rules
- When a newly published dependency does not resolve in Fid4, check CocoaPods resolution before assuming the code change failed.
- Distinguish these layers:
- source repo podspec or helper code
- published private podspec repo
- consumer `Podfile`
- local/pipeline lockfile state
- Do not assume FTFrameworks source tells the whole truth about the active dependency graph.
- Treat private podspec repo edits as high-signal release-path behavior that may explain why local or pipeline resolution differs from expectations.
- When giving advice, separate:
- what fixed the immediate unblock
- what is healthy long-term dependency management
---
## CocoaPods Best-Practice Anchors
- CocoaPods podspecs are expected to declare dependency requirements explicitly.
- CocoaPods documentation recommends the optimistic operator `~>` because it provides version control without being overly restrictive.
- Overly restrictive dependency requirements can block compatibility.
- Removing dependency constraints entirely can weaken compatibility guarantees and make transitive resolution less predictable.
- `pod install` is the normal command after dependency-definition changes; `pod update` is for intentionally updating pod versions.
- `Podfile.lock` is important for reproducible installs and should normally be committed.
---
## Current Project Caution
- In this project, removing the XFlowViewMaker version reference from published `FTAccountOpen` and `FTTransfer` podspecs unblocked Fid4 resolution.
- That should be understood as the current operational fix, not automatically as the ideal dependency-management pattern.
- Because `Podfile.lock` is not committed in Fid4, broad podspec-repo edits can silently change future resolutions more than they should in a healthier CocoaPods setup.
---
## What Good Answers Should Include
- Whether the issue is in source code, published specs, or consumer resolution
- Whether `pod install`, `pod install --repo-update`, or `pod update` is the appropriate command for the stated goal
- Whether the current fix improves compatibility or only removes guardrails
- Whether the result is reproducible or vulnerable to future resolver drift
- Whether the advice is a short-term unblock or a durable recommendation

94
project-knowledge/03-context/ios/current-practices.md Normal file
View File

@@ -0,0 +1,94 @@
---
type: guidance
project: fidelity
status: active
updated: 2026-04-16
tags:
- ios
- fidelity
---
# Current iOS And Swift Practices
## Goal
Keep Swift/iOS answers modern without turning the workspace into stale API documentation.
---
## Currentness Rule
For version-sensitive recommendations, verify against official sources before presenting as current best practice.
Prefer:
- Apple Developer Documentation
- Swift.org / docs.swift.org
- official WWDC materials when API behavior or migration guidance matters
Avoid relying only on memory for:
- newest SwiftUI APIs
- Observation / data-flow migration guidance
- Swift Testing availability or migration advice
- Swift concurrency behavior
- Xcode or iOS version-specific recommendations
- CocoaPods, podspec, private specs repo, trunk/CDN, or dependency-resolution behavior
- Swift Package Manager migration or package-resolution behavior
- CI/build tooling behavior that may depend on current toolchain versions
- claims that something is a "bad practice" when the answer depends on ecosystem status, migration cost, or project constraints
---
## Technical Verification Rule
For programming concepts tied to project decisions, the agent should behave like a senior engineer:
- distinguish stable engineering principles from ecosystem-specific guidance
- verify current tool behavior with primary documentation when the topic is version-sensitive
- separate general best practice from project-safe recommendation
- avoid blanket statements such as "CocoaPods is bad practice" without context
- explain tradeoffs: maintenance status, migration cost, consumer integration risk, release propagation, and validation path
- suggest workspace improvements when a recurring answer-quality gap appears
For Fidelity, dependency tooling is project-relevant because XFlowSDK, XFlowViewMaker, FTFrameworks, and Fid4 integration can depend on published versions, podspec repos, release propagation, and consumer validation.
---
## Stable Defaults
- Prefer simple, testable Swift over clever abstractions.
- Prefer structured concurrency over ad-hoc callback or detached-task patterns when the deployment target and codebase support it.
- Keep UI state changes on the main actor.
- Avoid recommending new APIs until deployment target and project constraints are known.
- For SwiftUI, separate pure view composition from side effects and navigation/workflow coordination.
- For testing, use the framework already adopted by the codebase unless the user explicitly asks about migration.
---
## Testing Guidance
- Apple positions Swift Testing as a modern option for unit tests in Xcode 16 and later.
- XCTest remains relevant, especially for UI tests, performance tests, and existing test suites.
- Do not recommend wholesale migration from XCTest unless the project constraints support it.
---
## SwiftUI Guidance
- Observation can be adopted incrementally; do not assume a project can immediately replace all `ObservableObject` usage.
- In SwiftUI code review, focus on data ownership, lifecycle, invalidation scope, navigation boundaries, and side effects.
- Avoid introducing `@StateObject`, `@ObservedObject`, `@State`, or `@Observable` recommendations without first identifying ownership and deployment constraints.
---
## Source Anchors
- SwiftUI documentation: `https://developer.apple.com/documentation/swiftui`
- Observation migration: `https://developer.apple.com/documentation/swiftui/migrating-from-the-observable-object-protocol-to-the-observable-macro`
- Swift Testing: `https://developer.apple.com/documentation/testing`
- XCTest: `https://developer.apple.com/documentation/xctest`
- Swift language: `https://developer.apple.com/swift/`
- CocoaPods Build with CocoaPods: `https://guides.cocoapods.org/making/`
- CocoaPods Specs and Specs Repo: `https://guides.cocoapods.org/making/specs-and-specs-repo.html`
- CocoaPods Private Pods: `https://guides.cocoapods.org/making/private-cocoapods`
- CocoaPods trunk read-only plan: `https://blog.cocoapods.org/CocoaPods-Specs-Repo/`

36
project-knowledge/03-context/ios/index.md Normal file
View File

@@ -0,0 +1,36 @@
---
type: guidance-index
project: fidelity
status: active
updated: 2026-04-17
tags:
- ios
- fidelity
---
# iOS And Swift Context
## Goal
Help the agent answer Swift and iOS programming questions with current best practices while still respecting Fidelity/XFlow project constraints.
---
## Files
- [current-practices.md](./current-practices.md)
Rules for staying current with Apple and Swift best practices.
- [project-swift-guidance.md](./project-swift-guidance.md)
Fidelity-specific guidance for applying Swift/iOS advice in this workspace.
- [cocoapods-dependency-management.md](./cocoapods-dependency-management.md)
CocoaPods, private podspec repo, and dependency-resolution guidance for Fidelity release and consumer integration work.
---
## Usage
- Use these files before answering Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging questions.
- Use the CocoaPods guidance whenever the question touches release propagation, podspecs, dependency conflicts, Fid4 resolution, or FTFrameworks consumer updates.
- When a recommendation depends on current Apple APIs, prefer official Apple or Swift documentation before making strong claims.
- Keep project constraints visible: XFlow is backend-driven, Fid4 is consumer validation, and REST/GraphQL migration constraints may affect architecture.

50
project-knowledge/03-context/ios/project-swift-guidance.md Normal file
View File

@@ -0,0 +1,50 @@
---
type: guidance
project: fidelity
status: active
updated: 2026-04-17
tags:
- ios
- fidelity
---
# Project Swift Guidance
## Goal
Apply Swift/iOS advice in a way that fits Fidelity's XFlow, Fid4, XFlowViewMaker, and FTFrameworks environment.
---
## Fidelity-Specific Constraints
- XFlow is backend-driven; UI behavior may be service/configuration driven, not purely local Swift code.
- Fid4 is the real consumer validation target for many issues.
- XFlowViewMaker and FTFrameworks can affect whether a fix is visible in Fid4.
- CocoaPods and private podspec-repo behavior are part of the real integration surface, not just build tooling details.
- REST migration constraints still matter; do not assume REST is active by default.
- Some work happens behind feature flags, especially risky consumer-impact changes.
---
## SwiftUI / XFlow Priorities
- Treat modal presentation, dismissal sequencing, and lifecycle boundaries as high-risk areas.
- Be careful when removing UIKit bridges such as `UIHostingController`; preserve consumer behavior and rollout safety.
- When discussing SwiftUI architecture, include how the change affects:
- backend-driven flow rendering
- consumer app integration
- feature flags
- validation in Fid4
- UIKit/SwiftUI parity
---
## Answering Rules
- If the user asks a general Swift question, answer generally but include a Fidelity/XFlow note when relevant.
- If the user asks about a code change, separate modern best practice from what is safe for the current project.
- If codebase constraints are unknown, say what must be confirmed: deployment target, Xcode version, module ownership, feature flag path, and consumer validation path.
- If the work touches dependency propagation, published specs, or consumer upgrade behavior, explicitly include CocoaPods and podspec-repo reasoning instead of treating them as secondary operational noise.
- If the user asks whether CocoaPods, podspec repositories, or dependency propagation is good/bad practice, corroborate with current CocoaPods/Apple/Swift documentation and then adapt the recommendation to Fidelity's release path.
- Do not recommend replacing CocoaPods with SPM just because SPM is modern; first identify current integration constraints, private specs usage, release ownership, consumer app expectations, and migration cost.
- For manager-ready explanations, connect the technical recommendation to scope, risk, and validation.

65
project-knowledge/03-context/process/communication-rules.md Normal file
View File

@@ -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.

60
project-knowledge/03-context/process/communication.md Normal file
View File

@@ -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.

31
project-knowledge/03-context/process/index.md Normal file
View File

@@ -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`.

39
project-knowledge/03-context/process/jira-story-rules.md Normal file
View File

@@ -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.

43
project-knowledge/03-context/process/pull-requests.md Normal file
View File

@@ -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.

72
project-knowledge/03-context/project.md Normal file
View File

@@ -0,0 +1,72 @@
---
type: project-context
project: fidelity
updated: 2026-04-17
tags:
- fidelity
- context
---
# Project Context - Fidelity
## Overview
This workspace supports daily iOS engineering work for Fidelity.
The product work happens outside this repository, usually from another machine. This repository exists to preserve context, track communication, and help AI generate accurate output for standups, Mattermost messages, Jira notes, and supervisor updates.
---
## Fidelity Ecosystem
- Fid4 is the main consumer iOS app
- XFlowSDK powers backend-driven UI flows
- XFlowViewMaker is an adapter layer under evaluation for removal
- FTFrameworks contains feature modules such as FTAccountOpen and FTTransfer
- Cogstore is the configuration publishing/version-tracking platform used to inspect which flow-definition versions are live in QA or Production
---
## Stable Context Map
- Core systems live under:
- `project-knowledge/03-context/systems/`
- Durable workstreams live under:
- `project-knowledge/03-context/workstreams/`
- Project-facing communication and process rules live under:
- `project-knowledge/03-context/process/`
- Named people and role mapping live under:
- `project-knowledge/04-people/`
The Slack archive has already been curated into these files so future sessions do not need to rediscover the same patterns from raw history.
---
## Current Priorities
- REST migration is replacing GraphQL over time, but REST is still behind a feature flag
- AO and Discourse issues require careful classification because many are incomplete, external, or auth-dependent
- XFlow debugging remains dynamic because behavior changes by entry point, authentication state, backend configuration, and consumer integration
- Consumer validation often depends on Fid4, FT modules, and version propagation, not just SDK behavior
---
## Workspace Use
This machine is used to:
- maintain current project context
- record findings from work performed elsewhere
- capture communication that changes technical understanding
- prepare polished updates for the current manager or stakeholder
- generate standups with better context coverage
This means the context files should hold durable engineering knowledge, while `project-knowledge/06-daily/` and `project-knowledge/01-current/` hold the moving day-to-day view.
---
## First Files To Read
- `project-knowledge/03-context/index.md`
- `project-knowledge/03-context/workstreams/index.md`
- `project-knowledge/03-context/process/communication.md`
- `project-knowledge/04-people/index.md`

40
project-knowledge/03-context/systems/almx-toolbox.md Normal file
View File

@@ -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`

54
project-knowledge/03-context/systems/artifactory.md Normal file
View File

@@ -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`

42
project-knowledge/03-context/systems/cogstore.md Normal file
View File

@@ -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.

38
project-knowledge/03-context/systems/confluence.md Normal file
View File

@@ -0,0 +1,38 @@
---
type: system
project: fidelity
status: active
systems: []
workstreams: []
people: []
related: []
tags:
- system
- fidelity
updated: 2026-04-17
---
# Confluence
## Role
- Internal documentation/wiki surface used across Fidelity workflows.
---
## 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`

39
project-knowledge/03-context/systems/discourse.md Normal file
View File

@@ -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`

53
project-knowledge/03-context/systems/fid4.md Normal file
View File

@@ -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.

38
project-knowledge/03-context/systems/fidelity-central.md Normal file
View File

@@ -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`

48
project-knowledge/03-context/systems/ftframeworks.md Normal file
View File

@@ -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.

89
project-knowledge/03-context/systems/index.md Normal file
View File

@@ -0,0 +1,89 @@
---
type: system-index
project: fidelity
status: active
updated: 2026-04-16
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.
- [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.
---
## 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.

50
project-knowledge/03-context/systems/iosinstaller.md Normal file
View File

@@ -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`

38
project-knowledge/03-context/systems/miro.md Normal file
View File

@@ -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`

40
project-knowledge/03-context/systems/myaccess.md Normal file
View File

@@ -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`

40
project-knowledge/03-context/systems/nexus-fidelity.md Normal file
View File

@@ -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`

39
project-knowledge/03-context/systems/slate.md Normal file
View File

@@ -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`

39
project-knowledge/03-context/systems/splunk.md Normal file
View File

@@ -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`

39
project-knowledge/03-context/systems/trackit.md Normal file
View File

@@ -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`

41
project-knowledge/03-context/systems/vault-preprod.md Normal file
View File

@@ -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 `project-knowledge/` documentation directory.
---
## Related Context
- `vault.md`

38
project-knowledge/03-context/systems/vault.md Normal file
View File

@@ -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 `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`

41
project-knowledge/03-context/systems/wukong.md Normal file
View File

@@ -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`

59
project-knowledge/03-context/systems/xflowsdk.md Normal file
View File

@@ -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.

58
project-knowledge/03-context/systems/xflowviewmaker.md Normal file
View File

@@ -0,0 +1,58 @@
---
type: system
project: fidelity
status: active
workstreams: [consumer-integration, xflow-swiftui-migration]
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
updated: 2026-04-17
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.
---
## 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.

40
project-knowledge/03-context/systems/xq1-portfolio-summary.md Normal file
View File

@@ -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`

50
project-knowledge/03-context/workstreams/ao-discourse.md Normal file
View File

@@ -0,0 +1,50 @@
---
type: workstream
project: fidelity
status: active
systems: [xflowsdk, fid4, cogstore]
work-items: [pdiap-15765]
related: [xflow-debugging, flow-page-references]
updated: 2026-04-16
tags:
- workstream
- fidelity
---
# AO And Discourse Issues
## Goal
Handle externally reported issues without misclassifying scope or over-claiming regression.
---
## Stable Patterns
- AO and Discourse reports are often incomplete or partially reproducible.
- External reports should be treated as external behavior until verified.
- Many issues only reproduce with authenticated users or in consumer-specific contexts.
- Some historical reports turned out to be service/configuration issues, environment issues, or existing behavior rather than new regressions.
- AO-backed flows still carry older service conventions that can differ from what newer XFlow SwiftUI paths were primarily validated against.
- In at least some AO validation cases, iOS expected `validations` while older AO payloads could still send fallback-style keys such as `birthDate`.
---
## Investigation Rules
- Always clarify:
- authenticated vs non-authenticated
- reproducibility
- entry point
- whether the issue exists in main
- whether the behavior is external, existing, or regression
- Do not use vague comparison phrases like "same behavior" without scope.
- For AO consumers, check whether the payload shape reflects older AO service conventions before concluding the issue is purely client-side.
- If iOS-only behavior appears around validation decoding, compare what AO sends against older fallback handling already present in XFlow, especially when Android appears more permissive.
---
## Historical Signals From Slack
- Historical reports around button visibility, analytics, slot updates, and consumer validation repeatedly required deeper reproduction work before scoping a fix.
- Slack history shows multiple examples where the original ticket or report was not enough to define the real root cause.
- Jeff clarified on April 15, 2026 that these fallback validation paths exist largely to accommodate AO flows. AO was the earliest service integration, built around older custom backend tooling and harder-to-change payload conventions, while newer consumer services were primarily built through Slate and aligned more naturally with `validations` during the SwiftUI refactor.

111
project-knowledge/03-context/workstreams/consumer-integration.md Normal file
View File

@@ -0,0 +1,111 @@
---
type: workstream
project: fidelity
status: active
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4]
updated: 2026-04-17
tags:
- workstream
- fidelity
---
# Consumer Integration And Release
## Goal
Capture the durable release and validation path between XFlow changes and real consumer behavior.
---
## Stable Patterns
- End-to-end validation often requires more than an SDK change.
- Historical Slack evidence shows repeated coupling across:
- XFlowSDK
- XFlowViewMaker
- FTFrameworks modules
- Fid4 / flagship
- Version pins, publishing delays, and consumer build issues can block validation even when the original code change is ready.
---
## Current Release Propagation Model
- The current release path is usually:
- `pr100660-xflow-for-ios` releases XFlowSDK
- `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release
- `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version
- downstream consumer release then determines when the change reaches the App Store build
- A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated.
- In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
- In the current integration model, Fid4 consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
- For current-state reasoning and communication, treat XFlowViewMaker as a required part of the Fid4 propagation path, not as an optional or "usually" present layer.
- Other frameworks also consume XFlow through XFlowViewMaker, especially `FTAccountOpen` and `FTTransfer`.
- For Account Opening paths, the practical consumer route is currently understood to run through `FTAccountOpen`.
---
## Step-By-Step Propagation
1. Release XFlowSDK from `pr100660-xflow-for-ios`.
- Jenkins pipeline: `xflow-for-ios-publish`
- Produces the XCFramework artifact
- Publishes to internal Fidelity Artifactory at `artifactory.fmr.com`
- Publishes the podspec to the dedicated podspec repo `ap010981-ios_podspecs_3x`
- After publication, consumers can adopt the new SDK version through CocoaPods
2. Update and release XFlowViewMaker from `PR100660-ios-frameworks`.
- XFlowViewMaker lives in `Adapters/XFlowViewMaker`
- Update the XFlowViewMaker podspec to the new XFlowSDK version
- Run `tuist generate -n`
- Run `pod install`
- Open a PR and get required approvals
- Ping code owners when protected-branch approval is the remaining blocker
- After merge, the `publish-XFlowViewMaker` Jenkins pipeline publishes the adapter
- That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example `0.5.0` -> `0.6.0`
- Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on `main`
3. Update Fid4 in `ap010981-ios-flagship-app`.
- Modify the Podfile to consume the new XFlowViewMaker version
- Run `tuist generate -n`
- Run `pod install --repo-update`
- Open a PR and get approvals
- After merge, the consumer team owns the final application release to the App Store
---
## Investigation Rules
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
- When the question is specifically about Account Opening, verify the path through `FTAccountOpen` before assuming a direct Fid4-only dependency view is sufficient.
- Separate these failure modes:
- SDK bug
- adapter/version propagation issue
- protected-branch or code-owner approval delay
- publish pipeline failure or auto-versioning surprise
- FT module publish/test issue
- consumer app setup or pipeline issue
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
- Version verification in Fid4 is not always straightforward because `Podfile.lock` is currently ignored in the app repo.
- The fastest reliable signals are:
- fixed version references in the Podfile when present
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
- Useful Fidelity-specific sources include `iosinstaller`, which exposes App Store/internal builds plus their `Podfile.lock`, and the Flagship app pipeline artifact `appstore/DistributionSummary.plist`, which records the framework versions included in a shipped build.
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
- When a consumer build must be reproduced exactly from an older dependency snapshot, `Podfile.lock` alone may still be insufficient if the private podspec repo changed afterward; the stronger reproduction path is to align the podspec repo revision too.
- A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
- Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
- Current evidence suggests the effective constraint may live in the podspec repo layer rather than in the FTFrameworks source repo itself.
- For the current XFlowViewMaker propagation issue, the practical fix was made in the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
- After that podspec-repo PR was merged, `pod install --repo-update` in Fid4 resolved successfully because those podspecs no longer constrained the XFlowViewMaker version.
- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their checked FTFrameworks source podspec files; the effective resolution is managed through the published podspec layer and `ftAdapter` behavior.
- This appears to be a risky workaround rather than a healthy long-term dependency-management pattern.
- CocoaPods documentation recommends explicit dependency requirements in podspecs and specifically recommends the optimistic operator `~>` because it gives version control without being overly restrictive.
- Removing version constraints entirely from published intermediate podspecs weakens compatibility guarantees, makes transitive resolution less predictable, and increases the chance that consumers pick up unvalidated downstream versions.
- That risk is even higher in this workspace because Fid4 does not keep `Podfile.lock` in Git, so published podspec changes can alter future resolutions without a strong repository-level lockfile trail.
---
## Historical Signals From Slack
- Version bump work repeatedly involved XFlowViewMaker, FTAccountOpen, and FTTransfer.
- Some rollout problems involved Jenkins, Apex/ApexKit, preview macro compatibility, or secret/token access rather than the product behavior under investigation.

37
project-knowledge/03-context/workstreams/flow-page-references.md Normal file
View File

@@ -0,0 +1,37 @@
---
type: workstream
project: fidelity
status: active
systems: [xflowsdk, cogstore]
work-items: [pdiap-15765]
related: [ao-discourse, xflow-debugging]
updated: 2026-04-16
tags:
- workstream
- fidelity
---
# Flow And Page References
## Goal
Keep recurring flow names, page names, and shorthand references aligned so debugging notes and external updates do not drift into ambiguous wording.
---
## Current Mappings
- `HybridYouthAccountOpening`
- This is the real flow identifier when David refers to the Youth flow in recent AO validation discussions.
- The relevant page in this flow is `TeenIdentityCheck`.
- `HybridBrokerageAccountOpening`
- This is the separate authenticated flow discussed alongside the Youth issue.
- The relevant page in this flow is `JointIdentityCheck`.
---
## Usage
- When drafting updates, prefer the real flow identifier if there is any risk that shorthand like `Youth flow` or `HybridBrokerage` could be misunderstood.
- When a shorthand is still useful for readability, keep the real flow ID available somewhere in the same session context.
- Capture additional stable flow/page mappings here when they come up repeatedly in debugging, standups, Jira comments, or consumer communication.

38
project-knowledge/03-context/workstreams/index.md Normal file
View File

@@ -0,0 +1,38 @@
---
type: workstream-index
project: fidelity
status: active
updated: 2026-04-16
tags:
- workstream
- fidelity
---
# Workstreams Index
## Active Durable Workstreams
- [rest-migration.md](./rest-migration.md)
GraphQL deprecation and REST rollout constraints.
- [ao-discourse.md](./ao-discourse.md)
External issue intake, ambiguity, and authenticated-only reproduction patterns.
- [xflow-debugging.md](./xflow-debugging.md)
How to reason about backend-driven flows and dynamic behavior.
- [xflow-swiftui-migration.md](./xflow-swiftui-migration.md)
Historical SwiftUI transition themes that still shape XFlow work.
- [consumer-integration.md](./consumer-integration.md)
Release and validation coupling across XFlow, XFlowViewMaker, FT modules, and Fid4.
- [flow-page-references.md](./flow-page-references.md)
Stable mapping between shorthand flow references and their real flow/page identifiers.
---
## Guidance
- Open `ao-discourse.md` before classifying external bug reports.
- Open `xflow-debugging.md` for reproduction and investigation framing.
- Open `consumer-integration.md` when the work depends on release propagation or validation in consumer apps.

44
project-knowledge/03-context/workstreams/rest-migration.md Normal file
View File

@@ -0,0 +1,44 @@
---
type: workstream
project: fidelity
status: active
systems: [xflowsdk]
work-items: [pdiap-15838]
related: [consumer-integration]
updated: 2026-04-16
tags:
- workstream
- fidelity
---
# REST Migration
## Goal
Deprecate GraphQL and Apollo safely while preserving behavior through REST-backed flows.
---
## Stable Constraints
- REST is behind a feature flag.
- GraphQL remains the default fallback unless confirmed otherwise.
- REST should never be assumed active by default.
- Migration work must preserve behavior parity before removing Apollo-related code.
---
## What Matters In Practice
- Validation must clarify whether the tested path is actually using REST or still falling back to GraphQL.
- Story scope should distinguish:
- transport migration work
- feature-flag cleanup
- tests and mocks tied to Apollo/GraphQL
- Communication should avoid implying the migration is complete before the fallback path is removed.
---
## Historical Signals From Slack
- Historical Slack evidence around release and dependency work reinforces that transport or dependency changes often require consumer validation, not just local SDK changes.
- Some dependency and pipeline issues complicated migration-related rollout even when the technical change itself was understood.

51
project-knowledge/03-context/workstreams/xflow-debugging.md Normal file
View File

@@ -0,0 +1,51 @@
---
type: workstream
project: fidelity
status: active
systems: [xflowsdk, fid4, cogstore, xflowviewmaker, ftframeworks]
work-items: [pdiap-15765, pdiap-14859, pdiap-15836]
related: [ao-discourse, consumer-integration, flow-page-references]
updated: 2026-04-16
tags:
- workstream
- fidelity
---
# XFlow Debugging
## Goal
Debug backend-driven flows without losing track of dynamic dependencies or misclassifying integration behavior.
---
## Stable Patterns
- XFlow screens are backend-driven, so UI can change without local code changes.
- Reproduction depends on:
- entry point
- authentication state
- backend configuration
- consumer integration path
- Not all entry points are reachable from visible UI; some require exploratory validation.
---
## Investigation Rules
- Confirm the entry point before comparing behavior.
- Separate service-driven behavior from client regressions.
- Confirm whether the issue reproduces in:
- sample app
- XFlow-only environment
- Fid4 / flagship
- authenticated vs non-authenticated state
- If a fix appears correct in the SDK but not in consumer validation, inspect the release chain before reopening root cause assumptions.
- When validating service/configuration changes, check the active flow-definition version in Cogstore before assuming a change is live in QA or Production.
- Do not assume a flow ID will exist in both Cogstore and Slate; verify which config system actually owns the flow you are inspecting.
---
## Historical Signals From Slack
- Historical debugging covered Next-button visibility, markdown modal analytics, modal presentation, slot updates, and SwiftUI lifecycle behavior.
- Multiple pipeline or dependency problems looked like XFlow issues until the build chain or consumer integration path was inspected more carefully.

47
project-knowledge/03-context/workstreams/xflow-swiftui-migration.md Normal file
View File

@@ -0,0 +1,47 @@
---
type: workstream
project: fidelity
status: active
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
work-items: [pdiap-14859, pdiap-15836]
related: [consumer-integration, xflow-debugging]
updated: 2026-04-16
tags:
- workstream
- fidelity
---
# XFlow SwiftUI Migration
## Goal
Track the durable behavior patterns introduced while moving XFlow from older assumptions toward a more complete SwiftUI implementation.
---
## Stable Themes
- SwiftUI migration was not just a UI rewrite; it exposed contract, lifecycle, and parity gaps.
- Historical Slack evidence repeatedly referenced:
- component type expansion beyond simple string assumptions
- Next-button visibility rules driven by full service parameters
- markdown link handling and analytics integration
- navigation and modal behavior in pure SwiftUI environments
- dismissal delegate lifecycle sequencing
---
## What Matters Now
- When a SwiftUI issue appears, check whether the missing behavior is:
- parity with UIKit behavior
- an incomplete service contract interpretation
- a lifecycle sequencing problem
- a consumer presentation constraint in Fid4
- Do not assume a visual issue is only cosmetic; several historical SwiftUI bugs changed flow behavior materially.
---
## Historical Signals From Slack
- Jeff and Norman repeatedly refined story titles and descriptions around SwiftUI architecture changes, showing that scope wording mattered because the work was often deeper than the first symptom.
- Historical Slack context also shows that SwiftUI-specific work frequently required cross-team clarification when external dependencies or consumer environments behaved differently.

27
project-knowledge/04-people/README.md Normal file
View File

@@ -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

34
project-knowledge/04-people/aylwing-olivas.md Normal file
View File

@@ -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

31
project-knowledge/04-people/bruce-meeks.md Normal file
View File

@@ -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

33
project-knowledge/04-people/david-delagneau.md Normal file
View File

@@ -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

36
project-knowledge/04-people/derian-cordoba.md Normal file
View File

@@ -0,0 +1,36 @@
---
type: person
project: fidelity
role: collaborator
status: inactive
updated: 2026-04-17
tags:
- person
- fidelity
---
# Derian Cordoba
## Role
Historical Fidelity collaborator in project support discussions.
- No longer works with the current All-Win Software / Mattermost / Slack collaboration group.
---
## 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
- Treat Derian as historical context, not a current active collaborator
- If future context clarifies the formal role or team, update this file directly

37
project-knowledge/04-people/erik-reynolds.md Normal file
View File

@@ -0,0 +1,37 @@
---
type: person
project: fidelity
role: collaborator
status: inactive
updated: 2026-04-17
tags:
- person
- fidelity
---
# Erik Reynolds
## Role
Historical Fidelity collaborator in XFlow-related discussions.
- Previously worked for Fidelity but no longer does.
---
## 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
- Treat Erik as historical Fidelity context, not a current active stakeholder
- If future context clarifies the formal role or team, update this file directly

35
project-knowledge/04-people/gurram-santosh.md Normal file
View File

@@ -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

64
project-knowledge/04-people/index.md Normal file
View File

@@ -0,0 +1,64 @@
---
type: people-index
project: fidelity
updated: 2026-04-17
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)
Former collaborator in historical Slack threads; primary implementer/investigator across SwiftUI, AO/Fid4 bugs, and release work, but no longer works with the current All-Win Software / Mattermost / Slack group.
- [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; previously worked for Fidelity but no longer does.
- [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; no longer works with the current All-Win Software / Mattermost / Slack group.
- [tauf.md](./tauf.md)
Taufiqur Ashrafy, often referred to as Tauf; CI/Jenkins support contact who helps with release-pipeline troubleshooting and related publication issues.
## 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

31
project-knowledge/04-people/jason-mandozzi.md Normal file
View File

@@ -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

76
project-knowledge/04-people/jeff-dewitte.md Normal file
View File

@@ -0,0 +1,76 @@
---
type: person
project: fidelity
role: manager
status: active
updated: 2026-04-17
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
- Acts as the main communication bridge into the Fidelity-side Teams context while David works from the All-Win Software side
---
## 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
- Jeff is often the person who reports progress or status into the Fidelity-facing context after David advances the implementation or investigation work
---
## 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

43
project-knowledge/04-people/manager.md Normal file
View File

@@ -0,0 +1,43 @@
---
type: role-map
project: fidelity
role: manager
status: active
updated: 2026-04-17
tags:
- role
- manager
- 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.
- In practice, Jeff is also the main bridge between David's All-Win Software work and the Fidelity-side reporting context.
---
## 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

35
project-knowledge/04-people/norman-arauz.md Normal file
View File

@@ -0,0 +1,35 @@
---
type: person
project: fidelity
role: collaborator
status: inactive
updated: 2026-04-17
tags:
- person
- fidelity
---
# Norman Arauz
## Role
Frequent Fidelity/XFlow engineer collaborator in historical Slack threads.
- No longer works with the current All-Win Software / Mattermost / Slack collaboration group.
---
## 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
- Treat Norman as historical context, not a current active collaborator
- If later communication clarifies the formal team/title, update this file directly

31
project-knowledge/04-people/quy-mai.md Normal file
View File

@@ -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

30
project-knowledge/04-people/raj-sundararaj.md Normal file
View File

@@ -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

44
project-knowledge/04-people/tauf.md Normal file
View File

@@ -0,0 +1,44 @@
---
type: person
project: fidelity
role: CI and Jenkins support
status: active
teams: [ci-cd, ios-frameworks]
topics: [jenkins, pipelines, podspec-publication, release-support]
related: [consumer-integration, pdiap-15765]
aliases: [Taufiqur Ashrafy, Tauf]
tags:
- person
- fidelity
updated: 2026-04-17
---
# Taufiqur Ashrafy
## Role
- CI / Jenkins support contact who helps unblock pipeline and publication issues.
---
## Collaboration Pattern
- David reaches out to Tauf when Jenkins or release-pipeline steps need support, especially around XFlowViewMaker publication or approval/pipeline follow-through.
- Tauf has been specifically relevant to the `PDIAP-15765` propagation work because David planned to ping him about the remaining XFlowViewMaker approval path.
---
## Communication Notes
- Useful contact for operational release and pipeline troubleshooting.
- David has seen podspec-repo edits happen after publication and specifically called out Tauf as someone involved in CI support around that ecosystem.
- Often referred to informally as `Tauf`.
- Fidelity Teams may show names in a surname-first style, so this person may appear under a different display order there.
- In the current XFlowViewMaker propagation issue, Tauf clarified that the needed fix belongs in the podspec repo rather than FTFrameworks source, and pointed David toward removing the XFlowViewMaker version constraint for `ftaccountopen`.
---
## Related Context
- `project-knowledge/03-context/workstreams/consumer-integration.md`
- `project-knowledge/02-work-items/pdiap-15765.md`

30
project-knowledge/04-people/tim-longfield.md Normal file
View File

@@ -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

48
project-knowledge/05-decisions/discourse-handling.md Normal file
View File

@@ -0,0 +1,48 @@
---
type: decision
project: fidelity
status: accepted
title: "Discourse Issues Handling"
updated: 2026-04-16
tags:
- decision
- fidelity
---
# Discourse Issues Handling
## Context
External reports from AO testing or Discourse may:
- already exist in main
- be partially reproducible
- depend on authentication
- reflect backend behavior rather than a new regression
---
## Decision
Treat incoming reports as external issues until scope is confirmed.
---
## Validation Rules
Always confirm:
- reproducibility
- environment
- auth state
- entry point
- whether the issue exists in main
---
## Communication Rule
Do not say a report is a regression until comparison has been validated.
Preferred framing:
"Investigating external report. Scope, auth state, and reproducibility still being confirmed."

40
project-knowledge/05-decisions/rest-vs-graphql.md Normal file
View File

@@ -0,0 +1,40 @@
---
type: decision
project: fidelity
status: accepted
title: "REST vs GraphQL"
updated: 2026-04-16
tags:
- decision
- fidelity
---
# REST vs GraphQL
## Decision
Deprecate GraphQL and migrate to REST progressively.
---
## Constraints
- REST is behind a feature flag
- GraphQL remains fallback
- Behavior parity matters during migration
---
## Communication Rule
When reporting findings:
- state whether REST was confirmed enabled
- avoid implying REST is the default path
- call out when behavior may still come from GraphQL fallback
---
## Follow-up
- Remove Apollo when migration is safe
- Retire GraphQL-specific tests only after parity is confirmed

40
project-knowledge/06-daily/2026-04-08.md Normal file
View File

@@ -0,0 +1,40 @@
---
type: daily
project: fidelity
date: 2026-04-08
focus: [ao-discourse]
work-items: [pdiap-15765]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-08
## Work Done
- Investigated a Youth account flow issue reported externally
- Compared the observed behavior against prior flow behavior
- Captured notes to explain the issue clearly before sharing updates
---
## Findings
- Reproduction required an authenticated user
- Behavior appeared consistent with previously observed flow behavior
- The report did not yet prove a regression
---
## Communication
- Prepared a clearer explanation for follow-up through Mattermost
- Framed the issue as an external report pending scope confirmation
---
## Next Step
- Confirm whether any additional action is needed before closing the issue

65
project-knowledge/06-daily/2026-04-09.md Normal file
View File

@@ -0,0 +1,65 @@
---
type: daily
project: fidelity
date: 2026-04-09
focus: [ao-discourse, xflow-swiftui-migration, rest-migration]
work-items: [pdiap-15765, pdiap-15836, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-09
## Work Done
- Refined manager-facing communication about a reported behavior difference
- Reframed ambiguous language before documenting the outcome in Jira
- Updated context to reflect auth-dependent behavior
- Confirmed the reported DOB validation issue only reproduces for authenticated users on TeenIdentityCheck
- Created `PDIAP-15836` for dismissal delegate lifecycle sequencing in pure SwiftUI (`8` points)
- Aligned `PDIAP-15838` scope with REST migration cleanup and feature-flag removal
- Confirmed XFlowViewMaker `0.5.0` is already in Fid4
- Updated the root cause document for the AccountLink dismissal sequencing issue tied to `PDIAP-15836` and got approval on the proposed wording
---
## Findings
- The reported behavior depended on authenticated context
- The original external report was incomplete
- The comparison needed more precise wording to avoid implying regression
- The dismissal sequencing change needs extra validation across flows, so the story was sized at 8 points
- The REST deprecation story covers Apollo, GraphQL networking code, related tests/mocks, and transport feature flags
---
## Communication
- Prepared clearer wording for Jeff
- Focused on context, observation, and action instead of vague comparison language
- Proposed a root cause document update and got confirmation on the revised wording
---
## Slack Archive Import
- Imported 2,500 historical Slack messages spanning `2023-01-26` to `2025-11-24`
- Channels covered: `fidelity-code-review`, `fidelity-grabaciones`, `fidelity-interface-meetings-on-calendar-outlook-team-etc`, `fidelity-jira`, `fidelity-preguntas`, `fidelity-reports-read-this-shit-no-excuses`, `fidelity-retrospective`, `fidelity-standup`
- High-signal historical themes: XFlow SwiftUI migration work, Jira/story approval threads, pipeline debugging, and manager-reviewed message wording
- Treated older pipeline and story details as historical evidence unless they still change current understanding
---
## Next Step
- Keep using explicit issue framing for future Mattermost and Jira updates
---
## Workflow Clarification
- This workspace is mainly used off the Fidelity work machine
- Main practical use cases are: drafting Mattermost updates to Jeff, translating/refining English, reusing prior context, getting Swift technical support, and drafting PR/story text
- Recommendations for new commands should prioritize communication support and context reuse over heavy local triage workflows that assume direct access to the product environment

48
project-knowledge/06-daily/2026-04-10.md Normal file
View File

@@ -0,0 +1,48 @@
---
type: daily
project: fidelity
date: 2026-04-10
focus: [xflow-swiftui-migration, rest-migration, ao-discourse]
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-10
## Clarification
- `PDIAP-15838` should not be framed as directly tied to the UIKit-removal spike.
- Avoid wording that implies `PDIAP-15838` is dependent on or part of the dismissal-sequencing / UIKit-removal spike.
- Standups should prioritize updates directly tied to active work items and omit side questions such as version reminders that were only for internal context.
- Current focus for today is to finalize `PDIAP-14859` with a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
- Omit standup items that are not directly related to a story.
- Use the approved title `Remove Apollo for iOS` for `PDIAP-15838`.
- When a documentation or root cause update directly supports a story, report it under that story instead of as a separate standup item.
- In standups, format Jira references as `ID - Title` or `ID Title`, not `ID, Title`.
- Jeff clarified that `PDIAP-15838` is the next story to work on and `PDIAP-15836` comes later.
- Clarification: the feature-flag and rollout planning feedback applies to the broader UIKit-removal spike, not only to the dismissal sequencing changes; the sequencing work should fit into that same consumer rollout plan.
- Current priority is to create a process-oriented document that explains the rollout plan Jeff described for the UIKit-removal spike, with the goal of sharing it for feedback.
- Clarification: the document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt. The dismissal sequencing work is only one part of that broader migration plan.
- The document should clearly explain that the rollout uses a dual-path pattern to switch between the `UIHostingController` path and the SwiftUI-only path during migration.
- Jeff said the remaining spike deliverable is a clear consumer-facing rollout plan covering risky entry points like FTTransfer, consumer communication, XQ1 validation, a 30-day production period with no reported bugs, and a follow-up release to remove the feature flag and old code; he suggested sending that process-oriented document to Quy for feedback when ready.
- Reviewed the first Copilot-generated draft of the SwiftUI-only migration rollout document from screenshots.
- The draft already includes the main requested elements: dual-path rollout, `xflow-master-swiftui-enabled`, XQ1 validation, FTTransfer coordination, rollback handling, 30-day stabilization window, and final cleanup release.
- The next revision should shift the tone slightly away from formal incident/operations language and make the consumer rollout sequence, decision owners, and entry-point-based enablement flow feel more like an engineering migration plan than a generic release runbook.
- Correction for the next rollout-document revision: the rollout should not be framed as entry-point-based enablement; it uses a global feature flag and should emphasize broad XQ1 validation before any production release.
- Correction for audience framing: the document is consumer-facing and should avoid stakeholder-oriented wording.
- Further correction for the rollout document: it should not say production rollout begins with lower-risk consumers. The production flag is global and applies across flows together once the team decides to enable it.
- The document should present broad XQ1 validation as the required gate before any production rollout, not as one stage within a consumer-by-consumer enablement sequence.
- The migration framing should also call out that the rollout incorporates architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced SwiftUI anti-patterns.
- Reviewed the next screenshot-based revision of the rollout document. It now correctly reflects a global production flag model, broad XQ1 validation before production enablement, consumer-facing wording, and architectural improvements learned from prior SwiftUI iterations.
- Remaining polish areas in the latest draft: reduce lingering operational/runbook wording (`SLA`, `operational response`, `release manager delegate`, heavy monitoring-threshold language) and make the high-risk-consumer section sound more like coordination/validation within a global rollout than a separate rollout phase.
- The rollout document should be more concise and should not use an overly complex multi-phase model.
- Reviewed the newer simplified screenshot-based revision. The rollout structure is now much closer to the intended model: a simple gated flow of broad XQ1 validation, global production enablement, then a 30-day stabilization window before cleanup.
- Remaining issues in the latest draft are mostly wording and trimming: it still includes extra runbook-style sections such as `Production Monitoring and Guardrails`, `Coordination Model for High-Risk Consumers`, `Rollback and Operational Response`, and `Decision Gates Summary`, which may be more detail than needed for the concise consumer-facing version.
- Reviewed another screenshot-based revision after the simplification prompt. The top-level rollout flow is still good and concise, but the lower half of the document still retains most of the extra runbook-style sections, so the latest revision did not yet materially reduce those details.
- Clarified the AO/Discourse config explanation for the authenticated `TeenIdentityCheck` DOB issue: the requirement is not to rename the root from `birthDate` to `validations`; instead, the `validation-rules` payload should contain a JSON object whose root key is `validations`, and if the age gate is required it should include `eighteenOrAbove: true`, matching the `CheckIdentity` structure rather than relying on a separate transactional rule boolean like `"eighteen-or-above": true`.
- Further clarification for the same AO/Discourse thread: the reply should explicitly state that the earlier comment was referring to the literal `"eighteen-or-above": true` attribute inside the transactional-rules array, while still distinguishing that from the separate `validation-rules` structure.
- Additional clarification for the authenticated `TeenIdentityCheck` config issue: the `validation-rules` attribute is the structure that drives the check. `CheckIdentity` was already configured correctly. The `TeenIdentityCheck` problem had two parts: the wrong root key (`birthDate` instead of the expected `validations`) and the missing `eighteenOrAbove` attribute inside `validation-rules`.
- For the Rashmi reply, the intended closing clarification is that the previous `CheckIdentity` `validation-rules` shape is the expected model for `TeenIdentityCheck`, and a JSON snippet can be shared to show the expected structure directly.

27
project-knowledge/06-daily/2026-04-13.md Normal file
View File

@@ -0,0 +1,27 @@
---
type: daily
project: fidelity
date: 2026-04-13
focus: [xflow-swiftui-migration, ao-discourse, rest-migration]
work-items: [pdiap-14859, pdiap-15765, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-13
## Standup Context
- Corrected the approved title for `PDIAP-14859` to `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
- Manual clarification for Monday standup: reference Friday work rather than the prior calendar day.
- Friday update for `PDIAP-14859`: created a draft rollout document for removing UIKit in favor of a SwiftUI-only path, including feature-flag planning.
- Today update: publish the rollout document for `PDIAP-14859` and continue with `PDIAP-15838` `Remove Apollo for iOS`.
- Standups should include story titles, not only Jira IDs, when the title is available.
## Mattermost Sync
- `PDIAP-14859`: sent Jeff the rollout draft for review after updating it around the global feature flag, broad `XQ1` validation, and the consumer-facing rollout flow.
- Jeff replied that he will review the `PDIAP-14859` document this morning.
- For `PDIAP-15765`, Jeff approved sending the config clarification that `CheckIdentity` was already correct and that `TeenIdentityCheck` needed the `validations` root key plus `eighteenOrAbove` inside `validation-rules`; the message was sent with an expected validation snippet.

81
project-knowledge/06-daily/2026-04-14.md Normal file
View File

@@ -0,0 +1,81 @@
---
type: daily
project: fidelity
date: 2026-04-14
focus: [xflow-swiftui-migration, ao-discourse, xflow-debugging]
work-items: [pdiap-14859, pdiap-15765, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-14
## Previous Workday Refresh
- `PDIAP-14859` rollout draft remained in revision on April 13 rather than being finalized; the work was limited to the specific draft changes requested in review, not a broad rewrite.
- The rollout document should rename the proposed flag from `xflow-master-swiftui-enabled` to `xflow-swiftui-enabled`.
- The first rollout phase should explicitly mention contacting consumers ahead of time and asking them to validate their flows in `XQ1`.
- The rollout document should remove overly technical wording and avoid implying there are no consumer-side changes without qualification.
- Current spike clarification: `FTTransfer` changes are no longer considered strictly required after applying the SwiftUI dismissal behavior correctly, but risky entry points still need explicit rollout coverage.
## AO / Discourse Findings
- The AO reply about `TeenIdentityCheck` was approved and sent after clarifying that `CheckIdentity` was already correct and that the `TeenIdentityCheck` issue was the missing `validations` root and missing `eighteenOrAbove` inside `validation-rules`.
- Later validation showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
- A `HybridBrokerage` scenario reproduces on both iOS and Android.
- A Youth flow (`Open an account` -> `Save & Invest for a child` -> `Fidelity Youth Account`) fails on iOS while working on Android.
- Current evidence suggests Android is more flexible when decoding rule variations, while iOS is stricter about the expected `validation-rules` structure in the Youth-flow scenario.
- The iOS-only Youth-flow discrepancy is the scenario currently aligned with the story-level client fix.
- The cross-platform `HybridBrokerage` scenario should stay scoped separately until it is clear whether it is a service/config issue or a distinct bug.
## Current Direction
- `PDIAP-14859` remains focused on incorporating rollout-document feedback and publishing a consumer-facing plan.
- `PDIAP-15838` remains the next implementation story after the rollout-document work is in a good state.
## New Investigation Note
- For the Murali group discussion, there appears to be usage of `ApexBridgingAddressComponent` through references in `XFlowPageApexItem`.
- If that usage is active, the dependency comes from `ApexKitV3`, which was expected to retain support after the earlier ApexKit removal.
- Current guidance from that discussion is to migrate toward `FDS` or `ApexKitSwiftUI`, but the exact replacement for `ApexBridgingAddressComponent` is still unclear and needs investigation and validation.
- Narrower wording for the current status: there are visible references at a glance, but it is not yet confirmed whether they are active or dead code; the next step is to validate with a run.
## Fresh Mattermost Sync
- Confirmed with breakpoints that `ApexBridgedAddressComponent` is not used when loading an address component; the observed path goes through `ApexGoogleAddressViewModel`.
- A follow-up review raised that the old component may still be used to load rules and appears in `XFloaValueChanger`, so it should not be treated as dead code without deeper verification.
- Current direction for that investigation is to be exhaustive and avoid assumptions before describing the old bridged path as unused.
- Clarification from the same thread: the remaining `ApexKitV3` reference does not cause build issues because `ApexKitSwiftUI` still depends on `ApexKitV3`.
- `PDIAP-14859` rollout-document follow-up: Jeff asked whether the FTTransfer section needed updating, and David confirmed the document had already been revised to clarify that root cause.
- Latest clarification in the Murali thread: `ApexBridgedAddressComponent` belonged to the old UIKit rule-handling flow. In the current implementation, rules are described as being handled through the SwiftUI path, parsed from the payload and applied through the `XFlowViewApadater` / `ViewModelAdapter` layer using `ApexGoogleAddressViewModel`.
- Clarification for the retro/ownership discussion: the earlier FTTransfer-side explanation was not fully wrong, but it was incomplete. The SwiftUI state behavior was a real symptom/effect on the consumer side; the deeper root cause was the dismissal flow handling that had not been covered correctly. The main gap was concluding consumer ownership before isolating that underlying dismissal root cause.
- Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation.
- Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed.
- Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently.
- Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims.
## ApexKitV3 / Swift 6 Follow-up
- Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced.
- Breakpoint and import-removal follow-up showed that removing `import ApexKitV3` across XFlow causes `23` compilation issues.
- Replacing those imports with `ApexKitSwiftUI` still leaves `13` build errors.
- Current high-confidence understanding is that XFlow still has meaningful dependency impact from `ApexKitV3`, and this is not just a trivial dead-code cleanup.
- Swift 6 support is not yet implemented; related work is planned under a `26Q3` backlog epic.
- New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by `4:30 PM`.
- The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing.
- Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments.
- Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder.
- Additional analysis context for the ApexKitV3 investigation: the Swift version change was reverted back to Swift 5, and the Pods were updated to the latest versions including `ApexKitSwiftUI 1.27.14`. The current question is whether the ApexKitV3-removal impact remains the same under that updated dependency baseline.
- Document-review guidance for the ApexKitV3 impact write-up: it should not read as if code changes have already been made, should stay understandable for a non-technical reader, and should avoid overcommitting on production impact where SwiftUI-vs-legacy-path usage is still being verified.
- Additional document-review guidance: if the write-up already recommends consumer testing, it should not hedge with wording like `if the change extends beyond small cleanup`. The risk section should stay internally consistent and reflect the current conclusion directly.
## Late-Day Outcome
- The ApexKitV3 impact write-up was revised with the requested wording changes, including using `Impacted Flows` and making consumer validation a direct recommendation rather than a conditional one.
- Jeff approved the ApexKitV3 write-up after those edits, and David published it and sent the Confluence link to Quy with a concise summary of the effort and risk.
- End-of-day direction for `PDIAP-14859`: the rollout document was approved as good enough, but it was not published on April 14. The next step is to publish it on the next workday, then comment the spike with `Spike Results:` links and the follow-up story link.
- The UIKit-removal follow-up story should be linked as a blocker for the reopened UIKit-removal work after the spike is closed out.
- End-of-day direction for `PDIAP-15765`: move the story back to In Progress on the next workday and focus on the authenticated iOS-only Youth `TeenIdentityCheck` gap so iOS handles the service response the same way as Android.
- The separate `HybridBrokerage` scenario remains distinct from the iOS-only Youth-flow issue and may need its own follow-up ticket if the service-side problem still stands after the client-side story is resumed.

61
project-knowledge/06-daily/2026-04-15.md Normal file
View File

@@ -0,0 +1,61 @@
---
type: daily
project: fidelity
date: 2026-04-15
focus: [xflow-swiftui-migration, ao-discourse]
work-items: [pdiap-14859, pdiap-15765]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-15
## Toggle Name Follow-up
- Additional historical context from Teams suggests the existing LaunchDarkly flag name `xflow-master-swiftui-enabled` was already shared in the Fid4 LaunchDarkly project as the SwiftUI toggle.
- User-provided historical references: Neetu Gupta asked for the SwiftUI toggle name and Jason Mandozzi replied with `xflow-master-swiftui-enabled` plus the LaunchDarkly link; in January 2025, Thomas Payne also asked whether the team was ready to activate that same toggle.
- Current interpretation: the team may be able to keep using the same flag name even though the rollout intent is now narrower. In the current rollout, toggling would switch only the final `UIHostingController` wrapping on or off, while SwiftUI remains in use either way.
- This historical evidence supports keeping the existing flag name if renaming would add friction, but the semantic mismatch should still be acknowledged when describing the rollout.
- Fresh clarification from Jeff on April 15: do not reuse the old SwiftUI LaunchDarkly flag for this rollout.
- New required flag name for the rollout document: `xflow-swiftui-container-enabled`.
- The rollout document should explicitly note that this new flag is `to be added in the future as part of implementation`.
- Jeff plans to ask later how to get the new flag added when implementation time comes.
## PDIAP-15765 Follow-up Drafting Context
- David plans to confirm that `PDIAP-15765` was moved from investigation back to In Progress.
- Current working interpretation: the `HybridBrokerageAccountOpening` / `JointIdentityCheck` behavior appears to be a different issue from the iOS-only Youth `TeenIdentityCheck` gap.
- This separate `HybridBrokerage` path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect.
- Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly.
- One reason for suspicion is that the validation appears to use `min: 10` and `max: 10`, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story.
- Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the `birthDate` key.
- Once the payload was changed from `birthDate` to `validations`, the originally reported iOS issue no longer reproduced and the validation loaded correctly.
- Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally.
- Jeff asked that the message start with: `One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):`
- Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well.
- Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from `birthDate` to `validations`.
- Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only.
## Jeff Context On AO Fallback Handling
- Jeff confirmed the minimal iOS fallback change is the right fix for this issue.
- He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows.
- Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor.
- That history explains why `validations` aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling.
- Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS.
## PR Drafting Context
- The `xflow-for-ios` PR template currently uses sections `## What`, `## Why`, `## How`, `### Changes details`, and `## Missed anything?` with a final checklist.
- The April 15 iOS fix PR is a one-line change in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`, adding `birthDate` as a fallback after `validations`.
- This PR should be described as a small compatibility bug fix for older AO-style payloads rather than as a broader Android-parity refactor.
- David opened the PR for this minimal iOS compatibility fix.
## Standup And Flow Naming Notes
- David prefers standups to use one top-level Jira bullet with indented sub-bullets when a single ticket has multiple updates.
- In recent standup wording, `Youth flow` should be treated as shorthand for the real flow ID `HybridYouthAccountOpening`.
- The relevant page in that flow is `TeenIdentityCheck`.
- The separate authenticated flow under discussion remains `HybridBrokerageAccountOpening`, with the relevant page `JointIdentityCheck`.

46
project-knowledge/06-daily/2026-04-16.md Normal file
View File

@@ -0,0 +1,46 @@
---
type: daily
project: fidelity
date: 2026-04-16
focus: [ao-discourse, xflow-debugging]
work-items: [pdiap-15765]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-16
## Mattermost
- Jeff clarified that `PDIAP-15765` should not move to Done until the PR is merged.
- Santosh approved the PR, but one code-owner approval is still required before merge.
- Jeff asked for one more AO working-group Teams reply that:
- summarizes that the original iOS issue was reproduced and addressed with the iOS-side change
- points the group to the Jira comment, Discourse comment, and PR
- explains that the initially found `HybridBrokerageAccountOpening` / `JointIdentityCheck` problem is separate
- notes which service-side changes were already made and which still appear to be needed
- David clarified that the confirmed service-side change was limited to the Youth-flow `TeenIdentityCheck` path. For external communication, avoid overstating the scope or calling out Rashmi by name unless that attribution is specifically needed.
- David clarified that the iOS change should be described as a compatibility improvement to reduce similar future issues with the older `birthDate` format. It should not be described in a way that implies it also applies to the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
- Jeff said the AO working-group draft was still confusing and wanted to edit it himself to make it very clear and avoid follow-up questions.
- David clarified that the `HybridYouthAccountOpening` / `TeenIdentityCheck` issue was iOS-only; it should not be described as affecting both iOS and Android.
- David clarified that the service-side change and the iOS-side fallback address the same Youth / `TeenIdentityCheck` issue, not two separate Youth issues. The service change was the immediate resolution, while the iOS PR is a compatibility safeguard if that older `birthDate` format appears again.
- David has personally seen `birthDate` used on two pages so far, but broader reuse in other flows is still unconfirmed and should be described carefully.
- For Jeff's framing question, the current understanding is two affected flow scenarios, not three: the iOS-only Youth / `TeenIdentityCheck` issue, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue.
- Jeff confirmed on April 15 that the minimal iOS `birthDate` fallback is the right change for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
- Jeff clarified the historical reason for the fallback behavior: older AO services often still use older payload conventions, while the SwiftUI refactor was validated more heavily against newer Slate-based services using `validations`.
- Jeff said the easiest fix is usually this kind of iOS-side fallback when the consumer is AO, the issue is iOS-only, and the service payload shape differs from what the SDK expects.
- Jeff approved the Jira and Discourse comments with one wording change: say `I checked the original iOS issue again` instead of `I re-checked`.
- Jeff approved sending a final AO working-group summary, but wanted it to be much clearer about what was fixed on iOS, what Rashmi changed on the service side, and what separate service-side issue still remains in `HybridBrokerageAccountOpening` / `JointIdentityCheck`.
- David later checked Cogstore and confirmed that the relevant flow-definition change tied to Rashmi's service update is already in QA as version `0.0.142`, while Production is still on `0.0.133`, so that flow change is not live in production yet.
- Jeff concluded there is no point relying on a separate service release for the Youth issue if it would also require its own rollout; the iOS PR should be treated as the primary fix path, while the QA-side flow-definition change explains why the issue no longer reproduces in XQ1.
- Durable tooling/system note: in Fidelity flow work, Cogstore is the platform used to modify and publish many individual flow configurations, compare versions per flow, and check who/when a specific flow version was published to QA or Production. Slate was the newer consumer-side configuration tooling during the SwiftUI refactor, but Jeff believes it is now decommissioned.
- Additional tooling note: flow IDs are not guaranteed to exist in both Cogstore and Slate, so the active configuration source for a given flow should be verified instead of assumed.
- David confirmed that the `HybridBrokerageAccountOpening` / `JointIdentityCheck` flow-definition content is the same in QA and Production even though the versions differ (`0.0.267` vs `0.0.263`), so that separate rule-content issue should also be reproducible in Production.
- Jeff asked Rashmi to revert the Youth-flow service change so the iOS-side PR can remain the single fix path for that issue.
- David confirmed Rashmi reverted the QA change by publishing the earlier flow version, and local Fid4 validation with the iOS PR showed the `birthDate`-based validation now works as expected.
- Jeff's preferred external summary is now very explicit: we went back and fixed their original iOS-only issue on the iOS side, while the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is a new service-side problem that still needs its own follow-up.
- The `PDIAP-15765` PR later received final approval, was merged, and the release pipeline produced XFlow `2.8.48`.
- After the XFlow release, David updated XFlowViewMaker to `2.8.48`, opened the follow-up PR, and sent it for review so the fix can propagate through the consumer path.
- David also sent the final AO working-group update with links to the Jira story, Discourse ticket, and PR.

97
project-knowledge/06-daily/2026-04-17.md Normal file
View File

@@ -0,0 +1,97 @@
---
type: daily
project: fidelity
date: 2026-04-17
focus: [ao-discourse, consumer-integration, rest-migration]
work-items: [pdiap-15765, pdiap-15838]
blockers: []
updated: 2026-04-17
tags:
- daily
- fidelity
---
# 2026-04-17
## Standup Draft Clarification
- David clarified that the XFlowViewMaker follow-up work for `PDIAP-15765` is further along than the earlier summary implied.
- The XFlowViewMaker PR is already open and has some approvals.
- One FTFrameworks code-owner approval is still required before the PR can merge.
- After that approval, the remaining work is to run the pipeline and update Fid4 so the XFlow `2.8.48` change propagates through the consumer path.
- `PDIAP-15838` remains the next story after the `PDIAP-15765` propagation steps are in a good place.
- David's current plan is to ping Tauf for that remaining approval.
## Standup Wording Feedback
- Jeff said not to use `fallback` in the standup wording because a broader audience will not understand that term without extra context; prefer plain outcome wording like `Got the PR approved`.
- Jeff clarified that when `PDIAP-15765` is waiting on approvals or pipeline movement, the standup should explicitly say David is returning to GraphQL removal work rather than sounding like the day is blocked on waiting.
- David updated the standup wording with those changes and sent the final version.
## Learning Session - Release Propagation
- David clarified the current release propagation chain for XFlow changes.
- XFlowSDK is released from `pr100660-xflow-for-ios` through Jenkins pipeline `xflow-for-ios-publish`, which builds the XCFramework, publishes it to `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`.
- XFlowViewMaker lives in `PR100660-ios-frameworks/Adapters/XFlowViewMaker`; after an XFlowSDK release, its podspec must be updated, then `tuist generate -n`, `pod install`, PR review, protected-branch/code-owner approval, merge, and `publish-XFlowViewMaker` publication are required.
- The XFlowViewMaker publish pipeline usually auto-detects the next release and commonly auto-increments the minor version.
- Fid4 then consumes the new XFlowViewMaker version from `ap010981-ios-flagship-app` by updating the Podfile, running `tuist generate -n` and `pod install --repo-update`, opening a PR, and merging it before the downstream app release process carries the change to users.
- This release chain is durable context for understanding why an XFlowSDK fix can be merged and released but still not be visible yet in Fid4.
- David clarified that Fid4 consumes XFlow only through XFlowViewMaker, not directly through XFlowSDK.
- David also clarified that other frameworks such as `FTAccountOpen` and `FTTransfer` use XFlowViewMaker, and the practical Account Opening path is currently understood to go through `FTAccountOpen`.
- Version verification in Fid4 is imperfect because `Podfile.lock` is ignored in the repo; fixed Podfile references and pipeline artifacts can help verify released versions, but podspec-repo edits can still change what gets resolved later.
- Tauf was identified as a CI/Jenkins support contact who has helped with pipeline issues in the past.
- David clarified that Tauf's full name is `Taufiqur Ashrafy`; he is often referred to informally as `Tauf`.
- David also noted that Fidelity Teams may display people in surname-first order, which can make person matching less obvious across tools.
- David clarified that the surname-first display in Fidelity Teams is consistent for everyone.
- David also clarified that Teams and Mattermost represent different social contexts; outside of Jeff, people seen in Teams are generally not the same people David interacts with through Mattermost.
- David corrected current people status: Norman Arauz and Derian Cordoba no longer work with the current All-Win Software / Mattermost / Slack group, and Erik Reynolds previously worked for Fidelity but no longer does.
- David clarified an important working-context rule: Jeff is the only person who regularly communicates with Fidelity-side Teams stakeholders, while David works from the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
## Mattermost Refresh - Dependency Conflict
- After XFlowViewMaker was published, David hit a dependency conflict while trying to update Fid4.
- The conflict appears to come from `FTAccountOpen` and `FTTransfer` depending on XFlowViewMaker with constraints that do not yet allow the new version.
- David noted that Tauf has handled similar cases before by updating the constraint directly in the podspec repo.
- Jeff asked David to message Tauf, ask him to remind David what he does in this case, and then document the process for future reference.
- Follow-up Teams evidence from Tauf clarified the practical fix path:
- first try `pod install`
- if resolution still does not move to the latest XFlowViewMaker version, the change belongs in the podspec repo, not in FTFrameworks
- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their FTFrameworks source podspec files; the effective versioning is handled through the published podspec layer and the `ftAdapter` function
- David later clarified the actual fix: in the podspec repo PR, he removed the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs
- Tauf approved that podspec-repo PR
- After that merge, `pod install --repo-update` worked in Fid4 because the published podspecs no longer constrained the XFlowViewMaker version
## Mattermost Refresh - Release Progress
- The remaining XFlowViewMaker code-owner approval was obtained from Tauf, allowing the release process to continue.
- The XFlowViewMaker release was published successfully.
- David then opened the Fid4 PR with the latest versions and planned to request reviews from Santosh and Tauf.
## Mattermost Refresh - Urgent REST Validation
- Jeff redirected work to an urgent consumer report claiming REST calls were failing on iOS when the toggle was enabled.
- David clarified that David does not have access to Flagship LaunchDarkly projects; only the sample app LD project is available from David's side.
- David tested locally on `main` and reported that REST loaded correctly with the `iOS-XflowRestEnabled` flag enabled.
- David also verified that XFlow `2.8.47` already supports that flag and is present in the 4.30 line used for consumer validation.
- David later verified on the `release/4.30` branch that the behavior still looked correct there.
- Current working hypothesis: the consumer report may reflect a version mismatch or incorrect flag configuration rather than a reproducible iOS REST failure in current local validation.
- Adam's `trunk build` reference appears to mean a real-device build platform that can provide downloadable App Store/internal IPAs and a dependency snapshot such as `Podfile.lock`, even though David cannot run those IPAs on simulators.
## Communication Correction
- David corrected a drafting mistake: when proposing a message that David will send directly to a Fidelity-side contact, the wording must not imply Jeff is the sender or that the recipient already knows David through Jeff.
- For this kind of direct outreach, avoid phrases like `Jeff mentioned...` unless David explicitly wants that framing.
- David made a second correction: if Jeff asked for internal documentation or future-process capture, that should stay internal and should not be surfaced in David's external message unless explicitly requested.
## Mattermost Refresh - Dependency Reproduction Caution
- Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior.
- David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced.
- If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone.
## Learning Correction - Build Inspection Sources
- David clarified that `iosinstaller` is one of Fidelity's internal apps for inspecting distributed consumer builds.
- `iosinstaller` can download App Store and internal builds and also expose the corresponding `Podfile.lock`.
- David also clarified a useful app-store debugging path in the Flagship app pipeline: the artifact `appstore/DistributionSummary.plist` records the framework versions installed for that build.
- That artifact can be used to confirm which XFlowViewMaker and XFlow versions were actually installed in a specific App Store build.

34
project-knowledge/06-daily/index.md Normal file
View File

@@ -0,0 +1,34 @@
---
type: daily-index
project: fidelity
updated: 2026-04-16
tags:
- daily
- map
---
# Logs Index
Daily logs capture evolving evidence and same-day work context.
Promote durable facts into `project-knowledge/01-current/`, `project-knowledge/02-work-items/`, or `project-knowledge/03-context/` when they should survive beyond the day.
---
## Logs
- [2026-04-08](2026-04-08.md)
- [2026-04-09](2026-04-09.md)
- [2026-04-10](2026-04-10.md)
- [2026-04-13](2026-04-13.md)
- [2026-04-14](2026-04-14.md)
- [2026-04-15](2026-04-15.md)
- [2026-04-16](2026-04-16.md)
---
## Related Memory
- [Current Work](../01-current/current-work.md)
- [Work Item State](../01-current/work-items.md)
- [Work Item Index](../02-work-items/index.md)
- [Context Index](../03-context/index.md)

39
project-knowledge/07-maps/current-work.md Normal file
View File

@@ -0,0 +1,39 @@
---
type: map
domain: current-work
tags:
- map
- current-work
---
# Current Work Map
Current operational state for daily work, standups, and manager updates.
---
## Current State
- [New Member Onboarding](../00-start/onboarding.md)
- [Current Work](../01-current/current-work.md)
- [Work Item State](../01-current/work-items.md)
- [Work Item Index](../02-work-items/index.md)
- [Logs Index](../06-daily/index.md)
---
## Active Work Items
- [PDIAP-14859](../02-work-items/pdiap-14859.md)
- [PDIAP-15765](../02-work-items/pdiap-15765.md)
- [PDIAP-15836](../02-work-items/pdiap-15836.md)
- [PDIAP-15838](../02-work-items/pdiap-15838.md)
---
## Communication Context
- [Communication Rules](../03-context/process/communication-rules.md)
- Manager update prompt: `prompts/manager-update.md`
- Standup prompt: `prompts/standup.md`
- [Manager Mapping](../04-people/manager.md)

68
project-knowledge/07-maps/fidelity-apps.md Normal file
View File

@@ -0,0 +1,68 @@
---
type: map
domain: fidelity-apps
tags:
- map
- fidelity
- apps
---
# Fidelity Apps Map
Independent notes for internal Fidelity apps and tools that appear repeatedly in day-to-day engineering work.
---
## Build And Release
- [Artifactory](../03-context/systems/artifactory.md)
- [iOSInstaller](../03-context/systems/iosinstaller.md)
- [Nexus Fidelity](../03-context/systems/nexus-fidelity.md)
---
## Debugging And Validation
- [Splunk](../03-context/systems/splunk.md)
- [Cogstore](../03-context/systems/cogstore.md)
- [XQ1 Portfolio Summary](../03-context/systems/xq1-portfolio-summary.md)
- [Vault](../03-context/systems/vault.md)
- [Vault Preprod](../03-context/systems/vault-preprod.md)
---
## Collaboration And Documentation
- [Confluence](../03-context/systems/confluence.md)
- [Miro](../03-context/systems/miro.md)
- [Discourse](../03-context/systems/discourse.md)
- [Slate](../03-context/systems/slate.md)
---
## Access And Internal Portals
- [MyAccess](../03-context/systems/myaccess.md)
- [Fidelity Central](../03-context/systems/fidelity-central.md)
---
## Tracking And Support Tools
- [TrackIT](../03-context/systems/trackit.md)
- [ALMx Toolbox](../03-context/systems/almx-toolbox.md)
---
## Test Data And Other Utilities
- [Wukong](../03-context/systems/wukong.md)
---
## Related Context
- [Systems Index](../03-context/systems/index.md)
- [Fidelity Domain Map](fidelity-domain.md)
- [Consumer Integration](../03-context/workstreams/consumer-integration.md)
- [Fid4](../03-context/systems/fid4.md)

51
project-knowledge/07-maps/fidelity-domain.md Normal file
View File

@@ -0,0 +1,51 @@
---
type: map
domain: fidelity
tags:
- map
- fidelity
---
# Fidelity Domain Map
Stable Fidelity-specific systems, workstreams, and domain rules.
---
## Project Context
- [Glossary](../00-start/glossary.md)
- [Project Context](../03-context/project.md)
- [Context Index](../03-context/index.md)
- Fidelity profile: `profiles/fidelity/profile.md`
---
## Systems
- [Systems Index](../03-context/systems/index.md)
- [Fidelity Apps Map](./fidelity-apps.md)
- [Fid4](../03-context/systems/fid4.md)
- [XFlowSDK](../03-context/systems/xflowsdk.md)
- [XFlowViewMaker](../03-context/systems/xflowviewmaker.md)
- [FTFrameworks](../03-context/systems/ftframeworks.md)
- [CogStore](../03-context/systems/cogstore.md)
---
## Workstreams
- [Workstreams Index](../03-context/workstreams/index.md)
- [REST Migration](../03-context/workstreams/rest-migration.md)
- [AO And Discourse](../03-context/workstreams/ao-discourse.md)
- [XFlow Debugging](../03-context/workstreams/xflow-debugging.md)
- [XFlow SwiftUI Migration](../03-context/workstreams/xflow-swiftui-migration.md)
- [Consumer Integration](../03-context/workstreams/consumer-integration.md)
- [Flow And Page References](../03-context/workstreams/flow-page-references.md)
---
## Decisions
- [REST vs GraphQL](../05-decisions/rest-vs-graphql.md)
- [Discourse Handling](../05-decisions/discourse-handling.md)

36
project-knowledge/07-maps/index.md Normal file
View File

@@ -0,0 +1,36 @@
---
type: map-index
audience: project-reader
project: fidelity
updated: 2026-04-17
tags:
- map
---
# Knowledge Maps
Human navigation hubs for the Obsidian graph.
Use these maps to navigate Fidelity by meaning instead of by raw folder structure.
---
## Primary Maps
- [Current Work](current-work.md)
- [Fidelity Domain](fidelity-domain.md)
- [Fidelity Apps](fidelity-apps.md)
- [Work Items](work-items.md)
- [People](people.md)
- [Daily Notes](../06-daily/index.md)
---
## Entry Points
- [Start Here](../00-start/start-here.md)
- [New Member Onboarding](../00-start/onboarding.md)
- [Glossary](../00-start/glossary.md)
- [Project Context](../03-context/project.md)
- [Systems Index](../03-context/systems/index.md)
- [Workstreams Index](../03-context/workstreams/index.md)

45
project-knowledge/07-maps/people.md Normal file
View File

@@ -0,0 +1,45 @@
---
type: map
domain: people
tags:
- map
- people
---
# People Map
Stakeholder, manager, and collaborator context.
---
## Indexes
- [New Member Onboarding](../00-start/onboarding.md)
- [Glossary](../00-start/glossary.md)
- [People Index](../04-people/index.md)
- [Manager Mapping](../04-people/manager.md)
---
## People
- [Jeff DeWitte](../04-people/jeff-dewitte.md)
- [Norman Arauz](../04-people/norman-arauz.md)
- [David Delagneau](../04-people/david-delagneau.md)
- [Aylwing Olivas](../04-people/aylwing-olivas.md)
- [Bruce Meeks](../04-people/bruce-meeks.md)
- [Derian Cordoba](../04-people/derian-cordoba.md)
- [Erik Reynolds](../04-people/erik-reynolds.md)
- [Gurram Santosh](../04-people/gurram-santosh.md)
- [Jason Mandozzi](../04-people/jason-mandozzi.md)
- [Quy Mai](../04-people/quy-mai.md)
- [Raj Sundararaj](../04-people/raj-sundararaj.md)
- [Tim Longfield](../04-people/tim-longfield.md)
---
## Communication
- [Communication Rules](../03-context/process/communication-rules.md)
- Manager update workflow: `workflows/manager-update.md`
- Professional communication skill: `.opencode/skills/professional-communication/SKILL.md`

37
project-knowledge/07-maps/work-items.md Normal file
View File

@@ -0,0 +1,37 @@
---
type: map
domain: work-items
tags:
- map
- work-items
---
# Work Items Map
Canonical memory for active and recently relevant work units.
---
## Indexes
- [Current Work Map](current-work.md)
- [Work Item Index](../02-work-items/index.md)
- [Work Item State](../01-current/work-items.md)
- [Current Work](../01-current/current-work.md)
---
## Active Items
- [PDIAP-14859](../02-work-items/pdiap-14859.md)
- [PDIAP-15765](../02-work-items/pdiap-15765.md)
- [PDIAP-15836](../02-work-items/pdiap-15836.md)
- [PDIAP-15838](../02-work-items/pdiap-15838.md)
---
## Related Process
- [Jira Story Rules](../03-context/process/jira-story-rules.md)
- Story draft prompt: `prompts/story-draft.md`
- Status reporting skill: `.opencode/skills/status-reporting/SKILL.md`

23
project-knowledge/08-bases/daily.base Normal file
View File

@@ -0,0 +1,23 @@
filters:
and:
- type == "daily"
- file.ext == "md"
- '!file.inFolder("09-templates")'
properties:
date:
displayName: Date
focus:
displayName: Focus
work-items:
displayName: Work Items
blockers:
displayName: Blockers
views:
- type: table
name: Daily Notes
order:
- file.name
- date
- focus
- work-items
- blockers

26
project-knowledge/08-bases/decisions.base Normal file
View File

@@ -0,0 +1,26 @@
filters:
and:
- type == "decision"
- file.ext == "md"
- '!file.inFolder("09-templates")'
properties:
title:
displayName: Title
status:
displayName: Status
date:
displayName: Date
related:
displayName: Related
updated:
displayName: Updated
views:
- type: table
name: Decisions
order:
- file.name
- title
- status
- date
- related
- updated

23
project-knowledge/08-bases/people.base Normal file
View File

@@ -0,0 +1,23 @@
filters:
and:
- type == "person"
- file.ext == "md"
- '!file.inFolder("09-templates")'
properties:
role:
displayName: Role
status:
displayName: Status
project:
displayName: Project
updated:
displayName: Updated
views:
- type: table
name: People
order:
- file.name
- role
- status
- project
- updated

23
project-knowledge/08-bases/systems.base Normal file
View File

@@ -0,0 +1,23 @@
filters:
and:
- type == "system"
- file.ext == "md"
- '!file.inFolder("09-templates")'
properties:
project:
displayName: Project
status:
displayName: Status
workstreams:
displayName: Workstreams
related:
displayName: Related
views:
- type: table
name: Systems
order:
- file.name
- project
- status
- workstreams
- related

30
project-knowledge/08-bases/work-items.base Normal file
View File

@@ -0,0 +1,30 @@
filters:
and:
- type == "work-item"
- file.ext == "md"
- '!file.inFolder("09-templates")'
- status != "done"
properties:
ticket:
displayName: Ticket
title:
displayName: Title
status:
displayName: Status
systems:
displayName: Systems
workstreams:
displayName: Workstreams
updated:
displayName: Updated
views:
- type: table
name: Active Work Items
order:
- file.name
- ticket
- title
- status
- systems
- workstreams
- updated

23
project-knowledge/08-bases/workstreams.base Normal file
View File

@@ -0,0 +1,23 @@
filters:
and:
- type == "workstream"
- file.ext == "md"
- '!file.inFolder("09-templates")'
properties:
status:
displayName: Status
systems:
displayName: Systems
work-items:
displayName: Work Items
related:
displayName: Related
views:
- type: table
name: Workstreams
order:
- file.name
- status
- systems
- work-items
- related

49
project-knowledge/09-templates/daily.md Normal file
View File

@@ -0,0 +1,49 @@
---
type: daily
project: fidelity
date: "{{date:YYYY-MM-DD}}"
status: active
focus: []
work-items: []
blockers: []
tags:
- daily
- fidelity
updated: "{{date:YYYY-MM-DD}}"
---
# {{date:YYYY-MM-DD}}
## Focus
-
---
## Work Done
-
---
## Findings
-
---
## Communication
-
---
## Next Steps
-
---
## Blockers
- None currently.

39
project-knowledge/09-templates/decision.md Normal file
View File

@@ -0,0 +1,39 @@
---
type: decision
project: fidelity
status: proposed
date:
title: "{{title}}"
systems: []
workstreams: []
people: []
related: []
tags:
- decision
- fidelity
updated: "{{date:YYYY-MM-DD}}"
---
# {{title}}
## Decision
-
---
## Context
-
---
## Constraints
-
---
## Follow-up
-

Some files were not shown because too many files have changed in this diff Show More