用途：把 Calypso Reader 的数据获取代码迁移到目标架构——fetcher 放在 @automattic/api-core，query/mutation 选项放在 @automattic/api-queries，组件直接调用 useQuery()/useMutation()。两类来源需迁移：client/state/data-layer/wpcom/read/ 中的 Redux data-layer，以及使用 wpcomRequest 的 @automattic/data-stores Reader hooks。
主要能力：提供文件落位表与命名规范（fetcher 用 fetchRead{Name}，query 用 read{Name}Query，mutation 用 {verb}Read{Name}Mutation，响应类型用 Read{Name}Response），以及强制工作流：先审计 CRUD 与已有 fetcher、写计划、做 bridge 决策，再带检查点执行。计划需含完整 CRUD 审计、bridge 决策及理由、提交拆分、每个 mutation 的失效与乐观更新决策、待更新消费者清单与测试计划，保存到 .context/plan-migrate-reader-{name}.md。
必要用法：迁移前 grep 现有 api-core fetcher 避免重复；替换 queryKey 前必须 grep 所有读写该 key 的代码（mutation 的乐观写入常会静默失效）。创建 fetcher 时从 ../wpcom-fetcher 导入 wpcom，并照抄原 data-layer 的 method、path、apiVersion 与参数。查询 key 形如 ['read', '{domain}', ...params]，staleTime 约 1 分钟（外部变更数据）或约 5 分钟（慢变列表）；参数可为 null 时使用 enabled。测试 nock URL 为 https://public-api.wordpress.com/rest/v{apiVersion}/{path}，运行 yarn test-client client/components/data/query-reader-{name}/test/。Redux 清理需与迁移分开提交。
适用场景：QueryReaderTag 等 Reader 数据获取组件迁移、data-stores hooks 替换、bridge 组件保留或移除、Redux Reader 状态与 isRequesting 选择器清理。
限制：不要求把类组件改写成函数组件，必要时用 HOC；bridge 仅在多消费者等情况下保留并记录原因；涉及 X-WPSUBKEY 的登出订阅端点需先与后端确认鉴权行为。其他细节资料暂未提供。