记录输入事实的设备坐标

[utopiafar]

关联 issue

Closes #295

变更

• 为输入 Fact header 增加结构化 input_location，只来自设备 GPS，不从文本地名推断。
• 新增 InputLocation domain model，并增强 Fact header metadata 解析，兼容旧的空 metadata。
• 当前 GPS 超时/失败时，仅使用 2 分钟内的 last-known device GPS 作为保守 fallback，陈旧坐标继续丢弃。

测试

• flutter test --no-pub test/data/repositories/submit_input_test.dart test/data/services/location_context_service_test.dart
• flutter analyze --no-pub lib/domain/models/input_location.dart lib/data/services/location_context_service.dart lib/data/repositories/submit_input.dart test/data/repositories/submit_input_test.dart test/data/services/location_context_service_test.dart
• flutter build apk --debug --flavor globalDev --no-pub
• git diff --check
• Android emulator Medium_Phone_API_35：grant fine/coarse location，emu geo fix 121.456789 31.212345，从 Timeline 输入 GPS_QA_20260616_1145 并提交；读取 Fact 文件确认 header 写入 input_location，lat/lng 与模拟坐标一致，source 为 device_gps。

[github-actions]

PR AI Review / PR AI 语义预检

中文

• 风险等级：低风险
• 需要人工审核：否
• 黄金链路影响：无
• 置信度：high
• Workflow run：27593678009

为输入记录添加设备 GPS 坐标作为 Fact header 元数据（input_location）。新增 InputLocation domain model，增强 LocationContextService 支持超时/last-known fallback，扩展 FileSystemService 的 Fact 条目元数据解析并保持向后兼容。变更架构清晰，测试覆盖完整，无安全或数据风险。

影响范围

• repository
• service
• storage
• tests

黄金链路

• 未识别到黄金链路影响。
• 说明：变更是纯增量的：为 Fact header 元数据添加 input_location 字段，不影响现有卡片渲染、agent pipeline 或本地数据兼容性。旧格式已做向后兼容解析。

风险项

• info FileSystemService 元数据解析未单独测试。证据：lib/data/services/file_system_service.dart: _parseFactEntryMetadata() 和更新的正则表达式, test/data/repositories/submit_input_test.dart: 'parses old empty and missing Fact header metadata' 测试通过 submitInput 集成覆盖了该逻辑。
  建议：当前通过 submit_input_test.dart 的集成测试已覆盖。如后续 _parseFactEntryMetadata 逻辑变复杂，可考虑为 FileSystemService.extractFactContentFromFile 添加独立单元测试。

测试缺口

• 未发现新的测试缺口。

English

• Risk level: LOW
• Human review required: NO
• Golden path impact: NONE
• Confidence: high
• Workflow run: 27593678009

Adds device GPS coordinates as Fact header metadata (input_location) for each input submission. Introduces InputLocation domain model, enhances LocationContextService with timeout and last-known-GPS fallback, and extends FileSystemService fact-entry metadata parsing with backward compatibility. Architecture is clean, test coverage is thorough, and no security or data risks identified.

Affected Areas

• repository
• service
• storage
• tests

Golden Path

• No golden path impact was identified.
• Rationale: Change is purely additive: adds an input_location field to Fact header metadata. Does not affect existing card rendering, agent pipeline, or local data compatibility. Old formats are parsed with backward-compatible logic.

Findings

• info FileSystemService metadata parsing not independently tested. Evidence: lib/data/services/file_system_service.dart: _parseFactEntryMetadata() 和更新的正则表达式, test/data/repositories/submit_input_test.dart: 'parses old empty and missing Fact header metadata' 测试通过 submitInput 集成覆盖了该逻辑.
  Recommendation: Currently covered via the integration test in submit_input_test.dart. If _parseFactEntryMetadata grows more complex, consider adding a dedicated unit test for FileSystemService.extractFactContentFromFile.

Test Gaps

• No new test gap was reported.

AI review is advisory. Maintainers should verify the result before merging.

[github-actions]

PR Preflight Summary / PR 预检汇总

中文

• 统一结论：低风险：两个预检均已完成，质量预检通过，可走普通手动合并流程。
• Policy preflight：低风险。未命中打回或高风险规则。
• Flutter quality：通过。Analyzer 和 test baseline 均未发现新增问题。
• PR head：803c55630d248e4970f9a3045c685b7a3b7a729f
• Policy run：27593678006
• Flutter run：27593678983

