Add daily logs and templates for Fidelity project

- Created daily log entries for April 13-16, 2026, capturing standup contexts, Mattermost syncs, and ongoing work items.
- Established a daily logs index for easy navigation of daily entries.
- Introduced templates for daily notes, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Developed maps for AI workspace core, current work, Fidelity domain, and work items to enhance workspace navigation.
- Implemented base configurations for daily notes, decisions, people, systems, work items, and workstreams to streamline data management.
- Added a placeholder for attachments to facilitate file organization.

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

@@ -0,0 +1,37 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-08
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-08
+
+## Work Done
+
+- Investigated a Youth account flow issue reported externally
+- Compared the observed behavior against prior flow behavior
+- Captured notes to explain the issue clearly before sharing updates
+
+---
+
+## Findings
+
+- Reproduction required an authenticated user
+- Behavior appeared consistent with previously observed flow behavior
+- The report did not yet prove a regression
+
+---
+
+## Communication
+
+- Prepared a clearer explanation for follow-up through Mattermost
+- Framed the issue as an external report pending scope confirmation
+
+---
+
+## Next Step
+
+- Confirm whether any additional action is needed before closing the issue

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

@@ -0,0 +1,62 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-09
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-09
+
+## Work Done
+
+- Refined manager-facing communication about a reported behavior difference
+- Reframed ambiguous language before documenting the outcome in Jira
+- Updated context to reflect auth-dependent behavior
+- Confirmed the reported DOB validation issue only reproduces for authenticated users on TeenIdentityCheck
+- Created `PDIAP-15836` for dismissal delegate lifecycle sequencing in pure SwiftUI (`8` points)
+- Aligned `PDIAP-15838` scope with REST migration cleanup and feature-flag removal
+- Confirmed XFlowViewMaker `0.5.0` is already in Fid4
+- Updated the root cause document for the AccountLink dismissal sequencing issue tied to `PDIAP-15836` and got approval on the proposed wording
+
+---
+
+## Findings
+
+- The reported behavior depended on authenticated context
+- The original external report was incomplete
+- The comparison needed more precise wording to avoid implying regression
+- The dismissal sequencing change needs extra validation across flows, so the story was sized at 8 points
+- The REST deprecation story covers Apollo, GraphQL networking code, related tests/mocks, and transport feature flags
+
+---
+
+## Communication
+
+- Prepared clearer wording for Jeff
+- Focused on context, observation, and action instead of vague comparison language
+- Proposed a root cause document update and got confirmation on the revised wording
+
+---
+
+## Slack Archive Import
+
+- Imported 2,500 historical Slack messages spanning `2023-01-26` to `2025-11-24`
+- Channels covered: `fidelity-code-review`, `fidelity-grabaciones`, `fidelity-interface-meetings-on-calendar-outlook-team-etc`, `fidelity-jira`, `fidelity-preguntas`, `fidelity-reports-read-this-shit-no-excuses`, `fidelity-retrospective`, `fidelity-standup`
+- High-signal historical themes: XFlow SwiftUI migration work, Jira/story approval threads, pipeline debugging, and manager-reviewed message wording
+- Treated older pipeline and story details as historical evidence unless they still change current understanding
+
+---
+
+## Next Step
+
+- Keep using explicit issue framing for future Mattermost and Jira updates
+
+---
+
+## Workflow Clarification
+
+- This workspace is mainly used off the Fidelity work machine
+- Main practical use cases are: drafting Mattermost updates to Jeff, translating/refining English, reusing prior context, getting Swift technical support, and drafting PR/story text
+- Recommendations for new commands should prioritize communication support and context reuse over heavy local triage workflows that assume direct access to the product environment

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

