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

core/integrations/memory-vault-model.md

@@ -72,6 +72,7 @@ This gives agents an automatic destination for new notes without coupling the ru
 
 - Use the memory interface when creating new canonical notes from a known type.
 - Use the memory interface for broad search, Base queries, and vault health checks.
+- Prefer Obsidian CLI property operations for frontmatter/property edits when available, especially on existing notes that appear in Bases, because the CLI reduces YAML formatting drift.
 - Edit Markdown directly for precise memory curation, corrections, and content updates.
 - Do not treat Obsidian CLI failure as project context.
 - Do not require Obsidian to be running for core workspace operation.

vault/01-current/current-work.md

@@ -18,7 +18,7 @@ tags:
 - Follow up on active tickets through `vault/02-work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
 - Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike
 - After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later
-- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by getting the remaining FTFrameworks code-owner approval on the XFlowViewMaker PR, then run the pipeline and update Fid4 while continuing `PDIAP-15838` in parallel where possible
+- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by carrying the already-published XFlowViewMaker update through the Fid4 PR and downstream consumer path
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
 - Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
 - Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
@@ -35,7 +35,8 @@ tags:
 - When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future `birthDate` payloads, not as a fix for the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue
 - The Youth / `TeenIdentityCheck` issue was iOS-only; do not describe it as reproducing on both platforms
 - The service-side payload update and the XFlowSDK fallback PR address the same Youth / `TeenIdentityCheck` issue; do not split them into separate Youth issues when summarizing scope
-- The `PDIAP-15765` compatibility fix is now merged and released in XFlow `2.8.48`; the remaining near-term work is getting the last FTFrameworks code-owner approval on the XFlowViewMaker PR, then running the pipeline and updating Fid4
+- The `PDIAP-15765` compatibility fix is now merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up has also been approved, published, and unblocked in Fid4 through a podspec-repo change, and the current downstream step is the open Fid4 PR/update path
+- A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both `main` and `release/4.30`; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
 - Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
 - The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up
 
@@ -50,6 +51,7 @@ tags:
 - Preserving accurate context when summarizing work from another machine
 - Validating dismissal sequencing changes across SwiftUI flows
 - Keeping REST deprecation scope explicit while GraphQL fallback still exists
+- Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
 - Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
 - Closing `PDIAP-14859` cleanly with the right links, blocker relationship, and feature-flag wording
 - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope

vault/01-current/work-items.md

@@ -32,4 +32,4 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
 
 - `PDIAP-15765` - AO DOB field error not showing investigation
   Detail: `vault/02-work-items/pdiap-15765.md`
-  Current note: the small XFlowSDK iOS `birthDate` compatibility fix was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up PR is open and partially approved but still needs one FTFrameworks code-owner approval before merge. After that, `publish-XFlowViewMaker` must release the adapter, then Fid4 must update its Podfile and merge the consumer PR so the change propagates through the real app path.
+  Current note: the small XFlowSDK iOS `birthDate` compatibility fix was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up is now approved and published. A downstream Fid4 dependency conflict was resolved through a podspec-repo update removing the XFlowViewMaker version reference from the latest `FTAccountOpen` and `FTTransfer` podspecs, and the current step is the open Fid4 PR so the change can propagate through the real app path.

vault/02-work-items/pdiap-15765.md

@@ -21,8 +21,8 @@ tags:
 
 - Active closeout
 - Small XFlowSDK compatibility fix merged and released in XFlow `2.8.48`
-- XFlowViewMaker was updated to the new XFlow version and a follow-up PR was opened
+- XFlowViewMaker was updated to the new XFlow version, approved, and published after the required code-owner approval
-- The XFlowViewMaker PR already has some approvals, but one FTFrameworks code-owner approval is still required before merge
+- The downstream Fid4 update is in progress through an open consumer PR
 
 ---
 
@@ -74,7 +74,7 @@ tags:
 - Resolve the Fid4 dependency conflict through the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
 - The podspec-repo PR was sent to Tauf and approved.
 - After that merge, `pod install --repo-update` in Fid4 worked because the published podspecs no longer restricted the XFlowViewMaker version.
-- Continue with the consumer PR/update path now that dependency resolution is unblocked.
+- A Fid4 PR with the latest versions is now open; continue with the consumer PR/review path now that dependency resolution is unblocked.
 - After the Fid4 PR merges, treat the app release as the final downstream step before broader user visibility.
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
 - Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.

vault/03-context/process/context-maintenance.md

@@ -20,6 +20,7 @@ Keep this workspace useful as living memory instead of a pile of disconnected no
 - Update canonical context when a durable fact changes.
 - Prefer correcting stale context over appending contradictory notes.
 - If a canonical note appears in an Obsidian Base, update its frontmatter properties together with the prose content.
+- When changing frontmatter properties on existing canonical notes, prefer Obsidian CLI property operations through `scripts/obsidian/cli.sh` when available so YAML spacing and property formatting stay clean; fall back to direct Markdown edits only when the CLI is unavailable or the operation is unsupported.
 - Keep templates under `vault/09-templates/` out of real-note Bases by filtering the template folder.
 - Role mapping files should not use `type: person`; reserve `type: person` for actual people profiles.
 - Work-item notes should keep known `systems`, `workstreams`, `people`, and `related` properties current.

vault/03-context/workstreams/consumer-integration.md

@@ -90,6 +90,7 @@ Capture the durable release and validation path between XFlow changes and real c
   - fixed version references in the Podfile when present
   - archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
 - 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.

vault/06-daily/2026-04-17.md

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