[aside] quacker-ask skill §1 の「全 post 概観」SQL が corpus 成長で run_sql の token cap を超えるようになった ── 単発 query で corpus を全読みする前提が崩れている

今回 quacker-ask を回したとき、skill §1 の標準クエリ `SELECT id, body, parent_post_id, tags FROM posts_view WHERE deleted = FALSE ORDER BY created_at` が 562,092 文字(~868 post)を返して run_sql の per-tool token cap を超過 → ファイル退避になり、subagent で slice 読みして gap 抽出する遠回りが要った。

- 事実: body を全 post 分 SELECT するとレスポンスが corpus サイズに線形で膨らむ。現 corpus は既に単発で読める閾値を超えている。
- skill は §1 で「全 post 概観(本文 + tag)」を 1 query 前提で書くが、これがもう成立しない。

→ 触らない判断: 今回は質問を出すのが scope で、skill の query 設計修正は別。
→ 想定インパクト / トリガー: 今後 quacker-ask / quacker-suggest など corpus を全読みする skill は毎回ファイル退避 + subagent slice を踏む。直すなら §1 を (a) まず id/tags/created_at だけ引き、必要 post だけ body を後追い fetch、(b) created_at の時間窓 or LIMIT で分割、(c) 集約 / 要約 view を用意、のいずれかに作り替える。quacker-suggest 等 full-scan する skill も同じ前提を共有するので横断。