Bounded v1 · rc.1 prerelease

Honesty for Agents.

Pick up the right task, in the right repository, at the right revision.

Overseer Kit keeps one trusted NEXT handoff per repository. It checks the context before an agent session begins and makes every replacement deliberate.

$ ./.overseer/bin/ok status
repository · branch · revision · NEXT
$ ./.overseer/bin/ok next
validated handoff ready

Get v1.0.0-rc.1 Git-only quickstart View on GitHub

The release is a prerelease. Installation is checksum verified and uses a fixed local source path.

Overseer flow: initialize, check status, read trusted NEXT, and publish a reviewed replacement

The core safeguard

Technical detail

Before NEXT is printed: Overseer validates the repository UUID, physical root, selected authority, branch, revision, and handoff digest.

Daily read

./.overseer/bin/ok status
./.overseer/bin/ok next

Context check — the right task for this exact checkout

A copied prompt should not become another project’s work. Overseer compares on-disk identity and current version-control state before it prints the trusted handoff. A mismatch stops the read and leaves the task untouched.

One trusted NEXT

Readable — a plain-text task you can inspect before using it.
Bound — repository, branch, revision, lane, model label, and action identity travel with it.
Deliberate — replacing it requires the prior NEXT digest.

Repository · Branch · Revision

Repository — persistent UUID plus exact physical-folder binding.
Branch — confirms the workstream named by the handoff.
Revision — detects when work moved after the task was written.
Authority — Git or Muse is chosen explicitly for each repository.

The failure mode

Why context honesty matters

AI-assisted work breaks down when a good prompt is detached from the repository state that made it true.

Wrong repository
A handoff copied from a similar project looks plausible.
Stale revision
The branch moved after the task was written.
Lost handoff
A new session reconstructs intent from partial memory.
Accidental replacement
A task is overwritten without proving which version it replaced.

Overseer makes the handoff inspectable — and refuses to present it when its repository context no longer matches.

The real flow

How it works

Initialize once. Check the context. Read NEXT. Publish a reviewed replacement only when the task changes.

Initialize the repository
Choose Git or Muse explicitly, then bind the repository’s persistent identity and physical root.
Check status
See the active authority, repository, branch, revision, lane, model label, and NEXT digest.
Read trusted NEXT
Validate and print the handoff. Overseer does not run it or decide whether the task is good.
Replace it deliberately
Review the new task and publish it with exact context plus the previous NEXT digest.

Structure at a glance

The familiar diagrams are back, with labels aligned to the bounded v1 that actually ships.

Repository identity, branch, revision, and lane lead to one trusted NEXT handoff — One handoff is bound to one repository context. Lane remains a label inside that context.

Version-control choices: Git-only, Muse with a GitHub mirror, and Muse-only — Git-only is permanently supported. Muse authority and an optional GitHub mirror are explicit choices.

Repository identity, current branch and revision, and NEXT digest checks — Three checks establish whether a handoff belongs to the current checkout.

Overseer Kit source initializes a repository with local configuration and a trusted NEXT handoff for an agent session — The kit installs a repository-bound launcher. Your agent session remains separate and under your control.

Small by design

What Overseer does — and does not do

Local CLI
It runs in a repository you are authorized to manage.
No automatic execution
It prints a task; it does not run the prompt.
No automatic merge
Mirror delivery may open a pull request; the operator reviews and merges.
No hosted product
No service, desktop app, background process, telemetry, or updater.

Hooks are optional and off by default. Overseer protects against stale context and ordinary mistakes on a trusted host; it is not a security boundary against a malicious administrator.

Get started

Choose the version-control mode that matches the repository. Git-only requires no Muse installation, account, or future migration.

Git-only

Permanently supported. Initialize an existing Git checkout and keep all daily handoff work local.

Open the quickstart →

Muse-only

Explicitly initialize or adopt Muse authority. Freshness follows the selected Muse branch and revision.

Read adoption and rollback →

Muse + GitHub mirror

Prepare and verify a controlled projection. Explicit delivery can push the mirror and create a pull request; it never merges it.

Read the bridge workflow →

Install→Initialize→Status→NEXT→Reviewed replacement

Muse when it fits the repository

Git-only remains a complete ongoing mode. Muse can become the explicit authority, with or without a controlled GitHub mirror. The choice belongs to each repository.

See version-control choices · Bridge workflow

See it in practice

Five bounded-v1 examples show wrong-project protection, revision freshness, Git-only use, explicit Muse adoption, and controlled mirroring.

Open the scenario gallery →