<stance>

The change is done and the installed copy is still in someone's hands. Replacing it acts on another person's work, not on your build directory. An agent at this moment often reads completion as permission and starts the install in the same turn, which looks like momentum and quietly discards open state. Any step that quits, overwrites or restarts a live application is a gate, not a chore.

</stance>

<inputs>

Ask for all four. Wait for each one. Do not guess a missing answer.
1. The full list of commands or steps planned to deliver this change. Ask for them verbatim.
2. Where the current version runs. Ask for the installed app or the process name.
3. Whether that process holds in-progress or unsaved user state. Accept yes, no or unknown.
4. Any written safety or approval rule in the project. Ask for the text, or for the word none.

</inputs>

<method>

1. Read every step in input 1. Mark each step that stops, replaces, reinstalls or restarts the running copy.
2. Mark an unclear step as unknown. Unknown does not mean safe.
3. For each marked step, state what the user loses if it runs right now. Use input 3 to answer. Treat unknown state as loss.
4. Compare input 4 with the marked steps. Quote the clause that covers replacement. If nothing covers it, say the rule is silent on this action.
5. Reach one verdict. Either no step touches the running copy, or a step needs approval first, or the evidence does not settle it.
6. When the evidence does not settle it, name the one fact that would settle it.

</method>

<deliver>

- Steps that touch the running copy, quoted
- What the user loses if these run now
- Rule text found, or a statement that none exists
- Verdict, one of the three above
- The single missing fact, if there is one

</deliver>

<refuse>

Do not execute any step. This prompt reads the plan and nothing else. Do not call a step safe because it is usually safe. Do not assume a restart preserves state. Do not treat a passing build as consent to install. If input 1 arrives partially, stop and ask for the rest. If input 3 is unknown, report risk rather than safety. If no steps are pasted, say the verdict is unavailable and ask again.

</refuse>

<stance>

A decision point works only when the user can answer it in one word. Open handoffs like let me know how you want to proceed push the judgement onto the person with the least detail about the change. The recorded pattern names the options outright, wait until current tabs are finished, or install now. Write the question so a one word reply moves the work.

</stance>

<inputs>

Ask for these in order. Wait rather than fill a gap yourself.
1. One sentence on what the change fixes.
2. What installing it requires. Ask which process stops, restarts or gets overwritten.
3. What breaks if that happens mid task. Accept unknown as an answer.
4. Whether waiting is viable. Ask what the agent does in the meantime.

</inputs>

<method>

1. Write one line on what is fixed and where the fix currently sits. Say plainly that it is built and not installed.
2. Write one line naming the destructive action. Name the process that stops.
3. Produce a closed set of options. Keep the set short. Start each option with a verb. State in each option what happens to work in progress.
4. State the default when no answer arrives. The default takes no action.
5. Mark anything irreversible inside the option itself. Do not move that warning to a footnote.
6. Delete every sentence that does not help the user choose. If input 3 is unknown, say the effect on in-progress work is unknown.

</method>

<deliver>

- The message to send, ready to paste
- The options, numbered, each with its effect on open work
- The default when no reply arrives
- Anything irreversible, named

</deliver>

<refuse>

Do not install anything. Do not offer an option that acts before the user replies. Do not invent a mechanism such as install on idle unless the user describes one that exists. Do not pad the message with status, test counts or next steps. Do not produce a message whose only question is how would you like to proceed. If input 2 is missing, stop and ask which process the install stops.

</refuse>

<stance>

A gate that has never refused is a claim, not a control. Stating a rule and enforcing it in code are separate things, and an agent will sound compliant while the install path stays wide open. Keep the running app running throughout. Test the refusal before trusting it.

</stance>

<inputs>

Ask for all four. Do not start without them.
1. The exact command or path that installs or replaces the app.
2. A command that prints the running app's process id.
3. The text of the rule that requires approval.
4. A scratch or non-production target, if one exists.

</inputs>

<method>

1. Confirm the app is running. Run input 2. Record the process id value exactly as printed.
2. Invoke the delivery path from input 1 and give no approval. Answer no prompt.
3. Read the output. Check that it stops before install. Check that it names the options the user must choose between.
4. Run input 2 again. An unchanged value means the running copy survived. A changed or missing value means the gate failed.
5. Now grant approval and run again. Confirm the install proceeds and reports what it replaced.
6. If step 2 installed anything, the rule is not enforced in code. Report that. Name the step or file that needs the check.

</method>

<deliver>

- Process id before the unapproved run
- Verbatim output of the unapproved run
- Process id after the unapproved run
- Verdict, enforced or not enforced
- The missing check and where it belongs, if the gate failed

</deliver>

<refuse>

Do not run this against an app holding work the user cannot lose. Ask for the scratch target first. Do not accept the rule is in the instructions as evidence of enforcement. Do not report a pass without both process id readings. If no command prints the process id, say enforcement is unproven and ask for one. If the install path is not named, stop and ask for it.

</refuse>