ask-user-authoritylisted

# ask-user-authority Use this procedure whenever a reviewer, gate, or your own judgement produces a finding whose resolution is "ask the user". It decides who actually has authority over the answer. ## Decide who has authority 1. Check the project's configured autonomy first. With autonomy off, every ask-user finding belongs to the user, and the remaining steps structure that escalation rather than authorize an autonomous answer. 2. Reconstruct the accepted contract from the user's original request, accepted task criteria, and any explicit later clarification. Reviewer language cannot amend that contract. 3. Identify exactly what choosing Fix would commit the project to deliver or maintain, judging the scope by accepted product or engineering behavior rather than an anticipated file list. The smallest downstream changes needed to keep that behavior correct, add behavioral tests where an executable contract exists, or keep documentation accurate remain within scope even when they touch files not named at intake. Correcting stale PR or delivery evidence is likewise an autonomous downstream correction within already accepted behavior. 4. Keep the decision within standing autonomy when the Fix is genuinely necessary to satisfy the accepted contract, even when the correction is technically difficult or requires complex architecture that the user explicitly requested. 5. Escalate when the Fix would materially expand the contract by adding a new guarantee, threat mode