source.tiktok_shop.th.observed_rate_limit

覆盖范围

• 实测有效 QPS / 并发上限：在给定 app + shop 授权下实际打通的速率。
• 限流响应特征：触发限流时返回的 HTTP 状态、错误码、Retry-After 语义。
• 配额恢复行为：窗口是滑动还是固定、恢复时长。
• 与文档值的偏差：文档写 X 而实测 Y 的差额及观测条件（时段、市场、店铺类型）。

不覆盖

• 任何官方声明的限流值。文档写的进 rate_limit_json.documented， 来源是 source.tiktok_shop.th.api。两段互不越界。
• 任何 FACT / RULE。本 Source 只能产生 assertion_class: OBSERVATION （KA §6.2 / OS §9.1 AC-2）。若一个 Endpoint 同时有官方与实测限流， 按 OS §4.10 拆成两个对象（FACT + OBSERVATION），用 DERIVED_FROM 关联。
• 接口的功能语义（字段含义、业务约束）。那是 API 文档的事。
• 其它平台/市场的观测。观测结果不跨市场外推 —— 同一接口在 TH 与 MY 的 实际配额可能由不同网关承载，外推等于编造。

取证方式

fetch_strategy: manual：观测数据不是抓来的，是压测/生产埋点跑出来的， 由 owner（core.integration）人工录入。

因 fetch_strategy=manual，指向本 Source 的 Evidence 必须有 screenshot_ref （L3-18 阻断）。这里的"截图"是观测证据本身：压测报告、监控面板截图或带时间戳的 日志导出。理由与登录墙页面一致 —— 没有可复核的凭证，数字就只是一句话。

每条观测必须记录：观测窗口（起止时间）、样本量、app/shop 维度、 observed_at、confidence（OS §4.10 示例结构）。

authority 升档依据（KA §6.2，不得跳档）：

30 天复核（KA §7.2 api 域上限）：平台调整网关配额不发公告，只能靠复测发现。