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

feat: Update documentation for memory vault integration and work items, clarifying usage of Obsidian CLI and resolving Fid4 dependency conflicts

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 14:42:00 -06:00
parent 4ea188739d
commit 696a1258b1
7 changed files with 35 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
vault/06-daily/2026-04-17.md
View File

@@ -4,7 +4,7 @@ project: fidelity
date: 2026-04-17
focus: [ao-discourse, consumer-integration, rest-migration]
work-items: [pdiap-15765, pdiap-15838]
blockers: [xflowviewmaker-code-owner-approval]
blockers: []
updated: 2026-04-17
tags:
- daily
@@ -60,8 +60,31 @@ tags:
- Tauf approved that podspec-repo PR
- After that merge, `pod install --repo-update` worked in Fid4 because the published podspecs no longer constrained the XFlowViewMaker version
## Mattermost Refresh - Release Progress
- The remaining XFlowViewMaker code-owner approval was obtained from Tauf, allowing the release process to continue.
- The XFlowViewMaker release was published successfully.
- David then opened the Fid4 PR with the latest versions and planned to request reviews from Santosh and Tauf.
## Mattermost Refresh - Urgent REST Validation
- Jeff redirected work to an urgent consumer report claiming REST calls were failing on iOS when the toggle was enabled.
- David clarified that David does not have access to Flagship LaunchDarkly projects; only the sample app LD project is available from David's side.
- David tested locally on `main` and reported that REST loaded correctly with the `iOS-XflowRestEnabled` flag enabled.
- David also verified that XFlow `2.8.47` already supports that flag and is present in the 4.30 line used for consumer validation.
- David later verified on the `release/4.30` branch that the behavior still looked correct there.
- Current working hypothesis: the consumer report may reflect a version mismatch or incorrect flag configuration rather than a reproducible iOS REST failure in current local validation.
- Adam's `trunk build` reference appears to mean a real-device build platform that can provide downloadable App Store/internal IPAs and a dependency snapshot such as `Podfile.lock`, even though David cannot run those IPAs on simulators.
## Communication Correction
- David corrected a drafting mistake: when proposing a message that David will send directly to a Fidelity-side contact, the wording must not imply Jeff is the sender or that the recipient already knows David through Jeff.
- For this kind of direct outreach, avoid phrases like `Jeff mentioned...` unless David explicitly wants that framing.
- David made a second correction: if Jeff asked for internal documentation or future-process capture, that should stay internal and should not be surfaced in David's external message unless explicitly requested.
## Mattermost Refresh - Dependency Reproduction Caution
- Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior.
- David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced.
- If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone.