david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
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.