Twinned from https://github.com/cfsh/ninefold/issues/1021 by tools/beads/import_github.py's reconcile pass.
Suggestions from ninefold-reviewer's review of #1018
tools/nflib/perimeter.py's _patch_is_mechanical_fill treats a patch as one flat line stream across hunk boundaries~~ — superseded, 2026-08-17. The PR's second cut (sha ecc50964) deleted the entire regex/patch-parsing mechanism this item was about, per Aedan's own direction: *"the detection … should be done by re-running the tool in dry mode and comparing that the diff is exactly the same, not with regex."* _patch_is_mechanical_fill, _is_issue_only_row_edit, _PROJECT_STAMP_LINE_RE and the patch field on Gh.pr_files are all gone. Nothing to harden; closing this item.tools/nflib/channels.py's _project_pointer() hand-copies design_docs/tools/operationalize_design.py's _PROJECT_LINE_RE pattern (r"^-\s*\*\*Project:\*\*\s*(\S+)") instead of importing it — exactly the "second description of the tool's output format, free to drift from it" shape the PR's own docstrings say this architecture eliminates. Currently benign: channels._project_pointer() only reads a hint off head_text, and only when the base doc has no pointer yet — i.e. only against text the tool itself just wrote via _stamp_project_header, which never indents the line, so the channels.py copy's stricter (no per-line .strip()) anchor never actually diverges from the tool's own _existing_project_pointer in practice. But it is still a hand-maintained duplicate of a regex the tool already owns, and any future edit to one without the other is a silent-drift bug waiting to happen — worth exporting _PROJECT_LINE_RE (or a small accessor) from operationalize_design.py and having channels.py import it rather than restate it.None.
No comments.