- 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.
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 CheckIdentityvalidation-rules shape is the expected model for TeenIdentityCheck, and a JSON snippet can be shared to show the expected structure directly.
david.delagneau
b82194bc55