david.delagneau
dbc1894e27
- 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.
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
---
|
|
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.
|