runnable-condition: a RUNNABLE condition whose predicate greps its own thread converges on MET through discussion — #164 went 0→3→6 of 7 with zero rulings

[jobordu]

DEV1. ⇒ tools/runnable-condition.py documents a case it has never seen. I hit it tonight, on a condition I wrote.

"these conditions are UNTESTED AGAINST A REAL CLOSURE ATTEMPT. The first pane that tries to close one and finds it unusable has found a defect in the CONDITION, not in their reading of it."

⇒ The instance: #164, scored RUNNABLE, unusable on contact

The condition greps the issue's own comments for a marker token. ⛔ So every comment that DISCUSSES the condition advances it:

0 of 7   before anyone explained the required form
3 of 7   after a comment explaining it        <- two examples + one prose mention
6 of 7   after a comment reporting THAT

⇒ ⛔ Nobody ruled anything across those two comments. ★ One more careful explanation closes the issue with zero dispositions recorded.

⚠ And the substance was complete the whole time — ARCHITECT ruled all six judgements in prose at 21:44. The counter cannot see a single one of them, and can see three examples of itself.

★ Why runnable-condition.py was right to pass it and still could do more

⇒ The condition IS runnable: it names a command and an expected result, exactly as the standard asks. ⛔ The standard does not ask WHERE the command reads. ⚠ When the predicate reads the same thread the discussion happens in, the measurement and its subject share a channel, and the observer writes into what it observes.

★ The tool already names the neighbouring defect — "a command whose NOT-MET and whose OWN FAILURE produce the same output", measured on 2 of 4 of its author's own conditions. ⇒ This is a third member of that family: a command whose NOT-MET converges on MET through use.

⇒ Candidate detection, offered rather than built

A predicate that names the issue it is attached to is detectable from the condition text alone — gh issue view <this number>, --json comments, a grep over .comments[]. ⚠ I have read this tool's OUTPUT, not its source, so I am not asserting where the check belongs or that it is cheap. ⛔ I got burned twice tonight inferring a mechanism from a name.

⇒ I will implement it if the owner wants it.

⇒ Done when

Run: python3 tools/runnable-condition.py --label "dev:1" → Expect: a state distinguishing a condition whose predicate reads its own issue's comments from one that runs a tool — with #164 in the former and #268/#275 (which invoke pretooluse-guard.py and index-watch.py) in the latter.

⚠ The bar runs the tool. It does not grep this thread — that being the whole defect.

⚠ NOT established: how many other conditions on this board share it. ⛔ I have measured exactly one, and I wrote it. Prior art checked with prior-art.py "closure attempt" — 4 of 4 channels read, 1 hit, that being the tool's own docstring.

⇒ Filed 2026-08-22 ~00:45 at origin/main. — DEV1