warrior-authority

Files (1)

• SKILL.md

SKILL.md (first lines)

# Warrior authority model

An agent that can edit files is not thereby allowed to commit them. An agent
that can commit is not thereby allowed to push. Nothing at all confers
permission to delete.

Most agent damage is not a wrong edit. It is a correct edit applied with
authority the agent assumed it had.

## The five authorities are independent

| Authority | Grants | Never implies |
|---|---|---|
| **read** | inspect files, history, refs | edit |
| **edit** | change the working tree | commit |
| **commit** | write objects to local history | push |
| **push** | publish to one named remote | any other remote |
| **delete** | remove branches, worktrees, files, stashes | anything, ever — always separately requested |

Read them as a ladder that does not climb itself. Holding rung three tells you
nothing about rung four. An agent that reasons "I was allowed to commit, so
presumably I may push" has invented authority.

Push authority is **per remote**, not global. Approval to push `origin` is not
approval to push `upstream`, a fork, or a private mirror.

## Authority is recorded, not inferred

Authority must live in a durable record the agent reads, not in the agent's
recollection of the conversation. Give every unit of work an explicit row:

```
work_item_id        what this change belongs to
repository_path     the canonical repository that owns the files
branch              the branch this work may touch
file_scope          the exact paths in scope, enumerated
commit_authority    none | local
push_authority      none | approved
push_remote         the one named remote, when push is approved
```

Two consequences follow, and both matter:

- Authority is scoped to **this repository and this work item**, not to the
  agent. The same agent may hold `commit=local push=approved` on one work item
  and `commit=none` on another, at the same time.
- An agent that cannot find a record grants itself nothing. Absence of a
  record is absence of authority, never a default of convenience.

## Never infer authority from

- being able to edit the file;
- the repository being private;
- the repository being the agent's "own" project;
- a plan having been shown to the human and not objected to — **showing a plan
  is not consent**;
- a previous approval for a similar operation;
- the operation being reversible in principle;
- the work being obviously correct;
- the human being busy, absent, or asleep.

## Evidence standards

**A zero exit code is not proof of anything.** Verify the state you intended,
by observing that state.

- **Push landed?** Confirm the local HEAD commit appears among the remote's
  refs (`git ls-remote <remote>` and compare against `git rev-parse HEAD`).
  Never trust the push command's exit status. A push into an already
  up-to-date repository can exit 0 having transmitted nothing, which is
  indistinguishable from success unless you check the refs.
- **Transport matters.** A filesystem path may support `ls-remote`, `clone`
  and `fetch` while rejecting every push at the receiving hook. Validate the
  transport you intend to publish over, and prefer SSH for publishing.
- **Never push into a pull-mirror.** A pull-mirror is overwritten from its
  upstream on a schedule. Anything pushed directly into one is destroyed at
  the next sync, silently and completely. Detect mirror status before
  publishing and refuse rather than proceed.
- **A mirror protects committed objects only.** Shelves, index-only blobs,
  stashes, untracked files and unreachable commits have no protection from any
  remote whatsoever. Never describe a repository as "backed up" on the
  strength of a mirror existing.
- **Builds are not behaviour.** Compiling, and passing type checks, are not
  evidence a change works. Say what you verified and what you did not.

## Model identity is part of authority

When work is delegated to a model through an adapter, record the model that
**answered**, not only the model that was **requested**. Adapters fall back.

A real, observed case: a session was requested as one vendor's large model at
high reasoning effort; the error returned named an entirely different vendor's
small model, which does not accept effort settings at all. The request and the
responder had diverged silently. Any claim about capability, cost, or quality
based on the requested model would have been false.

So keep `requested_model` and `model` as separate fields, treat a mismatch as
a first-class incompatibility, and preserve that record as evidence rather
than retrying over it.

## Before any Git mutation, state

1. the work item and its bounded objective;
2. the canonical repository, and the owner of every nested repository touched;
3. current branch, HEAD, upstream, ahead/behind, remotes;
4. pre-existing dirty or untracked files, explicitly **excluded**;
5. the exact files proposed, enumerated — never `git add .`, never `-A`;
6. the validation performed, and its result;
7. the proposed commit message;
8. whether commit authority exists for this exact scope;
9. whether push authority exists, and the named remote;
10. recovery facts that do not depend on uncommitted work being mirrored.

If any of these is unknown, the correct output is a **checkpoint plan**, not an
operation.

## Inspection must not mutate

Read-only means read-only in practice, not in intent:

From deanhowe/warrior, MIT.

More from deanhowe/warrior