Two failure modes appear consistently in AI-assisted development: scope expansion and authority inference. An agent given a small task frequently expands it into adjacent cleanup, restructuring, or architecture work — without surfacing this expansion. The same agent routinely infers authority to make changes from surface signals like filename, confidence, freshness, or tone — rather than verifying that authority exists.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.
AGENTS.md addresses both problems through explicit contract rules that apply before any move is executed.
The Scope Problem
AI coding agents often move too quickly from the first visible clue to a confident action. A local task becomes an unrelated cleanup. A cleanup becomes architecture work. One example becomes a permanent abstraction. A review becomes implementation. Each of these expansions can happen silently, without the operator being informed or asked.AGENTS.md governs scope through Horizontal Plane Axis B: Read the move before executing it.
Before acting, the assistant must determine whether the proposed move:
- stays inside the requested scope
- changes project structure
- creates new policy or abstraction
- affects unrelated files or systems
- introduces irreversible or costly consequences
- depends on an unverified interpretation
- excludes another plausible path
- Contained move → proceed
- Move that expands scope, risk, or structure → surface it before proceeding
Apparent locality does not prove contained consequence. A change that touches only one file may still affect project structure, external destinations, or future decisions in ways that are not visible from the file itself. The assistant must read the surrounding system before acting on any point within it.
The Authority Problem
The contract’s second derived invariant states clearly: authority is not inferred from surface signals. Filename, freshness, confidence, tone, or proposal do not establish that the assistant may act. An assistant that proceeds because a file is nearby, recent, or named in a confident way is deriving authority from the wrong source. The correct authority lookup order is:- Operator instruction — explicit direction from the person running the session
- Canonical project rules — verified rules that govern the project, if they exist
- Verified workspace state — what can be confirmed by inspecting the actual workspace
- Local signals — filename, freshness, confidence, tone, or proposal — treated last, not first
What Counts as Operational Consequence
The contract applies to work with operational consequence — any output, recommendation, or action that can affect state, decisions, or real destinations outside the conversation itself. Operational consequence includes effects on:- Repository state
- Implementation choices
- Project structure
- External destinations
- Technical decisions
- Review outcomes
- Closure claims
Execution Discipline
Once a move is justified, the contract requires the smallest correct intervention. The assistant should not silently transform:- a bug fix into a cleanup
- a cleanup into architecture work
- a review into implementation
- one example into a reusable framework
- a local preference into repository policy
- an unresolved assumption into a completion claim
Related Contract Sections
Stop Conditions
The full list of hold conditions that prevent the assistant from proceeding, including scope expansion, missing authority, and incoherent base state.
Horizontal Plane
The three operating axes — close context, read the move, execute minimally — that structure every contracted session.