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

This commit is contained in:
2026-04-17 10:06:45 -06:00
parent 83d91ed19a
commit 01f0a6bd33
4 changed files with 23 additions and 3 deletions

View File

@@ -35,6 +35,10 @@ When the format fits, prefer:
- 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.
- 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.
- 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.

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
- 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.
- 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.
---