@@ -0,0 +1,45 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-10
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-10
+
+## Clarification
+
+- `PDIAP-15838` should not be framed as directly tied to the UIKit-removal spike.
+- Avoid wording that implies `PDIAP-15838` is dependent on or part of the dismissal-sequencing / UIKit-removal spike.
+- Standups should prioritize updates directly tied to active work items and omit side questions such as version reminders that were only for internal context.
+- Current focus for today is to finalize `PDIAP-14859` with a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
+- Omit standup items that are not directly related to a story.
+- Use the approved title `Remove Apollo for iOS` for `PDIAP-15838`.
+- When a documentation or root cause update directly supports a story, report it under that story instead of as a separate standup item.
+- In standups, format Jira references as `ID - Title` or `ID Title`, not `ID, Title`.
+- Jeff clarified that `PDIAP-15838` is the next story to work on and `PDIAP-15836` comes later.
+- Clarification: the feature-flag and rollout planning feedback applies to the broader UIKit-removal spike, not only to the dismissal sequencing changes; the sequencing work should fit into that same consumer rollout plan.
+- Current priority is to create a process-oriented document that explains the rollout plan Jeff described for the UIKit-removal spike, with the goal of sharing it for feedback.
+- Clarification: the document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt. The dismissal sequencing work is only one part of that broader migration plan.
+- The document should clearly explain that the rollout uses a dual-path pattern to switch between the `UIHostingController` path and the SwiftUI-only path during migration.
+- Jeff said the remaining spike deliverable is a clear consumer-facing rollout plan covering risky entry points like FTTransfer, consumer communication, XQ1 validation, a 30-day production period with no reported bugs, and a follow-up release to remove the feature flag and old code; he suggested sending that process-oriented document to Quy for feedback when ready.
+- Reviewed the first Copilot-generated draft of the SwiftUI-only migration rollout document from screenshots.
+- The draft already includes the main requested elements: dual-path rollout, `xflow-master-swiftui-enabled`, XQ1 validation, FTTransfer coordination, rollback handling, 30-day stabilization window, and final cleanup release.
+- The next revision should shift the tone slightly away from formal incident/operations language and make the consumer rollout sequence, decision owners, and entry-point-based enablement flow feel more like an engineering migration plan than a generic release runbook.
+- Correction for the next rollout-document revision: the rollout should not be framed as entry-point-based enablement; it uses a global feature flag and should emphasize broad XQ1 validation before any production release.
+- Correction for audience framing: the document is consumer-facing and should avoid stakeholder-oriented wording.
+- Further correction for the rollout document: it should not say production rollout begins with lower-risk consumers. The production flag is global and applies across flows together once the team decides to enable it.
+- The document should present broad XQ1 validation as the required gate before any production rollout, not as one stage within a consumer-by-consumer enablement sequence.
+- The migration framing should also call out that the rollout incorporates architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced SwiftUI anti-patterns.
+- Reviewed the next screenshot-based revision of the rollout document. It now correctly reflects a global production flag model, broad XQ1 validation before production enablement, consumer-facing wording, and architectural improvements learned from prior SwiftUI iterations.
+- Remaining polish areas in the latest draft: reduce lingering operational/runbook wording (`SLA`, `operational response`, `release manager delegate`, heavy monitoring-threshold language) and make the high-risk-consumer section sound more like coordination/validation within a global rollout than a separate rollout phase.
+- The rollout document should be more concise and should not use an overly complex multi-phase model.
+- Reviewed the newer simplified screenshot-based revision. The rollout structure is now much closer to the intended model: a simple gated flow of broad XQ1 validation, global production enablement, then a 30-day stabilization window before cleanup.
+- Remaining issues in the latest draft are mostly wording and trimming: it still includes extra runbook-style sections such as `Production Monitoring and Guardrails`, `Coordination Model for High-Risk Consumers`, `Rollback and Operational Response`, and `Decision Gates Summary`, which may be more detail than needed for the concise consumer-facing version.
+- Reviewed another screenshot-based revision after the simplification prompt. The top-level rollout flow is still good and concise, but the lower half of the document still retains most of the extra runbook-style sections, so the latest revision did not yet materially reduce those details.
+- Clarified the AO/Discourse config explanation for the authenticated `TeenIdentityCheck` DOB issue: the requirement is not to rename the root from `birthDate` to `validations`; instead, the `validation-rules` payload should contain a JSON object whose root key is `validations`, and if the age gate is required it should include `eighteenOrAbove: true`, matching the `CheckIdentity` structure rather than relying on a separate transactional rule boolean like `"eighteen-or-above": true`.
+- Further clarification for the same AO/Discourse thread: the reply should explicitly state that the earlier comment was referring to the literal `"eighteen-or-above": true` attribute inside the transactional-rules array, while still distinguishing that from the separate `validation-rules` structure.
+- Additional clarification for the authenticated `TeenIdentityCheck` config issue: the `validation-rules` attribute is the structure that drives the check. `CheckIdentity` was already configured correctly. The `TeenIdentityCheck` problem had two parts: the wrong root key (`birthDate` instead of the expected `validations`) and the missing `eighteenOrAbove` attribute inside `validation-rules`.
+- For the Rashmi reply, the intended closing clarification is that the previous `CheckIdentity` `validation-rules` shape is the expected model for `TeenIdentityCheck`, and a JSON snippet can be shared to show the expected structure directly.

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

