feat: Clarify communication rules and document dependency conflict resolution process for improved stakeholder interactions
This commit is contained in:
@@ -70,9 +70,10 @@ tags:
|
||||
|
||||
## Next Step
|
||||
|
||||
- Get the remaining FTFrameworks code-owner approval on the XFlowViewMaker follow-up PR.
|
||||
- After merge, let `publish-XFlowViewMaker` release the updated adapter version.
|
||||
- Update the Fid4 Podfile in `ap010981-ios-flagship-app`, run `tuist generate -n` and `pod install --repo-update`, then open the consumer PR.
|
||||
- The XFlowViewMaker approval and publish step are now complete.
|
||||
- Resolve the new Fid4 dependency conflict caused by downstream `FTAccountOpen` / `FTTransfer` constraints that do not yet accept the published XFlowViewMaker version.
|
||||
- Ask Tauf to remind David of the exact podspec-constraint fix path used in similar cases, then document that process for future reuse.
|
||||
- After the dependency constraint issue is resolved, update the Fid4 Podfile in `ap010981-ios-flagship-app`, run `tuist generate -n` and `pod install --repo-update`, then open the consumer PR.
|
||||
- After the Fid4 PR merges, treat the app release as the final downstream step before broader user visibility.
|
||||
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
|
||||
- Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.
|
||||
|
||||
Reference in New Issue
Block a user