The reviewer caught two pieces of both-seams drift left over after the bash
get()/list() removal was reverted to a persistence-only change.
- docs/rfc/README.md: rename the index row from "persistence and bash seams" to
"Prune dead methods from the persistence seam" so it matches the RFC title and
the actually-shipped scope (verify-rfc-classification only checks the path is
indexed, so this prose slipped the gate).
- The implemented RFC body still read like the original both-seams proposal
(the "Two capability seams" framing, a `### BashExecutor.get()/.list()` problem
section, a bash removal bullet in the Proposal, and current-source links that
imply bash get/list were removed). Rewrite the body into the durable
decision-record form: Problem/Proposal/criteria/risks now describe only the
persistence has()/delete() removal that shipped, and the bash reasoning (why
get()/list() earn their keep — a ~35-line test-harness migration cost makes the
test consumer a real consumer) is folded into the top decision note as
"considered and deliberately kept", not as a shipped change. Drop the stale
bash source-line refs; keep the persistence consumer links pointing at current
code (agent-loop load, ACP session/list).
Tianyi Cui
00d7646558