- 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.
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.
david.delagneau
1ad707373a