diff --git a/.opencode/commands/standup.md b/.opencode/commands/standup.md index 6deab48..fc5f96a 100644 --- a/.opencode/commands/standup.md +++ b/.opencode/commands/standup.md @@ -106,8 +106,9 @@ Return a standup that is: - safe to send without overstating certainty - written in natural US English that can be sent externally without rewriting - written as David's progress report -- free of any mention of Jeff by name - free of any mention of Mattermost, since it is internal-only communication +- starts with exactly `Hi @jeff, here’s my daily scrum update:` for the active Fidelity profile +- does not mention Jeff again after the greeting unless explicitly needed - uses bullet points for each item - groups multiple updates for the same Jira item as indented sub-bullets - uses `JIRA-ID - Title` or `JIRA-ID Title` formatting instead of comma-separated ID/title formatting diff --git a/project-knowledge/02-work-items/pdiap-15838.md b/project-knowledge/02-work-items/pdiap-15838.md index 28ef0ec..2ee5745 100644 --- a/project-knowledge/02-work-items/pdiap-15838.md +++ b/project-knowledge/02-work-items/pdiap-15838.md @@ -66,6 +66,7 @@ tags: - Follow-up runtime scan now suggests `GraphQL/NetworkClient.swift` has no live production callers and only self-references remain inside the file. The proposed next removal order is to delete `GraphQL/NetworkClient.swift` first, build/reference-check, then delete `GraphQL/ApolloGeneratedCode`, while keeping the AppSync members in `XFlowInitManagerConfig.swift` temporarily as compatibility-only surface. - Current local state after broader cleanup: runtime Apollo decoupling and most Apollo-specific test cleanup now appear complete, production code compiles cleanly aside from a pre-existing environment issue, and no live Apollo imports/references remain in production code. Remaining work is mainly package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`. - Current local state now also indicates the test target compiles cleanly after a minimal follow-up update to `XFlowTransportSelectionTests.swift`, preserving REST-relevant transport tests while removing obsolete GraphQL/Apollo assertions. The remaining Apollo-removal work appears concentrated in package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`. +- Latest follow-up says the Apollo package/build cleanup has also now been applied: direct Apollo dependency references were removed from package/build ownership surfaces, leaving the main remaining follow-up as Fid4 validation plus any later decision on whether to deprecate/remove the temporary AppSync compatibility getters in `XFlowInitManagerConfig.swift`. - Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task. - Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared. diff --git a/project-knowledge/06-daily/2026-04-21.md b/project-knowledge/06-daily/2026-04-21.md index 49f3e2f..7212539 100644 --- a/project-knowledge/06-daily/2026-04-21.md +++ b/project-knowledge/06-daily/2026-04-21.md @@ -17,6 +17,8 @@ updated: 2026-04-21 ## Focus - Continue `PDIAP-15838` Apollo-removal cleanup. +- Continue validating the Apollo-removal state. +- If time allows, publish new XFlow and XFlowViewMaker versions. --- @@ -39,6 +41,7 @@ updated: 2026-04-21 - Follow-up scan says `GraphQL/NetworkClient.swift` now appears runtime-dead for production, `GraphQL/ApolloGeneratedCode` appears unreferenced by production runtime after model cleanup, and the safest next step is to remove `NetworkClient.swift` first, then validate before removing `ApolloGeneratedCode`. - Broader Apollo cleanup has now removed `NetworkClient.swift`, `ApolloGeneratedCode`, Apollo-specific test files/mocks, and related project-file entries. Current reported state says production code has zero live Apollo imports/references and retained REST behavior, while remaining follow-up work is package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`. - Test-target cleanup is now also in a good state: a minimal update to `XFlowTransportSelectionTests.swift` removed obsolete GraphQL/Apollo assertions, preserved REST-oriented coverage, and left no remaining non-environment test-target compile errors. +- The latest cleanup pass also removed the remaining direct Apollo package/build references, so the story is now in a cleaner post-removal state and ready for consumer-side validation from Fid4. - The current FTTransfer communication should say the primary fix is the dismissal adjustment in the UIKit hosting path; FTTransfer-side improvements are secondary and not strictly required to reproduce the same visual behavior. - After the `ApolloGeneratedCode` removal, local compilation still succeeds for David; the Copilot-reported `ApexKitSwiftUI` blocker should be treated as environment-specific noise unless it becomes reproducible in the real local build. - No live production Apollo runtime references remain in `XFlowSDK/XFlowSDK`; the next cleanup surface is deferred test references plus any intentionally retained AppSync compatibility APIs. @@ -53,6 +56,8 @@ updated: 2026-04-21 - Remove Apollo-only tests, mocks, codegen scripts, and build wiring once runtime references are gone. - Treat any transitive PicoSDK Apollo dependency as a separate dependency-exit step. - Continue cleanup by removing GraphQL/Apollo-era test references and related test-only helpers without changing production runtime behavior. +- Continue validating the Apollo-removal state today. +- If time allows, publish new XFlow and XFlowViewMaker versions. --- diff --git a/prompts/standup.md b/prompts/standup.md index f60aa76..dbb4878 100644 --- a/prompts/standup.md +++ b/prompts/standup.md @@ -1,17 +1,20 @@ # Standup Prompt -Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the detailed files referenced from that active-work summary, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday Mattermost context, today's daily note if present, and the latest available Mattermost context. +Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the detailed files referenced from that active-work summary, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday communication context, today's daily note if present, and the latest available communication context. -Generate a standup update for an iOS engineer working on Fidelity. +Generate a standup update for the active project profile. ## Output contract -- Return exactly three sections in this order: `Yesterday:`, `Today:`, `Blockers:` -- Return Markdown that is ready to copy/paste directly into Mattermost -- Use one top-level bullet per Jira item +- Use the greeting required by the active profile or command. If no greeting is specified, omit the greeting and start with the previous-work section. +- Return the greeting, a previous-work section, and `Today:` +- Include `Blockers:` only when there is a real blocker to report; omit the entire section when there are no blockers +- Use `Yesterday:` only when the previous-work section truly refers to yesterday; otherwise use a truthful label such as `Last workday:` or the weekday/date when clearer +- Return Markdown that is ready to copy/paste directly into the configured team communication tool +- Use one top-level bullet per work item - Use indented sub-bullets only when they improve clarity - Prefer one concise sub-bullet when nearby events are part of the same continuous context -- Keep sub-bullets in chronological order within each Jira item +- Keep sub-bullets in chronological order within each work item - Keep the whole standup concise and ready to send ## Selection rules @@ -20,8 +23,9 @@ Generate a standup update for an iOS engineer working on Fidelity. - `Yesterday` must describe work that actually happened on the previous workday, not older status changes that still appear in current memory - On Mondays, use Friday's work context unless a later prior day has Mattermost activity - If the previous calendar day has no work activity or is OOO/weekend, use the latest prior day with Mattermost activity -- Treat the previous workday communication context as the primary source for `Yesterday` -- Use current memory to disambiguate, not to backfill unrelated older events +- Treat the previous workday communication context as the primary source for the previous-work section +- If a latest daily log exists, use its `Work Done` and same-day findings as the primary source for `Yesterday`; use current memory only to disambiguate, not to backfill unrelated older events +- Do not reuse older investigation context from `current-work.md` as `Yesterday` unless the latest daily log or previous-workday communication confirms it happened on that workday - Prefer updates directly tied to active work items over side questions, context refreshes, or manager-only reminders - Exclude items that are not directly tied to a story unless they are true blockers - Do not mention stories assigned to a future sprint unless they are a real blocker for today's work @@ -29,26 +33,26 @@ Generate a standup update for an iOS engineer working on Fidelity. ## Story handling rules -- Mention Jira IDs and approved titles when they are available and clearly tied to the reported work +- Mention work item IDs and approved titles when they are available and clearly tied to the reported work - Prefer including story titles whenever a reported update maps clearly to a Jira item - Prefer story-based reporting when the work maps clearly to a Jira item - If documentation, root-cause analysis, or implementation analysis directly supports a story, group that work under the related story instead of listing it separately -- When one Jira item has multiple concrete updates, keep them under one top-level `JIRA-ID - Title` bullet -- When pairing a Jira ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them +- When one work item has multiple concrete updates, keep them under one top-level `ID - Title` bullet +- When pairing a work item ID with a title, prefer `ID - Title` or `ID Title`; do not use commas between them ## Writing rules - Write in natural US English that can be forwarded externally without rewriting -- Write the standup as David's external progress report +- Write the standup as the workspace user's progress report - Be specific, concise, and evidence-backed - Avoid vague phrases and generic progress language - Mention debugging findings only if they materially changed understanding - Clarify auth-dependent behavior when relevant - Separate external issues from regressions when that distinction matters -- For standups that may also be sent to Teams, prefer plain outcome language over internal implementation jargon; avoid unexplained terms like `fallback` +- For standups that may also be sent outside the immediate team, prefer plain outcome language over internal implementation jargon; avoid unexplained terms like `fallback` - 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 +- Do not mention manager or stakeholder names except in the configured greeting or when the user explicitly asks +- Do not mention internal evidence sources or communication tools unless the user explicitly asks ## Compression rules @@ -58,22 +62,26 @@ Generate a standup update for an iOS engineer working on Fidelity. ## Anti-patterns to avoid -- Do not report a story as worked yesterday just because it is now `Done` +- Do not report a work item as worked yesterday just because it is now `Done` - Do not pull old closure events from durable memory into a new standup unless they happened on the previous workday - Do not mention next-sprint work in `Today` when today's plan is already known and different - Do not turn context notes into fake progress lines Format: + + Yesterday: -- PDIAP-#### - Title +- ITEM-#### - Title - Update 1 - Update 2 Today: -- PDIAP-#### - Title +- ITEM-#### - Title - Next action 1 - Next action 2 Blockers: - ... + +If there are no blockers, omit `Blockers:` entirely.