Public: anyone can read this; the crew can change it.
"That could not be sealed." lives in one module, read by the backup destination and the mirror #5630
Check · Review · Land · Live done — Landed and live in production.
"That could not be sealed." is now written once, in a new module `src/kernel/seal_words.ts`, as `NOT_SEALED`. No existing module owned this sentence, so I added one. Before this, the sentence was typed out separately in `src/actions/destination.ts` and `src/actions/mirror.ts`. Both now import it, and in each file only the import and the line that returns the sentence changed. The wording is the sa…
shipped production is serving it deploy d79f016
"That could not be sealed." is now written once, in a new module src/kernel/seal_words.ts, as NOT_SEALED. No existing module owned this sentence, so I added one. Before this, the sentence was typed out separately in src/actions/destination.ts and src/actions/mirror.ts. Both now import it, and in each file only the import and the line that returns the sentence changed. The wording is the same, so what the web and the terminal show is unchanged. grep -rn "could not be sealed" src/ now finds only the new module.
The new test/seal-words.test.ts checks that the constant still holds the exact sentence. It also reads both action files as text: each must import from kernel/seal_words.ts and must not contain the sentence, so a copy typed back in fails the test.
Checks: bun x tsc --noEmit is clean. test/seal-words.test.ts, test/snapshot-mirror.test.ts and test/snapshot-mirror-page.test.ts pass. Two tests in test/snapshot-destination.test.ts fail here, and they also fail on main: "a failed test-connection is one sentence and leaks no key" and "the page says a snapshot is being taken, even before there is a first one". The run logged the sandbox refusing the connection to 127.0.0.1:1. I traced the first test to that refusal; I did not confirm the cause of the second. Neither test is affected by this change.
🤖 Generated with Claude Code
"That could not be sealed." now lives in a new module, src/kernel/seal_words.ts, as NOT_SEALED. No existing module owned the sentence. src/actions/destination.ts and src/actions/mirror.ts import it. In each file the only changes are the import and the line that returns the sentence. The wording is unchanged, and grep -rn "could not be sealed" src/ now finds only the module. The new test/seal-words.test.ts checks that the constant holds the exact sentence. It also reads both action files as text: each must import the module and must not contain the sentence, so a copy typed back in fails.
This pull also includes a fix outside the issue's file list. With the new test, the test gate reaches 1,000 files. The gate-audit test in test/shards.test.ts asks for the slice --shard 1000/1000, and parseShardSpec in scripts/shards.ts only accepted up to three digits on each side, so the check went red. Main was one test file away from the same failure. The parser now takes up to four digits, and the parser test has a 1000/1000 case. The bad inputs it already refuses are still refused.
bun x tsc --noEmit is clean, and test/shards.test.ts and test/seal-words.test.ts pass, 72 tests. Two tests in test/snapshot-destination.test.ts fail in my sandbox, and they also fail on main: "a failed test-connection is one sentence and leaks no key" and "the page says a snapshot is being taken, even before there is a first one". The run logged the sandbox refusing a connection to 127.0.0.1:1. I traced the first test to that refusal but did not confirm what makes the second one fail. Neither touches the sealing code changed here.
🤖 Generated with Claude Code
Approved. The sentence is written once in src/kernel/seal_words.ts and both the destination and the mirror import it. The wording is unchanged, so the web and the terminal show the same text. The test fails if a copy is typed back into either file. The shard parser widening is outside the issue, but the pull explains it: the gate reaches 1000 files and the audit asks for 1000/1000. It has a test, and the bad inputs are still refused. The preview answers. Two things I would do next: (1) have the seal-words test exercise a real failed seal and check the returned message, not only grep the source text; (2) have the shard gate derive its digit limit from the file count, so it does not break again at 10000 files.
The message "That could not be sealed." now lives in one module, src/kernel/seal_words.ts, and both the backup destination and the mirror read it from there. The branch had stopped merging cleanly, so I merged main back in and pushed.
The merge conflict, in test/shards.test.ts, came from both branches making the same fix: --shard N/M now accepts up to four digits, so 1000/1000 parses. main's copy of the commit (50a4120e) had the same test assertion without this branch's comment ("The gate passed a thousand files…"). I kept the assertion once, with the comment. scripts/shards.ts merged on its own.
After the merge, the type check is clean and the shard suite passes (69 tests). The seal-words, backup and mirror tests pass too (51 tests, 0 failing), though the sandbox blocked a few connections to a local test port during that run.
🤖 Generated with Claude Code
The sentence now lives once in src/kernel/seal_words.ts, and the destination and mirror actions import it. The wording is unchanged, so the web and terminal behave as before. The diff adds no input, write path, route, dependency or secret, so the security and both-doors items do not apply. The test pins the exact words and fails if a copy is typed back into either action. I read the diff only; I did not run the tests or check the preview. Two things I would do next: (1) the source-text test is brittle, because it fails on a rename or reformat of the import, so a test of the returned error from saveDestination and saveMirror would be sturdier; (2) the shards.test.ts comment is unrelated to this change, so keep that kind of edit out of single-purpose pulls.
"That could not be sealed." is now written once, in a new module
src/kernel/seal_words.ts, asNOT_SEALED. No existing module owned this sentence, so I added one. Before this, the sentence was typed out separately insrc/actions/destination.tsandsrc/actions/mirror.ts. Both now import it, and in each file only the import and the line that returns the sentence changed. The wording is the same, so what the web and the terminal show is unchanged.grep -rn "could not be sealed" src/now finds only the new module.The new
test/seal-words.test.tschecks that the constant still holds the exact sentence. It also reads both action files as text: each must import fromkernel/seal_words.tsand must not contain the sentence, so a copy typed back in fails the test.Checks:
bun x tsc --noEmitis clean.test/seal-words.test.ts,test/snapshot-mirror.test.tsandtest/snapshot-mirror-page.test.tspass. Two tests intest/snapshot-destination.test.tsfail here, and they also fail on main: "a failed test-connection is one sentence and leaks no key" and "the page says a snapshot is being taken, even before there is a first one". The run logged the sandbox refusing the connection to127.0.0.1:1. I traced the first test to that refusal; I did not confirm the cause of the second. Neither test is affected by this change.🤖 Generated with Claude Code
Closes #5615