david.delagneau
2a234701c5
- Updated work items with new statuses, notes, and dependencies: - `PDIAP-15838` moved to Done, draft PR remains unmerged. - `PDIAP-15836` status updated to backlog-ready, sequenced after `PDIAP-15838`. - `PDIAP-12284` reopened for UIKit removal, dependency for `PDIAP-15836`. - Added new backlog items: `PDIAP-11961`, `PDIAP-11962`, `PDIAP-11562`, `PDIAP-12226`, `PDIAP-12227`, `PDIAP-12228`. - Completed `PDIAP-16167`, documented findings in Confluence. - Created daily log for 2026-05-05 summarizing work item updates and backlog triage. - Added diagnostic script for workspace analysis.
1.7 KiB
1.7 KiB
type, project, status, ticket, title, systems, workstreams, people, related, updated, tags
| type | project | status | ticket | title | systems | workstreams | people | related | updated | tags | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| work-item | fidelity | backlog-review | PDIAP-11562 | Investigate if XFlow is being built as debug |
|
|
|
2026-05-05 |
|
PDIAP-11562 - Investigate if XFlow is being built as debug
Status
- Backlog item under review for possible next work.
Current Understanding
- This is related to how the XFlow podspec is configured and how Fid4 consumes it.
- It is not currently understood as Sparta-team work.
- The concern is whether a debug build configuration or debug-like flag is being used in a dependency-integration context where it should not be.
- Next investigation should identify why/how the flag or build configuration is used and whether there is a safer integration approach.
Historical Slack Context
- September 2025 backlog context lists the full title as
Spike: Research/investigate if Xflow is being built as debug in Fid4 and if that’s a concern or intentional. - November 2025 Slack context says the relevant check is the
XFlowSDK_Debugvariable in the podspec, not a Podfile setting. - David confirmed in November 2025 that the
XFlowSDK_Debugvariable check was still present. - Working interpretation from that thread: Jenkins likely does not set the variable when building the static framework; the
if/elsepath may be intended so local development consumes XFlow as a normal library while Jenkins builds/consumes it as an xcframework. - Treat that as a historical hypothesis to verify in current code/build settings, not as a confirmed current production behavior.