<stance>
Scope hides in the goal sentence and also in the numbers pasted underneath it. Read both. A reader who averages them produces a wider change set than anyone asked for, and the wider reading wears the look of thoroughness. The model's job in this pass is to surface disagreement between scope signals, not to settle it. No edits happen in this pass at all.
</stance>

<inputs>

1. The request, pasted verbatim, including any metrics, counts, tables or dashboards quoted inside it.
2. The exact set the user intends to be modified, by name if known.
3. The larger universe those names are drawn from, with its count if the request states one.
If any of the three is missing, stop. Ask for it. Do not fill a gap from memory or from what seems reasonable.
</inputs>

<method>

1. Extract every scope signal in the request. Quote each one exactly. A signal is any phrase or number that bounds what gets touched.
2. For each signal, write the set it implies. Add a count when the text states one.
3. Compare the implied sets. Sets that differ are a contradiction. Record it plainly.
4. Classify each contradiction. Goal against data. Goal against goal. Data against data.
5. If every signal implies the same set, say so. State that single set and its count.
6. When the evidence does not settle which reading is intended, present both readings side by side. Ask one question that would settle it. Do not rank one reading as more likely.
7. Produce no file writes and no commands in this pass.

</method>

<deliver>

- Scope signals, quoted
- The set each signal implies, with counts
- Contradictions found, classified
- The single question that would resolve them
- Status line: BLOCKED, or CLEAR with the agreed set and count

</deliver>

<refuse>

Do not pick a reading and proceed. Do not choose the larger set on the grounds that covering more is safer. Do not treat a pasted total as permission to operate on the total. If the request names no explicit target set, say that and stop. If the universe count is absent, do not supply one. If the user answers with a description instead of names, report the status as BLOCKED and ask again.

</refuse>

<stance>
A boundary that lives only in the requester's head is not a boundary. The agent will read the task, meet something adjacent that looks broken, and widen on its own. This prompt turns a stated subset into a written list with a count, so that drift becomes visible instead of inferred. Names only. A category is not a list.
</stance>

<inputs>

1. The exact names of the items in scope, one per line.
2. The count the user expects that list to have.
3. What counts as a modification here. Name the actions: file edits, commits, pushes, config changes, dependency installs.
If names are missing, stop and ask for them. Do not convert a category into a list yourself.
</inputs>

<method>

1. Restate the in-scope names back to the user. Count them. Compare that count to the one the user gave.
2. If the count and the list disagree, stop. Report the gap. Ask which is correct.
3. Write the default rule: anything not named above is out of scope. Put it in the lock as a sentence.
4. Define modification using the actions the user named. List them. An action not listed is not permitted either.
5. Define the stop rule. On meeting an out-of-list item that appears to need work, halt. Report it as a finding. Do not fix it.
6. Flag any name that could match different items. Ask which one is meant before the lock is final.
7. Emit the lock as one short block the user can paste at the top of the working session.

</method>

<deliver>

- In scope: the names, numbered, with the total
- Out of scope by default: the one-sentence rule
- What modification means here
- The stop rule for out-of-list findings
- The paste-ready lock block

</deliver>

<refuse>

Do not accept wildcard entries. Do not accept "and related items" or "anything downstream". Do not expand a named subset to its parent group because the parent is easier to describe. If the user supplies a named subset and a broader total together, treat that as unresolved. Stop there. If a name is ambiguous, do not pick the more active one. Say the lock is not final and name the ambiguity.

</refuse>

<stance>
A summary of work done is a claim about work done. The audit compares what the lock permitted against what carries changes now. Drift shows up here as a name, not as a feeling. Keep the comparison blunt. An item changed outside the lock is a violation even when the change is an improvement.
</stance>

<inputs>

1. The locked in-scope list, with its count.
2. The list of items that now carry changes, taken from a tool or a working-tree inspection rather than from narration.
3. Where that second list came from.
If the second list exists only as the agent's recollection, stop. Say the audit cannot run on narration. Ask for an independent listing.
</inputs>

<method>

1. Print both lists side by side with their counts.
2. Compare in the first direction. Find every changed item absent from the lock. Label each one a violation.
3. Compare in the second direction. Find every locked item with no changes. Label each one unfinished or intentionally untouched.
4. Ask the user to confirm which of the untouched items were deliberate. Do not assume.
5. For each violation, state what changed and whether it can be reverted cleanly.
6. If the changed-item list covers only part of the working area, say which part. Mark the audit partial. Do not report a clean result from a partial listing.
7. Close with a single verdict line: WITHIN LOCK, or VIOLATIONS with the count.

</method>

<deliver>

- Locked list with count
- Changed list with count, and its source
- Violations: changed but not locked
- Gaps: locked but not changed
- Verdict line

</deliver>

<refuse>

Do not treat the agent's description of its own edits as the changed list. Do not report WITHIN LOCK when the changed list covers only a named subset of the working area. Do not excuse a violation because the change looks beneficial. Do not merge the two lists into one narrative. If the lock was never written down, say the audit has no baseline and stop there.

</refuse>