- Deleted obsolete files: obsidian-vault.md, onboarding.md, workspace-model.md
- Updated opencode.json to remove references to deleted files.
- Revised profile.md to clarify the status of legacy paths and communication evidence.
- Adjusted prompts to reflect new file paths and improve clarity.
- Enhanced daily logs with focus, work-items, and blockers properties.
- Updated work-item notes to include systems, workstreams, people, and related properties.
- Improved context maintenance guidelines to ensure accurate and durable project knowledge.
- Refined base filters to exclude template files and ensure only relevant notes are displayed.
- Updated daily templates to ensure proper formatting and consistency.
- Modified workflows to align with the new vault structure and improve context synchronization.
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.
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.
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.
david.delagneau
374991a568