USER TEST PLAN

tasks

Derived from: no git repository here (git status → `fatal: not a git repository (or

0/26 checked · 0 pass · 0 fail

Flows

check each step and final check

Ground truth: `tasks` is an empty scaffold, not a codebase

Proves the whole project is four empty directories and nothing else — before trusting any theory about where it came from, confirm there is nothing else here.

Persona / precondition: anyone about to act on ~/Projects/tasks for the first time, terminal open at ~/Projects/tasks, nothing modified yet.

0/5

Run ls -la ~/Projects/tasks. Expect: exactly one entry besides ./..:
eir-dc-motor — no README, no CLAUDE.md, no package.json, no .git.

Run find ~/Projects/tasks -type f. Expect: no output at all — the tree contains
zero regular files (confirmed: find ... -type f | wc -l prints 0, macOS-padded as
0).

Run find ~/Projects/tasks -type d. Expect: exactly three lines beyond the root:
~/Projects/tasks/eir-dc-motor, ~/Projects/tasks/eir-dc-motor/solution, and
~/Projects/tasks/eir-dc-motor/solution/solve.sh — that last one being a directory is
the anomaly F3 examines.

Run git status. Expect: fatal: not a git repository (or any of the parent directories): .git.

Final check: find ~/Projects/tasks | wc -l reports 4 (root + the three directories
above, nothing more) — the entire project, top to bottom.

Trace the debris to its source: terminus3's `new-eir-dc-motor` dispatch run

Proves this isn't a mystery — the tree's timestamp puts it inside one specific, named build run, not a manual mkdir or an unrelated tool.

Persona / precondition: F1 passed; same terminal; ~/Projects/terminus3 present on this machine.

0/5

Run stat -f "%Sm" ~/Projects/tasks/eir-dc-motor/solution/solve.sh (and re-run against
eir-dc-motor and eir-dc-motor/solution). Expect: Aug 4 10:21:42 2026 on all
three — one atomic creation event, not three separate ones.

Run cat ~/Projects/terminus3/_build/logs/vendor-runs/new-eir-dc-motor/dispatcher ~/Projects/terminus3/_build/logs/vendor-runs/new-eir-dc-motor/vendor. Expect:
conductor-197b70ae then codex — a named, logged build run, not a human at a shell.

Run stat -f "%N %Sm" ~/Projects/terminus3/_build/logs/vendor-runs/new-eir-dc-motor/dispatcher ~/Projects/terminus3/_build/logs/vendor-runs/new-eir-dc-motor/last. Expect: mtimes
10:16:31 and 10:24:34 on 2026-08-04 — the debris's 10:21:42 timestamp falls inside
that window, not before or after it.

Run python3 -c "import json; d=json.load(open('/Users/wolf/Projects/terminus3/_build/logs/vendor-runs/new-eir-dc-motor/last')); print(d['workdir']); print(any('/Projects/tasks/' in f for f in d['files_touched']))".
Expect: first line /Users/wolf/Projects/terminus3/_build/work/eir-dc-motor, second
line False — the run's own declared workdir, and its own self-reported
files_touched list, both point at terminus3 and never mention ~/Projects/tasks/.

Final check: cat ~/Projects/terminus3/_build/logs/vendor-runs/new-eir-dc-motor/exit reads 0 — this was a
successful, exit-0 build run that nonetheless left untracked debris the run itself never
reported.

Defect: `solution/solve.sh` is a directory, not a script (currently fails)

Proves the exact shape of the anomaly the dispatch run left behind: a required task file materialized as an empty directory instead of executable content.

Persona / precondition: F1–F2 passed.

0/4

Run file ~/Projects/tasks/eir-dc-motor/solution/solve.sh. Expect: a Frontier-Bench
task's solve.sh should be a real script — Bourne-Again shell script text executable, ASCII text (matching the sibling checked in step 2). This currently fails: the
actual output is /Users/wolf/Projects/tasks/eir-dc-motor/solution/solve.sh: directory.

Run file ~/Projects/terminus3/tasks/reviewing/eir-dc-motor/solution/solve.sh (the real,
completed sibling task). Expect: Bourne-Again shell script text executable, ASCII text — confirming the correct shape exists safely elsewhere; nothing was lost, only a
stray husk was left behind at the top-level path.

Run ls -la ~/Projects/tasks/eir-dc-motor/solution/solve.sh/. Expect (buggy, current
state): total 0 with only . and .. — a completely hollow directory, no script
content anywhere inside it.

Final check: treating solve.sh as a path component that got mkdir -p'd instead of
written as a file explains both the empty directory (step 3) and the fact that the run's
own files_touched log (F2.4) never mentions it — the write step for this particular path
silently became a directory-creation step instead.

Observify's board tells the truth about the debris

Proves the fleet dashboard doesn't launder this into looking like a real, staffed project — it should read as an untouched baseline stub.

Persona / precondition: the local Observify server reachable at http://127.0.0.1:8787 (confirmed live for this audit).

0/4

Run curl -s "http://127.0.0.1:8787/api/kanban?project=tasks" and read the backlog
column's single card. Expect: "reachable": true and the card's raw field reads
exactly Repo baseline — tasks project directory (no root README found).

In the same response, find the tasks entry inside the top-level projects array.
Expect: "baseline_only": true, "card_count": 1, "session_count": 0, and
"freshness": "unknown".

Check every other pipeline column for this project. Expect: in_progress,
running, in_development, testing, done, and deployed all show "cards": [].

Final check: nothing in the board claims a human ever worked this project — it matches
F1–F3's finding that tasks is untouched debris, not silently promoted into real work.

This document lights up Observify's `/testit` surface (the two-consumer proof)

Proves the board-book chapter and Observify's /testit auto-discovery are fed by this one file — no second authoring pass needed.

Persona / precondition: this file did not exist before this audit; step 1 was checked true before writing it, step 2 is checked true after.

0/4

Before this file existed, curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8787/testit/tasks returned 404 (verified 2026-08-07, moments before
this document was written). Re-run it now on a fresh checkout to confirm it still would
without this file present. Expect: 404 if USER_TESTING.md is absent.

With ~/Projects/tasks/USER_TESTING.md present (as it is now), run the same command.
Expect: 200.

Run curl -s http://127.0.0.1:8787/api/testit and find the entry with "slug": "tasks". Expect: "project": "tasks" and a progress.total greater than 0,
matching this document's own item count.

Final check: open http://127.0.0.1:8787/testit/tasks in a browser — it renders this
document's six flows as a checklist, proving the board-book chapter and the /testit page
are the same source file.

The leak is an isolated incident, not a recurring dispatch bug

Proves (or disproves) that terminus3's dispatch pipeline scatters debris on every run — checked here, not assumed.

Persona / precondition: F2's evidence chain established; ~/Projects/terminus3/_build present.

0/4

Run ls ~/Projects/terminus3/_build/logs/vendor-runs/. Expect: a list of ~90 named
runs (e.g. wall-hook, auger-screw, skeleton-shelf, new-valet-tray, …) alongside
eir-dc-motor and new-eir-dc-motor.

For three of those other names, check whether they leaked the same way:
[ -e ~/Projects/wall-hook ] && echo LEAKED || echo clean,
[ -e ~/Projects/auger-screw ] && echo LEAKED || echo clean,
[ -e ~/Projects/skeleton-shelf ] && echo LEAKED || echo clean. Expect: clean for
all three — no matching top-level directory under ~/Projects/.

Run ls ~/Projects | grep -v '^\.' and confirm tasks is the only vendor-run-shaped
stray name present. Expect: every other top-level entry is a real, intentional
project directory (matches the Observify project roster), not a bare task-slug.

Final check: across every completed terminus3 vendor run checked, exactly one
(new-eir-dc-motor, 2026-08-04) left a stray top-level directory — worth a guard in
dispatch.sh (e.g. assert pwd matches $wd after its cd), but not, on this evidence, a
proven recurring failure.

Not covered and why

**Whether eir-dc-motor's "new-" era working copy at

~/Projects/terminus3/tasks/eir-dc-motor/ (pre-promotion to tasks/reviewing/) still
exists or was cleaned up**: out of scope — this audit is about the top-level
~/Projects/tasks/ stray tree, not terminus3's own internal pipeline state.

Repairing or deleting the debris: this plan is read-only by design; fixing it (most

likely rm -rf ~/Projects/tasks, once a human confirms nothing else depends on it) is a
decision for a human, not something this document performs.

Reproducing the leak: re-running the exact codex dispatch to confirm it happens again

would cost a live vendor call and is not read-only; F6 checks the historical record
instead of forcing a repeat.

**Whether other, non-terminus3 tools on this machine also write relative paths from the

wrong cwd**: the pattern (a path meant to include a filename ending up mkdir -p'd
into a directory instead) may not be unique to this one run; a wider sweep is a separate
audit.

Results

Flow	Verdict	Failures → tickets
F1 ground truth
F2 trace to source
F3 solve.sh defect
F4 board honesty
F5 /testit discovery
F6 isolated vs systemic