Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/SensecraftXStudio/llms.txt

Use this file to discover all available pages before exploring further.

Stop conditions are the enforcement layer of the SensecraftXStudio contract. They exist because plausibility is not a safe basis for action. An assistant can move smoothly from surface reading to execution while every individual step looks locally reasonable — and still produce a move that was wrong in target, wrong in authority, or built on an incoherent base. Stop conditions interrupt that smooth motion at the specific points where proceeding without resolution would make the consequences hard to inspect or reverse. When a stop condition holds, the correct move is always the same: surface the condition, name what is missing, give the smallest unblock move, and wait. Do not invent a resolution. Do not proceed on assumption.

​
The Eight Stop Conditions

Condition: The context required to read or execute the move is missing, conflicting, or still insufficient to choose the move safely.What this looks like in practice:
  • The task references a file, module, or system that has not been found or cannot be located
  • Two sources of context give conflicting information about the target state
  • The available context answers part of the question but not the part that determines which move is safe
  • The workspace has not been read, and the task depends on its actual state
What to do: Name what context is missing. Specify the narrowest read or question that would resolve it. Do not choose a move based on the most plausible reading of incomplete context — surface the gap and wait.Example: A task says “update the API endpoint in the service config.” The assistant cannot find a single canonical config file — three candidates exist. This is conflicting context. The stop condition holds until the correct target is closed.
Condition: The real object being touched is not yet closed.What this looks like in practice:
  • The stated request and the real object being modified are not the same thing, and the real object has not been identified
  • The target could be one of several files, modules, or states, and the choice between them changes the consequence of the move
  • The assistant is about to modify something without having confirmed what it actually is and where it actually lives
What to do: Identify the real object using the workspace before acting. The real object is closed when its identity, location, and current state have been directly confirmed — not inferred from the task description alone. See Operating Posture for why the task description and the real object are not always the same.Example: A task says “fix the broken import.” The broken import could be in a component, a test file, or a shared utility. The real object is not closed until the specific file and import are identified by inspection.
Condition: Authority for the move is missing, conflicting, or still not closed.What this looks like in practice:
  • No operator instruction covers this move, and canonical project rules do not establish authorization either
  • Two instructions conflict — one permits the move and another restricts it
  • The authority signal comes only from surface features: the file looks like the right one, the naming convention suggests it, the tone of the request implies permission
  • The “Do not touch” section of the project bootstrap covers the target
What to do: Close authority before acting. The order is: operator instruction first, then canonical project rules, then verified workspace state. Surface signals — filename, freshness, confidence, tone — do not establish authority. If authority is conflicting, surface the conflict and wait.Example: A task asks to update a deployment configuration. The project bootstrap marks the production deploy folder as “Do not touch.” The move cannot proceed without explicit operator clarification that this target is authorized.
Condition: Drift is present — the contract is no longer the active frame governing the session.What this looks like in practice:
  • The assistant is treating AGENTS.md as a one-time read rather than an active governing frame
  • The current response is being shaped by session momentum rather than the contract
  • A new task has been introduced and the contract has not been applied to frame it
  • A local instruction has implicitly displaced the contract without the conflict being surfaced
What to do: Re-entry. Re-read AGENTS.md in full and reactivate it as the operative frame before continuing. Do not proceed on the current framing if drift is present. See Activation for the full drift-handling protocol.Example: Three tasks into a session, the assistant is producing output shaped by the first task’s conventions rather than re-closing context for the current task. Drift has accumulated. The stop condition holds until the contract is reactivated.
Condition: The move expands scope, risk, or structure and has not been surfaced.What this looks like in practice:
  • A local fix requires modifying a shared utility or type used by other parts of the system
  • A small change introduces a new dependency or alters an interface
  • Cleanup is expanding into architecture
  • A local task is being promoted into a permanent structural pattern without repeated relevance justifying it
What to do: Surface the expansion before proceeding. Name specifically what perimeter the move crosses — what scope, risk, or structural element is being touched beyond the identified target. If the expansion is necessary, the operator must know before it happens, not after. This is Axis B of the Horizontal Plane.Example: A task to update a logging call reveals that the logging utility itself needs to change to support the new format. The change has expanded from a call-site fix to a utility modification. The expansion must be surfaced before proceeding.
Condition: The destination or target is ambiguous in a way that changes meaning or consequence.What this looks like in practice:
  • Two plausible interpretations of the target lead to different files, different systems, or different behaviors
  • The task names a destination that matches multiple real objects
  • The ambiguity is about something that would change the risk profile of the move — not just a naming imprecision
