[Birfy]

The owner pressed Always allow for this Bot and the same permission card came back. Root cause: standingCovers (core/src/host/approvals.js) only honoured a grant when settled(rt, sessionId) === OWNER; a turn that carries no message verdict settles to undefined, so the grant was skipped and the card re-appeared. DSH opens exactly such a turn for its own retry after an approval answer.

复现

In the group-status harness: grant always-bot from a group card, then open the Bot's own-chat turn the way DSH retries after an answer — no message, or only a host notice — and ask for the same kind:

git show 81c708d054f43c90fd201ae3a281fd2e8e8916e7:core/src/host/approvals.js > core/src/host/approvals.js   # main source, new tests kept
DSH_HARNESS=/opt/flybot node --import ./core/test/harness-resolve.mjs --test core/test/group-status.test.js
# not ok 13 - #608: an own-chat turn that carries no verdict still honours the Bot grant
# tests 17 / pass 16 / fail 1

改了谁

• core/src/host/approvals.js: standingCovers now also answers a turn with no verdict in the Bot's own chat (rt.chatOwners.get(sessionId) === botId) — nobody's request is in that turn. A friend's message, another member's line or a room with other people in it still asks (verdict other). A grant a turn cannot use is no longer skipped silently: the first such ask per session and kind logs the standing approval for <kind> was not used: the turn is … (bounded set, 200).
• core/test/group-status.test.js: the red test above, plus a restart test that reopens the same home with a fresh runtime and asserts the grant still answers (persistence guard; passes on main too — the defect is the verdict gap, not the store).
• patches/ds-bot/0001-core-fixes.patch: regenerated with node scripts/ds-bot-patches.mjs generate.
• docs/subsystems/core-host.md: the grant rule and the skip line.
• changelog.d/608-always-allow-own-chat-turn.fixed.md.

安全面：权限 grant 的适用范围（请按这段核）

这个 PR 动的是审批 grant 的适用范围，不是授权规则本身。逐条边界：

场景	修复前	本 PR 之后
本人（owner）在自己 Bot 的私聊里发起的 turn，有 verdict	grant 生效	grant 生效（不变）
同一个本人 Bot 的私聊，但 turn 没有 verdict（DSH 批准后自开的重试 turn）	grant 被跳过 → 卡片又回来（缺陷）	grant 生效
turn 里带别人的话语（verdict other：好友、另一个成员、另一个 owner 的 Bot）	要问	仍然要问（不变）
shared Bot 的 scheduled turn（settled 映射成 other）	要问	仍然要问（不变）
权限卡本身、密钥、共享/发布、authz.js 的 owner 规则	—	未改

判定条件写死在 standingCovers 里：只在 rt.chatOwners.get(sessionId) === botId（这个私聊属于这个 Bot 自己）且该 turn 无 verdict 时才算覆盖；任何带 verdict 的 turn 走原来的分支，因此 other 一律照旧要问。测试 #608: an own-chat turn that carries no verdict still honours the Bot grant 覆盖前者；同文件里既有的 other 用例覆盖后者，未改动、仍绿。

给 Chief 的说明：这属于安全面（grant 扩大），已由实现 Lead 转报。范围仅限上表第二行；不新增配置项，不改存储格式，不触碰 secret/sharing/authz。

跑了什么

• core/test/group-status.test.js 17/17, member-status 9/9, inbox 19/19, authz 18/18, turn-origin 3/3, turn-reasoning 4/4, turn-tail 9/9, rounds 38/38 (each with DSH_HARNESS=/opt/flybot --import ./core/test/harness-resolve.mjs).
• node scripts/ds-bot-patches.mjs check → ok (pin v0.1.5, 10 patches, core/ equals ds-bot/ + patches).
• node .github/scripts/changelog.mjs check → 20 fragments well formed.
• core/scripts/lint.mjs → oxlint 0 errors / 43 warnings (same warnings as main); check-arch-docs → OK (5 changed files).

撤掉源码改动后变红

git show <base>:core/src/host/approvals.js > core/src/host/approvals.js
DSH_HARNESS=/opt/flybot node --import ./core/test/harness-resolve.mjs --test core/test/group-status.test.js
# not ok 13 - #608: an own-chat turn that carries no verdict still honours the Bot grant
# tests 17 / pass 16 / fail 1

Restored: # tests 17 / pass 17 / fail 0.

没跑什么

core 全量一次性（本容器 pid 上限 256）、三个插件套件、smoke、真机、完整 npm run verify；CI 在 tip 上跑 tests-ok。

