短暂与仅追加优先于有状态存储

上级: structure

代码库中反复出现的一种品味：能派生或追加的可变状态，就不要保留。

• 语料库路径由目录树派生得到（derived-path-corpus-as-filesystem），而不是被存储
• 简历 PDF 从不写入磁盘——由 gotenberg 在打印时按需渲染（schema.sql 在 resume_drafts 旁边就是这么写的；打印载荷只在 Redis 里放 60 秒，owner/jobs/printsess/store.go）。自 1b1ebed2b（2026-09-07）起，编辑器和打印页由同一份 Puck 配置渲染，所以不只没有文件，渲染器也只有一个
• 抓取到的职位从不进入数据库——它存放在 Redis 中（1 天 TTL，owner/jobs/jobs.go），只有在创建草稿或投递时才被快照进去
• 配额是仅追加的账本——内核那张 code_bookings 表已随 #135 退役（f376b0432，2026-07-25）；现在每个能力在自己的隔离存储里用 capquota.Counter 实时计数（internal/capabilities/capquota/capquota.go，aab8abe90，2026-08-01）。仍然不减、不衰减、没有竞态——只是账本换了地方
• 对话从不"结束"——摘要只是一份可重新生成的、仅追加的 chat_reports 产物

这与 deployment 的读多写少 / 单写者形态相契合：派生或追加，而不是维护可变的行。