债:/api/ingest-clipping 的 workflow dispatch 是死路(2026-07-08 认知 OS Batch 4 记档)
导读
现象
worker/handlers/ingest.js 的 handleIngestClipping 仍然 POST actions/workflows/ingest.yml/dispatches,但 repo 里 .github/workflows/ 目录已整体删除(GH Actions billing 停摆 + 2026-05/06 清理)——GitHub 对不存在的 workflow 返回 404,前端 IngestClippingButton(剪藏页底部「结构化入 wiki」按钮)的链路实际已断。
顺带:IngestClippingButton.tsx 的 WORKER_URL 只读 NEXT_PUBLIC_WORKER_URL env,没有其它三处组件的 pages.dev → location.origin fallback,env 未配时按钮直接报错,与站内其它 worker 调用不一致。
为什么现在不修(scope 决策)
认知 OS v1 的快速捕获(/api/capture,2026-07-08 上线)走 GitHub Contents PUT 直接落 sources/inbox/,不依赖 workflow dispatch,已覆盖"手机把内容送进 ingest 队列"的需求。修 clipping 按钮属独立决策:要么改成走 /api/capture 同款 PUT + 本地 session 跑 auto_ingest.py,要么直接删按钮(clipping 本身由 Telegram bot 抓,按钮价值待定)。
修复选项(择一)
- 改造:
handleIngestClipping弃 dispatch,改写「把 clipping slug 排进sources/inbox/work/」的 Contents PUT(复用worker/lib/github.js的ghPutFile),本地 ingest 时消化;IngestClippingButton补 origin fallback。 - 退役:删
IngestClippingButton+handleIngestClipping路由(clipping 已有 TG bot 通道,按钮从未在断链后被真用)。
判断依据:看 ledger/真用信号——若剪藏按钮无人用,走选项 2(delete-useless-decisive)。