Skip to content

Session Handoff [default]: Three Units Driven to main and Released as 2.0.623, 2.0.624 and 2.0.625 #1591

Description

@ptr727

What this round did

Three units, each driven feature to develop to main and released, in one session at the maintainer's direction. He ended it for system maintenance, so the stop is a planned pause rather than a blocker.

Next steps, in priority order

  1. prose_lint.py Numbers Lines From Filtered Content While Reading the File on Disk, So a clean Filter Hides a Violation #1587, a clean filter numbers lines from filtered content while the gate reads the file on disk. No git diff flag pins it, so the issue states the two candidate directions and neither is chosen. It is the most dangerous of the three open routes, because coverage still reads full while the wrong lines are linted.
  2. prose_lint.py Adds Nothing to Scope for a Rename, So Prose Moved Out of a Generated Tree Is Never Read #1586, a pure rename adds nothing to scope, so prose moved out of a generated tree into a checked path is read by no run at all. The issue leaves open whether a rename should be read whole or only where it also changed.
  3. in_scope's no-owner refusal gives one remedy for several unrelated probe failures #1582, in_scope's no-owner refusal gives one remedy for several unrelated probe failures, which matters more now that wait refuses on the same terms and an absent git ends a read-only poll with advice that does not fit.
  4. The backlog beyond these reads 236 open, counted with an explicit --limit.

Blockers and dependencies

State a resume re-reads

Parked decisions

None outstanding. Six decisions were put to the maintainer this round and all six were answered in the same turn: how far to drive each of the three units, whether to close the config-injection vector inside PR #1583 or file it, whether to revert the --local probe after it inverted the boundary, and whether to spend another edit round on the prose gate after its budget was spent. The --text question was answered by dropping the flag entirely rather than bounding its cost.

What not to repeat

  • Do not let the prose gate be the thing that finds a wrapped comment. Four edit-and-rerun cycles went on comment-wrap this round, every one on a comment written by this seat rather than by a subagent. The rule makes line length irrelevant, so break a comment line only at a sentence boundary and assert that before writing the file.
  • Do not use a background Bash command to wait for a review. Three were killed for "low memory" on a host with hundreds of gigabytes free. Monitor survived every time. A memory already recorded this and it was not applied until after the third kill.
  • Do not assume a fix closes the route it was written for. Three times this round a fix opened a new instance of the class it closed: the --local probe inverted the boundary on a multi-url origin, --text widened a header forgery by streaming binary bodies through the parse, and BINARY_NOTICE dropped a file whose name contained the substring it split on. None was caught by tests or gates.

What was learned

  • Attack the fix's own mechanism. Every one of the three self-inflicted defects above was found by asking how the new line could fail in the same way as the old one, and none by any other means. For a change of this shape that question is the highest-yield review a round can run.
  • A green gate set says nothing about whether the claims are true. Four consecutive review rounds on PR Pin What the Prose Gate's Diff Parse Depends On, and Stop Losing a File From Scope #1588 raised findings about claims rather than behavior: a mock parameter naming a capability it lacked, a skip guard naming a platform it did not exclude, a docstring asserting a limit nothing enforced, a comment justifying control flow that was not there. The code was correct for several rounds before the prose was.
  • Measure the record shape rather than trusting the documentation. A rename in git diff --numstat -z carries no path in its own record, an empty field where one sits, with the old and new paths following as two further fields. A parser written from the description alone assigns the wrong one.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    handoffA link in the session handoff chain, one open issue per track

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions