Concepts/Definition

Application context: loading an entire repository can still omit the decisive information

A coding agent receives dozens of source files but does not know why the change is needed, which interfaces must remain stable, or which checks define success. Another receives only “fix login” without logs or reproduction steps. One has too much undirected material; the other lacks mandatory evidence.

Definition

A Context Contract specifies what a task must know before it starts, what may be loaded on demand, source precedence, and acceptance material. A useful structure covers Why (goal and business reason), What (objects, scope, and non-goals), How (constraints, interfaces, and available capabilities), and Acceptance (tests, receipts, or human judgement).

Engineering mechanism

P1 information is mandatory before execution, such as the target object, authority scope, and interfaces that may not break; absence triggers clarification. P2 information is loaded per step, such as neighbouring code, past decisions, and domain material. Retrieval may supply P2 items, but each retains source, version, and scope. The contract is versioned, and the trace records which entries were actually loaded.

Boundary

A Context Contract does not collect everything up front. It controls the boundary through mandatory and on-demand information. Open exploration can use a broad Why and acceptance definition; operations that write external state require tighter goals, authority, and mechanical state.