71 lines
5.4 KiB
Markdown
71 lines
5.4 KiB
Markdown
# Current Work
|
|
|
|
## Focus
|
|
|
|
- Keep Fidelity context current from daily work performed on another machine
|
|
- Track REST migration findings
|
|
- Debug Discourse and AO issues
|
|
- Prepare better updates for the current manager or stakeholder through Mattermost
|
|
- Follow up on active tickets through `ai/work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
|
|
- Finalize `PDIAP-14859` with a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately
|
|
- Prioritize `PDIAP-15838` next; `PDIAP-15836` comes later
|
|
- 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
|
|
- Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance
|
|
- The process-oriented rollout document for the UIKit-removal spike has been drafted and sent to Jeff for review
|
|
- The rollout 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 rollout document should make clear that the migration plan uses a dual-path pattern to switch between the `UIHostingController` path and the SwiftUI-only path during rollout
|
|
- The rollout should be described as a global feature-flag rollout, not entry-point-based enablement
|
|
- The document should emphasize broad validation in XQ1 before any production release
|
|
- The document is directed to consumers and should not use stakeholder-oriented wording
|
|
- The rollout document should not say rollout phases begin with low-risk consumers; the global flag applies to all flows together once production rollout begins
|
|
- Broad XQ1 validation is a required gate before any production enablement
|
|
- The document should explicitly mention applying architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced anti-patterns
|
|
- The rollout document should stay concise and avoid an overly complex phase model
|
|
- The rollout document needs one more revision before publishing, including the `xflow-swiftui-enabled` flag name, clearer first-phase consumer contact and `XQ1` validation language, and removal of overly technical wording
|
|
- Re-check the authenticated AO validation issue with scenario-specific evidence: the Youth `TeenIdentityCheck` path currently points to an iOS-only decoding gap, while a separate `HybridBrokerage` case reproduces on both platforms
|
|
|
|
---
|
|
|
|
## Active Concerns
|
|
|
|
- Authenticated vs non-authenticated behavior
|
|
- Reproducibility across entry points
|
|
- Backend-driven inconsistencies in XFlow
|
|
- Distinguishing external issues from true regressions
|
|
- 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
|
|
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
|
|
- Keeping the consumer-facing rollout document aligned with the actual global-flag rollout model and broad XQ1 validation requirement
|
|
- Incorporating Jeff's pending review feedback on the `PDIAP-14859` rollout draft once it arrives
|
|
- Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope
|
|
- Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance
|
|
- When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers
|
|
|
|
---
|
|
|
|
## Communication Priorities
|
|
|
|
- Standups should reflect the latest technical state, not generic progress
|
|
- Standups should prefer updates directly tied to active work items over one-off memory refreshes or side questions
|
|
- Standups should include story titles whenever a reported update maps to a Jira item
|
|
- Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
|
|
- When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
|
|
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work
|
|
- If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
|
|
- Standups should omit items not tied to a story unless they are real blockers
|
|
- Manager updates should be short, precise, and natural in English
|
|
- Mattermost messages should make scope and next action explicit
|
|
- When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault
|
|
- Standups should be written as David's external progress report and should not mention Jeff by name
|
|
- Standups should never mention Mattermost because it is internal-only communication
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
- REST remains behind a feature flag
|
|
- Validate against main before calling something a regression
|
|
- This workspace is the context source for communication, not the source of product code changes
|