feat: Update standup guidelines for clarity and audience accessibility

.opencode/commands/standup.md

@@ -49,6 +49,8 @@ Before drafting:
 - exclude items that are not directly tied to a story unless they are true blockers
 - when one Jira item has multiple concrete updates, group them under one top-level `JIRA-ID - Title` bullet with indented markdown sub-bullets instead of repeating the same Jira line
 - use `vault/03-context/workstreams/flow-page-references.md` to preserve real flow/page identifiers when shorthand appears in logs or messages
+- for standups that will also be sent to Teams, prefer plain language over internal implementation jargon; avoid unexplained terms like `fallback`
+- if work is in release-process waiting state, show the parallel story work explicitly instead of implying idle waiting
 
 Return a standup that is:
 

prompts/standup.md

@@ -23,6 +23,8 @@ Requirements:
 - Prefer evidence-backed statements over assumptions
 - Write in natural US English that can be forwarded externally without rewriting
 - Write the standup as David's external progress report
+- For standups that will also be sent to Teams, prefer plain outcome language over internal implementation jargon; avoid terms like `fallback` unless they are explained well enough for a broader audience
+- If a release or propagation step is waiting on approvals or pipeline work, make the parallel work explicit instead of sounding like the day is blocked on waiting alone
 - Do not mention Jeff by name
 - Do not mention Mattermost because it is internal-only communication
 - Use bullet points for each item

vault/01-current/current-work.md

@@ -18,7 +18,7 @@ tags:
 - Follow up on active tickets through `vault/02-work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
 - Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike
 - After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later
-- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by getting the remaining XFlowViewMaker code-owner approval, then run the pipeline and update Fid4 before returning to `PDIAP-15838`
+- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by getting the remaining XFlowViewMaker code-owner approval, then run the pipeline and update Fid4 while continuing `PDIAP-15838` in parallel where possible
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
 - Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
 - Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
@@ -68,6 +68,8 @@ tags:
 - Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
 - When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
 - When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
+- For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
+- When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
 - Standups should omit side questions or manager-only context refreshes unless they materially changed story work
 - If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
 - Standups should omit items not tied to a story unless they are real blockers

vault/03-context/process/communication.md

@@ -2,7 +2,7 @@
 type: process
 project: fidelity
 status: active
-updated: 2026-04-16
+updated: 2026-04-17
 tags:
   - process
   - fidelity
@@ -35,6 +35,8 @@ When the format fits, prefer:
 - If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity.
 - For standups, when a Jira item has multiple concrete updates, use one top-level `JIRA-ID - Title` bullet and indented markdown sub-bullets instead of repeating the same Jira line.
 - When a flow/page shorthand could be ambiguous, prefer the real flow identifier and page name from `vault/03-context/workstreams/flow-page-references.md`.
+- For standups that may also be sent to Teams, prefer plain audience-friendly wording over internal implementation shorthand; avoid terms like `fallback` unless the audience already has the necessary context.
+- When a release is waiting on approvals or pipeline movement, make the concurrent work explicit so the update does not imply idle waiting.
 - Avoid vague phrasing such as:
   - "same behavior"
   - "looks fixed"

vault/06-daily/2026-04-17.md

@@ -19,3 +19,9 @@ tags:
 - One code-owner approval is still required before the PR can merge.
 - After that approval, the remaining work is to run the pipeline and update Fid4 so the XFlow `2.8.48` change propagates through the consumer path.
 - `PDIAP-15838` remains the next story after the `PDIAP-15765` propagation steps are in a good place.
+
+## Standup Wording Feedback
+
+- Jeff said not to use `fallback` in the standup wording because a broader audience will not understand that term without extra context; prefer plain outcome wording like `Got the PR approved`.
+- Jeff clarified that when `PDIAP-15765` is waiting on approvals or pipeline movement, the standup should explicitly say David is returning to GraphQL removal work rather than sounding like the day is blocked on waiting.
+- David updated the standup wording with those changes and sent the final version.