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

chore: update work items and daily logs with May 12 entries, including REST backend deployment and validation meeting details

Browse Source
This commit is contained in:
David Delagneau
2026-05-12 07:24:04 -06:00
parent b5c3ada57d
commit 767f97f3bb
6 changed files with 33 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
project-knowledge/02-work-items/IA improvements.md
View File

@@ -14,4 +14,9 @@
- Investigation: Differences of skills vs instructions from vscode copilot
- Investigation: Differences from agents vs skills using agent, what is more general? correct relationship and use
- Charles Proxy integration
- LaunchDarkly integration
- LaunchDarkly integration
- Teams integration
- Photo uploader
- Start as a service
- Auto categorize by context
- Multi photos session, copy multiples images in clipboard

4
project-knowledge/02-work-items/pdiap-12284.md
View File

@@ -8,7 +8,7 @@ systems: [xflowsdk, xflowviewmaker]
workstreams: [xflow-swiftui-migration, consumer-integration]
people: [jeff-dewitte]
related: [pdiap-15836, pdiap-15838]
updated: 2026-05-11
updated: 2026-05-12
tags:
- work-item
- fidelity
@@ -25,6 +25,7 @@ tags:
- Jeff directed David to do this UIKit-removal work and `PDIAP-15836` dismissal/lifecycle work in the same branch because both are disruptive enough to require consumer testing.
- Current implementation direction is to avoid Fid4-owned per-flow host-mode mapping and evaluate XFlowViewMaker-owned global host-mode resolution.
- David continued the implementation/validation loop on May 11; current simulator log review is promising for the SwiftUI-host dismissal sequencing in the tested run.
- Jeff confirmed on May 11 that the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) should be implemented as part of this branch's work.
---
@@ -36,6 +37,7 @@ tags:
- XFlowSDK should not be coupled directly to LaunchDarkly, Flagship, or app-specific feature-flag clients; it should receive an already-resolved host-mode decision.
- If `hostMode` must be passed through `FlowConfig` or a similar object, keep it as adapter/internal plumbing rather than a new consumer-facing per-flow responsibility.
- The latest tested run reported the expected dismissal order for the SwiftUI-host path, but the branch still needs review of the shared host-mode routing and any required broader validation before story closure.
- Current code-review concerns to resolve before accepting the implementation: avoid unnecessary duplicate host-mode enums across XFlowViewMaker and XFlowSDK if one shared type can express the public contract safely; avoid naming that over-commits to `Fallback` if the toggle should be neutral and rollout-oriented; prefer a Fidelity-aligned boolean flag name using the `iOS-` prefix pattern when applicable; and review the new `AnyView` usage in `buildFlow` against safer SwiftUI alternatives.
---

5
project-knowledge/02-work-items/pdiap-15838.md
View File

@@ -8,7 +8,7 @@ systems: [xflowsdk]
workstreams: [rest-migration]
people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
related: [launchdarkly, github-copilot]
updated: 2026-05-11
updated: 2026-05-12
tags:
- work-item
- fidelity
@@ -89,6 +89,9 @@ tags:
- Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days.
- Branch maintenance is now part of the work: keep the GraphQL/Apollo-removal branch up to date with `main` until the REST backend/toggle validation window allows merge. If future `main` merges create conflicts that look non-trivial, raise it so a 1-2 point maintenance story can be created.
- May 11 preparation for another REST-layer validation meeting: Fid4 `4.32` was checked out in a separate folder, aligned to the published/internal build `Podfile.lock` from iOSInstaller, and built successfully. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated XFlow entry point to use for a quick readiness test.
- Jeff confirmed May 11 that the REST back end has now been deployed, and a meeting is scheduled for May 12 with the team lead and Bruce to toggle the flag and test both REST and non-REST states.
- REST detection for the meeting: Charles Proxy to verify `/xflow/api` endpoints and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
- Production testing: Raj is trying to get approval to test in production. A production test account will be needed; currently only Bruce is known to have one. David found a way to force the production environment from the simulator if needed.
---