docs(engagement): the two walk defects, fixed -- and what digest is

Follows docs#203, which recorded the two defects Phase 13's acceptance walk found
and left them for placing. They are fixed in website#181, so Phase 13's as-built
says so and says what the fix was rather than leaving a reader to find the PR.

Two other files were describing a contract the code did not honour, which is why
the second defect could exist at all:

  * BACKEND_DESIGN's `template_keys` column row said only that keys are
    shape-checked. It now says the one thing that was actually load-bearing --
    `digest` is a key that is NOT a channel, because it names a MODE's body --
    and that the rules validator rejected it until website#181, which made every
    rule shipping one unsaveable from the Rules screen, core's own included.
  * MODULE_API 2.4 already told modules they may point `template_keys` at
    `notify.digest` and never said what `digest` was. A module author reading it
    would reasonably have expected it to be a channel. One bullet, next to the
    generic-bodies one that sends them there.

No contract changed; the docs were right and the code was wrong. No
MODULE_API_VERSION bump for the same reason.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2026-09-01 14:31:00 -05:00
parent 924204f8ba
commit b3dd2c7cbb
3 changed files with 13 additions and 3 deletions

View File

@@ -3852,8 +3852,15 @@ is the Phase 11b defect class staying fixed.
key they never typed. The only way to save is to delete the digest body, which silently removes
digest support from that rule. The two validators have to agree about what `digest` is.
Neither is fixed here: this phase's PR is the documentation of a cutover, and a core change belongs
in its own. Both are recorded for the org lead to place.
**Both are fixed in website#181.** `settings.db` gained `claim(key, value)` — the same
`INSERT IGNORE` as `seedDefault`, reporting its own `affectedRows`, so exactly one caller can win a
key — and both seeders now claim before inserting rather than stamping after. The trade the code
already documented is unchanged, only its order: a process that dies mid-loop leaves the group
stamped and partly seeded, which both functions already called the better failure. The stubs are
`claim`-shaped now and each suite gained a test that runs two seeders under `Promise.all`; reverting
the fix makes the module one report every rule inserted twice, which is how the fix was checked. And
`engagementRules.model.js` now admits `digest` as the one key that is a slot rather than a channel,
so the two validators agree; anything else is still refused, with a test in each direction.
**Also still open:** nothing else. `.profile/README.md` (step 8) landed — the org lead called the
engagement system a headline capability — and Phase 12's second finding became **Phase 14**.