diff --git a/core/integrations/memory-vault-model.md b/core/integrations/memory-vault-model.md index 691ddfb..eb9b991 100644 --- a/core/integrations/memory-vault-model.md +++ b/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. diff --git a/vault/01-current/current-work.md b/vault/01-current/current-work.md index 7a089b5..070638f 100644 --- a/vault/01-current/current-work.md +++ b/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 diff --git a/vault/01-current/work-items.md b/vault/01-current/work-items.md index 147681a..4331267 100644 --- a/vault/01-current/work-items.md +++ b/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. diff --git a/vault/02-work-items/pdiap-15765.md b/vault/02-work-items/pdiap-15765.md index 84e9c6d..3d11f36 100644 --- a/vault/02-work-items/pdiap-15765.md +++ b/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 -- The XFlowViewMaker PR already has some approvals, but one FTFrameworks code-owner approval is still required before merge +- XFlowViewMaker was updated to the new XFlow version, approved, and published after the required code-owner approval +- 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. diff --git a/vault/03-context/process/context-maintenance.md b/vault/03-context/process/context-maintenance.md index 9b5d309..10a6374 100644 --- a/vault/03-context/process/context-maintenance.md +++ b/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. diff --git a/vault/03-context/workstreams/consumer-integration.md b/vault/03-context/workstreams/consumer-integration.md index 34e7fc1..4fe605c 100644 --- a/vault/03-context/workstreams/consumer-integration.md +++ b/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. diff --git a/vault/06-daily/2026-04-17.md b/vault/06-daily/2026-04-17.md index ebda28d..ed13a29 100644 --- a/vault/06-daily/2026-04-17.md +++ b/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.