Add daily logs and templates for project fidelity
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
This commit is contained in:
@@ -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.
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
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 **published** Fid4 validation until that full dependency chain has propagated.
|
||||
- However, for **local validation**, developers can bypass the publication chain by modifying the `fid4` Podfile to use local path references for `XFlowSDK` and `XFlowViewMaker`.
|
||||
- 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
|
||||
|
||||
---
|
||||
|
||||
## Local Validation Path
|
||||
|
||||
- Testing a change locally in `fid4` does **not** require publishing a new version of `XFlowSDK` or `XFlowViewMaker`.
|
||||
- The local validation path involves:
|
||||
- Modifying the `fid4` (`ap010981-ios-flagship-app`) Podfile.
|
||||
- Adding local path references pointing to the local directories of `XFlowSDK` y `XFlowViewMaker` instead of versioned pods.
|
||||
- Running `pod install` to link the local workspaces.
|
||||
- This allows for rapid iteration and testing of XFlow changes directly within the flagship app context before committing to the full release propagation chain.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
work-items: [pdiap-14859, pdiap-15836, pdiap-12284]
|
||||
related: [consumer-integration, xflow-debugging]
|
||||
updated: 2026-05-08
|
||||
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.
|
||||
- For UIKit-wrapping removal, prefer a host-mode design that keeps SwiftUI as the default and limits `UIHostingController` to an explicit temporary fallback. Missing or unknown rollout configuration should not silently restore the UIKit host.
|
||||
- Keep host-mode ownership at the shared integration layer when possible. A Fid4-only per-flow map is less reusable for XFlow's multiple consumers and creates cleanup work when the fallback is retired.
|
||||
- Dismissal sequencing changes must be validated as lifecycle contracts, not just visual symptom fixes: delegate/session-clear callbacks should fire after confirmed dismissal, and `onDisappear` should not be treated as sufficient proof without simulator-log evidence.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user