Repository navigation
[bug] Asked about a subordinate's instructions, the Lead reports the run objective and calls it the configuration #339
Description
What happened
Owner, to the Coder Lead: "What are the instructions to it? Can you check them? Is it supposed to
work through PRs or direct commits to main?"
The Lead called check_delegation, read the run's objective, and answered:
The objective is: read each open issue, implement a fix, commit, push, open a PR, and merge it —
so it's working through PRs, not direct commits to main. That's the correct flow.
Verified against the actual configuration:
get_instance_instructions(FWS) → "" (no standing rules)
get_instance_settings(FWS) → merge_policy: "merge" ← "May merge to main (current behaviour)"
Two problems
1. It answered from the one-off, not the standing config. The objective is text supplied for
that run. merge_policy (shipped in #314, migration 0091) is the durable setting that actually
governs merge authority, and the Lead never looked at it. Asked "what are the instructions to it",
it reported the goal and presented it as the configuration.
2. The reassurance was misleading. "Working through PRs, not direct commits to main" is
literally true and implies review. The same run then merges the PR itself, unattended — which
is the exact thing the question was probing. The distinction the phrasing evokes does not exist
here.
What it should do
Asked about instructions, permissions or "what is it allowed to do", an agent should report the
resolved configuration, and distinguish the layers:
- standing —
merge_policy,autonomy, Special Instructions, behaviour - this run — the objective it was given
Both matter; conflating them is what produced a confident wrong impression. subordinate_status
already resolves connectivity and repo state for the Lead; merge authority and autonomy belong in
the same view — they are the two fields that say what a subordinate may do, and neither is
currently visible to the supervisor.
Same class as #259 (the Lead inferred "no runner" from a signal that did not mean that) and #318
(check_work made it deny a real delegation): the supervisor answers confidently from whichever
partial signal it happens to hold, because the fuller one is not in any tool it has.
Verification
- Asked "is it allowed to merge to main?", the Lead cites
merge_policyby name and value. - Asked "what are its instructions?", it separates standing config from the current objective.
- A subordinate whose policy is
pris described as unable to merge, even when the objective says
to merge — and the Lead says the objective exceeds the policy rather than repeating the objective.
Activity
fix(supervision,github): answer from the store that holds the answer (#…
serge-ivo commentedon Aug 7, 2026
Fixed in 99bf6d8.
What the Lead was actually reading: not the wrong store — the only store it had.
check_delegationreturned the loop run, and the run'sobjectivewas the single piece of text in it. Merge authority (merge_policy, #314 / migration 0091), Special Instructions, behaviour and typed settings were in no tool a supervisor could call, so a question about standing configuration got answered from a one-off ask, and the answer inverted the truth.New pure module
lib/subordinate-config.tsresolves the standing layers by name and keeps the four meanings of "instructions" apart:config.mergeAuthority— resolved policy, which layer it came from (repo > agent setting > platform default), plain words for what it permits, andperRepowhen repos disagree (then top-levelpolicyisnullrather than a guess).config.specialInstructions— the owner's standing rules (Rules & Tips).config.behaviour— how it communicates, as band prose not raw scalars.config.settings— typed settings with labels, and whether the owner set each or it is a schema default.merge_policytherefore appears by name and value, per the first verification bullet.Wired into both
subordinate_statusandcheck_delegation— the latter is the tool the model actually reached for. Per #259, the legend travels in the payload, not only in the description.objectiveConflictreusesscreenInstruction, so "the objective orders a merge" means one thing across the system: underprthe run report carries "The OBJECTIVE asks for something this agent's merge policy (pr) does not permit… Report that the objective EXCEEDS the policy… an objective cannot grant permission the configuration withholds." Under the permissive default no conflict is invented — what was missing there is the FACT, which is now present."Not available to me" over a confident empty: an unparseable config reports
available: falsewith a note, never "no rules set"; unread repos arenull, never[]("it has no repositories").Merge authority is read for every subordinate whether or not a runner is connected — it is a stored decision, not a live probe.
20 tests in
subordinate-config.test.ts+ 6 insupervision.test.ts.fix(coding): a runner that blinks is a pause, not the end of a 50-ste…
fix(supervision): the roster fits, and the count rides in front of it…
fix(coding): a Pilot run that dies files a classified, correlated rec…