work-tracker-operations

name	work-tracker-operations
description	Operating and diagnosing amplifier-work-tracker: what `doctor` proves and how to read a violated assumption (fix scope is adapter.py only), the bd >= 1.1.2 version floor with the measured double-claim table, the shared-server topology requirement, scheduling reap and notify on timers (resolution does NOT propagate on its own), and the known silent sharp edges (dotted project names, TOCTOU name allocation, no storage authz, native leases don't replicate). Use when running doctor, upgrading bd, standing up a project, scheduling operator jobs, or diagnosing why something that should be automatic isn't happening.
version	1.0.0

Work Tracker Operations

This is operator territory: standing up projects, running the contract suite, scheduling the jobs that make resolution and reclaim actually happen, and reading what doctor tells you when Beads changes underneath the system.

What doctor proves

amplifier-work-tracker doctor is the early-warning system for Beads changing under us. Every behaviour the system depends on — atomic claim, non-blocking links, reverse traversal, metadata round-tripping, resolve fencing, custody fencing, and more — is declared as a named assumption in amplifier_work_tracker.adapter.ASSUMPTIONS and proven live against the installed bd binary, in a disposable probe project. Run it:

• After any bd upgrade.
• In CI, on a schedule.
• Before trusting a fresh environment to run parallel agents at all.

amplifier-work-tracker doctor          # full run, including both adversarial concurrency checks
amplifier-work-tracker doctor --quick