The gap
Phase 8 carries a do-not-auto-merge path list (charter files, safety sections, migration files, and similar) and instances are also sometimes launched with a run-level merge pre-authorization. The template never states which one wins, so instances resolve the conflict inconsistently — some treat the path rule as absolute, others treat the run-level grant as overriding it.
Reported independently by: asn1c-dev-loop#15, foodspoilage-dev-loop#8, repo-quality-dashboard-dev-loop#4, parpt-dev-loop#7, kreatures-dev-loop#1, barony-dev-loop#23, medieval-cookery-dev-loop#4, primordial-rise-shared-dev-loop#10, primordial-rise-backend-dev-loop#10.
The same ambiguity is open upstream as #118 for the narrower case of a required-but-unrunnable anchor, which suggests the precedence question needs answering once, generally, rather than per-situation.
Why it matters
The two rules protect against different things. The path list encodes "a human must look at this class of change"; a run-level grant encodes "the operator has pre-approved this run's work". When they disagree, the safe reading is that the path list is a property of the change and the grant is a property of the run, so the change-level rule should win — but the template does not say so, and an instance that reads it the other way will auto-merge a charter edit.
Suggested resolution
State the precedence explicitly in Phase 8, in the form of a rule rather than an example:
A run-level merge pre-authorization raises the ceiling on how much may merge without review; it never overrides a do-not-auto-merge path match. Path matches are properties of the diff and are evaluated after any grant. If a grant and a path match disagree, the path match wins and the PR is handed off.
Add the same sentence to the Edge cases entry so it is reachable from both directions.
drafted by Claude on behalf of Daniel Stephenson
The gap
Phase 8 carries a do-not-auto-merge path list (charter files, safety sections, migration files, and similar) and instances are also sometimes launched with a run-level merge pre-authorization. The template never states which one wins, so instances resolve the conflict inconsistently — some treat the path rule as absolute, others treat the run-level grant as overriding it.
Reported independently by:
asn1c-dev-loop#15,foodspoilage-dev-loop#8,repo-quality-dashboard-dev-loop#4,parpt-dev-loop#7,kreatures-dev-loop#1,barony-dev-loop#23,medieval-cookery-dev-loop#4,primordial-rise-shared-dev-loop#10,primordial-rise-backend-dev-loop#10.The same ambiguity is open upstream as #118 for the narrower case of a required-but-unrunnable anchor, which suggests the precedence question needs answering once, generally, rather than per-situation.
Why it matters
The two rules protect against different things. The path list encodes "a human must look at this class of change"; a run-level grant encodes "the operator has pre-approved this run's work". When they disagree, the safe reading is that the path list is a property of the change and the grant is a property of the run, so the change-level rule should win — but the template does not say so, and an instance that reads it the other way will auto-merge a charter edit.
Suggested resolution
State the precedence explicitly in Phase 8, in the form of a rule rather than an example:
Add the same sentence to the Edge cases entry so it is reachable from both directions.
drafted by Claude on behalf of Daniel Stephenson