37 lines
1.2 KiB
Markdown
37 lines
1.2 KiB
Markdown
# Consumer Integration And Release
|
|
|
|
## Goal
|
|
|
|
Capture the durable release and validation path between XFlow changes and real consumer behavior.
|
|
|
|
---
|
|
|
|
## Stable Patterns
|
|
|
|
- End-to-end validation often requires more than an SDK change.
|
|
- Historical Slack evidence shows repeated coupling across:
|
|
- XFlowSDK
|
|
- XFlowViewMaker
|
|
- FTFrameworks modules
|
|
- Fid4 / flagship
|
|
- Version pins, publishing delays, and consumer build issues can block validation even when the original code change is ready.
|
|
|
|
---
|
|
|
|
## Investigation Rules
|
|
|
|
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
|
|
- Separate these failure modes:
|
|
- SDK bug
|
|
- adapter/version propagation issue
|
|
- FT module publish/test issue
|
|
- consumer app setup or pipeline issue
|
|
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
|
|
|
|
---
|
|
|
|
## Historical Signals From Slack
|
|
|
|
- Version bump work repeatedly involved XFlowViewMaker, FTAccountOpen, and FTTransfer.
|
|
- Some rollout problems involved Jenkins, Apex/ApexKit, preview macro compatibility, or secret/token access rather than the product behavior under investigation.
|