Files
fidelity-ai-workspace/vault/03-context/workstreams/rest-migration.md
david.delagneau 374991a568 Refactor workspace structure and documentation
- Deleted obsolete files: obsidian-vault.md, onboarding.md, workspace-model.md
- Updated opencode.json to remove references to deleted files.
- Revised profile.md to clarify the status of legacy paths and communication evidence.
- Adjusted prompts to reflect new file paths and improve clarity.
- Enhanced daily logs with focus, work-items, and blockers properties.
- Updated work-item notes to include systems, workstreams, people, and related properties.
- Improved context maintenance guidelines to ensure accurate and durable project knowledge.
- Refined base filters to exclude template files and ensure only relevant notes are displayed.
- Updated daily templates to ensure proper formatting and consistency.
- Modified workflows to align with the new vault structure and improve context synchronization.
2026-04-16 16:28:30 -06:00

1.3 KiB

type, project, status, systems, work-items, related, updated, tags
type project status systems work-items related updated tags
workstream fidelity active
xflowsdk
pdiap-15838
consumer-integration
2026-04-16
workstream
fidelity

REST Migration

Goal

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.