odw status, odw logs, and the dashboard remain the primary supervision
surface. Operator scripts in scripts/ add workshop-oriented views over ODW
run directories, Git branch movement, and sibling worktree filesystem activity.
scripts/odw-list-runs tabulates runs from the ODW runs root, showing the
source project, status, last update, run id, and workflow name. It defaults to
running runs; filters widen or narrow the view:
scripts/odw-list-runs # running runs only
scripts/odw-list-runs --all --limit 20 # every status, newest first
scripts/odw-list-runs -s failed -s stopped # explicit statuses
scripts/odw-list-runs --source my-project # substring match on source
scripts/odw-watch tails events for every running run whose metadata records
a given source directory, printing recent history and then following new
events, discovering newly started runs as it polls:
scripts/odw-watch "$PROJECT" -n 20 # last 20 events, then follow
scripts/odw-watch "$PROJECT" --poll 2.0 # slower discovery/tail cadence
Both ODW scripts tolerate live writes (a torn status.json or event line is
re-read on the next pass) and warn on stderr when run state is genuinely
malformed. Both read --runs-dir (defaulting to ~/.odw/runs), so point them
at a sidecar-local runsRoot when a workshop overrides it.
scripts/git-commit-feed prints a live commit feed for local branches in a Git
repository. It prints an initial backlog, then follows branch-tip changes:
scripts/git-commit-feed "$PROJECT" # latest 10 commits, then follow
scripts/git-commit-feed "$PROJECT" --remotes # include remote-tracking refs
scripts/git-commit-feed "$PROJECT" -n 0 # follow-only
scripts/blinkentrees opens a Textual dashboard over sibling Git worktrees,
using Linux inotify to show file activity per worktree. Run it from the parent
directory that contains the worktrees, or pass that directory explicitly:
scripts/blinkentrees --pattern 'roadmap-*' .
scripts/blinkentrees --any-matching-dir /path/to/worktrees
A task's post-merge audit and a settled step's remediation triage each create
their own throwaway inspection worktree, which appears in blinkentrees
alongside the roadmap-* build worktrees. These inspection worktrees are built
with the same verified sequence the build worktrees use: fetch origin/<base>,
create with git donkey <slug> <base> (the configured base is passed
explicitly, because git donkey's no-argument default is always main), then
git reset --hard origin/<base> inside the new worktree and re-verify its base
sha. So audit and triage always inspect the current origin/<base> and can
never silently root on a stale local base. If an audit or triage agent reports
a "based on a stale commit" style failure, that sequence is where to look.