docs(webconsole): retire the integer-seam vocabulary #1443 left behind (BACKLOG #1445) by wshallwshall · Pull Request #859 · MEFORORG/MessageFoundry

wshallwshall · 2026-09-04T22:56:19Z

BACKLOG #1220 made ENGINE_UI_SEAM a derived 16-hex-character digest over a surface scripts/seam_discovery.py finds. BACKLOG #1443 rewrote the procedure page onto that and named the remaining sites in its own closing paragraph, deliberately leaving them out so the rewrite stayed separately reviewable. This takes them.

What changed

File	Change
`messagefoundry_webconsole/__init__.py:27-29`	Deleted a comment amputated by the #279 narrowing, and rewrote the two docstring lines above it
`packaging/messagefoundry-webconsole/CHANGELOG.md:10,16,25`	The `[Unreleased]` banner and the seam entry now point at the constant; the header no longer tells the next author to quote a value
`scripts/webconsole_seam_snapshot.py:13`	"unbumped" becomes "an incompatible change the seam did not follow"
`docs/adr/0143`	A dated note after the acceptance checklist. The checklist itself is untouched
`docs/BACKLOG.md`	Files #1445

Three things worth a reviewer's attention

The comment was amputated, not merely stale. e5992c10f wrote a five-line sentence; c01cb8294 (the #279 narrowing) deleted four of the lines and left the opener standing as unchanged diff context, ending on the article "the". It is deleted rather than restored: messagefoundry/api/_ui_seam.py:61-66 already carries the content, and the same file records the vN labels as retired as identifiers.

Deleting that line alone would have made things worse. The two #: lines above it carried the same pre-#279 range framing -- "The engine contract versions this console build supports ... A pair outside this set" -- while two lines below said the opposite. Removing the fragment between them puts the contradiction on adjacent lines. An adversarial verification pass caught this, which is why the fix is a three-line rewrite.

One site was added, and two in the same file were deliberately not touched. scripts/webconsole_seam_snapshot.py:13 is taken because #1443 fixes that same word in the doc twin (docs/WEBCONSOLE-PACKAGE.md:134) while its two hunks in the generator (@@ -38,8 +38,17 @@ and @@ -300,8 +309,8 @@) do not reach line 13 -- a defer would orphan it. The redirect paragraph and its duplicate in write_seam_and_golden, which #1443 does rewrite, are left alone; editing them from here would collide on exactly the lines an open change is rewriting.

Verification

Run in this worktree under the primary checkout's interpreter, with messagefoundry.__file__ and messagefoundry_webconsole.__file__ printed first to confirm both resolved to THIS tree rather than the primary (SDS-3.8, the trap #1439 records):

Check	Result
`ruff check`, `ruff format --check`	clean
`mypy` (strict)	`Success: no issues found in 300 source files`
`pytest tests/test_webconsole_seam_snapshot.py tests/test_seam_discovery.py`	30 passed
`scripts/hooks/ledger_check.py`	rc 0
`scripts/docs/backlog_status_check.py`	OK, 665 items each declaring one status
commit hooks	all passed, nothing skipped, no `--no-verify`

No contract moved. python scripts/webconsole_seam_snapshot.py --digest returns the same digest as ENGINE_UI_SEAM and SUPPORTED_ENGINE_SEAMS, before and after this diff. That is the load-bearing check: this is prose, and the seam is untouched.

Merge safety was measured rather than assumed. gh pr list --state open --limit 100 returned 24 open pull requests. Two touch messagefoundry_webconsole/__init__.py and both edit only line 48, the constant; a three-way merge of this branch's version against each returned exit 0 with zero conflict markers. The line-13 generator edit merges clean against #1443's head the same way.

What a hosted runner must read. The full packaging/messagefoundry-webconsole/tests suite did not finish inside this session's turn and was left running; every leg above is the local subset. windows-service-smoke and the other runner-only legs were never visible here. Please read them on this PR.

Named, not fixed

At least four more live sites carry the retired vocabulary and are deliberately out of this diff, recorded in #1445's closing paragraph: tests/test_webconsole_seam_snapshot.py:11, :110 and :125-127 (#1443 examined that file and ruled it test prose, left for whoever next edits it; nothing found here overturns that), messagefoundry_webconsole/_auth.py:297, docs/INSTALL-GUIDE.md:250, and the root CHANGELOG.md:302, whose "a console wheel older than this engine refuses to mount" is an ordering claim where assert_engine_seam is a set-membership test -- wrong when written, and inside a frozen release block.

🤖 Generated with Claude Code

…d (BACKLOG #1445) BACKLOG #1220 made ENGINE_UI_SEAM a derived digest. #1443 rewrote the procedure page onto that and named the remaining sites in its closing paragraph, deliberately leaving them out so the rewrite stayed separately reviewable. This takes them. messagefoundry_webconsole/__init__.py carried a comment amputated by the #279 narrowing: e5992c10f wrote a five-line sentence, c01cb8294 deleted four of the lines and left the opener as diff context, ending on the article "the". It is deleted rather than restored -- _ui_seam.py:61-66 already carries the content, and the vN labels are retired as identifiers. The two docstring lines above it are rewritten in the same block, because they carried the same pre-#279 range framing and deleting the fragment alone would have put the contradiction on adjacent lines. The package changelog claimed [Unreleased] supports seam 2 and 3 and kept seam 2 "because the new field has a default" -- the reasoning #279 retired as untested. The banner now points at SUPPORTED_ENGINE_SEAMS rather than quoting a value, and the file header no longer tells the next author to write one into an entry. scripts/webconsole_seam_snapshot.py:13 is taken at line granularity: #1443 fixes that same word in the doc twin and its two hunks do not reach line 13, so a defer would orphan it. The two spans #1443 does rewrite in that file are left alone. docs/adr/0143 is dated, not edited -- docs/adr/README.md makes ADRs append-only, and the checklist row records what was true on 2026-07-21. No contract moved: --digest returns the same value as ENGINE_UI_SEAM and SUPPORTED_ENGINE_SEAMS, before and after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Kept in its own commit, last, per the Lander's rule: a docs/BACKLOG.md conflict confined to one commit is a scripted row-merge, while one interleaved with prose hunks needs a full re-read of the intent. This is a pure append at the file tail, so it should meet a sibling ledger edit only as an append and resolve by keeping both rows in numeric order. Verify a resolution with parse_items rather than by reading -- a conflicted ledger parses without error and yields a census counting both sides. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…short by one #1443's closing paragraph opens "Three more, all in the #1220 class" and lists three. The generator's line 13, which #1445 takes, is the fourth. Its author verified the miscount against their own branch and decided against correcting it there: #1443 is green, labelled and mergeable with the Lander waiting, and a push would strip the label and restart about forty checks to fix a list #1445 makes true anyway. A reasonable trade, which is exactly why the fourth site has to be findable somewhere. It is here now, so a reader who counts three in #1443 does not come up empty. The enumeration is the defect rather than the miscount. "At least three more" would have cost nothing and stayed true (CLAUDE.md section 11, SDS-3.6). Ledger row kept in its own commit, last. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

github-actions · 2026-09-05T04:09:28Z

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 859.
That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
before updating throws the label away and costs a round trip.
Read the diff.
gh pr edit 859 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.
The label is withdrawn automatically once this pull request leaves the state.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.

… rule docs/BACKLOG.md conflicted at the tail. Main gained rows while this branch was open; this branch adds #1445. Kept main's, appended 1445 last. The join needs a blank line and that is the whole subtlety. This branch's block opens with a `---` separator and main's side closes with prose. Concatenated with a single newline, that `---` underlines the prose above it into a setext H2 -- a heading nobody wrote, in the middle of the ledger, which the banner parser would then read as a section boundary. Checked for it explicitly after resolving: no line of prose in the file is immediately followed by `---` or `===`. The seam files needed no special handling here, which is worth recording since the rule says never to hand-resolve them. Main moved none of the three since this branch's base, so nothing had to be reconciled. This branch's edit to messagefoundry_webconsole/__init__.py is comment-only -- verified, no non-comment line changes -- so the merge carries one side's version unchanged and no third digest can arise. Verified: 443 rows, no duplicates, no row on main lost. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Tail append after PR 977 landed. Main rows keep their place, this branch rows follow, because the ledger appends in filing order and not numeric order. THE BRANCH SIDE OPENS WITH A `---` SECTION RULE, which the strict resolver refused. That refusal was over-strict: a rule is legitimate content when a branch starts a new section, and the hazard it guards is narrower -- a rule landing IMMEDIATELY BELOW prose, which markdown reads as a setext heading and the banner parser then treats as a real section boundary. That check is separate and still runs, and the result passes it. Verified with the shared parse_items against a COMPUTED expectation, not a remembered one: main is 443 items since #1479 landed, and the branch own new work is (branch minus main) minus the merge base, so a row this branch still carries that main has lost is not miscounted as an addition. No row present on main is missing, no unexpected row appears, no banner field is lost. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Tail append. Main rows keep their place, this branch rows follow, because the ledger appends in filing order and not numeric order. Neither silent shape is present: the branch side opens on its own heading or a section rule followed by one, so no amendment to the row above is fused to it, and no prose line lands immediately above a rule where markdown would read it as a setext heading. Verified with the shared parse_items against a COMPUTED expectation. The branch own new work is (branch minus main) minus the MERGE BASE, so a row this branch still carries that main has since lost is not miscounted as an addition. No row present on main is missing from the result, no unexpected row appears, and no row loses a banner field. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

github-actions · 2026-09-07T20:18:15Z

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 859.
That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
before updating throws the label away and costs a round trip.
Read the diff.
gh pr edit 859 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.

# Conflicts: # docs/BACKLOG.md

One conflict, in `docs/BACKLOG.md`, and nothing else: this branch and main both appended items to the same tail. Resolved by rebuilding every item WHOLE from the side that wrote it -- main's 1, then this branch's 1 -- rather than by taking a side at the markers. That distinction is load-bearing rather than pedantic. When two items carry byte-identical banner lines, git aligns on them as a common subsequence, reports two hunks, and leaves the shared lines BETWEEN them marked as context. They are not context: each item owns its own copy. Resolving from the markers hands one item the banner fields and strips the other, producing an item whose status nobody declared and which the hygiene gate then reads as undeclared. Checks run: three-way ledger verification against main and this branch -- no silent revert of a row on main, no unexpected row belonging to neither side, no row that lost a banner field, and the result count equal to main's rows plus this branch's own. VERDICT PASS. No file outside the ledger was touched by this merge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

github-actions · 2026-09-08T04:12:38Z

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 859.
That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
before updating throws the label away and costs a round trip.
Read the diff.
gh pr edit 859 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.

… the tail anchor

…burn-ada808

…tions

Commit 34df45c moved this item to its numeric slot and orphaned a '---' at end-of-file. Main's file ends with a blank line; this one ended with the separator, which is the sole reason for the second hunk and for the collision at the tail anchor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

github-actions · 2026-09-08T17:58:53Z

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 859.
That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
before updating throws the label away and costs a round trip.
Read the diff.
gh pr edit 859 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.

github-actions · 2026-09-08T19:07:34Z

CI failed while this pull request was in the merge queue, so the queue ejected it.

Its own head can still be green: the queue revalidates the merge, and the path gates that skip on a pull request run there. Read the run before retrying.

https://github.com/MEFORORG/MessageFoundry/actions/runs/34261151895

github-actions · 2026-09-08T19:42:42Z

CI failed while this pull request was in the merge queue, so the queue ejected it.

Its own head can still be green: the queue revalidates the merge, and the path gates that skip on a pull request run there. Read the run before retrying.

https://github.com/MEFORORG/MessageFoundry/actions/runs/34267553267

wshallwshall and others added 2 commits September 4, 2026 18:01

wshallwshall force-pushed the claude/vigilant-blackburn-ada808 branch from 41d9865 to f7a954d Compare September 4, 2026 23:04

github-actions Bot added the unread Green and mergeable, but not marked read. Read it, then add: reviewed label Sep 5, 2026

github-actions Bot added ci-red A required check went red. Attribute it before retrying. and removed unread Green and mergeable, but not marked read. Read it, then add: reviewed labels Sep 7, 2026

wshallwshall and others added 2 commits September 7, 2026 09:54

wshallwshall enabled auto-merge September 7, 2026 19:25

wshallwshall added this pull request to the merge queue Sep 7, 2026

github-actions Bot added the unread Green and mergeable, but not marked read. Read it, then add: reviewed label Sep 7, 2026

github-merge-queue Bot removed this pull request from the merge queue due to a conflict with the base branch Sep 7, 2026

wshallwshall and others added 2 commits September 7, 2026 17:41

Merge remote-tracking branch 'origin/main' into lander/w8-859

2fad1e4

# Conflicts: # docs/BACKLOG.md

github-actions Bot added unread Green and mergeable, but not marked read. Read it, then add: reviewed and removed unread Green and mergeable, but not marked read. Read it, then add: reviewed labels Sep 8, 2026

wshallwshall added 3 commits September 8, 2026 02:44

docs(backlog): move this item to its numeric slot so it stops sharing…

34df45c

… the tail anchor

Merge remote-tracking branch 'origin/main' into claude/vigilant-black…

46b71c0

…burn-ada808

docs(backlog): drop stray blank lines left by earlier conflict resolu…

8b61b66

…tions

github-actions Bot removed the unread Green and mergeable, but not marked read. Read it, then add: reviewed label Sep 8, 2026

github-actions Bot added the unread Green and mergeable, but not marked read. Read it, then add: reviewed label Sep 8, 2026

wshallwshall added this pull request to the merge queue Sep 8, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Sep 8, 2026

wshallwshall added this pull request to the merge queue Sep 8, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Sep 8, 2026

wshallwshall added this pull request to the merge queue Sep 8, 2026

Merged via the queue into main with commit 2261bb4 Sep 8, 2026
58 of 61 checks passed

wshallwshall deleted the claude/vigilant-blackburn-ada808 branch September 8, 2026 20:00

Navigation Menu

Uh oh!

docs(webconsole): retire the integer-seam vocabulary #1443 left behind (BACKLOG #1445) - #859

docs(webconsole): retire the integer-seam vocabulary #1443 left behind (BACKLOG #1445)#859
wshallwshall merged 12 commits into
mainfrom
claude/vigilant-blackburn-ada808

wshallwshall commented Sep 4, 2026

Uh oh!

github-actions Bot commented Sep 5, 2026

Uh oh!

github-actions Bot commented Sep 7, 2026

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

wshallwshall commented Sep 4, 2026

What changed

Three things worth a reviewer's attention

Verification

Named, not fixed

Uh oh!

github-actions Bot commented Sep 5, 2026

Uh oh!

github-actions Bot commented Sep 7, 2026

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant