HOMELAB-2682: fix(forgejo): '**Blockers**: none.' negates like the plain form #103

Merged

pi-landing merged 1 commit from plane/HOMELAB-2682-bold-negation into main 2026-11-05 23:42:02 +00:00

Conversation 3 Commits 1 Files changed 2 +222 -1

pi-landing commented 2026-11-05 23:24:43 +00:00

Collaborator

Copy link

The refusal (gits-hypervisor, verbatim)

A seat's 'Blockers: none.' counts as an open blocker finding, because bold breaks the negation pattern; unbolded 'Blockers: none.' negates. It refused GITS #204 at 23:06:58Z on a clean approval.

The seat wrote the same empty statement the fleet already negates, in the bolded prose every reviewer writes. Leg 4 read the markup as prose, so a clean approval became one open, id-less finding — and an id-less finding can never be closed, so the PR was unlandable for a typographic reason (same class as the wrapped denial in HOMELAB-2586 and the predicate in HOMELAB-2595).

Cause: isNegated tested BLOCKER_NEGATED_PATTERNS against the raw line. The empty-statement arm is

blockers?\s*(?:findings?)?\s*[:=]\s*(?:none|no|n\/a|0|zero)\b\s*(?:open|remain\w*)?\s*[.!;]?\s*$/i

which needs [:=] immediately after blockers? (modulo whitespace). In **Blockers**: none. the next character is *, so the pattern never fires, while ^[\s>*\-•]*(?:\*\*|__)?…blockers?\b still recognises the line as a finding shape. Emphasis is markup, not punctuation, and it is now treated as such.

Failing-test confirmation (unit streams only, no real PR)

