Add daily logs and templates for Fidelity project
- Created daily log entries for April 13-16, 2026, capturing standup contexts, Mattermost syncs, and ongoing work items. - Established a daily logs index for easy navigation of daily entries. - Introduced templates for daily notes, decisions, meeting notes, people, systems, and work items to standardize documentation. - Developed maps for AI workspace core, current work, Fidelity domain, and work items to enhance workspace navigation. - Implemented base configurations for daily notes, decisions, people, systems, work items, and workstreams to streamline data management. - Added a placeholder for attachments to facilitate file organization.
This commit is contained in:
25
vault/02-work-items/README.md
Normal file
25
vault/02-work-items/README.md
Normal 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 `vault/01-current/work-items.md` as a short bridge summary, not the primary source of detailed ticket context.
|
||||
39
vault/02-work-items/index.md
Normal file
39
vault/02-work-items/index.md
Normal 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.
|
||||
61
vault/02-work-items/pdiap-14859.md
Normal file
61
vault/02-work-items/pdiap-14859.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
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"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
72
vault/02-work-items/pdiap-15765.md
Normal file
72
vault/02-work-items/pdiap-15765.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: active
|
||||
ticket: PDIAP-15765
|
||||
title: "AO DOB field error not showing investigation"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
---
|
||||
# PDIAP-15765 - AO DOB field error not showing investigation
|
||||
|
||||
## Status
|
||||
|
||||
- Active again
|
||||
- Move back to In Progress on the next workday
|
||||
- Small XFlowSDK compatibility PR opened for the iOS-side fix
|
||||
- PR has Santosh approval, but still needs code-owner approval before merge and story completion
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
- Get the small XFlowSDK compatibility PR reviewed and released.
|
||||
- Send one more AO working-group Teams summary that points to the Jira comment, Discourse comment, and PR while keeping the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue clearly out of the original Youth-fix scope.
|
||||
- Keep the final AO working-group message very explicit about there being two flow scenarios: the Youth iOS-only issue now handled by the service change plus iOS fallback, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue.
|
||||
- Update that AO working-group message so it now reflects the final framing: the original Youth issue is fixed on the iOS side, and the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is the remaining service-side follow-up.
|
||||
- Close the story with comments explaining that the immediate Youth issue was resolved on the service side and that the XFlowSDK fallback fix will be available in the next release.
|
||||
- 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.
|
||||
49
vault/02-work-items/pdiap-15836.md
Normal file
49
vault/02-work-items/pdiap-15836.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: active
|
||||
ticket: PDIAP-15836
|
||||
title: "Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
---
|
||||
# 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`.
|
||||
48
vault/02-work-items/pdiap-15838.md
Normal file
48
vault/02-work-items/pdiap-15838.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: active
|
||||
ticket: PDIAP-15838
|
||||
title: "Remove Apollo for iOS"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
---
|
||||
# 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`.
|
||||
Reference in New Issue
Block a user