fidelity-ai-workspace/ai/state/current.md

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
• 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

---

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

---

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
• 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