Files

david.delagneau dbc1894e27 Add project-knowledge structure and templates

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

2026-04-17 15:52:08 -06:00

2.2 KiB

Raw Blame History

type, project, status, workstreams, related, updated, tags

type

project

status

workstreams

updated

FTFrameworks

Role

FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTransfer, and related libraries that mediate how XFlow changes reach Fid4.

Durable Context

FTFrameworks is often part of the real validation and release chain, not just a downstream detail.
Historical Slack context shows pinned FT module versions repeatedly blocking adoption of newer XFlow or XFlowViewMaker changes in Fid4.
Changes to XFlow often needed corresponding FTAccountOpen or FTTransfer updates before end-to-end testing was realistic.
FTAccountOpen and FTTransfer consume XFlow through XFlowViewMaker rather than directly from XFlowSDK.
For Account Opening flows, the current path is understood to go through FTAccountOpen.

Validation And Release Implications

If Fid4 does not reflect the expected XFlow fix, check FT module versions before concluding the SDK change failed.
Version movement can require a chain such as:
- XFlowSDK
- XFlowViewMaker
- FTAccountOpen / FTTransfer
- Fid4
Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready.
FTFrameworks code-owner approval can also be a practical gate when the XFlowViewMaker update PR lives inside the shared PR100660-ios-frameworks monorepo.
In the current XFlowViewMaker propagation pattern, effective downstream constraints may be enforced in the podspec repo rather than the FTFrameworks source repo itself.
A successful Fid4 upgrade required removing the XFlowViewMaker version reference from both the latest FTAccountOpen and FTTransfer podspecs in the podspec repo, then rerunning pod install --repo-update.

Historical Signals From Slack

FTAccountOpen and FTTransfer were repeatedly mentioned in version bump and release coordination work.
Historical messages also tied FTFrameworks to FTAuth and MFA-related stories, showing that dependency understanding matters when sizing or scoping work.

2.2 KiB Raw Blame History