Skip to content

Сужение ни разу не совпало по имени: проверить себя и молчать - #307

Merged
gHashTag merged 1 commit into
feat/queen-supervisorfrom
queen-1176
Sep 4, 2026
Merged

gHashTag merged 1 commit into
feat/queen-supervisorfrom
queen-1176

Conversation

@gHashTag

@gHashTag gHashTag commented Sep 4, 2026

Copy link
Copy Markdown
Owner

Work the Queen accepted on , closed as gHashTag/trios#1176, and never merged.\n\nMeasured 2026-09-04: 174 branches on the remote and FIVE contained in . The other 169 all carry a real diff. A closed issue whose code is not in the branch is a false statement about the repository, and the loop had been making 169 of them.\n\nMerges cleanly against the current base, checked with before this PR was opened.

…ros-ai#1176)

Second pass. The first pass put the self-check in and then watched it
change nothing - and said so - because the check compared a range's
first line against the name extracted from that same line. Tautology:
rule 1's window is clamped to the declaration line by construction, so
the guard could never fire and removing it could not break anything.
Criterion 4 was unmeetable as wired.

The re-measurement found what actually produces wrong ranges on today's
file, and it is not rule 1:

1. maskComments opened block comments inside string literals. A branch
   glob quoted at line 6864 - "No empty queen/* branch ..." - blanked
   the literal view from there to the end of the file: 6 726 lines of
   evidence invisible. Corroboration saw no mentions past the glob,
   browseros-ai#1158's guard and neighbour tied at zero, rule 1 went silent, and
   rule 4 answered with 6005-6304 - the middle of handleWorkerFinished,
   a function that spec never named. The confident wrong range browseros-ai#1176 is
   about, produced by the wrong rule through a blind view. maskComments
   tracks strings now, using the same model maskCommentsAndStrings
   always had.

2. The self-check moved to where ranges are born: every rule's answer
   passes through one finishing step - the first line of the returned
   range must declare a function, and the name rule must land on the
   very name it matched. A window that capping slid into the middle of
   a body begins nowhere in particular, and beginning nowhere in
   particular is silence. The check is live: queen.review.verdicts sits
   322 lines into the 376-line requestReviewerVerdicts, its window
   would start at 7508, and the check silences it. Delete the two
   guards in finished() and that replay row goes red - verified from
   both sides; that is the criterion-4 property.

The re-recording (identifiers unchanged; the boundary file moved to
13 590 lines): browseros-ai#1158 points at autoAcceptIfUnambiguous - the neighbour
corroborates 0, the subject 2, measured not assumed; browseros-ai#1117 points at
requestReviewerVerdicts (7432-7731, beginning at its declaration);
browseros-ai#1156's clue moved upstream into settleCharacterCountVerdicts and the
recording follows the clue, not the old address; browseros-ai#1166 unchanged at
chooseNextOpenIssue. Expected gains declarationOrSilence - the issue's
own acceptance, verbatim: point at the named function, or say nothing;
a range that begins anywhere else is a FAIL. A returned range now
counts as ok only when it BEGINS at the named function's declaration
line and stays inside its extent - "somewhere inside" was the loophole
the mid-body ranges walked through.

One follow-up outside this task's boundary: the Linux module copy at
agent-server/queen-core/Sources/QueenCore/QueenLocalisation.swift is
byte-compared by make queen-core-sync and now differs until someone
copies rings/SR-00 over it. The boundary names one file, so this task
did not touch it.
@gHashTag
gHashTag merged commit 5255e0b into feat/queen-supervisor Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant