- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People."
- Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views.
- Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation.
- Updated scripts and prompts to reflect the new project-knowledge directory structure.
- Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps.
- Ensured all references in workflows and scripts point to the new project-knowledge paths.
Deprecate GraphQL and Apollo safely while preserving behavior through REST-backed flows.
Stable Constraints
REST is behind a feature flag.
GraphQL remains the default fallback unless confirmed otherwise.
REST should never be assumed active by default.
Migration work must preserve behavior parity before removing Apollo-related code.
What Matters In Practice
Validation must clarify whether the tested path is actually using REST or still falling back to GraphQL.
Story scope should distinguish:
transport migration work
feature-flag cleanup
tests and mocks tied to Apollo/GraphQL
Communication should avoid implying the migration is complete before the fallback path is removed.
Historical Signals From Slack
Historical Slack evidence around release and dependency work reinforces that transport or dependency changes often require consumer validation, not just local SDK changes.
Some dependency and pipeline issues complicated migration-related rollout even when the technical change itself was understood.
david.delagneau
dbc1894e27