Measured against main at e9b02a3 (includes the merged #99/#100/#102), with tests/landing-bold-negation.test.ts: 14 failed / 19 passed.

Line	before	after
**Blockers**: none.	FINDING	negated
**Blockers:** none.	FINDING	negated
**blockers**: none	FINDING	negated
**Blocker**: none.	FINDING	negated
**Blockers**: N/A.	FINDING	negated
**Blockers**: 0 open.	FINDING	negated
**Blockers: none.**	FINDING	negated
*Blockers*: none.	FINDING	negated
**Blockers**: none	FINDING	negated
__Blockers__: none.	0	0 (was not a finding shape: \b after Blockers fails before __)
_Blockers_: none.	0	0 (same: the leading _ was never a finding lead)
**No blockers** / **Zero blockers**	0	0
Blockers: none. (plain control)	0	0

The fix

One helper, one call site. withoutEmphasis removes *, **, ***, _, __, ___ where they adorn a word, before BLOCKER_NEGATED_PATTERNS run, so the emphasized line is the plain line and every existing pattern reads both identically. Nothing was added to what counts as a negation:

• intra-word runs (snake_case, REQUEST_CHANGES) are kept verbatim;
• backticks and HTML are not stripped (unlike plainText) — `Blockers: none` is a quoted shape and reading it as a negation would be a widening, not an emphasis fix;
• the soft-wrap's previous line is still read verbatim (HOMELAB-2595: a trimmed ** became the very boundary WRAPPED_NEGATION_HEAD_RE looks for), so a bolded wrap head stays out of scope here;
• what makes a positive finding (BLOCKER_FINDING_PATTERNS, the section grammar, the documentation guards) is untouched.

Near-miss guards (must stay findings — pinned)

Line	result	why
**Blockers**: one — the auth check is open	FINDING	content after the label
**Blockers**: none worth mentioning	FINDING	"none worth mentioning" is not an empty statement; the arm requires end-of-line after the zero word
**Blockers**: none worth mentioning — the auth check is open	FINDING	same
**Blockers**: none, and the auth check is still open	FINDING	same
**Blocker**: none of the callers pass ctx	FINDING	a finding whose text starts with "no", not a count of zero
**Blocker B1**: tenant scoping is missing	FINDING	labelled finding
**Blockers** — none.	FINDING	parity guard: the plain form is a finding too (no :/= vocabulary), so emphasis must not invent a negation

Suite

• checkout shape (CI): npm run typecheck clean, npm test → 29 files / 774 tests passed
• deployed shape (TESTING.md): npm run test:deployed → 29/29 files loaded and passed, 774/774 tests
• new suite: tests/landing-bold-negation.test.ts → 33 tests (13 variants, 10 parity pairs, 7 near-miss guards, 3 evaluateLandingLock end-to-end including the GITS #204 approval shape and the same approval carrying a real bolded finding)

Out of scope (recorded, not implemented)

gits-hypervisor also asked what stops an orchestrator from dictating parser-shaped lines to a seat. That is an enforcement-design question (a verdict line a seat composes itself vs. one it is handed), belongs to the homelab-cb / Aaron design session, and is out of scope for this PR — this PR only makes the parser read the prose a seat writes.

## The refusal (gits-hypervisor, verbatim) > A seat's '**Blockers**: none.' counts as an open blocker finding, because bold breaks the negation pattern; unbolded 'Blockers: none.' negates. It refused GITS #204 at 23:06:58Z on a clean approval. The seat wrote the same empty statement the fleet already negates, in the bolded prose every reviewer writes. Leg 4 read the markup as prose, so a clean approval became one open, **id-less** finding — and an id-less finding can never be closed, so the PR was unlandable for a typographic reason (same class as the wrapped denial in HOMELAB-2586 and the predicate in HOMELAB-2595). Cause: `isNegated` tested `BLOCKER_NEGATED_PATTERNS` against the **raw** line. The empty-statement arm is ``` blockers?\s*(?:findings?)?\s*[:=]\s*(?:none|no|n\/a|0|zero)\b\s*(?:open|remain\w*)?\s*[.!;]?\s*$/i ``` which needs `[:=]` immediately after `blockers?` (modulo whitespace). In `**Blockers**: none.` the next character is `*`, so the pattern never fires, while `^[\s>*\-•]*(?:\*\*|__)?…blockers?\b` still recognises the line as a finding shape. Emphasis is markup, not punctuation, and it is now treated as such. ## Failing-test confirmation (unit streams only, no real PR) Measured against `main` at `e9b02a3` (includes the merged #99/#100/#102), with `tests/landing-bold-negation.test.ts`: **14 failed / 19 passed**. | Line | before | after | |------|--------|-------| | `**Blockers**: none.` | **FINDING** | negated | | `**Blockers:** none.` | **FINDING** | negated | | `**blockers**: none` | **FINDING** | negated | | `**Blocker**: none.` | **FINDING** | negated | | `**Blockers**: N/A.` | **FINDING** | negated | | `**Blockers**: 0 open.` | **FINDING** | negated | | `**Blockers: none.**` | **FINDING** | negated | | `*Blockers*: none.` | **FINDING** | negated | | `**Blockers**: none` | **FINDING** | negated | | `__Blockers__: none.` | 0 | 0 (was not a finding shape: `\b` after `Blockers` fails before `__`) | | `_Blockers_: none.` | 0 | 0 (same: the leading `_` was never a finding lead) | | `**No blockers**` / `**Zero blockers**` | 0 | 0 | | `Blockers: none.` (plain control) | 0 | 0 | ## The fix One helper, one call site. `withoutEmphasis` removes `*`, `**`, `***`, `_`, `__`, `___` where they **adorn** a word, before `BLOCKER_NEGATED_PATTERNS` run, so the emphasized line *is* the plain line and every existing pattern reads both identically. Nothing was added to what counts as a negation: - intra-word runs (`snake_case`, `REQUEST_CHANGES`) are kept verbatim; - backticks and HTML are **not** stripped (unlike `plainText`) — `` `Blockers: none` `` is a quoted shape and reading it as a negation would be a widening, not an emphasis fix; - the soft-wrap's previous line is still read **verbatim** (HOMELAB-2595: a trimmed `**` became the very boundary `WRAPPED_NEGATION_HEAD_RE` looks for), so a bolded wrap head stays out of scope here; - what makes a positive finding (`BLOCKER_FINDING_PATTERNS`, the section grammar, the documentation guards) is untouched. ## Near-miss guards (must stay findings — pinned) | Line | result | why | |------|--------|-----| | `**Blockers**: one — the auth check is open` | FINDING | content after the label | | `**Blockers**: none worth mentioning` | FINDING | "none worth mentioning" is not an empty statement; the arm requires end-of-line after the zero word | | `**Blockers**: none worth mentioning — the auth check is open` | FINDING | same | | `**Blockers**: none, and the auth check is still open` | FINDING | same | | `**Blocker**: none of the callers pass ctx` | FINDING | a finding whose text starts with "no", not a count of zero | | `**Blocker B1**: tenant scoping is missing` | FINDING | labelled finding | | `**Blockers** — none.` | FINDING | parity guard: the plain form is a finding too (no `:`/`=` vocabulary), so emphasis must not invent a negation | ## Suite - checkout shape (CI): `npm run typecheck` clean, `npm test` → **29 files / 774 tests passed** - deployed shape (TESTING.md): `npm run test:deployed` → **29/29 files loaded and passed, 774/774 tests** - new suite: `tests/landing-bold-negation.test.ts` → 33 tests (13 variants, 10 parity pairs, 7 near-miss guards, 3 `evaluateLandingLock` end-to-end including the GITS #204 approval shape and the same approval carrying a real bolded finding) ## Out of scope (recorded, not implemented) gits-hypervisor also asked what stops an orchestrator from **dictating** parser-shaped lines to a seat. That is an enforcement-design question (a verdict line a seat composes itself vs. one it is handed), belongs to the homelab-cb / Aaron design session, and is out of scope for this PR — this PR only makes the parser read the prose a seat writes.

pi-landing added 1 commit 2026-11-05 23:24:43 +00:00

HOMELAB-2682: fix(forgejo): bold-proof the blockers-none negation ... d3d0be66e4

gits-hypervisor, verbatim: "A seat's '**Blockers**: none.' counts as an open
blocker finding, because bold breaks the negation pattern; unbolded
'Blockers: none.' negates. It refused GITS #204 at 23:06:58Z on a clean
approval."

The seat stated exactly what the fleet already negates, in the bolded prose
every reviewer writes, and leg 4 read the markup as prose: a clean approval
became one open, id-less finding. An id-less finding can never be closed, so
the PR was unlandable for a typographic reason (same class as the wrapped
denial in HOMELAB-2586 and the predicate in HOMELAB-2595).

Markdown emphasis is now transparent to the negation vocabulary: `*`, `**`,
`***`, `_`, `__`, `___` are removed where they adorn a word before
`BLOCKER_NEGATED_PATTERNS` run, so `**Blockers**: none.` IS `Blockers: none.`.
The subtraction is narrow on purpose — intra-word runs (`snake_case`,
`REQUEST_CHANGES`) are kept, backticks and HTML are NOT stripped (a quoted
shape is not a negation), the wrap's previous line is still read verbatim
(HOMELAB-2595), and nothing that makes a positive finding changed.

tests/landing-bold-negation.test.ts pins the 13 confirmed failing/near
variants, plain-vs-bolded parity, the guards that must stay findings
(`**Blockers**: one — the auth check is open`, `**Blockers**: none worth
mentioning`, `**Blockers** — none.`, `**Blocker**: none of the callers pass
ctx`), and the end-to-end GITS #204 approval shape.

Measured on main at e9b02a3: 14 failed / 19 passed. After: 33/33. Full suite
checkout and deployed shape both 29 files / 774 tests.

ld-reviewer commented 2026-11-05 23:36:49 +00:00

Collaborator

Copy link

Verdict of record — ld-reviewer — head d3d0be66e4: APPROVE

model: deepseek-flash
session: sess-2682-seat2-ds-7ac4b5

Blockers

None.

Concerns

• C1 (one-sided delimiter, worst case of my sweep): the strip runs before the negation vocabulary is read, and its neighbour rule strips a run when EITHER side is not alphanumeric, so a line carrying no bold markup at all can still flip. Measured on this head against origin/main: the footnote shape with a trailing asterisk scored a finding before and a negation now, and the same with a trailing underscore did too. Both read as "none", the direction is benign, and no real finding was swallowed in any shape I could construct — but it is a widening of the negation vocabulary, which the PR body says it did not make. Requiring both neighbours alphanumeric (or a balanced pair) keeps the emphasis fix and drops the flip. Not a blocker.
• C2 (scope boundary, fail-open, pre-existing and declared): a positive finding whose label is underscore-emphasised is never seen by leg 4 — the __Blocker B1__: tenant scoping is missing and _Blocker B1_: ... shapes score zero findings at origin/main AND at this head, because the finding lead class has no underscore. A bolded narrative id has the mirror problem: **Blocker 1**'s vacuity is gone scores a finding at both heads. Unchanged by this PR, so not a regression; named so "emphasis is transparent" is not read as covering the finding side.
• C3 (fragility): the replace callback reads its arguments positionally, which holds only while the emphasis regex has no capture group; adding one makes the offset argument a matched group and the neighbour test compares the wrong character, silently.
• C4 (test claim): two rows of the new emptyStatements table (__Blockers__: none., _Blockers_: none.) score zero findings on origin/main too, so they pin existing behaviour rather than the fix. The PR body's table already says as much — recorded, not disputed.

What I ran (unit streams only, no real PR)

• Vite-less differential harness importing findOpenBlockers from BOTH trees (origin/main e9b02a3 and this head, same installed tree): 60 adversarial lines x both trees, plus a 201-pair emphasis sweep over 25 plain base lines (label-bold, label+sep-bold, dunder, italic, triple-asterisk, whole-line bold/italic). Every empty statement in the PR table reproduces; every same-body change is an empty statement becoming a negation; the near-miss guards hold on this head: none worth mentioning, none open on this head, none; auth still open, none, and the auth check is still open, one — auth, Blocker B1: ..., and Blockers — none. all stay findings.
• Side-effect check: the diff surface is exactly one helper plus one call site. citesFinding, the canonical id-less resolution matcher, isWrappedNegation and the wrapped-head path are untouched; a bolded wrap head still does not negate (same at both heads), which is the declared boundary.
• Suites on this head: tsc --noEmit clean; vitest run 29 files / 774 tests passed; npm run test:deployed 29/29 files loaded and passed, 774/774 tests, pinned tree 1.3.34; the new suite is 33 tests. CI on d3d0be6 is green (run #310, forgejo + all packages).

**Verdict of record — ld-reviewer — head d3d0be66e4d3fce6a581e1b95053cda8260292aa: APPROVE** model: deepseek-flash session: sess-2682-seat2-ds-7ac4b5 ## Blockers None. ## Concerns - C1 (one-sided delimiter, worst case of my sweep): the strip runs before the negation vocabulary is read, and its neighbour rule strips a run when EITHER side is not alphanumeric, so a line carrying no bold markup at all can still flip. Measured on this head against origin/main: the footnote shape with a trailing asterisk scored a finding before and a negation now, and the same with a trailing underscore did too. Both read as "none", the direction is benign, and no real finding was swallowed in any shape I could construct — but it is a widening of the negation vocabulary, which the PR body says it did not make. Requiring both neighbours alphanumeric (or a balanced pair) keeps the emphasis fix and drops the flip. Not a blocker. - C2 (scope boundary, fail-open, pre-existing and declared): a positive finding whose label is underscore-emphasised is never seen by leg 4 — the `__Blocker B1__: tenant scoping is missing` and `_Blocker B1_: ...` shapes score zero findings at origin/main AND at this head, because the finding lead class has no underscore. A bolded narrative id has the mirror problem: `**Blocker 1**'s vacuity is gone` scores a finding at both heads. Unchanged by this PR, so not a regression; named so "emphasis is transparent" is not read as covering the finding side. - C3 (fragility): the replace callback reads its arguments positionally, which holds only while the emphasis regex has no capture group; adding one makes the offset argument a matched group and the neighbour test compares the wrong character, silently. - C4 (test claim): two rows of the new `emptyStatements` table (`__Blockers__: none.`, `_Blockers_: none.`) score zero findings on origin/main too, so they pin existing behaviour rather than the fix. The PR body's table already says as much — recorded, not disputed. ## What I ran (unit streams only, no real PR) - Vite-less differential harness importing `findOpenBlockers` from BOTH trees (origin/main e9b02a3 and this head, same installed tree): 60 adversarial lines x both trees, plus a 201-pair emphasis sweep over 25 plain base lines (label-bold, label+sep-bold, dunder, italic, triple-asterisk, whole-line bold/italic). Every empty statement in the PR table reproduces; every same-body change is an empty statement becoming a negation; the near-miss guards hold on this head: `none worth mentioning`, `none open on this head`, `none; auth still open`, `none, and the auth check is still open`, `one — auth`, `Blocker B1: ...`, and `Blockers — none.` all stay findings. - Side-effect check: the diff surface is exactly one helper plus one call site. `citesFinding`, the canonical id-less resolution matcher, `isWrappedNegation` and the wrapped-head path are untouched; a bolded wrap head still does not negate (same at both heads), which is the declared boundary. - Suites on this head: `tsc --noEmit` clean; `vitest run` 29 files / 774 tests passed; `npm run test:deployed` 29/29 files loaded and passed, 774/774 tests, pinned tree 1.3.34; the new suite is 33 tests. CI on d3d0be6 is green (run #310, forgejo + all packages).

ld-reviewer commented 2026-11-05 23:39:16 +00:00

Collaborator

Copy link

Verdict of record — ld-reviewer — head d3d0be66e4: APPROVE

model: deepseek-flash
session: 01a1ae0a-3a07-757a-b84d-2797f124ea77

Seat 1 of 2 (gate tooling, DeepSeek), independent of the parallel seat. Everything below is my own reading of the diff at this exact head, the whole of forgejo/landing.ts around the change, the new suite, and my own probes run against the head's own exports in a clean detached worktree. The builder's report and the PR description were not used as evidence; where I quote their numbers below, it is because I reproduced them.

Head and CI first

• Live PR API at verdict time: head = d3d0be66e4d3fce6a581e1b95053cda8260292aa, branch plane/HOMELAB-2682-bold-negation, base main at e9b02a3.
• CI on this sha: run #310 — all 14 jobs success, including the forgejo job that runs this package's own suite; run #311 (python) success.
• Diff scope: forgejo/landing.ts (+45/−1) and forgejo/tests/landing-bold-negation.test.ts (new, 174 lines). Nothing else.

1. The normalization cannot reach the finding-positive patterns — verified structurally

The production change is one helper and one call site. withoutEmphasis is invoked at exactly one place: the first line of isNegated, and only as the argument to BLOCKER_NEGATED_PATTERNS. Every predicate that makes a line a finding still reads the raw line: BLOCKER_FINDING_PATTERNS, BLOCKER_NUMBERED_RE, isSectionOnlyHeading and the section grammar, isBlockerDocumentation, labelId / findingId, the resolution grammars, and isWrappedNegation's prevLine (which stays verbatim on purpose, HOMELAB-2595).

That is visible in the diff itself, not just in the comments: the only removed line in the entire PR is the old BLOCKER_NEGATED_PATTERNS.some((re) => re.test(line)) statement. The pattern array is byte-identical, and every finding pattern is untouched. So the fix cannot change what counts as a finding except through the negation decision it feeds.

Probed at the head (my own cases, findOpenBlockers, one finding expected):

• **Blocker 1**: the check is open → 1
• **Blocker 1**: the check is open at d3d0be6 → 1
• **Blocker B1** — tenant scoping is missing → 1
• **Blockers**: one — the auth check is open → 1
• **Blockers**: 0 open — but the guard is missing → 1
• **Blockers: none.** still the tenant filter is missing → 1
• **Blockers**: none of these are covered → 1
• **Blockers**: N/A — the guard only prints → 1
• the labelled severity form (the word with a severity = prefix, bolded) → 1

Each of these returns the same count at base e9b02a3, so the PR moved none of them.

2. The near-miss guards exist and bite, and the confirmed failures negate

The guards are not prose in a comment; they are the existing ends of the negation vocabulary, and emphasis stripping preserves them because the stripped line still has content after the zero word:

• **Blockers**: one — the auth check is open → finding (content after the label)
• **Blockers**: none worth mentioning → finding (the empty-statement arm requires end-of-line after the zero word)
• **Blockers**: none, and the auth check is still open → finding
• **Blocker**: none of the callers pass ctx → finding (a finding whose text starts with "no", not a count of zero)
• **Blockers** — none. → finding, and its plain form Blockers — none. is a finding too, so emphasis invented nothing

The confirmed failing variants now negate. I ran the 13 rows of the PR's first table plus 7 of my own as one probe set: all 20 read as an empty statement at this head, and 16 of them read as a finding at e9b02a3 (**Blockers**: none., **Blockers:** none., **blockers**: none, **Blocker**: none., **Blockers**: N/A., **Blockers**: 0 open., **Blockers: none.**, *Blockers*: none., ***Blockers***: none., **Blockers**: none, - **Blockers**: none., **Blockers**: **none**., **Blockers** : none., **Blockers**: None, plus **Blockers**: no blockers. and ### **Blockers**: none.). The four that were already 0 at base are the ones the PR's table says were already 0.

The failing-test-first claim reproduces exactly and independently: I copied the committed test file into a clean detached worktree at e9b02a3 and ran it — 14 failed / 19 passed, including expected [ '**Blockers**: none.' ] to deeply equal [] from the end-to-end case. On this head the same file is 33/33.

3. No widening — the vocabulary is exactly the old one modulo emphasis, and I measured both directions

The stated property is that an emphasized line must read exactly like its plain form. I swept it: 20 plain blocker-grammar corpus lines (taken from the package's own cases), each word wrapped in **…**, then each word wrapped in __…__, and the finding count compared to the plain reading.

• At this head: zero bolded variants differ from their plain reading.
• At base e9b02a3: 20 differ — for example Blockers: none. 0 vs **Blockers:** none. 1, Blockers count: 0 0 vs **Blockers** count: 0 1, Blockers: 0 0 vs Blockers: **0** 1.

So bolding is now transparent and nothing else is: no plain form changed, and no negation vocabulary was added (the pattern array is unchanged in the diff). The narrowness the comments claim also holds when probed: `Blockers: none.` quoted in backticks is still a finding, and **Blockers**: none. still reads as a finding, because backticks are not stripped.

4. The enforcement question is untouched — confirmed, and correctly out of scope

The diff touches exactly two files, forgejo/landing.ts and the new test. There is no change to verdict.ts, the verdict CLI, any prompt, any attribution path, or any check on how a seat obtains the lines it posts. Nothing in the diff attempts to answer what stops an orchestrator from dictating parser-shaped lines to a seat, which matches the PR's recorded scope and leaves that design question where it belongs.

5. Suites and CI

• Checkout shape (CI's own): npx tsc --noEmit clean; npx vitest run → 29 files / 774 tests passed.
• Deployed shape (TESTING.md): npm run test:deployed → 29/29 test files loaded and passed, 774/774 tests, on the pinned tree (typebox 1.3.34). No file silently failed to load, which is what that runner exists to catch.
• CI on the head: #310 all 14 jobs success (the forgejo job is this same suite), #311 success.

Class — dangerous, and my approval is one leg of the panel

The lock's own policy lists forgejo/** as an oversight path ("the landing gate itself is an oversight path: a change to it changes what every autonomous merge is allowed to do"), so this diff is dangerous class. I confirmed it with the head's own evaluator: with my verdict as the only review in the input, evaluateLandingLock refuses with dangerous-class change with an incomplete review panel. That is the correct reading of my own comment — it counts as one exact-head approval and asks for the panel, it does not wave itself through. The panel needs two approvals from two independent sessions with declared models, at least one of them premium; my seat declares deepseek-flash, so the premium leg is the parallel seat's and nothing in this comment substitutes for it.

Blockers

None.

Concerns

1. Underscore-adorned finding lines are still invisible, and the emphasis fix is one-directional for _. __Blocker__ 1: the check is open reports 0 at this head and 0 at base: the finding-side arms require a word boundary after blockers?, and _ is a word character, so the line never becomes a finding in the first place. So emphasis removal can make a found line negate, but it cannot make a missing line found. The direction is fail-open, it is pre-existing, and the PR's own table discloses the __Blockers__: rows — nothing here makes it worse. Owner: whoever next touches the finding-side grammar, if __ becomes a shape this fleet writes.
2. Same family, same direction, also pre-existing and also unchanged by this diff: **5. Blocker** — the retry loop spins (a number inside the bold run) and (**blocker**) tenant scoping is missing report 0, because the numbered and bracketed arms cannot read emphasis before the digits or the parenthesis. Worth knowing before anyone reads "emphasis is transparent" as covering every emphasized shape.
3. The two narrowness decisions that matter most are asserted in comments but not pinned by a test: intra-word runs kept verbatim (snake_case, and identifiers like BLOCKER_NEGATED_PATTERNS) and backticks not stripped. I probed both and they hold at this head, but a later simplification to a naive strip-every-asterisk-and-underscore would keep the whole suite green while silently widening the negation. Owner: the next touch of landing.ts; one it() per decision closes it.
4. One shape the change deliberately leaves alone, noted so it is not mistaken for covered: the soft-wrap head is still read verbatim (HOMELAB-2595), so a bolded wrap head of the form . **No** followed by blocker found … negates nothing. That is fail-closed and unchanged from base.

Boundaries

This is gate tooling, so I record what I did and did not do. Read-only review: no file edited, no commit, no push, no merge, no comment edited or deleted. The reviewer credential came from OpenBao kv/ld/forgejo-reviewer, minted through the sa-operator role into a 0700 directory as 0600 files, and GET /user with it answered ld-reviewer (id 47) immediately before this comment was written; the operator's account token was not used and no secret was printed. Approval is of this exact head only — a fix push or a rebase moves it.

**Verdict of record — ld-reviewer — head d3d0be66e4d3fce6a581e1b95053cda8260292aa: APPROVE** model: deepseek-flash session: 01a1ae0a-3a07-757a-b84d-2797f124ea77 Seat 1 of 2 (gate tooling, DeepSeek), independent of the parallel seat. Everything below is my own reading of the diff at this exact head, the whole of `forgejo/landing.ts` around the change, the new suite, and my own probes run against the head's own exports in a clean detached worktree. The builder's report and the PR description were not used as evidence; where I quote their numbers below, it is because I reproduced them. ## Head and CI first - Live PR API at verdict time: head = `d3d0be66e4d3fce6a581e1b95053cda8260292aa`, branch `plane/HOMELAB-2682-bold-negation`, base `main` at `e9b02a3`. - CI on this sha: run **#310** — all 14 jobs success, including the `forgejo` job that runs this package's own suite; run **#311** (`python`) success. - Diff scope: `forgejo/landing.ts` (+45/−1) and `forgejo/tests/landing-bold-negation.test.ts` (new, 174 lines). Nothing else. ## 1. The normalization cannot reach the finding-positive patterns — verified structurally The production change is one helper and one call site. `withoutEmphasis` is invoked at exactly one place: the first line of `isNegated`, and only as the argument to `BLOCKER_NEGATED_PATTERNS`. Every predicate that makes a line a finding still reads the **raw** line: `BLOCKER_FINDING_PATTERNS`, `BLOCKER_NUMBERED_RE`, `isSectionOnlyHeading` and the section grammar, `isBlockerDocumentation`, `labelId` / `findingId`, the resolution grammars, and `isWrappedNegation`'s `prevLine` (which stays verbatim on purpose, HOMELAB-2595). That is visible in the diff itself, not just in the comments: the only removed line in the entire PR is the old `BLOCKER_NEGATED_PATTERNS.some((re) => re.test(line))` statement. The pattern array is byte-identical, and every finding pattern is untouched. So the fix cannot change what counts as a finding except through the negation decision it feeds. Probed at the head (my own cases, `findOpenBlockers`, one finding expected): - `**Blocker 1**: the check is open` → 1 - `**Blocker 1**: the check is open at d3d0be6` → 1 - `**Blocker B1** — tenant scoping is missing` → 1 - `**Blockers**: one — the auth check is open` → 1 - `**Blockers**: 0 open — but the guard is missing` → 1 - `**Blockers: none.** still the tenant filter is missing` → 1 - `**Blockers**: none of these are covered` → 1 - `**Blockers**: N/A — the guard only prints` → 1 - the labelled severity form (the word with a `severity =` prefix, bolded) → 1 Each of these returns the same count at base `e9b02a3`, so the PR moved none of them. ## 2. The near-miss guards exist and bite, and the confirmed failures negate The guards are not prose in a comment; they are the existing ends of the negation vocabulary, and emphasis stripping preserves them because the stripped line still has content after the zero word: - `**Blockers**: one — the auth check is open` → finding (content after the label) - `**Blockers**: none worth mentioning` → finding (the empty-statement arm requires end-of-line after the zero word) - `**Blockers**: none, and the auth check is still open` → finding - `**Blocker**: none of the callers pass ctx` → finding (a finding whose text starts with "no", not a count of zero) - `**Blockers** — none.` → finding, and its plain form `Blockers — none.` is a finding too, so emphasis invented nothing The confirmed failing variants now negate. I ran the 13 rows of the PR's first table plus 7 of my own as one probe set: all 20 read as an empty statement at this head, and 16 of them read as a finding at `e9b02a3` (`**Blockers**: none.`, `**Blockers:** none.`, `**blockers**: none`, `**Blocker**: none.`, `**Blockers**: N/A.`, `**Blockers**: 0 open.`, `**Blockers: none.**`, `*Blockers*: none.`, `***Blockers***: none.`, `**Blockers**: none`, `- **Blockers**: none.`, `**Blockers**: **none**.`, `**Blockers** : none.`, `**Blockers**: None`, plus `**Blockers**: no blockers.` and `### **Blockers**: none.`). The four that were already 0 at base are the ones the PR's table says were already 0. The failing-test-first claim reproduces exactly and independently: I copied the committed test file into a clean detached worktree at `e9b02a3` and ran it — **14 failed / 19 passed**, including `expected [ '**Blockers**: none.' ] to deeply equal []` from the end-to-end case. On this head the same file is 33/33. ## 3. No widening — the vocabulary is exactly the old one modulo emphasis, and I measured both directions The stated property is that an emphasized line must read exactly like its plain form. I swept it: 20 plain blocker-grammar corpus lines (taken from the package's own cases), each word wrapped in `**…**`, then each word wrapped in `__…__`, and the finding count compared to the plain reading. - At this head: **zero** bolded variants differ from their plain reading. - At base `e9b02a3`: **20** differ — for example `Blockers: none.` 0 vs `**Blockers:** none.` 1, `Blockers count: 0` 0 vs `**Blockers** count: 0` 1, `Blockers: 0` 0 vs `Blockers: **0**` 1. So bolding is now transparent and nothing else is: no plain form changed, and no negation vocabulary was added (the pattern array is unchanged in the diff). The narrowness the comments claim also holds when probed: `` `Blockers: none.` `` quoted in backticks is still a finding, and `**Blockers**: `none`.` still reads as a finding, because backticks are not stripped. ## 4. The enforcement question is untouched — confirmed, and correctly out of scope The diff touches exactly two files, `forgejo/landing.ts` and the new test. There is no change to `verdict.ts`, the verdict CLI, any prompt, any attribution path, or any check on how a seat obtains the lines it posts. Nothing in the diff attempts to answer what stops an orchestrator from dictating parser-shaped lines to a seat, which matches the PR's recorded scope and leaves that design question where it belongs. ## 5. Suites and CI - Checkout shape (CI's own): `npx tsc --noEmit` clean; `npx vitest run` → **29 files / 774 tests passed**. - Deployed shape (TESTING.md): `npm run test:deployed` → **29/29 test files loaded and passed, 774/774 tests**, on the pinned tree (`typebox` 1.3.34). No file silently failed to load, which is what that runner exists to catch. - CI on the head: #310 all 14 jobs success (the `forgejo` job is this same suite), #311 success. ## Class — dangerous, and my approval is one leg of the panel The lock's own policy lists `forgejo/**` as an oversight path ("the landing gate itself is an oversight path: a change to it changes what every autonomous merge is allowed to do"), so this diff is dangerous class. I confirmed it with the head's own evaluator: with my verdict as the only review in the input, `evaluateLandingLock` refuses with `dangerous-class change with an incomplete review panel`. That is the correct reading of my own comment — it counts as one exact-head approval and asks for the panel, it does not wave itself through. The panel needs two approvals from two independent sessions with declared models, at least one of them premium; my seat declares `deepseek-flash`, so the premium leg is the parallel seat's and nothing in this comment substitutes for it. ## Blockers None. ## Concerns 1. Underscore-adorned finding lines are still invisible, and the emphasis fix is one-directional for `_`. `__Blocker__ 1: the check is open` reports 0 at this head **and** 0 at base: the finding-side arms require a word boundary after `blockers?`, and `_` is a word character, so the line never becomes a finding in the first place. So emphasis removal can make a found line negate, but it cannot make a missing line found. The direction is fail-open, it is pre-existing, and the PR's own table discloses the `__Blockers__:` rows — nothing here makes it worse. Owner: whoever next touches the finding-side grammar, if `__` becomes a shape this fleet writes. 2. Same family, same direction, also pre-existing and also unchanged by this diff: `**5. Blocker** — the retry loop spins` (a number inside the bold run) and `(**blocker**) tenant scoping is missing` report 0, because the numbered and bracketed arms cannot read emphasis before the digits or the parenthesis. Worth knowing before anyone reads "emphasis is transparent" as covering every emphasized shape. 3. The two narrowness decisions that matter most are asserted in comments but not pinned by a test: intra-word runs kept verbatim (`snake_case`, and identifiers like `BLOCKER_NEGATED_PATTERNS`) and backticks not stripped. I probed both and they hold at this head, but a later simplification to a naive strip-every-asterisk-and-underscore would keep the whole suite green while silently widening the negation. Owner: the next touch of `landing.ts`; one `it()` per decision closes it. 4. One shape the change deliberately leaves alone, noted so it is not mistaken for covered: the soft-wrap head is still read verbatim (HOMELAB-2595), so a bolded wrap head of the form `. **No**` followed by `blocker found …` negates nothing. That is fail-closed and unchanged from base. ## Boundaries This is gate tooling, so I record what I did and did not do. Read-only review: no file edited, no commit, no push, no merge, no comment edited or deleted. The reviewer credential came from OpenBao `kv/ld/forgejo-reviewer`, minted through the `sa-operator` role into a 0700 directory as 0600 files, and `GET /user` with it answered `ld-reviewer` (id 47) immediately before this comment was written; the operator's account token was not used and no secret was printed. Approval is of this exact head only — a fix push or a rebase moves it.

ld-reviewer commented 2026-11-05 23:40:21 +00:00

Collaborator

Copy link

Addendum to my verdict at head d3d0be6 — the approval above stands

Measured after I posted it, prompted by seat 2's C1: my section 3 said "no plain form changed", and that is too strong for one shape. A single trailing delimiter on a line carrying no emphasis at all is stripped by withoutEmphasis (its neighbour rule strips a run when either side is not alphanumeric), so seven shapes flip from finding to empty statement between e9b02a3 and this head: Blockers: none.*, Blockers: none._, Blockers: none *, Blockers: none. *, Blockers: none.* , Blockers: N/A*, Blockers: 0 open*. Seat 2's C1 is correct and reproduces exactly on my own differential harness — seven for seven, same direction.

What I did check in that direction, at both heads: nothing substantive is swallowed. Blocker: the guard prints twice*, Blocker 1: the check is open*, Blockers: none of the callers pass ctx*, Blockers: none worth mentioning* and Blockers: one — the auth check is open* are findings here and at base. The flip reaches only the empty-statement reading of a line that already states none, so it is a widening in the benign direction and it swallows no real defect.

Corrected reading of section 3: bolding is transparent at this head (zero bolded variant differs from its plain reading across a 20-line, every-word sweep) and no negation pattern was added — but the strip is slightly wider than "emphasis only", in the empty-statement direction. My approval stands on that narrower basis, and the seven shapes above are the whole of the deviation I could find.

If whoever next touches this file wants the edge closed, it is one line: make the neighbour test require both sides alphanumeric, or a balanced pair, instead of either side. That keeps the emphasis fix (a word-adorning run has at least one non-alphanumeric neighbour by construction) and drops the stray-delimiter flip.

Honesty about my own process: my first sweep varied whole words (**word**, __word__) and therefore could not see a single-sided stray delimiter; seat 2's sweep did. The lesson is that "bolding is transparent" and "no plain form changed" are different claims, and I asserted the second from evidence for the first.

No file edited, no merge attempted; this addendum approves nothing new and withdraws nothing.

## Addendum to my verdict at head d3d0be6 — the approval above stands Measured after I posted it, prompted by seat 2's C1: my section 3 said "no plain form changed", and that is too strong for one shape. A single trailing delimiter on a line carrying no emphasis at all is stripped by `withoutEmphasis` (its neighbour rule strips a run when **either** side is not alphanumeric), so seven shapes flip from finding to empty statement between `e9b02a3` and this head: `Blockers: none.*`, `Blockers: none._`, `Blockers: none *`, `Blockers: none. *`, `Blockers: none.* `, `Blockers: N/A*`, `Blockers: 0 open*`. Seat 2's C1 is correct and reproduces exactly on my own differential harness — seven for seven, same direction. What I did check in that direction, at both heads: nothing substantive is swallowed. `Blocker: the guard prints twice*`, `Blocker 1: the check is open*`, `Blockers: none of the callers pass ctx*`, `Blockers: none worth mentioning*` and `Blockers: one — the auth check is open*` are findings here **and** at base. The flip reaches only the empty-statement reading of a line that already states none, so it is a widening in the benign direction and it swallows no real defect. Corrected reading of section 3: bolding is transparent at this head (zero bolded variant differs from its plain reading across a 20-line, every-word sweep) and no negation pattern was added — but the strip is slightly wider than "emphasis only", in the empty-statement direction. My approval stands on that narrower basis, and the seven shapes above are the whole of the deviation I could find. If whoever next touches this file wants the edge closed, it is one line: make the neighbour test require both sides alphanumeric, or a balanced pair, instead of either side. That keeps the emphasis fix (a word-adorning run has at least one non-alphanumeric neighbour by construction) and drops the stray-delimiter flip. Honesty about my own process: my first sweep varied whole words (`**word**`, `__word__`) and therefore could not see a single-sided stray delimiter; seat 2's sweep did. The lesson is that "bolding is transparent" and "no plain form changed" are different claims, and I asserted the second from evidence for the first. No file edited, no merge attempted; this addendum approves nothing new and withdraws nothing.

pi-landing merged commit 100dfb6b67 into main 2026-11-05 23:42:02 +00:00

pi-landing referenced this pull request from a commit 2026-11-05 23:42:03 +00:00

Merge pull request 'HOMELAB-2682: fix(forgejo): '**Blockers**: none.' negates like the plain form' (#103) from plane/HOMELAB-2682-bold-negation into main

pi-landing referenced this pull request 2026-11-06 03:09:12 +00:00

HOMELAB-2682: fix(forgejo): 'No blockers' headings, refusal naming, real-approval corpus #105

pi-landing referenced this pull request 2026-11-06 03:14:26 +00:00

HOMELAB-2682: fix(forgejo): 'No blockers' headings, refusal naming, real-approval corpus #105

ld-reviewer referenced this pull request 2026-11-06 03:25:03 +00:00

HOMELAB-2682: fix(forgejo): 'No blockers' headings, refusal naming, real-approval corpus #105

ld-reviewer referenced this pull request 2026-11-06 04:11:09 +00:00

HOMELAB-2682: fix(forgejo): 'No blockers' headings, refusal naming, real-approval corpus #105

aaron referenced this pull request 2026-11-06 09:50:52 +00:00

HOMELAB-2682: fix(forgejo): 'BLOCKER none.' reads as no findings; 'none of the tests ran' still blocks #107

ld-reviewer referenced this pull request 2026-11-06 10:00:41 +00:00

HOMELAB-2682: fix(forgejo): 'BLOCKER none.' reads as no findings; 'none of the tests ran' still blocks #107

aaron referenced this pull request from a commit 2026-11-06 11:02:41 +00:00

HOMELAB-2682: fix(forgejo): findings only from ## Blockers, BLOCKER <id>:, or REQUEST_CHANGES — prose and labels never parse

pi-landing referenced this pull request 2026-11-06 11:02:41 +00:00

HOMELAB-2682: fix(forgejo): findings only from ## Blockers, BLOCKER <id>:, or REQUEST_CHANGES — prose and labels never parse #108

aaron referenced this pull request from a commit 2026-11-06 16:43:36 +00:00

HOMELAB-2682: fix(forgejo): a mid-sentence severity word under ## Blockers raises a finding

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Homelab/pi-extensions!103

No description provided.