Files

T

Jesse_ChenandClaude Fable 5 ce1939b074 docs(tasks): 星盘页与 VedAstro 外网调用脱钩 + 运行期真相两单

星盘页首屏那一发 /api/chart 没传 skip_vedastro_main_entry_overview，
本机实测冷算 0.40–0.66 秒里约 0.36 秒是 VedAstro 空转（连 endpoint 都
没配的情况下）；带标志的同一调用是 5 毫秒。生产 env 开着 network 与
fanout，等于首屏同步等 24 个外部请求加 3 次领域扫描，而前端 mapper 与
contract 根本不读这份证据。BUG-718，复发自 BUG-161。

运行期单记录两条新发现：官方 vedastro==1.23.25 其实是 REST 客户端，
且 import 时请求 pypi 并 pip install --upgrade 自升级（实测 pin 装完
一 import 即变 1.23.26）；无 key 时免费层排队是同步 sleep 加进程级
全局锁，24 个请求约 4.8 分钟堵住前台线程。台账补 ERR-107 / ERR-108，
生产 env 核对清单交产品负责人执行。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155nFCgCHtoA7jhSDGmZmMu

2026-09-15 15:47:32 +00:00

3.9 KiB

Raw Blame History

真人核对 · 生产 VedAstro 运行模式（2026-09-15）

这份清单只能由产品负责人在生产主机上执行（会话内没有 SSH 凭据，也不应该有）。目的是确认三件事：有没有 API key、fanout 是不是开着、缓存 TTL 是多少。

下面每条命令都刻意只输出「有 / 没有」或数字，不会打印 key 值。请不要改写成 cat .env.production 或 grep VEDASTRO_API_KEY 直接看值，也不要把命令输出之外的内容贴回对话。

准备

ssh -p <confirmed-port> deploy@118.194.235.34
cd /opt/jyotisha-production

1. key 是否配置（最关键）

grep -qE '^VEDASTRO_API_KEY=.+$' .env.production && echo "API_KEY: set" || echo "API_KEY: EMPTY"

回填：API_KEY: ____

EMPTY 意味着生产正在用官方免费公共模式。一次未命中缓存的完整取证要发 24 个外部请求，而免费层是 5 个/60 秒且我们的排队实现是同步 sleep + 全局锁——见 TASK-vedastro-runtime-ops-20260915.md 任务 2，该任务会因此升为 P0。

2. fanout 与 range scan 开关

grep -E '^VEDASTRO_(FULL_SNAPSHOT_FANOUT_ENABLED|RANGE_SCAN_NETWORK_ENABLED|ENABLE_NETWORK|TIMEOUT_SECONDS|GATEWAY_MODE)=' .env.production

这几个不是 secret，可以直接看值。回填：

变量	实际值	代码默认
`VEDASTRO_FULL_SNAPSHOT_FANOUT_ENABLED`	____	`1`（开，24 个请求）
`VEDASTRO_RANGE_SCAN_NETWORK_ENABLED`	____	跟随 `ENABLE_NETWORK`
`VEDASTRO_ENABLE_NETWORK`	____	空（关）
`VEDASTRO_TIMEOUT_SECONDS`	____	见适配器默认
`VEDASTRO_GATEWAY_MODE`	____	—

没有这一行就等于取代码默认值 1（开）。

3. 缓存 TTL

grep -E '^VEDASTRO_(CACHE_TTL_SECONDS|OFFICIAL_FULL_SNAPSHOT_CACHE_TTL_SECONDS)=' .env.production
grep -E '^JYOTISH_API_CHART_CACHE_TTL_SECONDS=' .env.production

回填：VEDASTRO_CACHE_TTL_SECONDS: ____、OFFICIAL_FULL_SNAPSHOT_CACHE_TTL_SECONDS: ____、JYOTISH_API_CHART_CACHE_TTL_SECONDS: ____（后者没配则是 900 秒）

4. 网关自报的运行状态

COMPOSE='docker compose -p jyotisha-production --env-file .env.production -f deploy/docker-compose.server.yml -f deploy/docker-compose.postgres.yml -f deploy/docker-compose.production.yml'
$COMPOSE exec -T api sh -c 'curl -s -m 20 http://127.0.0.1:5200/api/vedastro_gateway/status' | head -c 2000; echo

回填整段输出（它不含 key，只含布尔与状态名）。如果里面出现任何看起来像凭据的长串，不要贴回来，只说「有疑似凭据字段」。

5. 运行期 SDK 实际版本（验证 pin 是否漂移）

$COMPOSE exec -T api python -c "from importlib.metadata import version; print('vedastro runtime version:', version('vedastro'))"

回填：____

requirements.txt 固定的是 1.23.25。如果这里显示的不是 1.23.25，说明 SDK 在容器里自己把自己升级了（它 import 时会请求 pypi 并 pip install --upgrade），这就是 BUG-719 的生产实证。

6. 星盘页真实首屏（改动上线后再做）

TASK-chart-vedastro-decouple-20260915 部署到 staging 之后：

# 在你自己的电脑上，登录 staging 后用浏览器打开
https://staging.jyotisha.chat/chart

主盘应该几乎立刻出现（本机实测本地计算 5 毫秒）。
记录一次「冷」打开（先等 15 分钟以上让引擎缓存过期，或换一个还没算过的出生资料）的主观等待时间。
五个 Tab 逐个点开，内容与改动前一致即可。

回填：冷打开等待 ____ 秒；Tab 有无异常 ____

回填后怎么处理

把 1–5 的回填结果交给执行方，写进 BUG-720 的触发条件与定级。第 6 条写进 docs/testing/chart-page-20260915.md 的走查记录。

在这份清单回填之前，任何人不得声称「生产 VedAstro 行为已验证」。

3.9 KiB Raw Blame History Unescape Escape