English

• Combined result: Low risk: both preflights completed and quality passed; use the normal manual merge flow.
• Policy preflight: LOW RISK. No blocking or high-risk policy signal was found.
• Flutter quality: PASS. Analyzer and test baselines found no newly introduced issue.
• PR head: 803c55630d248e4970f9a3045c685b7a3b7a729f
• Policy run: 27593678006
• Flutter run: 27593678983

PR Policy Preflight / PR 规则预检

PR Policy Preflight / PR 规则预检

中文

• 判定：低风险
• 变更文件数：7
• 变更行数：619
• Diff 是否截断：false

未发现确定性规则问题。

English

• Decision: LOW RISK
• Changed files: 7
• Changed lines: 619
• Diff truncated: false

No deterministic policy findings.

PR Flutter Quality / Flutter 质量预检

PR Flutter Quality / Flutter 质量预检

中文

• 总体：通过
• Analyzer baseline：通过
• Test baseline：通过

English

• Overall: PASS
• Analyzer baseline: PASS
• Test baseline: PASS

Flutter Analyzer Baseline

• Base issues: 284
• PR issues: 284
• New issues: 0

No new analyzer issues introduced by this PR.

Flutter Test Baseline

• Base failures: 0
• PR failures: 0
• New failures: 0

No new Flutter test failures introduced by this PR.

[whbzju]

有个位置语义的问题想确认一下：这个 PR 新增的 input_location 看起来是“用户提交这条 Fact 时设备所在位置”，不是事件发生地/照片拍摄地，这点 issue 里也写得比较清楚。

我想确认下你对历史照片场景的考虑：如果用户人在 A 地，上传一张历史拍摄于 B 地且带 EXIF GPS 的图片，预期应该是：

• 图片 EXIF GPS 继续代表照片拍摄地 B；
• input_location 记录本次提交位置 A；
• card/event location 生成时不应该因为 input_location 或 current_location_context 把照片/事件地点覆盖成 A。

现在图片 EXIF 会通过 asset analysis 进 card agent，current_location_context 也会进 agent；工具 schema 里已有“memories / conflicting place 不要使用 current_location_context”的约束。这里是否需要再补一个更明确的 precedence 约束或测试，说明 input_location/current_location_context 只能作为“记录发生地”，不能覆盖 EXIF GPS、用户文本明确地点、user_fixed_location 或未来可能的 captured_location/event_location？

主要担心 media-only historical photo 且当前定位可用时，agent 有机会把当前地点当成照片地点。想确认这是否在本 PR 范围内需要防一下，还是先保持 metadata 语义清晰，后续再专门做 captured/event location 设计。

[utopiafar]

有个位置语义的问题想确认一下：这个 PR 新增的 input_location 看起来是“用户提交这条 Fact 时设备所在位置”，不是事件发生地/照片拍摄地，这点 issue 里也写得比较清楚。

我想确认下你对历史照片场景的考虑：如果用户人在 A 地，上传一张历史拍摄于 B 地且带 EXIF GPS 的图片，预期应该是：

• 图片 EXIF GPS 继续代表照片拍摄地 B；
• input_location 记录本次提交位置 A；
• card/event location 生成时不应该因为 input_location 或 current_location_context 把照片/事件地点覆盖成 A。

现在图片 EXIF 会通过 asset analysis 进 card agent，current_location_context 也会进 agent；工具 schema 里已有“memories / conflicting place 不要使用 current_location_context”的约束。这里是否需要再补一个更明确的 precedence 约束或测试，说明 input_location/current_location_context 只能作为“记录发生地”，不能覆盖 EXIF GPS、用户文本明确地点、user_fixed_location 或未来可能的 captured_location/event_location？

主要担心 media-only historical photo 且当前定位可用时，agent 有机会把当前地点当成照片地点。想确认这是否在本 PR 范围内需要防一下，还是先保持 metadata 语义清晰，后续再专门做 captured/event location 设计。

确实这里位置的语义有点混乱，需要明确下

[whbzju]

从我们记录生活的角度看，应该是原始输入中有的gps为第一原则，特别是很多用户场景是记录图片