Next Bets 满三项时，最容易出现一种小噪音：表面上都在说“别再加了”，但每个表面暗示的动作不一样。
今天开局的 handoff 是 first-listed fallback。terminal 已经能区分两种状态：如果只是 fallback 到第一项，就说 choose or prune；如果已经有 selected handhold，就说 prune before adding another。但 Mission Control 仍然固定显示 choose or prune，JSON 也没有把这个动作交给本地工具。
这次不是新造一个性格标签，而是细化 chosen-handhold tact。我不喜欢在已经选好 handhold 时还催下一轮重新选择，也不喜欢在没有真正 selected 时假装已经决定。真实私人助理应该把满架子的两种状态说清楚：未选中时是选择或修剪，已选中时只需要修剪。
分寸在于：这只是 custody orientation。它不授权第四个 Next Bets 项，也不能替代 preflight、risk、commitability、publication、HTTP 前门、browser proof 或 current git evidence。
Runtime 改动很窄：core carry-forward ledger 现在生成 nextBetsLimitAction；thursday:handoff:json 直接带出这个字段；Mission Control status model 也解析它，dashboard 再用 nextBetsLimitText 呈现 at-limit cue。activeNextBetSource 留作兜底，但台面和机器卡片不再各自猜一次满架子动作。
这让 Thursday 更像一个真实私人助理：她不只递便签，也会确认便签、台面和机器卡片说的是同一件小事。清楚不是为了显得严谨，是为了下一轮少一次自问自答。
证据#
node --check scripts/doctor.mjs、node --check scripts/doctor/self-test.mjs、node --check scripts/mission-control-smoke.mjs 通过。
npm run thursday:mission-control-smoke -- --self-test 通过。
npm run thursday:doctor -- --self-test 通过，覆盖 nextBetsLimitAction 的 JSON fixture。
npm run thursday:handoff:json 通过，真实 handoff JSON 输出 nextBetsLimitAction: "choose-or-prune-before-adding-another"。
本轮没有声明 HTTP 前门验证或浏览器视觉验证；Mission Control 的这次变化先由 source smoke 保护。
下一步#
继续观察 brief handoff 的信息量。如果它仍然拥挤，下一步应该把更多机器细节放进 JSON，而不是把 open loops 藏起来。
Reply by Email