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

feat: Clarify communication rules and document dependency conflict resolution process for improved stakeholder interactions

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 10:06:45 -06:00
parent 83d91ed19a
commit 01f0a6bd33
4 changed files with 23 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
vault/02-work-items/pdiap-15765.md
View File

@@ -70,9 +70,10 @@ tags:
## Next Step ## Next Step
- Get the remaining FTFrameworks code-owner approval on the XFlowViewMaker follow-up PR. - The XFlowViewMaker approval and publish step are now complete.
- After merge, let `publish-XFlowViewMaker` release the updated adapter version. - Resolve the new Fid4 dependency conflict caused by downstream `FTAccountOpen` / `FTTransfer` constraints that do not yet accept the published XFlowViewMaker version.
- Update the Fid4 Podfile in `ap010981-ios-flagship-app`, run `tuist generate -n` and `pod install --repo-update`, then open the consumer PR. - 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. - 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. - 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. - Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.

4
vault/03-context/process/communication.md
View File

@@ -35,6 +35,10 @@ When the format fits, prefer:
- Jeff is the main bridge into the Fidelity-side Teams context. - Jeff is the main bridge into the Fidelity-side Teams context.
- David works on the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side. - David works on the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
- Do not write updates as if David is directly embedded in the Fidelity Teams collaboration loop unless the context explicitly says so. - Do not write updates as if David is directly embedded in the Fidelity Teams collaboration loop unless the context explicitly says so.
- When drafting a message David will send to a Fidelity-side contact, do not phrase it as if Jeff is the sender or as if the recipient already knows David through Jeff unless the user explicitly says that framing is desired.
- Avoid wording like `Jeff mentioned...` in David-to-contact drafts when that would incorrectly imply a shared reporting chain or prior relationship.
- Keep Jeff's internal process requests separate from David's external message drafts unless the user explicitly wants them surfaced to the recipient.
- Do not include lines like `I want to document the steps for future cases` in David-to-contact drafts when that motivation is only internal workspace/process context.
- For standups, report the previous workday context, not blindly the prior calendar day. - For standups, report the previous workday context, not blindly the prior calendar day.
- On Mondays, use Friday's work context unless a later prior day has Mattermost activity. - On Mondays, use Friday's work context unless a later prior day has Mattermost activity.
- If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity. - If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity.

2
vault/03-context/workstreams/consumer-integration.md
View File

@@ -89,6 +89,8 @@ Capture the durable release and validation path between XFlow changes and real c
- fixed version references in the Podfile when present - fixed version references in the Podfile when present
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files - archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication. - Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
- A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
- Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
--- ---

13
vault/06-daily/2026-04-17.md
View File

@@ -45,3 +45,16 @@ tags:
- David also clarified that Teams and Mattermost represent different social contexts; outside of Jeff, people seen in Teams are generally not the same people David interacts with through Mattermost. - David also clarified that Teams and Mattermost represent different social contexts; outside of Jeff, people seen in Teams are generally not the same people David interacts with through Mattermost.
- David corrected current people status: Norman Arauz and Derian Cordoba no longer work with the current All-Win Software / Mattermost / Slack group, and Erik Reynolds previously worked for Fidelity but no longer does. - David corrected current people status: Norman Arauz and Derian Cordoba no longer work with the current All-Win Software / Mattermost / Slack group, and Erik Reynolds previously worked for Fidelity but no longer does.
- David clarified an important working-context rule: Jeff is the only person who regularly communicates with Fidelity-side Teams stakeholders, while David works from the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side. - David clarified an important working-context rule: Jeff is the only person who regularly communicates with Fidelity-side Teams stakeholders, while David works from the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
## Mattermost Refresh - Dependency Conflict
- After XFlowViewMaker was published, David hit a dependency conflict while trying to update Fid4.
- The conflict appears to come from `FTAccountOpen` and `FTTransfer` depending on XFlowViewMaker with constraints that do not yet allow the new version.
- David noted that Tauf has handled similar cases before by updating the constraint directly in the podspec repo.
- Jeff asked David to message Tauf, ask him to remind David what he does in this case, and then document the process for future reference.
## Communication Correction
- David corrected a drafting mistake: when proposing a message that David will send directly to a Fidelity-side contact, the wording must not imply Jeff is the sender or that the recipient already knows David through Jeff.
- For this kind of direct outreach, avoid phrases like `Jeff mentioned...` unless David explicitly wants that framing.
- David made a second correction: if Jeff asked for internal documentation or future-process capture, that should stay internal and should not be surfaced in David's external message unless explicitly requested.