风险

Permission surface: the owner's standing approval now also answers a verdict-less turn in their own Bot's chat; every turn carrying someone else's request still asks. (risk:T* is computed by the report-only workflow; not hand-set.)

Fixes #608

[Birfy]

Verdict: PASS at 2ca04f6 — 仅记录、等用户确认；权限面改动，我不入队、不合并。

Tip SHA: 2ca04f636551b3fafdb8801368e923b11bdedb83
CI at tip: all 8 checks success (tests-ok, package, plugins social/tree/timeline,
           ubuntu-latest Node 24, reviewed tip, risk tier)
Tier (from the diff): T3 — core/src/host/approvals.js is a T3 path in
           .github/agent/risk-rules.json (the controller is report-only, so this is read
           from the rules, not from a label)

Both directions reproduced locally at this tip, not inferred from CI:

$ cd core && TZ=UTC DSH_HARNESS=… node --import ./test/harness-resolve.mjs --test test/group-status.test.js
# tests 17 / pass 17 / fail 0

$ # approvals.js restored from base 81c708d0, new tests kept
not ok 13 - #608: an own-chat turn that carries no verdict still honours the Bot grant
# tests 17 / pass 16 / fail 1

Exactly the one new test goes red, and only it — gate ③ holds. The restart test passing on both sides is honest: the defect is the verdict gap, not the store.

I checked the new predicate against the store instead of assuming:

• ownChat() reads rt.chatOwners, which store.js fills only from a Bot's own-chat session (chatOwners.set(chatOf(bot.id), bot.id)); group Sessions go to groupOwners and earlier segments to pastOwners. So the widened clause cannot fire in a room, a group Session or an archived segment — those still ask.
• settled() still returns 'other' first for a friend's line, another member's line and a shared Bot's scheduled turn, so the grant stays off there. The test's fourth case (a remote friend's message in the own chat) pins that.
• The skip log is bounded (clears past 200) and writes one line per session+kind, so a grant that cannot be used is no longer silent.

One note for the owner, not a blocker: turn-origin.js documents "The caller treats none as 'other' (fail closed)", and originOfSource() returns undefined both for DSH's own notices and for any source kind it does not recognise (default:). After this change, a verdict-less turn in the owner's own chat applies the grant — correct for the retry turn DSH opens after an answer, but it also means an unrecognised future source kind arriving in a Bot's own chat would be covered by a standing approval instead of failing closed. Suggested follow-up, separate from this PR: either update that turn-origin.js header, or narrow the clause to turns with no message at all.

Ready to merge on the owner's word; not queued by me.

[Birfy]

Verdict: PASS at 2ca04f6 — owner approved 2026-10-21, merging.

The review above stands unchanged (tip 2ca04f63, 8/8 checks green, 17/17 with the fix, 16/17 with approvals.js reverted). This line only removes the earlier caveat that held it back until the owner answered: the owner has authorised this permission-surface change, so it now goes into the merge queue (squash, expectedHeadOid pinned to the tip above). No re-review, no new findings.

[Birfy]

Owner decision (2026-10-21): merge. Relay: Chief. This is the only status note on this PR from here on.

PR checks: Verdict: PASS at 2ca04f63 (Reviewer, record-only pending this owner confirmation), 8/8 checks green, group-status 17/17 and approvals.js reverted to 81c708d0 leaves exactly the #608 case red (16/17). Scope stays narrow: own-chat turns with no verdict only.

Follow-up (same round): fail-open on unknown source kind in turn-origin.js must be filed as its own issue and fixed right after #615.

Enqueued by: Chief (owner proxy — Reviewer session unavailable).

[Birfy]

Post-merge record (reviewer)

• Merged: 9f3aa7da (squash, via the merge queue; main tip now 9f3aa7da).
• Reviewed tip: 2ca04f63 — unchanged between review and queue, so the PASS stands.
• Closure: Fixes Always allow does not persist: the same permission card comes back after approval #608 is complete — Always allow does not persist: the same permission card comes back after approval #608 is closed as completed by this merge, and the gate evidence is the one in the review above (17/17 with the fix, not ok 13 with approvals.js reverted).
• Follow-up, separate issue: turn-origin: an unrecognised source kind in a Bot's own chat counts as the owner (fail-open left open by #616) #620 (an unrecognised source kind in a Bot's own chat now reaches the owner path instead of failing closed). Not a blocker for this PR; it is the residual hole the turn-origin.js header promises is closed.