# Authority, State, and Steering Contract

## User authority

The active user objective is the primary task anchor after higher-priority
constraints. Preserve it verbatim enough to detect when a new instruction
changes safety, scope, priority, output, or intended mutation.

Do not treat a queue append, a memory write, or receipt acknowledgement as
proof that a steering instruction changed behavior.

## Safe-boundary steering

Apply steering at a safe boundary:

1. finish the current atomic tool action;
2. stop dispatching additional old-plan tools;
3. make the steering visible in the next request;
4. require a structured reconciliation when it changes safety, scope, priority,
   or a planned mutation;
5. mark the first later action that is actually affected.

The reconciliation must identify:

```text
input id
applied | not_applicable | needs_clarification
changed constraints
revised next action
```

This is a user-authority boundary, not a generic anti-exploration gate. It may
temporarily stop old-plan actions, but it must not turn ordinary tool use into
permanent controller choreography.

## Active state model

Keep a single current record for each category:

| Category | Must retain | Must retire |
| --- | --- | --- |
| Goal | current objective and scope | superseded tasks |
| Steering | latest unacknowledged active steering | acknowledged/superseded copies |
| Source evidence | current path/version/coverage/visibility | stale or duplicate wrappers |
| Mutation | latest affected paths and real result | speculative “changed” claims |
| Verification | current tests, results, stale state | retired duplicate failures |
| Recovery | one current evidence-backed next action | old controller recaps |

## Task epochs

When a user replaces the task rather than merely adds detail:

- archive the prior task state for audit;
- begin a new task epoch;
- do not let old todos/cards/evidence assert authority over the new objective;
- retain only enough prior evidence to avoid repeating known facts where it is
still relevant.

## Workboard and todo contract

Workboards and todos are planning/evidence structures. They should help an
agent see work decomposition, ownership, and proof obligations.

They must not deny a legitimate source read, edit, verifier, or investigation
merely because board topology is imperfect. If state needs repair, show it as
an advisory and let the model decide when to repair the bookkeeping.

## Completion authority

An agent may report a task result only from current evidence. A delegated
worker can return evidence and a recommendation. The parent/coordinator owns
acceptance, card completion, and final task truth.