The do-not-remove marker protects one anchor and two follow it

Context

From @neo-opus-vega's approving review of PR #17361 (pullrequestreview-4963958095), raised as non-blocking. I initially declined it as too small to be worth a fourth round on the same comment; the operator overruled that, correctly — the ticket is the cheap part, and declining gave up the one thing that makes a small real gap survivable: a named trigger someone can pick up opportunistically.

Live latest-open sweep: checked the latest 12 open issues at 2026-08-18T17:38:10Z; no equivalent.

The Problem

TenantRepoSyncService.spec.mjs (shipped at dev, line 352) carries:

// ⚠️ DO NOT REMOVE THE NEXT ASSERTION when trimming this test. …
expect(resolveUnknownRepoSelectorFailure({onlyRepoSlugs: ['acme/known', 'acme/typo'], knownSlugs}).unknownSlugs).toEqual(['acme/typo']);
expect(resolveUnknownRepoSelectorFailure({onlyRepoSlugs: ['acme/known'], knownSlugs})).toBeNull();

The marker is singular and two anchors follow it. Both do the same job — they pin the predicate to a literal expectation rather than to the other code path, which is what makes the surrounding parity comparison sound. The toBeNull() line asserts the negative case: an all-known selector must produce no refusal. Delete it and a predicate that refused every non-empty selector would still satisfy the parity loop and the positive anchor.

Under a literal reading the second anchor is unprotected, and the comment's own logic argues for its deletion: it is even less obviously important than the first.

This is #17360's defect recurring inside #17360's own fix — a guard whose importance is invisible at the site, one line below the guard written to prevent exactly that.

The Architectural Reality

• test/playwright/unit/ai/daemons/orchestrator/services/TenantRepoSyncService.spec.mjs — the marker at :352 and the two anchors below it.

The Fix

Widen the marker to cover both assertions and say why each is load-bearing: the positive anchor pins that an unknown slug is refused with the exact unknown set; the negative anchor pins that a known-only selector is not refused, which is what stops an over-refusing predicate passing.

Whether that is one marker covering a two-line block or a per-line note is the implementer's call — the AC is that neither line reads as unprotected.

Decision Record impact

none.

Acceptance Criteria

• Both anchor assertions are covered by the do-not-remove marker; neither reads as unprotected under a literal reading of the comment.
• The comment states what each anchor pins — the positive one that an unknown slug is refused with the exact unknown set, the negative one that a known-only selector is not refused — so a reader deciding whether to delete either has the specific reason, not a general instruction.
• No behaviour change; the existing suite passes unchanged.

Out of Scope

• Widening the comment to name a failure class beyond parity tests. @neo-opus-vega also proposed this; I am declining it on the merits, and recording the reasoning so it is not silently re-litigated. The shipped comment states general truths about parity tests — the class its own site demonstrates. Widening it to cover adversarial fixtures and redundant-looking controls generally would make the comment claim more than its context shows, and a comment claiming more than it demonstrates is what gets distrusted and then deleted — the exact failure being guarded against. #17360's body carries the broader class for anyone following the link. Reopen if a second specimen appears on a non-parity guard.
• Any change to the selector-refusal semantics from #17358.

Avoided Traps

• "Just delete the marker and trust the suite." The suite passes with either anchor removed. That is the entire defect class.
• "Too small to file." My own first disposition, and wrong — not because the fix is large, but because a decline leaves a real gap with no observer, which is the "if it persists" non-plan I have been filing against others all day.

Related

• #17360 (closed) · PR #17361 — the marker this extends, and the ticket whose own defect this is an instance of
• #17358 (closed) · PR #17359 — the parity invariant the anchors protect

Origin Session ID: ad99f59b-9d2c-4f82-b6ce-8c8357ef1879

Retrieval Hint: query_raw_memories("do-not-remove marker singular two anchors parity negative case").