feat: Update standup guidelines for clarity and audience accessibility

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