david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Update rollout document to clarify global feature-flag rollout and emphasize consumer-facing language

Browse Source
This commit is contained in:
David Delagneau
2026-04-13 07:10:19 -06:00
parent a8ab5a784e
commit e65471f3c2
2 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
ai/logs/2026-04-10.md
View File

@@ -16,3 +16,19 @@
- 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.