用途与实际影响
这项功能怎样使用
为什么需要它
设备 API 能读的字段很多。若把高频心率、位置、营养目录、空日志和估算噪声全部常驻，不仅扩大私人数据面，也会让低质量信号压过真正相关证据。
举个实际例子
我问“上周三的步数有没有保存？不用重新同步。”系统只在已经完成的那份导出里查这一天，告诉我找到几条、覆盖到什么时间；没找到只代表这份记录里没有，不能顺手说成那天一步都没走。
最后我会得到什么
得到所选日期里睡眠、步数、活动或已记录运动的变化、覆盖和缺口，知道每项记录目前能不能用于眼前问题。只问某一天时只读那天已保存的字段；查到记录不等于能作医学判断。
可用于当前判断
所选日期和字段的来源、完整性与质量都过关时，才交健康项目负责人用于当前问题；单日查询只说明这一天保存了什么。
需要复核
重叠、缺页或覆盖不足会明确列出。某日没查到记录不等于真实数值为零，也不重新下载整段历史。
本轮不可用
选中的导出或文件无法核对时，先停在证据层，不根据残缺摘要解释身体状况。
从哪里开始
问近两周变化，或明确指定已采集的完整中国日期范围。
需要准备什么
- 要比较的睡眠、步数或活动等问题
- 想看的日期范围（如指定）
从开始到拿到结果
- 1
系统核对并处理
先离线核对原始页与覆盖，再按所选范围汇总相关字段；指定长范围就按该范围自身的质量判断。
- 2
交付与接续
交回变化、缺记录和可用性；保存了数据不等于这一字段足以支持健康结论。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
capture/brief无网络和凭据路线；指定日期、按日质量与multiple_roles已有实现，新增本地历史分段合并；2026-09-14全套140项离线合成测试通过，个人数据未读取关键规则与设计选择
默认 decision context 只有睡眠、步数、活动分钟和已记录运动事件。
默认最近 14 天至少 80% 日期有可解释记录是数据覆盖门，不是健康目标；指定日期使用 requested_period 自己的覆盖与 decision_ready。
用户指定范围时使用 brief --start / --through，含首尾且只接受已采集的完整中国日；requested_period 的质量和 decision_ready 单独判断，不能拿默认窗口代答。
质量按字段、日期和可回答的量分别判断；坏记录日期明确就只影响该日，日期不明才保守影响整页对应日期。
已处理成功且时长/区间可信的主睡眠加小睡双标签记录归入 multiple_roles，时长只计一次，不参与主睡眠起止推断；不重复计算、不擅自归类。
比较窗口为 14、28、90 天，并保留长期 90 天块与时间边界。
inventory_only 只读 manifest（清单） inventory，不读取 raw 内容。
具体日期仍未回答时，用精确 manifest（清单）、一个 --field 与日期离线窄查；不扫描目录、不重新下载。
--through-date包含当天，end_date_exclusive是次日；睡眠session的带时区绝对结束时间先转中国时间，再归属醒来日，其余使用可验证的日期字段，避免跨UTC/中国日期边界按错一天。
query/summary 的默认和硬上限均为 100 页、32 MiB、10,000 条，可按问题缩小，不能靠调大越过上限；这与 brief 的预算是两套不同限制。
本模块用到的名词
- decision_ready（可用于当前判断）
- 字段证据质量足以支持一个明确问题，不代表身体正常或临床结论。
- inventory_only（仅清单）
- 只知道资料类型存在，不读取正文、不进入判断。
- Coverage gate（覆盖门）
- 检查近期可解释日期占比；80% 是数据完整性要求，不是医学阈值。
- Downstream contract（下游使用合同）
- 只有相关字段自身 ready、来源 ready 且会改变判断时才能被 Health Owner（健康资料责任源） 采用。
专业定义
设备能提供很多数据，但当前判断只采用来源清楚、质量足够、确实相关的最小部分；其余只记录存在或暂时不用。
解决什么
解决“API 能读就全部进模型”、高频/高隐私字段常驻、空日志被解释、摘要读取全库和技术覆盖率冒充医学标准。
当前怎样实现
- capture --latest 读取最多 16 KiB 的固定指针，要求同一采集目录下的规范 manifest（清单）、验证回执与 brief，并核对 schema（数据结构）、complete 和文件 SHA-256；缺失、越界或漂移返回 latest_capture_*，不扫描替代目录。
- google_health_capture.py 只读固定 success handoff，验证 exact manifest（清单） path、status 与 SHA-256。
- create_verification_receipt 重验 profile、manifest（清单）、selected page chain 与文件 stat commitment。
- google_health_brief.py 只选择 DECISION_CONTEXT_FIELDS，受 256 页、64 MiB、500k 记录预算约束。
- _verified_history_segments核对扁平历史段、对应manifest（清单）哈希和既有验真回执；build_health_brief从各有效分段选四类低噪声决定字段，按_effective_start/_effective_end裁剪日期，排除已由新采集替代的旧当天。query_manifest同样把字段与日期路由到对应原件。
- 数值和事件字段分别处理真实零、重复、歧义、malformed、无记录和来源缺失。
- brief 输出 decision_context 与 inventory_only 两个不混用区域。
- resource_usage 明确 api_access=false、credential_access=false、full_raw_payloads_scanned=false。
- google_health_import.py 的 query_manifest 按字段与日期相交范围选择页面，核对每页 bytes/SHA-256，再按字段专用日期解析记录并去重；清单元数据字节与 raw page 预算分开计数。
- --query-manifest 返回 records 及 summary；--summary-manifest 调用同一查询但 include_records=false。summary 包含记录数、无日期资源数、重复数、页数和 days，不计算 numeric_sum/min/max。
- 查询结果单列 manifest（清单） 指纹、pages_considered/page_count、bytes_read、record_count、duplicate_record_count、gaps、truncated 和 timing；api_elapsed_seconds 恒为 0，不代表在线账号或设备当前可用。
执行流程
- 1
读取有界 success handoff 并解析 exact manifest（清单）。
- 2
验证 complete 状态与 manifest（清单） hash（内容指纹）。
- 3
生成/加载离线 verification receipt（执行回执）。
- 4
核对当前清单与扁平history.sources；从各有效日期段只选择四类判断字段页面，按分段边界排除已由新采集替代的旧当天。
- 5
计算字段质量、近期窗口和 blocked reason。
- 6
生成 decision context、inventory-only 和 downstream contract。
- 7
本地 manifest（清单）、verification receipt（执行回执） 与 brief 闭合并持久化后消费交接 pointer；Health Owner（健康资料责任源） 随后审阅最小结果并决定是否局部采用。
- 8
另有未回答的具体日期问题时，复用已完成的精确 manifest（清单），以一个字段和日期执行 query 或 summary；交回记录与缺口，不启动新的采集。
边界
- 不读取高频心率 raw、GPS/TCX、营养参考和其他 inventory-only 正文。
- 没有记录不证明没有运动、症状或疾病。
- 80% coverage 不表示健康，也不是目标分数。
- brief 输出不包含 OAuth（账号授权协议）、token、provider client 或实时网络状态。
- 普通 query pass 不是 decision_ready，也不自动更新 CURRENT.md；字段质量、来源与现实相关性仍由 Health Owner（健康资料责任源） 判断。
失败与恢复
- 混合第一方来源无法证明 tracker family
- 四类默认字段全部 provenance_blocked，只保留 inventory。
- selected raw page 哈希或分页链变化
- verification stale，brief 在读取健康解释前失败。
- 字段为空、缺失或 malformed
- 列入 blocked_fields，不把缺失转成零或正常。
- brief 选择页/字节/记录预算超限
- 返回 health_brief_budget_exceeded，不扩大读取范围。
- 某日 query 达到页数、字节或记录上限
- 保留已读结果并返回 partial、truncated=true 与 query_page_budget_exceeded、query_byte_budget_exceeded 或 query_record_budget_exceeded 缺口；缩小字段或日期后再查，不隐去截断。
- 某日 query 页面缺失、哈希漂移或记录日期不明
- 返回 partial，并分别记录 page_unreadable、manifest_page_hash_mismatch 或 record_date_unavailable；未覆盖日期仍列为 gap，不补猜数值。
- query 字段不在清单、日期范围非法或预算参数非法
- 分别返回 query_field_not_in_manifest、invalid_query_date_range 或 query_budget_invalid；不回退到全字段或在线查询。
真实入口
google_health_capture.py有界 success handoff、离线验证、brief 持久化与 pointer cleanup
google_health_brief.py字段解析、窗口、质量门、inventory-only 和 downstream contract
google_health_history.py扁平历史段身份、连续日期与清单哈希核对
tests/test_google_health_incremental.py跨采集历史、旧未完整日替代与离线无重计合成验证
google_health_import.py · query_manifest / summarize_manifest精确字段日期查询、独立读取预算、记录/摘要/缺口与零 API 耗时
tests/test_google_health_capture.py离线无凭据/网络、错误交接和安全重试回归
tests/test_google_health_brief.py29 项来源、哈希、覆盖、字段三态、inventory-only 与 CLI（命令行工具） 回归
tests/test_google_health_import.py · offline query tests按日期过滤、跨午夜睡眠、重复记录、缺页和预算截断的合成用例
如何验证
- 4 项 capture 测试证明入口无 OAuth（账号授权协议）/client/network route（处理路线），失败保留 success pointer 供离线重试
- 29 项 brief 测试覆盖 mixed source、真实零、空字段、哈希漂移、分页链、覆盖和 inventory-only
- 离线查询源码与合成用例覆盖字段日期过滤、跨午夜睡眠按结束日归属、记录去重、无日期缺口和预算 partial；本页修订只读这些代码，不运行私人 manifest（清单）
- 本轮没有读取任何真实健康数值或生成个人趋势图
与其他模块的关系
它消费原始保全模块的 complete 证据，向证据三态和 Health Owner（健康资料责任源） 模块提供字段级 ready/blocked 结果。