Archilyzer · Source

archilyzer

Archilyzer
git clone https://archilyzer.pages.dev/source/archilyzer.git
Log | Files | Refs | README | LICENSE

commit d044af114ddf70fd38d176e98a1bf916df9469ef
parent 4fbd9ed6ef40ded8de52f9ec93ec7c2553a70ce4
Author: I Mean I'm Just Saying <imeanimjustsaying@kiwifarms.st>
Date:   Sun, 20 Sep 2026 17:46:19 -0400

docs: say what the walk skips, and what "ready N of M" counts

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Diffstat:
Mumtool/docs/clip-bench.md | 37+++++++++++++++++++++++++++++++------
Mumtool/docs/report-video.md | 4+++-
2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/umtool/docs/clip-bench.md b/umtool/docs/clip-bench.md @@ -182,13 +182,37 @@ before the edit. ## Walking the cut `p` and `n` (and the links in the header line) move to the previous and next -clip, computed server-side from the timeline's own order. Reviewing a cut is -watching nineteen clips in a row, and going back to the project page between each -one is nineteen round trips to re-find your place. The project page starts the -walk: one **"Walk the cut → start at `<first clip>`"** button above the rows, +clip **on the walk**, computed server-side. Reviewing a cut is watching nineteen +clips in a row, and going back to the project page between each one is nineteen +round trips to re-find your place. The project page starts the walk: one +**"Walk the cut → start at `<first clip on it>`"** button above the rows, because the per-row links are the right control for "go to that one" and the wrong one for "start". +### What the walk skips + +The walk visits the clips that still **need judgement** and are **fetched**, in +timeline order — so `p`, `n`, both header links, the start button and the jump +<kbd>y</kbd> makes after it confirms all go to the nearest one of those. + +- **Needs judgement** means no verdict: the same rule `N reviewed` counts by. + Walking back onto a clip somebody already answered is the round trip the walk + exists to remove. +- **Fetched** means some file in `out/clips-raw` holds this clip's own window + end to end. Not the *padded* window a build would download, and not an + overlap: a half-covered clip cannot be watched through, so there is nothing + to judge. Landing on one is a dead end whose only move is `n` again. + +A **URL still opens any clip**, judged or unfetched — the bench renders it, says +*"nothing fetched for this clip yet"* and carries a **not fetched yet** pill, +and its two links point at the fetched, unjudged neighbours either side. The +per-row link on the project page is that URL, so "go to that one" is unchanged. + +Both pages read **`ready N of M needing judgement`**: `M` is the clips with no +verdict, `N` the ones among them that can be judged today. The gap between the +two is what is waiting on a download rather than on you — every row the project +page marks **not fetched yet**. + ### Is this accurate? A clip is a **claim** — the report said somebody said this, here — so the right @@ -196,8 +220,9 @@ column opens with what this clip is *supposed to be* (its `quote`, and its `note`: why it is in the cut) and then asks the one question the walk exists to answer. -<kbd>y</kbd> confirms and **advances**, because in the yes case the next clip is -what you want and a walk of sixty clips should be one finger. <kbd>x</kbd> puts +<kbd>y</kbd> confirms and **advances** — to the next clip on the walk, which is +the next one that needs an answer and has something to play — because in the yes +case that clip is what you want and a walk of sixty clips should be one finger. <kbd>x</kbd> puts the cursor in the `correction` box and marks it **required**, because the note *is* the no answer — and saving it stays put, so it can be read back against the clip. That save is ONE patch, `{correction, verdict: "incorrect"}`, so the diff --git a/umtool/docs/report-video.md b/umtool/docs/report-video.md @@ -205,7 +205,9 @@ to let somebody undo a note they wrote before the rule existed would be a trap. `reviewOf()` is the one definition of coverage — the bench header's `N reviewed`, the project page's "Walk the cut" button and `umtool corrections -<project>` all read it, and the last opens with +<project>` all read it, and `walkReadiness()` reads the same verdict rule to +decide what the walk VISITS (unjudged and fetched — see +[clip-bench.md](clip-bench.md#what-the-walk-skips)), and the last opens with `N clips: A incorrect, B confirmed (C with a note), D not yet reviewed (ids: …)` so the walk's coverage is visible beside the defects it found.