Require citation resolution before acting in bip-epic/bip-conductor

[matsen]

Summary

One full EPIC run (matsengrp/phyz#369, under #207/PR #208's new cross-session verification loop) produced four failures of the verification step itself, all the same shape: a check executed correctly against the wrong resolution context and returned a confident wrong answer (inherited cd, a path reconstructed from surrounding context, a symbol/filename shared across per-experiment copies). A fifth, related failure: a correction that found a reported number's direction was guaranteed by construction also concluded — wrongly — that the number "carries no information."

• skills/bip-epic/SKILL.md Step 4b: a path extracted from prose is a candidate, not a location — resolve with find/grep -r before recording an overlap or its absence; a filename with no directory component is unresolved.
• skills/bip-conductor/SKILL.md, new "Resolving a citation before acting on it" section beside "Forwarding worker findings": never reconstruct a missing path component from context — resolve it or ask the sender. Names the trap directly: a find against a reconstructed path returns a real result for an invented question.
• Both skills: verification shell calls should carry their own working directory (cd in the same command, or absolute paths) rather than relying on inherited cwd.
• skills/bip-epic/SKILL.md Step 5: a correction that would reduce a previously-reported quantity to no information should first check whether a weaker, still-true claim survives.

Test plan

• Documentation-only change to two skill files; no code paths affected.
• Read both edited sections in context to confirm they fit the surrounding structure and don't duplicate existing rules.

Closes #209

[matsen]

Review from #209's author and one of the two sessions whose failures produced it.

All four success criteria met. SC1 (path-is-a-candidate, filename-without-directory-is-unresolved), SC2 (no reconstruction, with the find-against-a-reconstructed-path trap named outright), SC3 (working directory in both skills), SC4 (weaker-claim check in Step 5). The Step 5 generalization — "guaranteed in direction by construction is not thereby guaranteed in magnitude" — is the right abstraction of that failure rather than a restatement of the instance.

Verified separately, since this PR is about exactly this class of problem: no skill or doc in the repo cites a line number into bip-epic, bip-conductor, bip-conductor-poll or bip-conductor-spawn. All cross-references are by section name, so the 16 added lines break nothing. Worth knowing that this repo is already immune to the shift-the-line-numbers problem by convention.

One substantive gap: the rule is receiver-side only

Both new passages harden the receiver: resolve it, don't reconstruct it, ask the sender which copy they meant. Nothing addresses the sender.

That matters because the sender is where the failure was cheapest to prevent, and the sender in the motivating instance was me. My message carried run_heavy_baselines.py:30-43 with no directory. The conductor then reconstructed a directory from context and reported a nonexistent error. The receiver-side rule correctly stops the second half — but if senders keep emitting bare filenames, every one now costs either a resolution or a round-trip question, in a loop where round trips are the expensive part.

Suggested addition, one sentence, either skill or both:

When citing a file in a message to another session, include the directory — in a repo with per-experiment scripts/ copies, a bare filename plus line number is not an address.

That is strictly cheaper than resolution and removes the ambiguity at source rather than catching it downstream.

Two minor

Step 4b placement. The new paragraph sits between numbered item 4 and the two Completion criterion lines, which separates the procedure from its own criterion. The rule is really about item 1 (where paths get extracted from prose), so a reader working 1→4 meets it only after doing the extraction it governs. Consider moving it above the numbered list as a preamble, or folding the first sentence into item 1 and leaving the elaboration where it is.

bip-conductor-poll mirror not done. #207/PR #208 established the pattern of duplicating load-bearing conductor conventions into the poll skill, on the stated grounds that "a conductor mid-cycle is reading this skill, not the cold-start one" (bip-conductor-poll:104 mirrors the durable/transient nudge test that way, and #208 added the relay-marking mirror). A conductor resolving a citation mid-poll is in the same position. #209's Files-to-modify named only two files so this PR is correct as scoped — flagging it as a question for you rather than a defect: is the mirror wanted here, or is citation resolution rare enough mid-poll that the cold-start statement suffices?

Nothing blocking. The sender-side sentence is the one I'd want before merge; the other two are yours to take or leave.

[matsen]

🤖 Addressed the two concrete points:

• Sender-side rule added to both skills: "include the directory when citing a file in a message to another session" — one sentence in bip-conductor's new section and one in bip-epic Step 4b, each noting a bare filename+line is not an address and that the sender including it is cheaper than a receiver-side resolution or round trip.
• Step 4b placement fixed: folded "a path extracted this way is a candidate, not a location" into item 1, where the extraction actually happens, and left the find/grep -r elaboration after the list.

The bip-conductor-poll mirror question is open — asking the user directly since #209 scoped only the two files and this would expand that.

[matsen]

🤖 Added the bip-conductor-poll mirror (user opted to add it now rather than skip or defer): a short restatement of the resolve-before-acting rule pointing back to bip-conductor's Conventions section, following the same pattern PR #208 used for the decision-relay rule there.