diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index 97fc155..a63e7d0 100644 --- a/project-knowledge/01-current/current-work.md +++ b/project-knowledge/01-current/current-work.md @@ -2,7 +2,7 @@ type: current project: fidelity status: active -updated: 2026-05-01 +updated: 2026-05-05 tags: - current-work - fidelity @@ -15,10 +15,10 @@ tags: - 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-15838` and `PDIAP-15836` +- Follow up on active tickets through `project-knowledge/02-work-items/`, especially branch maintenance for `PDIAP-15838` and implementation planning for `PDIAP-15836` / `PDIAP-12284` - `PDIAP-15765` is done and `PDIAP-14859` is also done -- `PDIAP-15838` is the active Apollo-removal / REST-migration cleanup and validation focus -- `PDIAP-15836` comes after the current REST-investigation / Apollo-removal work +- `PDIAP-15838` is Done from a Jira/status perspective after external review feedback was addressed, but its draft PR must remain unmerged and kept current with `main` until REST backend production readiness and the required REST-toggle consumer validation window allow merge +- `PDIAP-15836` is now paired with `PDIAP-12284` for the UIKit-removal / pure SwiftUI lifecycle implementation path; do not move the story to In Progress until the next sprint starts on Thursday after lunch - 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 @@ -42,8 +42,8 @@ tags: - Jeff suggested broadening the investigation support path while direct Flagship LaunchDarkly access is still missing: monitor the Tauf thread, follow up with Jeffrey O'Leary, package the scenario for the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available - The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot - Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles -- `PDIAP-15838` draft PR is open for internal review; after internal review, send the link to Bruce -- Do not merge the GraphQL/Apollo removal PR until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues +- `PDIAP-15838` draft PR has reached external review; Bruce left minor feedback, David addressed it, and Jeff directed David to move the ticket to Done while holding the merge +- Do not merge the GraphQL/Apollo removal PR until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues - Current `PDIAP-15838` follow-up centers on the `PicoSDK` update in `SampleApp`: the newer Pico path removes the remaining transitive Apollo dependency, re-enables FGO and FidFolios testing in `SampleApp`, and aligns the sample implementation with current Fid4 usage - The `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly - The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but current evidence shows it reproduces in `FTTransferPlayground` with Zachary's account and does not reproduce in `Fid4` with the same account @@ -55,6 +55,10 @@ tags: - The next implementation direction for the Discourse / FTTransfer issue is a pure SwiftUI fix that decouples alert state from the cover identity chain, avoiding unnecessary UIKit dependencies - `PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation` was created for the FTTransfer AccountLink investigation and root-cause report - Include in the `PDIAP-16167` report that the issue persists when rolling back `XFlowSDK` to `v0.1.0`, predating REST and modern architecture changes; Jeff explicitly asked David to include this in the document +- `PDIAP-16167` is Done: the Confluence report was published, findings were sent to Zachary / Jira / Discourse, and future references should describe the root cause as a consumer-side SwiftUI presentation-topology issue in `BankInformationView`, not an XFlow/XFlowViewMaker regression +- `PDIAP-12284` is the original UIKit-wrapping removal story reopened after rollback; track `PDIAP-15836` as blocked by `PDIAP-12284` unless further validation proves the lifecycle fix can be implemented independently on the SwiftUI path +- After `PDIAP-15836` / `PDIAP-12284` implementation, expect a long-lived branch: Jeff's current planning assumption is that the GraphQL-removal branch merges first after the REST validation period, then that is merged into the UIKit-removal/lifecycle branch, with `PDIAP-15836` / `PDIAP-12284` merge around 90-100 days from 2026-05-05 unless Fidelity shortens the review periods +- Backlog triage found future/reference items: `PDIAP-11962` has earlier secret-scanning closure evidence but two Google API Key alerts remain; `PDIAP-11961` is the related unassigned rotation/invalidation story for those alerts; `PDIAP-11562` concerns XFlow podspec/Fid4 debug-build configuration; Sparta items `PDIAP-12226`, `PDIAP-12227`, and `PDIAP-12228` are lower-priority until XFlow backlog items that can be closed are handled - 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 @@ -77,11 +81,13 @@ tags: - Avoid treating GitHub Copilot or LaunchDarkly as story-specific tools; both are broader Fidelity workflow tools that happened to matter in this investigation - Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement - Keep Apollo-removal / REST-migration cleanup grounded in production readiness: source-level cleanup can continue, but merge/release timing depends on the prior REST-toggle implementation being QA-tested and stable in production for the agreed window +- Keep the GraphQL/Apollo removal branch and the future `PDIAP-15836` / `PDIAP-12284` branch current with `main`; if conflict resolution looks non-trivial, flag it so a 1-2 point branch-maintenance story can be created - 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 +- Remaining Google API Key alerts should not be framed as newly introduced REST-story secrets unless evidence changes; current evidence ties them to older April 18, 2025 work and a separate backend/rotation support path --- diff --git a/project-knowledge/01-current/work-items.md b/project-knowledge/01-current/work-items.md index 68d8523..6902cc7 100644 --- a/project-knowledge/01-current/work-items.md +++ b/project-knowledge/01-current/work-items.md @@ -2,7 +2,7 @@ type: current-work-items project: fidelity status: active -updated: 2026-05-04 +updated: 2026-05-05 tags: - current-work - work-item @@ -20,12 +20,36 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `PDIAP-15838` - Remove Apollo for iOS Detail: `project-knowledge/02-work-items/pdiap-15838.md` - Current note: active Apollo-removal cleanup and validation; draft PR is open for internal review. `SampleApp` was updated to a newer `PicoSDK` path so Apollo is removed from the transitive sample-app dependency path too. Do not merge until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues. + Current note: ticket moved to Done after external review feedback was addressed, but the draft PR stays unmerged. Keep the branch up to date with `main` until REST backend is live in production and REST toggles have been enabled for consumers for the required validation window; expected merge timing is at least 30 days out. - `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`. + Current note: approved at `8` points and now paired with `PDIAP-12284` for the UIKit-removal implementation path. Do not move to In Progress until the next sprint starts on Thursday after lunch. Treat `PDIAP-15836` as blocked by `PDIAP-12284` unless validation proves the lifecycle fix can be implemented independently. + +- `PDIAP-12284` - Remove UIKit wrapping from XFlow + Detail: `project-knowledge/02-work-items/pdiap-12284.md` + Current note: reopened after rollback and should be handled with `PDIAP-15836`. Work can begin, but Jira status movement waits for the next sprint; merge/release waits until after REST-transition consumer validation. + +## Backlog / Future Reference + +- `PDIAP-11962` - Closure of secret scanning alerts + Detail: `project-knowledge/02-work-items/pdiap-11962.md` + Current note: prior closure was submitted on October 9, 2025 and Matthew closed earlier alerts/story on March 5, 2026. Two Google API Key alerts remain open and appear tied to old April 18, 2025 work, not the current REST story. + +- `PDIAP-11961` - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation + Detail: `project-knowledge/02-work-items/pdiap-11961.md` + Current note: related unassigned story for remaining Google API Key alerts; not a current priority but should be preserved for future planning. + +- `PDIAP-11562` - Investigate if XFlow is being built as debug + Detail: `project-knowledge/02-work-items/pdiap-11562.md` + Current note: likely tied to the `XFlowSDK_Debug` variable check in the XFlow podspec and Fid4 consumption, not Sparta-team work; historical Slack suggests Jenkins may build the xcframework path while local development consumes XFlow as a normal library, but this needs current validation. + +- `PDIAP-12226`, `PDIAP-12227`, `PDIAP-12228` - Sparta backlog items + Details: `project-knowledge/02-work-items/pdiap-12226.md`, `project-knowledge/02-work-items/pdiap-12227.md`, `project-knowledge/02-work-items/pdiap-12228.md` + Current note: Slack history ties these to the SpartaSDK follow-up split from initialization/JSON decoding, grid rendering/core components, and interactive/lifecycle behavior. Decoding and rendering are partially complete; interactive components remain blocked by unresolved mobile JavaScript execution. + +## Recently Completed - `PDIAP-16167` - AccountLink - XFlow causing web view rewrites investigation Detail: `project-knowledge/02-work-items/pdiap-16167.md` - Current note: active documentation/root-cause story for the FTTransfer AccountLink issue. The report should include the `XFlowSDK v0.1.0` rollback evidence and the minimal presentation-anchor fix. + Current note: moved to Done after publishing the Confluence report and sending the findings to Zachary / Jira / Discourse. Future references should frame this as a consumer-side SwiftUI presentation-topology issue, not an XFlow/XFlowViewMaker regression. diff --git a/project-knowledge/02-work-items/index.md b/project-knowledge/02-work-items/index.md index 1ad1fff..81f68a6 100644 --- a/project-knowledge/02-work-items/index.md +++ b/project-knowledge/02-work-items/index.md @@ -1,7 +1,7 @@ --- type: work-item-index project: fidelity -updated: 2026-04-16 +updated: 2026-05-05 tags: - work-item - map @@ -16,19 +16,39 @@ Provide a quick view of active and recently relevant Jira-linked work while keep ## 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-15838` ticket is Done, but the draft PR remains unmerged and must be kept current with `main` until REST backend production readiness and the required consumer validation window allow merge. - [pdiap-15836.md](./pdiap-15836.md) - `PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; comes after `PDIAP-15838`. + `PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; paired with `PDIAP-12284` and should not move to In Progress until the next sprint starts. -## Active / Reopened +- [pdiap-12284.md](./pdiap-12284.md) + `PDIAP-12284` reopened original UIKit-wrapping removal story; current blocker/dependency path for `PDIAP-15836`. + +## Backlog / Future Reference + +- [pdiap-11962.md](./pdiap-11962.md) + `PDIAP-11962` closure of secret scanning alerts; prior closure was submitted/closed, but two Google API Key alerts remain. + +- [pdiap-11961.md](./pdiap-11961.md) + `PDIAP-11961` related unassigned request for remaining Google API Key rotation/invalidation. + +- [pdiap-11562.md](./pdiap-11562.md) + `PDIAP-11562` investigate whether XFlow is being built as debug; historical Slack ties this to the `XFlowSDK_Debug` podspec variable and Fid4/Jenkins consumption. + +- [pdiap-12226.md](./pdiap-12226.md), [pdiap-12227.md](./pdiap-12227.md), [pdiap-12228.md](./pdiap-12228.md) + Sparta backlog items split across JSON decoding/initialization, grid rendering/core components, and interactive/lifecycle behavior; decoding/rendering are partially complete and interactive components remain blocked by unresolved mobile JavaScript execution. + +## Recently Completed + +- [pdiap-16167.md](./pdiap-16167.md) + `PDIAP-16167` AccountLink investigation completed with Confluence/Jira/Discourse/Zachary follow-up; root cause is a consumer-side SwiftUI presentation-topology issue, not XFlow/XFlowViewMaker. - [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. + `PDIAP-15765` authenticated-only DOB issue in `HybridYouthAccountOpening` / `TeenIdentityCheck`; completed while keeping the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of scope. + +- [pdiap-14859.md](./pdiap-14859.md) + `PDIAP-14859` spike around final UIKit wrapping removal and rollout planning is done. --- diff --git a/project-knowledge/02-work-items/pdiap-11562.md b/project-knowledge/02-work-items/pdiap-11562.md new file mode 100644 index 0000000..baa417f --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-11562.md @@ -0,0 +1,41 @@ +--- +type: work-item +project: fidelity +status: backlog-review +ticket: PDIAP-11562 +title: "Investigate if XFlow is being built as debug" +systems: [xflowsdk, fid4] +workstreams: [dependency-management, backlog-triage] +people: [jeff-dewitte] +related: [] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - build +--- + +# PDIAP-11562 - Investigate if XFlow is being built as debug + +## Status + +- Backlog item under review for possible next work. + +--- + +## Current Understanding + +- This is related to how the XFlow podspec is configured and how Fid4 consumes it. +- It is not currently understood as Sparta-team work. +- The concern is whether a debug build configuration or debug-like flag is being used in a dependency-integration context where it should not be. +- Next investigation should identify why/how the flag or build configuration is used and whether there is a safer integration approach. + +--- + +## Historical Slack Context + +- September 2025 backlog context lists the full title as `Spike: Research/investigate if Xflow is being built as debug in Fid4 and if that’s a concern or intentional.` +- November 2025 Slack context says the relevant check is the `XFlowSDK_Debug` variable in the podspec, not a Podfile setting. +- David confirmed in November 2025 that the `XFlowSDK_Debug` variable check was still present. +- Working interpretation from that thread: Jenkins likely does not set the variable when building the static framework; the `if/else` path may be intended so local development consumes XFlow as a normal library while Jenkins builds/consumes it as an xcframework. +- Treat that as a historical hypothesis to verify in current code/build settings, not as a confirmed current production behavior. diff --git a/project-knowledge/02-work-items/pdiap-11961.md b/project-knowledge/02-work-items/pdiap-11961.md new file mode 100644 index 0000000..6ca4933 --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-11961.md @@ -0,0 +1,39 @@ +--- +type: work-item +project: fidelity +status: backlog +ticket: PDIAP-11961 +title: "Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation" +systems: [xflowsdk] +workstreams: [security, backlog-triage] +people: [jeff-dewitte] +related: [pdiap-11962] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - security +--- + +# PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation + +## Status + +- Backlog item; not assigned yet. +- Jeff relayed that this is not a priority yet, but asked David to keep the details noted for future reference. + +--- + +## Context + +- Related to the remaining Google API Key alerts not included in the previous `PDIAP-11962` closure. +- If key rotation or invalidation is required, David/XFlow likely needs backend support or clarification because Google API Key rotation is not owned directly by the XFlow iOS side. + +--- + +## Historical Slack Context + +- October 2025 Slack context describes `PDIAP-11961` as the request for rotation/invalidation of active exposed Google API keys. +- The active Google API keys were documented as still valid/in use by the service, so they were intentionally separated from inactive-secret closure evidence. +- `PDIAP-11962` was created as the second-phase closure story to run after `PDIAP-11961` invalidation/rotation work completed. +- Earlier investigation noted that the API key appeared in a service response and that GitHub was flagging the old commit where the key had been hard-coded and later removed. diff --git a/project-knowledge/02-work-items/pdiap-11962.md b/project-knowledge/02-work-items/pdiap-11962.md new file mode 100644 index 0000000..e838cfb --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-11962.md @@ -0,0 +1,52 @@ +--- +type: work-item +project: fidelity +status: backlog-review +ticket: PDIAP-11962 +title: "Closure of secret scanning alerts" +systems: [xflowsdk] +workstreams: [security, backlog-triage] +people: [jeff-dewitte] +related: [pdiap-11961] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - security +--- + +# PDIAP-11962 - Closure of secret scanning alerts + +## Status + +- Backlog item under review for future work. +- Earlier alert-closure process appears partially completed, but two Google API Key alerts remain open. + +--- + +## Current Findings + +- David found an October 9, 2025 email confirming the prior submission. +- Follow-up shows Matthew closed the earlier alerts/story on March 5, 2026. +- Two Google API Key alerts remain open and were not part of that closure. +- Those alerts appear tied to an old `MockPageViewWithHiddenToggle` commit from April 18, 2025, not newly introduced REST-story work. +- Google API Key rotation is not owned by David/XFlow directly; backend support or clarification may be needed if rotation/invalidating is required. + +--- + +## Historical Slack Context + +- October 2025 Slack context ties this story to `PDIAP-11573 - Remediate secret scanning alerts in XFlow iOS SDK`. +- The intended sequence was: + 1. report inactive secrets through the SSDLC/AAVD process, + 2. use `PDIAP-11961` to handle invalidation/rotation of still-active Google API keys, + 3. use `PDIAP-11962` to close the GitHub alerts after `PDIAP-11961` is completed. +- Slack context from October 10, 2025 says inactive secrets were reported in `ESWR-35407`, `PDIAP-11961` was created for active-secret invalidation, and `PDIAP-11962` was created to manage alert closure after invalidation. +- Slack context from November 19, 2025 says the secret-remediation alerts were still present and none had been marked resolved at that time. +- Treat `PDIAP-11962` as the closure/follow-up story, not the rotation/invalidation story itself. + +--- + +## Related Work + +- `PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation` is the related story for the remaining Google API Key alerts and is not assigned yet. diff --git a/project-knowledge/02-work-items/pdiap-12226.md b/project-knowledge/02-work-items/pdiap-12226.md new file mode 100644 index 0000000..71ea65b --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-12226.md @@ -0,0 +1,40 @@ +--- +type: work-item +project: fidelity +status: backlog-partial +ticket: PDIAP-12226 +title: "iOS: Implement SpartaSDK initialization and JSON decoding" +systems: [sparta, xflowsdk] +workstreams: [sparta, backlog-triage] +people: [jeff-dewitte, aylwing-olivas] +related: [pdiap-12227, pdiap-12228] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - sparta +--- + +# PDIAP-12226 - iOS: Implement SpartaSDK initialization and JSON decoding + +## Status + +- Backlog item; partially complete. + +--- + +## Current Understanding + +- Last known work was a decoding-layer refactor based on internal feedback from Aylwing. +- Direction was to make decoding strict so malformed backend responses surface errors to the consumer instead of silently skipping unsupported components. +- Earlier approach used a `strict mode` toggle where unsupported components were omitted from rendering. +- Refactor is still in progress; if no new component types are added, it may not require much beyond the existing work. + +--- + +## Historical Slack Context + +- October 2025 Slack context shows the work started from `PDIAP-11956` / `PDIAP-12066` exploration: dynamic JSON decoding, `SpartaNodeRegistry`, strict-mode behavior, and fallback handling for unknown node types. +- By October 21, 2025, decoding tests validated fallback handling and registry lookups in an internal `SwiftUIBuilder` PR. +- November 2025 planning split the remaining SpartaSDK work into separate stories; this one became the initialization and JSON-decoding story. +- November 20-24, 2025 Slack context says `PDIAP-12226` was moved to a later sprint and David was reviewing whether the current JSON-decoding implementation was ready for a formal PR. diff --git a/project-knowledge/02-work-items/pdiap-12227.md b/project-knowledge/02-work-items/pdiap-12227.md new file mode 100644 index 0000000..8107396 --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-12227.md @@ -0,0 +1,37 @@ +--- +type: work-item +project: fidelity +status: backlog-partial +ticket: PDIAP-12227 +title: "iOS: Render grid-based layout and core visual components" +systems: [sparta, xflowsdk] +workstreams: [sparta, backlog-triage] +people: [jeff-dewitte] +related: [pdiap-12226, pdiap-12228] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - sparta +--- + +# PDIAP-12227 - iOS: Render grid-based layout and core visual components + +## Status + +- Backlog item; partially complete. + +--- + +## Current Understanding + +- There is already a working base that places elements on the grid layout. + +--- + +## Historical Slack Context + +- October 2025 Slack context shows rendering work began after the decoding spike, with a SwiftUI renderer/protocol path and initial support for titles, buttons, text, and grid-related components. +- The Sparta work uses JSON responses with grid-position attributes; Jeff advised avoiding the term `DSL` in user-facing/sample naming unless the team confirms that language. +- November 2025 planning split the work so `PDIAP-12227` covered grid-based layout and core visual components. +- November 20, 2025 Slack context says Quy wanted `PDIAP-12226` and `PDIAP-12227` placed into the sprint after next at that time, with the option to pull them in earlier if capacity allowed. diff --git a/project-knowledge/02-work-items/pdiap-12228.md b/project-knowledge/02-work-items/pdiap-12228.md new file mode 100644 index 0000000..6ad8a54 --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-12228.md @@ -0,0 +1,37 @@ +--- +type: work-item +project: fidelity +status: backlog-blocked +ticket: PDIAP-12228 +title: "iOS: Implement interactive components and lifecycle behaviors" +systems: [sparta, xflowsdk] +workstreams: [sparta, backlog-triage] +people: [jeff-dewitte] +related: [pdiap-12226, pdiap-12227] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - sparta +--- + +# PDIAP-12228 - iOS: Implement interactive components and lifecycle behaviors + +## Status + +- Backlog item; blocked or unresolved. + +--- + +## Current Understanding + +- Covers interactive components such as buttons. +- Main unresolved question was how to execute JavaScript on mobile. + +--- + +## Historical Slack Context + +- November 2025 planning split the SpartaSDK proof-of-concept follow-up into initialization/decoding, rendering, interactive components/lifecycle, and navigation/flow logic tracks. +- Earlier Slack updates show buttons and dropdown rendering were already partially explored under foundational SpartaSDK work, but full interactive behavior and lifecycle/navigation behavior were not complete. +- Treat JavaScript execution on mobile as the major unresolved blocker for richer interactive behavior unless current project evidence supersedes it. diff --git a/project-knowledge/02-work-items/pdiap-12284.md b/project-knowledge/02-work-items/pdiap-12284.md new file mode 100644 index 0000000..2f1622d --- /dev/null +++ b/project-knowledge/02-work-items/pdiap-12284.md @@ -0,0 +1,46 @@ +--- +type: work-item +project: fidelity +status: backlog-ready +ticket: PDIAP-12284 +title: "Remove UIKit wrapping from XFlow" +systems: [xflowsdk, xflowviewmaker] +workstreams: [xflow-swiftui-migration, consumer-integration] +people: [jeff-dewitte] +related: [pdiap-15836, pdiap-15838] +updated: 2026-05-05 +tags: + - work-item + - fidelity + - swiftui + - xflow +--- + +# PDIAP-12284 - Remove UIKit wrapping from XFlow + +## Status + +- Reopened after rollback. +- Jeff asked David to start working on this with `PDIAP-15836`, but not to move the active story to In Progress until the next sprint starts on Thursday after lunch. + +--- + +## Context + +- This is the original story for removing the UIKit wrapping. +- Current relationship to track: `PDIAP-15836` is blocked by this story because the lifecycle-sequencing fix depends on the UIKit removal landing, unless further validation proves part of `PDIAP-15836` can be implemented independently on the SwiftUI path. + +--- + +## Historical Slack Context + +- November 21, 2025 Slack context says David created `PDIAP-12284` and `PDIAP-12285` to cover remaining UIKit-removal work inside XFlow after reviewing open Sendable and XFlowViewMaker-track stories. +- That same backlog refinement closed out pending XFlowViewMaker stories that were no longer needed. +- Current Mattermost context supersedes the old standalone refinement framing: this story is now reopened after rollback and should be handled together with `PDIAP-15836`. + +--- + +## Sequencing + +- Work can begin, but merge/release should wait until the REST-transition consumer-validation window has completed. +- Keep the implementation branch up to date with `main` while waiting for approval to work with consumers and merge. diff --git a/project-knowledge/02-work-items/pdiap-15836.md b/project-knowledge/02-work-items/pdiap-15836.md index 0a6dcd6..d9d1bc5 100644 --- a/project-knowledge/02-work-items/pdiap-15836.md +++ b/project-knowledge/02-work-items/pdiap-15836.md @@ -1,14 +1,14 @@ --- type: work-item project: fidelity -status: active +status: backlog-ready 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-21 +related: [pdiap-14859, pdiap-12284, pdiap-15838] +updated: 2026-05-05 tags: - work-item - fidelity @@ -19,8 +19,9 @@ tags: ## Status -- Approved -- Sequenced after `PDIAP-15838` +- Approved, but should not be moved to In Progress until the next sprint starts +- Jeff asked David to start working on the `PDIAP-15836` / `PDIAP-12284` implementation path, with Jira status movement deferred until Thursday after lunch +- Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation - Sized at `8` points --- @@ -44,8 +45,11 @@ tags: ## Sequencing And Dependencies - This story should come after `PDIAP-15838`. +- `PDIAP-12284` is the original UIKit-wrapping removal story and was reopened after rollback. +- Current relationship to add/track in Jira: `PDIAP-15836` is blocked by `PDIAP-12284`, because the UIKit removal needs to land for the lifecycle fix to apply. David still needs to validate whether any part of `PDIAP-15836` can be implemented independently on the SwiftUI path. - 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. +- Expect a long-lived branch: after implementation, maintain the branch until consumer-testing approval. Jeff expects the GraphQL-removal branch to merge first after the REST validation period, then that branch should be merged into the `PDIAP-15836` / `PDIAP-12284` branch. Current estimate is roughly 90-100 days from 2026-05-05 unless Fidelity shortens the review windows. --- @@ -56,3 +60,4 @@ tags: - The Confluence/root-cause document was updated to reflect that FTTransfer changes are not the primary need anymore. - The primary recommendation is to adjust the dismissal handling/sequencing correctly in the hosting path. - FTTransfer improvements can still be mentioned as a secondary improvement, but not as a required change to reproduce the same visual behavior. +- When explaining why code still remains, clarify that the spike identified and documented the root cause, but implementation changes have not yet been published. diff --git a/project-knowledge/02-work-items/pdiap-15838.md b/project-knowledge/02-work-items/pdiap-15838.md index aa458e8..505785b 100644 --- a/project-knowledge/02-work-items/pdiap-15838.md +++ b/project-knowledge/02-work-items/pdiap-15838.md @@ -1,14 +1,14 @@ --- type: work-item project: fidelity -status: active +status: done-pending-merge ticket: PDIAP-15838 title: "Remove Apollo for iOS" systems: [xflowsdk] workstreams: [rest-migration] people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas] related: [launchdarkly, github-copilot] -updated: 2026-04-29 +updated: 2026-05-05 tags: - work-item - fidelity @@ -19,8 +19,9 @@ tags: ## Status -- Draft PR open for internal review -- PR merge should wait until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues +- Ticket moved to Done after external review feedback was addressed +- Draft PR remains unmerged and must be kept up to date with `main` +- PR merge should wait until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues - Sized at `8` points --- @@ -82,9 +83,15 @@ tags: - Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue. - Jeff clarified the validation ask: inspect whether Fid4 has simulator-versus-physical-device or generated-build differences in build settings/schemes/configurations, including any optimized-build-size or release-style settings that could explain behavior seen in generated builds but not when running locally. - Current likely Fid4 build differences to report: Trunk/generated builds use the `Release` configuration while local runs are usually `Debug`; optimization settings such as `SWIFT_OPTIMIZATION_LEVEL` and `GCC_OPTIMIZATION_LEVEL` can differ; Jenkins uses a generated `build-overrides` xcconfig that local builds do not use and may affect values such as secrets; and CocoaPods dependency resolution can vary depending on the local specs repo state. +- External review reached Bruce and produced minor feedback. David addressed the feedback and pushed the suggested change. +- One accepted review change was to set `responseKey: String? = nil` as the default in `FlowRESTOperationContract`, allowing operations such as `updateSlots`, `storeString`, and `publishEvent` to omit `responseKey` when not needed. +- The native Swift domain enum file should remain as the canonical location for XFlow domain enums after removal of GraphQL-generated code. +- Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days. +- Branch maintenance is now part of the work: keep the GraphQL/Apollo-removal branch up to date with `main` until the REST backend/toggle validation window allows merge. If future `main` merges create conflicts that look non-trivial, raise it so a 1-2 point maintenance story can be created. --- ## Sequencing - This story remains sequenced before `PDIAP-15836`. +- This branch should merge to `main` before the future `PDIAP-15836` / `PDIAP-12284` branch is updated and merged. diff --git a/project-knowledge/02-work-items/pdiap-16167.md b/project-knowledge/02-work-items/pdiap-16167.md index 4b61d97..d625782 100644 --- a/project-knowledge/02-work-items/pdiap-16167.md +++ b/project-knowledge/02-work-items/pdiap-16167.md @@ -1,7 +1,7 @@ --- type: work-item project: fidelity -status: active +status: done ticket: PDIAP-16167 title: AccountLink - XFlow causing web view rewrites investigation systems: [xflowsdk, xflowviewmaker, fttransfer] @@ -13,16 +13,16 @@ tags: - fidelity - discourse - swiftui -updated: 2026-05-04 +updated: 2026-05-05 --- # PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation ## Status -- Root cause identified and verified -- Confluence report requested by Jeff; draft sent for review -- Jeff approved creating the story +- Done +- Confluence report published +- Findings/comment sent to Zachary and posted for Jira/Discourse follow-up --- @@ -51,11 +51,12 @@ updated: 2026-05-04 ## Current Guidance -- Jeff's direction: document the findings clearly in a Confluence report, send it to Zachary, and comment it on the story. No need to fix their code directly; clear communication of the issue is the goal. -- Jeff also asked to include a version comparison showing that recent REST/GraphQL changes to XFlowSDK do not intersect with this flow. +- Keep future references clear that this was documented as a consumer-side SwiftUI presentation-topology defect, not an XFlow/XFlowViewMaker regression. +- Include Jeff's preferred clarification that `XFlowSDK v0.1.0` predates the REST and Apollo-related changes that were newer additions. --- -## Next Step +## Closure Notes -- Finalize and publish the Confluence report with all findings, the v0.1.0 rollback evidence, and the XFlowViewMaker version comparison. +- The published recommendation is to move the full-screen cover modifier to the stable root of `BankInformationView`, outside the conditional branch. +- David moved the story to Done on 2026-05-05. diff --git a/project-knowledge/06-daily/2026-05-05.md b/project-knowledge/06-daily/2026-05-05.md new file mode 100644 index 0000000..239c891 --- /dev/null +++ b/project-knowledge/06-daily/2026-05-05.md @@ -0,0 +1,50 @@ +--- +type: daily +project: fidelity +date: 2026-05-05 +updated: 2026-05-05 +focus: [pdiap-15838, pdiap-16167, pdiap-15836, backlog-triage] +work-items: [PDIAP-15838, PDIAP-16167, PDIAP-15836, PDIAP-12284, PDIAP-11962, PDIAP-11961, PDIAP-11562, PDIAP-12226, PDIAP-12227, PDIAP-12228] +blockers: [consumer-validation-window, backend-rest-production-readiness, remaining-google-api-key-alerts] +tags: + - daily + - fidelity +--- + +# 2026-05-05 + +## Mattermost Evidence Promoted + +- `PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation` + - Daily scrum reported minor Confluence report adjustments and planned publication. + - The Confluence report was published and the proposed Jira/Discourse/DM wording was sent to Zachary. + - Final external framing: root cause is a consumer-side SwiftUI presentation-topology / view-identity invalidation in `BankInformationView`, not XFlow or XFlowViewMaker. The issue reproduces on `XFlowSDK v0.1.0`, predating REST and Apollo-related changes, and Flagship does not appear to show the same behavior because presentation ownership is behind a more stable boundary. + - David moved `PDIAP-16167` to Done. + +- `PDIAP-15838 - Remove Apollo for iOS` + - Daily scrum reported the draft PR was sent for external review. + - Bruce left minor feedback; David addressed it and pushed the suggested change. + - One review change set `responseKey: String? = nil` as the default in `FlowRESTOperationContract`, so operations such as `updateSlots`, `storeString`, and `publishEvent` can omit `responseKey` when not needed. + - David kept the file that now serves as the canonical location for XFlow domain enums after removal of GraphQL-generated code. + - Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days. + - Jeff clarified that the GraphQL-removal branch must stay up to date with `main` until REST backend is live in production with REST toggles enabled and the 30-day validation window is complete. + +- `PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment` and `PDIAP-12284` + - Jeff initially noted that starting this work now could create a long-lived branch, because UIKit-removal work needs feature flags, consumer testing, and a later merge/release window after the REST transition finishes. + - David clarified that the spike identified and documented the root cause, but no code changes have been published yet. + - `PDIAP-12284` is the original UIKit-wrapping removal story and was reopened after rollback. David noted `PDIAP-15836` should be treated as blocked by `PDIAP-12284`, although the Jira link was not yet present. + - Jeff later asked David to start working on `PDIAP-15836` / `PDIAP-12284`, but not to move the stories to In Progress until the next sprint starts on Thursday after lunch. + - Jeff's branch-management guidance: after implementation, maintain the branch until consumer-testing approval; merge the GraphQL-removal branch first after the REST validation period, then merge that into the `PDIAP-15836` / `PDIAP-12284` branch. Expected merge timing is roughly 90-100 days from today unless Fidelity shortens the review windows. + +- Backlog triage + - Jeff asked for previously assigned backlog work because there are no other in-progress stories after `PDIAP-16167` and `PDIAP-15838` move to Done. + - `PDIAP-11962 - Closure of secret scanning alerts`: David found an October 9, 2025 email confirming submission; Matthew closed the earlier alerts/story on March 5, 2026. Two Google API Key alerts remain open and were not part of that closure. + - `PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation`: related story for the remaining Google API Key alerts; not assigned yet. Jeff said this is not a priority yet but should be noted for future. + - `PDIAP-11562 - investigate if XFlow is being built as debug`: David identified it as related to XFlow podspec configuration and Fid4 consumption, not Sparta-team work. + - Sparta backlog notes: `PDIAP-12226` decoding is partially complete with a strict-decoding refactor still in progress; `PDIAP-12227` rendering has a working grid-layout base and is partially done; `PDIAP-12228` interactive components is blocked by unresolved mobile JavaScript execution. + +## Slack Archive Backfill + +- Checked the historical Slack archive for the newly recreated work-item notes. +- Promoted useful Slack backfill into the relevant work-item notes for `PDIAP-11962`, `PDIAP-11961`, `PDIAP-11562`, `PDIAP-12226`, `PDIAP-12227`, `PDIAP-12228`, and `PDIAP-12284`. +- Skipped non-Fidelity API-key hits and generic Sparta chatter that did not map cleanly to these Jira items. diff --git a/project-knowledge/06-daily/index.md b/project-knowledge/06-daily/index.md index 3990cdf..24a4a75 100644 --- a/project-knowledge/06-daily/index.md +++ b/project-knowledge/06-daily/index.md @@ -1,7 +1,7 @@ --- type: daily-index project: fidelity -updated: 2026-05-01 +updated: 2026-05-05 tags: - daily - map @@ -29,6 +29,7 @@ Promote durable facts into `project-knowledge/01-current/`, `project-knowledge/0 - [2026-04-28](2026-04-28.md) - [2026-04-29](2026-04-29.md) - [2026-04-30](2026-04-30.md) +- [2026-05-05](2026-05-05.md) ---