Beagle SCM

POST-006: be post POSTCFLCT false-fires on conflict-marker strings in tracked source comments/literals

be post scans staged tracked files for WEAVE conflict markers (<<<< / |||| / >>>>) and refuses with POSTCFLCT if a full triple is found. But a source file that legitimately CONTAINS those marker strings — e.g. sniff/PATCH.c, the conflict-handling code itself, whose comments show <<<<theirs||||ours>>>> at :339-340 — false-fires, blocking the commit and forcing be post --force. Hit this session committing the picked-header move: the triple is documentation, not an unresolved merge. Resolution: best-effort detect the real WEAVE output shape so obvious doc/literal markers don't refuse; where a file genuinely contains a full conflict-shaped block we cannot disambiguate, be post! (the bang/--force override, DIS-030/031) is the sanctioned escape — accepted, not a bug. See POST, PATCH, CLAUDE.

Issues

The scan can't tell a real unresolved marker from a marker string in a comment or literal.

• Any edit to the conflict-handling code (or any file that quotes the markers) is uncommittable without --force; be post refuses on the doc triple at sniff/PATCH.c:339-340.
• --force overrides the WHOLE conflict scan, not just the false-positive — too blunt; a real conflict elsewhere in the same commit would also be waved through.
• Repro: stage a .c file containing a <<<<…||||…>>>> triple inside a // comment → be post → POSTCFLCT / BEDOGEXIT.

Blockers

None. Localized to the post conflict-marker scan.

Planned

Best-effort detect the real WEAVE output shape; where undetectable, be post! is the accepted override.

• Repro first (CLAUDE §17): a test staging a file with a marker triple inside a // comment / string literal (the common false-positive), asserting be post does NOT refuse; and a file with a genuinely WEAVE-shaped unresolved block still DOES refuse.
• Recognize only the WEAVE output shape — the full <<<< / |||| / ==== / >>>> sequence at line starts in the structural order a real conflict emits — not any inline occurrence in a comment/literal. This clears the obvious documentation cases (e.g. sniff/PATCH.c).
• Where the file legitimately contains a full, well-formed conflict-shaped block the scan cannot distinguish from a real one, do NOT try to be cleverer — be post! (bang = --force, DIS-030/031) is the documented, sanctioned override. Accept the bluntness there; that is the intended escape, not a defect.

WIP

Design decisions

• Partial mitigation already in-tree: SNIFFHasConflictMarker (sniff/PATCH.c:397)

  now requires the ordered open→mid→close shape with nested-open abort, so a BARE <<<< / >>>> in prose no longer fires. An inline full triple in a comment (e.g. PATCH.c's own doc line <<<<theirs||||ours>>>> at PATCH.c:385) STILL fires — confirmed live 2026-06-27 (the POST-023 land needed be post!).

• New lever since filing: DIS-046 (6d7ee04f) sizes REAL WEAVE fences ONE LONGER

  than the longest </|/> run in the whole merged content (graf/WEAVE.c::weave_fence_run_max, :1145-1215). A genuine unresolved conflict in a file quoting a 4-char triple therefore carries fences ≥5 — the post pre-flight scan can use that invariant to clear doc/literal triples.

TODOs

• Repro-first (test/post/): stage a .c with an inline <<<<a||||b>>>>

  triple in a // comment → be post must NOT refuse; a WEAVE-shaped unresolved block (DIS-046-sized fences) still refuses. RED today.

• Teach the pre-flight scan (sniff/POST.c:1288 / :2755) the DIS-046

  invariant: a real conflict's fence run is strictly longer than every other marker run in the file — clear a triple whose fence length ties the file max.

• Keep be post! as the sanctioned escape for the residual undecidable case;

  don't regress test/post/42-refuse-atomic-store (POST-017 atomicity).

Blockers and bummers

• None. (The old top-board line pointed at DIS-040; the DIS-046 fence sizing is

  the piece that actually unblocks a precise fix.)

Outcome

(pending)