docs: plan the implementation for issue #11

Eight tasks against the approved design, ordered so the port and both telemetry backends land before the three call paths that feed them. Writing the plan turned up a third telemetry path the design missed: OcrClient emits through the same helper and builds its ChatRequest on the spot, just as embedding does. OCR rows share the table with chat rows, so leaving them out would put a hole in a multi-tenant caller's audit trail, and the same irreversibility argument applies. Listed as Task 6 and flagged as beyond the approved scope -- it may be dropped, but only by stating the limitation in the CHANGELOG, not silently. The integration task pins the issue's own argument as a test: build a 22-column table, open it with the current recorder, and assert the old rows read back as the empty string rather than NULL -- NULL under an RLS policy is invisible to everyone, not merely unassigned.
2026-08-17 06:10:53 -04:00
parent b671fb629a
commit a052f3eb28
7 changed files with 281 additions and 4 deletions
@@ -1,6 +1,6 @@
 # 调用方自定义维度设计(issue #11)

- **状态**: 待 Codex 审 → 待人类审批
+- **状态**: **已人类审批(2026-08-17)**;Codex 审查 4 项已全部采纳并修订
 - **触发**: issue #11「遥测表 llm_calls 缺少租户维度,多租户调用方无法在数据库层隔离」
 - **范围**: 公共 API(`chat`/`embed` 签名)、`ports.TelemetryRecorder` 端口、`types.ChatRequest`、两个遥测后端的 schema。属 CLAUDE.md §3 强制设计档 + 人类门。