@@ -0,0 +1,24 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-13
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-13
+
+## Standup Context
+
+- Corrected the approved title for `PDIAP-14859` to `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
+- Manual clarification for Monday standup: reference Friday work rather than the prior calendar day.
+- Friday update for `PDIAP-14859`: created a draft rollout document for removing UIKit in favor of a SwiftUI-only path, including feature-flag planning.
+- Today update: publish the rollout document for `PDIAP-14859` and continue with `PDIAP-15838` `Remove Apollo for iOS`.
+- Standups should include story titles, not only Jira IDs, when the title is available.
+
+## Mattermost Sync
+
+- `PDIAP-14859`: sent Jeff the rollout draft for review after updating it around the global feature flag, broad `XQ1` validation, and the consumer-facing rollout flow.
+- Jeff replied that he will review the `PDIAP-14859` document this morning.
+- For `PDIAP-15765`, Jeff approved sending the config clarification that `CheckIdentity` was already correct and that `TeenIdentityCheck` needed the `validations` root key plus `eighteenOrAbove` inside `validation-rules`; the message was sent with an expected validation snippet.

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

@@ -0,0 +1,78 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-14
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-14
+
+## Previous Workday Refresh
+
+- `PDIAP-14859` rollout draft remained in revision on April 13 rather than being finalized; the work was limited to the specific draft changes requested in review, not a broad rewrite.
+- The rollout document should rename the proposed flag from `xflow-master-swiftui-enabled` to `xflow-swiftui-enabled`.
+- The first rollout phase should explicitly mention contacting consumers ahead of time and asking them to validate their flows in `XQ1`.
+- The rollout document should remove overly technical wording and avoid implying there are no consumer-side changes without qualification.
+- Current spike clarification: `FTTransfer` changes are no longer considered strictly required after applying the SwiftUI dismissal behavior correctly, but risky entry points still need explicit rollout coverage.
+
+## AO / Discourse Findings
+
+- The AO reply about `TeenIdentityCheck` was approved and sent after clarifying that `CheckIdentity` was already correct and that the `TeenIdentityCheck` issue was the missing `validations` root and missing `eighteenOrAbove` inside `validation-rules`.
+- Later validation showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
+- A `HybridBrokerage` scenario reproduces on both iOS and Android.
+- A Youth flow (`Open an account` -> `Save & Invest for a child` -> `Fidelity Youth Account`) fails on iOS while working on Android.
+- Current evidence suggests Android is more flexible when decoding rule variations, while iOS is stricter about the expected `validation-rules` structure in the Youth-flow scenario.
+- The iOS-only Youth-flow discrepancy is the scenario currently aligned with the story-level client fix.
+- The cross-platform `HybridBrokerage` scenario should stay scoped separately until it is clear whether it is a service/config issue or a distinct bug.
+
+## Current Direction
+
+- `PDIAP-14859` remains focused on incorporating rollout-document feedback and publishing a consumer-facing plan.
+- `PDIAP-15838` remains the next implementation story after the rollout-document work is in a good state.
+
+## New Investigation Note
+
+- For the Murali group discussion, there appears to be usage of `ApexBridgingAddressComponent` through references in `XFlowPageApexItem`.
+- If that usage is active, the dependency comes from `ApexKitV3`, which was expected to retain support after the earlier ApexKit removal.
+- Current guidance from that discussion is to migrate toward `FDS` or `ApexKitSwiftUI`, but the exact replacement for `ApexBridgingAddressComponent` is still unclear and needs investigation and validation.
+- Narrower wording for the current status: there are visible references at a glance, but it is not yet confirmed whether they are active or dead code; the next step is to validate with a run.
+
+## Fresh Mattermost Sync
+
+- Confirmed with breakpoints that `ApexBridgedAddressComponent` is not used when loading an address component; the observed path goes through `ApexGoogleAddressViewModel`.
+- A follow-up review raised that the old component may still be used to load rules and appears in `XFloaValueChanger`, so it should not be treated as dead code without deeper verification.
+- Current direction for that investigation is to be exhaustive and avoid assumptions before describing the old bridged path as unused.
+- Clarification from the same thread: the remaining `ApexKitV3` reference does not cause build issues because `ApexKitSwiftUI` still depends on `ApexKitV3`.
+- `PDIAP-14859` rollout-document follow-up: Jeff asked whether the FTTransfer section needed updating, and David confirmed the document had already been revised to clarify that root cause.
+- Latest clarification in the Murali thread: `ApexBridgedAddressComponent` belonged to the old UIKit rule-handling flow. In the current implementation, rules are described as being handled through the SwiftUI path, parsed from the payload and applied through the `XFlowViewApadater` / `ViewModelAdapter` layer using `ApexGoogleAddressViewModel`.
+- Clarification for the retro/ownership discussion: the earlier FTTransfer-side explanation was not fully wrong, but it was incomplete. The SwiftUI state behavior was a real symptom/effect on the consumer side; the deeper root cause was the dismissal flow handling that had not been covered correctly. The main gap was concluding consumer ownership before isolating that underlying dismissal root cause.
+- Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation.
+- Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed.
+- Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently.
+- Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims.
+
+## ApexKitV3 / Swift 6 Follow-up
+
+- Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced.
+- Breakpoint and import-removal follow-up showed that removing `import ApexKitV3` across XFlow causes `23` compilation issues.
+- Replacing those imports with `ApexKitSwiftUI` still leaves `13` build errors.
+- Current high-confidence understanding is that XFlow still has meaningful dependency impact from `ApexKitV3`, and this is not just a trivial dead-code cleanup.
+- Swift 6 support is not yet implemented; related work is planned under a `26Q3` backlog epic.
+- New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by `4:30 PM`.
+- The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing.
+- Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments.
+- Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder.
+- Additional analysis context for the ApexKitV3 investigation: the Swift version change was reverted back to Swift 5, and the Pods were updated to the latest versions including `ApexKitSwiftUI 1.27.14`. The current question is whether the ApexKitV3-removal impact remains the same under that updated dependency baseline.
+- Document-review guidance for the ApexKitV3 impact write-up: it should not read as if code changes have already been made, should stay understandable for a non-technical reader, and should avoid overcommitting on production impact where SwiftUI-vs-legacy-path usage is still being verified.
+- Additional document-review guidance: if the write-up already recommends consumer testing, it should not hedge with wording like `if the change extends beyond small cleanup`. The risk section should stay internally consistent and reflect the current conclusion directly.
+
+## Late-Day Outcome
+
+- The ApexKitV3 impact write-up was revised with the requested wording changes, including using `Impacted Flows` and making consumer validation a direct recommendation rather than a conditional one.
+- Jeff approved the ApexKitV3 write-up after those edits, and David published it and sent the Confluence link to Quy with a concise summary of the effort and risk.
+- End-of-day direction for `PDIAP-14859`: the rollout document was approved as good enough, but it was not published on April 14. The next step is to publish it on the next workday, then comment the spike with `Spike Results:` links and the follow-up story link.
+- The UIKit-removal follow-up story should be linked as a blocker for the reopened UIKit-removal work after the spike is closed out.
+- End-of-day direction for `PDIAP-15765`: move the story back to In Progress on the next workday and focus on the authenticated iOS-only Youth `TeenIdentityCheck` gap so iOS handles the service response the same way as Android.
+- The separate `HybridBrokerage` scenario remains distinct from the iOS-only Youth-flow issue and may need its own follow-up ticket if the service-side problem still stands after the client-side story is resumed.

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

@@ -0,0 +1,58 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-15
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-15
+
+## Toggle Name Follow-up
+
+- Additional historical context from Teams suggests the existing LaunchDarkly flag name `xflow-master-swiftui-enabled` was already shared in the Fid4 LaunchDarkly project as the SwiftUI toggle.
+- User-provided historical references: Neetu Gupta asked for the SwiftUI toggle name and Jason Mandozzi replied with `xflow-master-swiftui-enabled` plus the LaunchDarkly link; in January 2025, Thomas Payne also asked whether the team was ready to activate that same toggle.
+- Current interpretation: the team may be able to keep using the same flag name even though the rollout intent is now narrower. In the current rollout, toggling would switch only the final `UIHostingController` wrapping on or off, while SwiftUI remains in use either way.
+- This historical evidence supports keeping the existing flag name if renaming would add friction, but the semantic mismatch should still be acknowledged when describing the rollout.
+- Fresh clarification from Jeff on April 15: do not reuse the old SwiftUI LaunchDarkly flag for this rollout.
+- New required flag name for the rollout document: `xflow-swiftui-container-enabled`.
+- The rollout document should explicitly note that this new flag is `to be added in the future as part of implementation`.
+- Jeff plans to ask later how to get the new flag added when implementation time comes.
+
+## PDIAP-15765 Follow-up Drafting Context
+
+- David plans to confirm that `PDIAP-15765` was moved from investigation back to In Progress.
+- Current working interpretation: the `HybridBrokerageAccountOpening` / `JointIdentityCheck` behavior appears to be a different issue from the iOS-only Youth `TeenIdentityCheck` gap.
+- This separate `HybridBrokerage` path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect.
+- Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly.
+- One reason for suspicion is that the validation appears to use `min: 10` and `max: 10`, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story.
+- Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the `birthDate` key.
+- Once the payload was changed from `birthDate` to `validations`, the originally reported iOS issue no longer reproduced and the validation loaded correctly.
+- Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally.
+- Jeff asked that the message start with: `One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):`
+- Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well.
+- Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from `birthDate` to `validations`.
+- Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only.
+
+## Jeff Context On AO Fallback Handling
+
+- Jeff confirmed the minimal iOS fallback change is the right fix for this issue.
+- He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows.
+- Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor.
+- That history explains why `validations` aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling.
+- Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS.
+
+## PR Drafting Context
+
+- The `xflow-for-ios` PR template currently uses sections `## What`, `## Why`, `## How`, `### Changes details`, and `## Missed anything?` with a final checklist.
+- The April 15 iOS fix PR is a one-line change in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`, adding `birthDate` as a fallback after `validations`.
+- This PR should be described as a small compatibility bug fix for older AO-style payloads rather than as a broader Android-parity refactor.
+- David opened the PR for this minimal iOS compatibility fix.
+
+## Standup And Flow Naming Notes
+
+- David prefers standups to use one top-level Jira bullet with indented sub-bullets when a single ticket has multiple updates.
+- In recent standup wording, `Youth flow` should be treated as shorthand for the real flow ID `HybridYouthAccountOpening`.
+- The relevant page in that flow is `TeenIdentityCheck`.
+- The separate authenticated flow under discussion remains `HybridBrokerageAccountOpening`, with the relevant page `JointIdentityCheck`.

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

@@ -0,0 +1,40 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-16
+updated: 2026-04-16
+tags:
+  - daily
+  - fidelity
+---
+# 2026-04-16
+
+## Mattermost
+
+- Jeff clarified that `PDIAP-15765` should not move to Done until the PR is merged.
+- Santosh approved the PR, but one code-owner approval is still required before merge.
+- Jeff asked for one more AO working-group Teams reply that:
+  - summarizes that the original iOS issue was reproduced and addressed with the iOS-side change
+  - points the group to the Jira comment, Discourse comment, and PR
+  - explains that the initially found `HybridBrokerageAccountOpening` / `JointIdentityCheck` problem is separate
+  - notes which service-side changes were already made and which still appear to be needed
+- David clarified that the confirmed service-side change was limited to the Youth-flow `TeenIdentityCheck` path. For external communication, avoid overstating the scope or calling out Rashmi by name unless that attribution is specifically needed.
+- David clarified that the iOS change should be described as a compatibility improvement to reduce similar future issues with the older `birthDate` format. It should not be described in a way that implies it also applies to the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
+- Jeff said the AO working-group draft was still confusing and wanted to edit it himself to make it very clear and avoid follow-up questions.
+- David clarified that the `HybridYouthAccountOpening` / `TeenIdentityCheck` issue was iOS-only; it should not be described as affecting both iOS and Android.
+- David clarified that the service-side change and the iOS-side fallback address the same Youth / `TeenIdentityCheck` issue, not two separate Youth issues. The service change was the immediate resolution, while the iOS PR is a compatibility safeguard if that older `birthDate` format appears again.
+- David has personally seen `birthDate` used on two pages so far, but broader reuse in other flows is still unconfirmed and should be described carefully.
+- For Jeff's framing question, the current understanding is two affected flow scenarios, not three: the iOS-only Youth / `TeenIdentityCheck` issue, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue.
+- Jeff confirmed on April 15 that the minimal iOS `birthDate` fallback is the right change for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
+- Jeff clarified the historical reason for the fallback behavior: older AO services often still use older payload conventions, while the SwiftUI refactor was validated more heavily against newer Slate-based services using `validations`.
+- Jeff said the easiest fix is usually this kind of iOS-side fallback when the consumer is AO, the issue is iOS-only, and the service payload shape differs from what the SDK expects.
+- Jeff approved the Jira and Discourse comments with one wording change: say `I checked the original iOS issue again` instead of `I re-checked`.
+- Jeff approved sending a final AO working-group summary, but wanted it to be much clearer about what was fixed on iOS, what Rashmi changed on the service side, and what separate service-side issue still remains in `HybridBrokerageAccountOpening` / `JointIdentityCheck`.
+- David later checked Cogstore and confirmed that the relevant flow-definition change tied to Rashmi's service update is already in QA as version `0.0.142`, while Production is still on `0.0.133`, so that flow change is not live in production yet.
+- Jeff concluded there is no point relying on a separate service release for the Youth issue if it would also require its own rollout; the iOS PR should be treated as the primary fix path, while the QA-side flow-definition change explains why the issue no longer reproduces in XQ1.
+- Durable tooling/system note: in Fidelity flow work, Cogstore is the platform used to modify and publish many individual flow configurations, compare versions per flow, and check who/when a specific flow version was published to QA or Production. Slate was the newer consumer-side configuration tooling during the SwiftUI refactor, but Jeff believes it is now decommissioned.
+- Additional tooling note: flow IDs are not guaranteed to exist in both Cogstore and Slate, so the active configuration source for a given flow should be verified instead of assumed.
+- David confirmed that the `HybridBrokerageAccountOpening` / `JointIdentityCheck` flow-definition content is the same in QA and Production even though the versions differ (`0.0.267` vs `0.0.263`), so that separate rule-content issue should also be reproducible in Production.
+- Jeff asked Rashmi to revert the Youth-flow service change so the iOS-side PR can remain the single fix path for that issue.
+- David confirmed Rashmi reverted the QA change by publishing the earlier flow version, and local Fid4 validation with the iOS PR showed the `birthDate`-based validation now works as expected.
+- Jeff's preferred external summary is now very explicit: we went back and fixed their original iOS-only issue on the iOS side, while the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is a new service-side problem that still needs its own follow-up.

vault/06-daily/index.md

@@ -0,0 +1,34 @@
+---
+type: daily-index
+project: fidelity
+updated: 2026-04-16
+tags:
+  - daily
+  - map
+---
+# Logs Index
+
+Daily logs capture evolving evidence and same-day work context.
+
+Promote durable facts into `vault/01-current/`, `vault/02-work-items/`, or `vault/03-context/` when they should survive beyond the day.
+
+---
+
+## Logs
+
+- [2026-04-08](2026-04-08.md)
+- [2026-04-09](2026-04-09.md)
+- [2026-04-10](2026-04-10.md)
+- [2026-04-13](2026-04-13.md)
+- [2026-04-14](2026-04-14.md)
+- [2026-04-15](2026-04-15.md)
+- [2026-04-16](2026-04-16.md)
+
+---
+
+## Related Memory
+
+- [Current Work](../01-current/current-work.md)
+- [Work Item State](../01-current/work-items.md)
+- [Work Item Index](../02-work-items/index.md)
+- [Context Index](../03-context/index.md)