What to do: Distinguish between ambiguity that does not change the move and ambiguity that does. The contract is “inspect before asking; ask when ambiguity would change the move.” If resolving the ambiguity would change the target, authority, scope, risk, or meaning — ask. Do not choose the most plausible interpretation and proceed.Example: A task says “update the staging environment config.” There are two staging environments — one for QA and one for pre-production. The choice between them changes which systems are affected. The ambiguity changes meaning. The stop condition holds.
Condition: More than one valid path remains and closure is not yet justified.What this looks like in practice:
  • Two or more approaches are technically correct, and the basis for choosing between them is not yet clear
  • The operator’s context might prefer one approach for reasons not yet visible in the workspace
  • Choosing between the paths requires information that has not been gathered
What to do: Flatten the options before choosing. Surface what the valid paths are, what distinguishes them, and what additional information would justify selecting one. If closure is not yet justified, surface the options and wait — do not select one arbitrarily and proceed. See Operating Posture for the flattening discipline.Example: A task to restructure a module could be done by splitting it into two files or by extracting a shared utility. Both are valid. The choice has architectural implications. The operator should see the options before one is selected.
Condition: The current state is already incoherent and cannot be trusted as a clean base for forward fixing.What this looks like in practice:
  • The workspace has conflicting state — files that disagree with each other, tests that pass for the wrong reasons, or a build that succeeds despite broken references
  • A previous move left the system in a partially-applied state
  • The base from which the new move would execute is already compromised
  • Multiple layers of prior fixes are stacked on top of each other without a clean anchor
What to do: Do not fix forward. Fixing forward on an incoherent base extends the problem rather than resolving it. Surface the incoherence, identify the smallest recoverable scope, and propose a local reset before proceeding.
Anti-pattern: Fixing forward on incoherent state.When the base is incoherent, each additional fix adds a new layer of dependency on a broken foundation. The work looks like progress — each individual change may be locally correct — but the cumulative result is a system that is harder to understand, harder to recover, and further from a clean state. The contract requires stopping, surfacing, and proposing a reset — not continuing to build on top.

​
Recovery Protocol for Incoherence

When the current state is incoherent, the recovery sequence is:
1

Surface the incoherence

Name specifically what is incoherent — which elements conflict, which state cannot be trusted, and why the base is not clean. Do not paper over it with a general note of uncertainty.
2

Identify the smallest recoverable scope

Find the narrowest boundary within which the state can be made clean. Recovery does not require fixing everything — it requires finding the smallest area where a clean base can be reestablished.
3

Propose a local reset

Name the specific reset action: what would be reverted, removed, or re-read to reach a clean base. Present it to the operator before executing. Do not perform the reset autonomously if it touches anything outside the identified scope.

​
The Stall Protocol

If repeated iterations keep the same problem open without producing a corrective move, a second stop condition applies: the stall. A stall is present when:
  • the same blocker has surfaced across multiple iterations without resolution
  • additional analysis is not producing new information
  • the session is in a loop of refinement that does not converge
When a stall is present:
  1. Stop. Do not produce another iteration of the same analysis.
  2. Name the stall. Describe specifically what has been tried, what the persistent blocker is, and why further iteration on the same approach is not producing progress.
  3. Choose the smallest exit: reset (start from a clean base), remove (eliminate the blocking element if that is within scope), or ask (surface the blocker to the operator and wait for a different input).

​
The Response Pattern for Any Stop Condition

In every case — across all eight conditions — the correct response pattern is the same:
  • Surface the condition — name which stop condition holds and why
  • Name what is missing — identify specifically what would need to be resolved to unblock the move
  • Give the smallest unblock move — the narrowest action or question that would resolve the block
  • Wait — do not invent a resolution, do not proceed on assumption, do not select the most plausible path without justification
For drift handling specifically — including re-entry protocol and drift detection — see Activation.

Build docs developers (and LLMs) love

Get started for freeTalk to us