feat: Add Cogstore documentation and update references in project context and debugging guidelines

ai/context/project.md

@@ -14,6 +14,7 @@ The product work happens outside this repository, usually from another machine.
 - XFlowSDK powers backend-driven UI flows
 - XFlowViewMaker is an adapter layer under evaluation for removal
 - FTFrameworks contains feature modules such as FTAccountOpen and FTTransfer
+- Cogstore is the configuration publishing/version-tracking platform used to inspect which flow-definition versions are live in QA or Production
 
 ---
 

ai/context/systems/cogstore.md

@@ -0,0 +1,23 @@
+# Cogstore
+
+## Role
+
+Cogstore is an important Fidelity platform used to manage and publish many flow configuration definitions, each with its own independent version history.
+
+---
+
+## Confirmed Context
+
+- In the Fidelity flow-config workflow, Cogstore is used to modify and publish individual flow definitions.
+- Cogstore tracks versions per flow definition rather than as one single platform-wide version.
+- Cogstore can be used to compare changes between flow-definition versions, similar to a Git-style diff.
+- Cogstore can be used to check which version of a specific flow definition is published in environments such as QA and Production, including who published it and when.
+- On April 16, 2026, David used Cogstore to confirm that the relevant flow-definition change tied to Rashmi's service-side update was present in QA as version `0.0.142`, while Production was still on `0.0.133`.
+
+---
+
+## Related Context
+
+- Jeff indicated on April 15, 2026 that Slate had been used by newer consumer services during the SwiftUI refactor, but is now believed to be decommissioned.
+- Because service/configuration changes can be environment-specific and versioned per flow, Cogstore should be checked before concluding that a payload/config change is live in Production.
+- Flow IDs are not guaranteed to exist in both Cogstore and Slate. When tracing a specific flow definition, confirm which configuration system actually owns that flow instead of assuming the same ID will appear in both places.

ai/context/systems/index.md

@@ -14,6 +14,9 @@
 - [ftframeworks.md](./ftframeworks.md)
   Consumer-side feature modules that often mediate whether XFlow changes can be validated in Fid4.
 
+- [cogstore.md](./cogstore.md)
+  Flow-configuration publishing and version-comparison platform used to verify what is live in QA/Production.
+
 ---
 
 ## Guidance
@@ -21,3 +24,4 @@
 - Start with `xflowsdk.md` for backend-driven behavior questions.
 - Start with `fid4.md` or `ftframeworks.md` for consumer validation and release flow questions.
 - Open `xflowviewmaker.md` when the question involves version bumps, transitional architecture, or pipeline friction.
+- Open `cogstore.md` when the question involves published flow-definition versions, config diffs, or whether a service/config change is live in QA vs Production.

ai/context/workstreams/xflow-debugging.md

@@ -28,6 +28,8 @@ Debug backend-driven flows without losing track of dynamic dependencies or miscl
   - Fid4 / flagship
   - authenticated vs non-authenticated state
 - If a fix appears correct in the SDK but not in consumer validation, inspect the release chain before reopening root cause assumptions.
+- When validating service/configuration changes, check the active flow-definition version in Cogstore before assuming a change is live in QA or Production.
+- Do not assume a flow ID will exist in both Cogstore and Slate; verify which config system actually owns the flow you are inspecting.
 
 ---
 

ai/logs/2026-04-16.md

@@ -21,5 +21,7 @@
 - Jeff said the easiest fix is usually this kind of iOS-side fallback when the consumer is AO, the issue is iOS-only, and the service payload shape differs from what the SDK expects.
 - Jeff approved the Jira and Discourse comments with one wording change: say `I checked the original iOS issue again` instead of `I re-checked`.
 - Jeff approved sending a final AO working-group summary, but wanted it to be much clearer about what was fixed on iOS, what Rashmi changed on the service side, and what separate service-side issue still remains in `HybridBrokerageAccountOpening` / `JointIdentityCheck`.
-- David later checked Cogstore and confirmed Rashmi's service change is already in QA as version `0.0.142`, while production is still on `0.0.133`, so that change is not live in production yet.
+- David later checked Cogstore and confirmed that the relevant flow-definition change tied to Rashmi's service update is already in QA as version `0.0.142`, while Production is still on `0.0.133`, so that flow change is not live in production yet.
-- Jeff concluded there is no point relying on a separate service release for the Youth issue if it would also require its own rollout; the iOS PR should be treated as the primary fix path, while the QA-side service change explains why the issue no longer reproduces in XQ1.
+- Jeff concluded there is no point relying on a separate service release for the Youth issue if it would also require its own rollout; the iOS PR should be treated as the primary fix path, while the QA-side flow-definition change explains why the issue no longer reproduces in XQ1.
+- Durable tooling/system note: in Fidelity flow work, Cogstore is the platform used to modify and publish many individual flow configurations, compare versions per flow, and check who/when a specific flow version was published to QA or Production. Slate was the newer consumer-side configuration tooling during the SwiftUI refactor, but Jeff believes it is now decommissioned.
+- Additional tooling note: flow IDs are not guaranteed to exist in both Cogstore and Slate, so the active configuration source for a given flow should be verified instead of assumed.