david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add daily logs and templates for project fidelity

Browse Source 
- 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:
David Delagneau
2026-05-21 12:28:07 -06:00
parent 7cbb49134a
commit 1ad707373a
203 changed files with 449 additions and 434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
workspaces/fidelity/project-knowledge/03-context/workstreams/consumer-integration.md Normal file
View File

@@ -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.