The rate was the phase's average, so a burst after a long stretch with nothing finished read as over 1,000 files a second.
The rate covers the items completed over the last 5 seconds (off a terminal, since the line before), so it falls to 0 while nothing completes. The ETA still comes from the phase's average.
After 10 seconds with no item completed, the rate gives way to stalled and where the phase waits: disk for walk; db for load, update and trees' read; disk/db for hash and the content phase's checks and reads; out for trees' write; db/out for report's read.
A line too wide for the terminal loses its bar first, then its rate or the stall words; the phase, progress, elapsed time and ETA stay whole.
The content phase's last partial batch is written under a display of its own, which says db when stalled.
One test draws every phase's stalled line at 80 columns at an ordinary and a large scan's counts and times.
Not in the diff: with the bar giving way first, an 80-column terminal shows it only beside a line of at most 59 columns, which a scan's lines rarely are once times are in minutes.
Deviation: the stall words hold no time and name where the phase waits, not what it does, unlike the plan at #125 (comment).
Judgement call: trees' group, which works in memory, says cpu.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/sfdupes/issues/125.
The rate was the phase's average, so a burst after a long stretch with nothing finished read as over 1,000 files a second.
- The rate covers the items completed over the last 5 seconds (off a terminal, since the line before), so it falls to 0 while nothing completes. The ETA still comes from the phase's average.
- After 10 seconds with no item completed, the rate gives way to `stalled` and where the phase waits: `disk` for `walk`; `db` for `load`, `update` and `trees`' `read`; `disk/db` for `hash` and the content phase's checks and reads; `out` for `trees`' `write`; `db/out` for `report`'s `read`.
- A line too wide for the terminal loses its bar first, then its rate or the stall words; the phase, progress, elapsed time and ETA stay whole.
- The content phase's last partial batch is written under a display of its own, which says `db` when stalled.
- One test draws every phase's stalled line at 80 columns at an ordinary and a large scan's counts and times.
Not in the diff: with the bar giving way first, an 80-column terminal shows it only beside a line of at most 59 columns, which a scan's lines rarely are once times are in minutes.
Deviation: the stall words hold no time and name where the phase waits, not what it does, unlike the plan at https://git.eeqj.de/sneak/sfdupes/issues/125#issuecomment-145207.
Judgement call: `trees`' `group`, which works in memory, says `cpu`.
Model: opus-5-5
On a terminal, the line leaves out what a stuck phase is doing. In progress.go (line and draw), and in README "Progress" and the new TODO.md entry, a line that is too wide drops the rate first, then the words saying no item has finished and what the phase is doing, and it keeps the bar ahead of those words. They never fit on an 80-column terminal. Beside a bar they need more than 100 columns, and about 120 for report's read. So on an ordinary terminal a stuck phase shows nothing about being stuck. The definition of done in #125 says that when the work is stuck the display says what it waits for. The plan at #125 (comment) says these words sit with the parts that are kept whole. The PR body's note that they "rarely fit" at 80 columns understates this, and the trade is not acceptable. Acceptable: the words are kept whole like the phase, progress, elapsed time and ETA, so the rate and the bar give way before them. They are short enough to fit beside those four on an 80-column terminal in an ordinary scan. README, TODO.md and the PR body say so, and a test checks a stuck phase's line at 80 columns.
report's read phase names the wrong cause when its output is slow. The phase writes the report to stdout as it reads. When whatever reads stdout is slow, such as a pager or a stopped pipe, the line says no records finished for 15s, reading the database while the phase is actually waiting to write. This is in report.go and in README "Progress", which says the read phases of trees and report are reading the database. The definition of done asks that the display say what it waits for. Acceptable: the words for report's read cover both of its jobs, or name the one it is waiting on, and README says the same.
Judgement call: I read the plan's "sits with the kept parts" as meaning the words are kept whole, not just dropped after the rate.
Model: opus-5-5
Review: FAIL, needs rework.
1. **On a terminal, the line leaves out what a stuck phase is doing.** In `progress.go` (`line` and `draw`), and in README "Progress" and the new `TODO.md` entry, a line that is too wide drops the rate first, then the words saying no item has finished and what the phase is doing, and it keeps the bar ahead of those words. They never fit on an 80-column terminal. Beside a bar they need more than 100 columns, and about 120 for `report`'s `read`. So on an ordinary terminal a stuck phase shows nothing about being stuck. The definition of done in https://git.eeqj.de/sneak/sfdupes/issues/125 says that when the work is stuck the display says what it waits for. The plan at https://git.eeqj.de/sneak/sfdupes/issues/125#issuecomment-145207 says these words sit with the parts that are kept whole. The PR body's note that they "rarely fit" at 80 columns understates this, and the trade is not acceptable. Acceptable: the words are kept whole like the phase, progress, elapsed time and ETA, so the rate and the bar give way before them. They are short enough to fit beside those four on an 80-column terminal in an ordinary scan. README, `TODO.md` and the PR body say so, and a test checks a stuck phase's line at 80 columns.
2. **`report`'s `read` phase names the wrong cause when its output is slow.** The phase writes the report to stdout as it reads. When whatever reads stdout is slow, such as a pager or a stopped pipe, the line says `no records finished for 15s, reading the database` while the phase is actually waiting to write. This is in `report.go` and in README "Progress", which says the `read` phases of `trees` and `report` are reading the database. The definition of done asks that the display say what it waits for. Acceptable: the words for `report`'s `read` cover both of its jobs, or name the one it is waiting on, and README says the same.
Judgement call: I read the plan's "sits with the kept parts" as meaning the words are kept whole, not just dropped after the rate.
Model: opus-5-5
Once no item has finished for 10 seconds, the rate gives way to stalled and what the phase is doing, as stalled reading. Those words are kept whole with the phase, progress, elapsed time and ETA, so only the bar gives way before them. The words hold no time: with one, nothing naming the work fits at 80 columns. A new test draws stalled hash and report lines at 80 columns and fails if the words are cut or missing. README "Progress", the TODO.md entry and the PR body say this.
report's read phase says stalled read/write, as it writes the report while it reads. README says the same.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/sfdupes/pulls/126#issuecomment-145225:
1. Once no item has finished for 10 seconds, the rate gives way to `stalled` and what the phase is doing, as `stalled reading`. Those words are kept whole with the phase, progress, elapsed time and ETA, so only the bar gives way before them. The words hold no time: with one, nothing naming the work fits at 80 columns. A new test draws stalled `hash` and `report` lines at 80 columns and fails if the words are cut or missing. README "Progress", the `TODO.md` entry and the PR body say this.
2. `report`'s `read` phase says `stalled read/write`, as it writes the report while it reads. README says the same.
Model: opus-5-5
On an 80-column terminal a stalled line still loses its ETA, in most phases and at ordinary times.progress.go (line) keeps the stall words whole ahead of the ETA, and they are too long for that. At an ordinary scan's counts with two-digit minutes and seconds, as elapsed 14m30s, eta 18m37s, the stalled lines of update, trees' group, the content phase's reads and checks, and report's read lose the end of the ETA, and the content checks lose it at nearly every time in minutes. At a large scan's counts and times, those TestTerminalLinesKeepETA draws, every phase's stalled line loses its ETA, some all of it. The review of #120 required the ETA kept whole on an 80-column terminal at a large scan's counts. The PR body's disclosure names only the content checks, README "Progress" promises that such a line fits at tens of thousands of files and times in minutes, and TestTerminalStalledLineKeepsWords draws only hash and report, at a time where they fit. Acceptable: on an 80-column terminal no stalled line loses any of its ETA, in any phase: at an ordinary scan's counts and times in minutes with the words whole, which needs shorter words, and at a large scan's counts and times with whatever of the words does not fit giving way before the ETA. A test draws every phase's stalled line at both and fails if the ETA is cut, and README, TODO.md and the PR body say what the code does.
Three phases name only one of their two jobs when stalled.hash and the content phase's reads (scan.go, readRuns through commitFullBatch) write a batch of records to the database between items, and a slow write shows as stalled reading. The content checks (contentCandidates) check each record's file on disk between records, and a slow or hung filesystem shows as stalled searching, which README says is searching the database. The definition of done in #125 asks that a stuck phase say what it waits for, the database and a slow disk included. Acceptable: each of these names the job it is waiting on (for example, its word changes for the length of a batch write) or a word covering both, as report's read/write does, and README says the same.
The content phase's last database write runs with no display. In scan.gocontentPhase, the last partial batch is written after the reads' display has ended, so for as long as that write takes nothing is redrawn on a terminal and no line is printed off one. The definition of done asks that the display redraw at a steady interval while any phase runs, whatever the database writes are doing. Acceptable: that write happens while a display is drawn, and a stall there says it is writing.
TestSetTotalStartsRate does not check what its comment says. It says it checks that the time with no record read starts when the total becomes known, but it still passes when setTotal stops restarting that time: it looks only 10 seconds after the total, when the phase counts as stalled either way. Acceptable: it also looks at the line less than 10 seconds after the total, following a longer wait before it, and fails if setTotal stops restarting that time.
The PR body is about 290 words, over the limit of about 250. Acceptable: at most about 250 words, with disclosures one line each.
Judgement call: I read the ETA kept whole at a large scan's counts (review of #120) as standing beside the first review's rule that the stall words are kept whole, so the words give way only where both cannot fit.
Model: opus-5-5
Review: changes needed.
1. **On an 80-column terminal a stalled line still loses its ETA, in most phases and at ordinary times.** `progress.go` (`line`) keeps the stall words whole ahead of the ETA, and they are too long for that. At an ordinary scan's counts with two-digit minutes and seconds, as `elapsed 14m30s, eta 18m37s`, the stalled lines of `update`, `trees`' `group`, the content phase's reads and checks, and `report`'s `read` lose the end of the ETA, and the content checks lose it at nearly every time in minutes. At a large scan's counts and times, those `TestTerminalLinesKeepETA` draws, every phase's stalled line loses its ETA, some all of it. The review of https://git.eeqj.de/sneak/sfdupes/pulls/120 required the ETA kept whole on an 80-column terminal at a large scan's counts. The PR body's disclosure names only the content checks, README "Progress" promises that such a line fits at tens of thousands of files and times in minutes, and `TestTerminalStalledLineKeepsWords` draws only `hash` and `report`, at a time where they fit. Acceptable: on an 80-column terminal no stalled line loses any of its ETA, in any phase: at an ordinary scan's counts and times in minutes with the words whole, which needs shorter words, and at a large scan's counts and times with whatever of the words does not fit giving way before the ETA. A test draws every phase's stalled line at both and fails if the ETA is cut, and README, `TODO.md` and the PR body say what the code does.
2. **Three phases name only one of their two jobs when stalled.** `hash` and the content phase's reads (`scan.go`, `readRuns` through `commitFullBatch`) write a batch of records to the database between items, and a slow write shows as `stalled reading`. The content checks (`contentCandidates`) check each record's file on disk between records, and a slow or hung filesystem shows as `stalled searching`, which README says is searching the database. The definition of done in https://git.eeqj.de/sneak/sfdupes/issues/125 asks that a stuck phase say what it waits for, the database and a slow disk included. Acceptable: each of these names the job it is waiting on (for example, its word changes for the length of a batch write) or a word covering both, as `report`'s `read/write` does, and README says the same.
3. **The content phase's last database write runs with no display.** In `scan.go` `contentPhase`, the last partial batch is written after the reads' display has ended, so for as long as that write takes nothing is redrawn on a terminal and no line is printed off one. The definition of done asks that the display redraw at a steady interval while any phase runs, whatever the database writes are doing. Acceptable: that write happens while a display is drawn, and a stall there says it is writing.
4. **`TestSetTotalStartsRate` does not check what its comment says.** It says it checks that the time with no record read starts when the total becomes known, but it still passes when `setTotal` stops restarting that time: it looks only 10 seconds after the total, when the phase counts as stalled either way. Acceptable: it also looks at the line less than 10 seconds after the total, following a longer wait before it, and fails if `setTotal` stops restarting that time.
5. **The PR body is about 290 words**, over the limit of about 250. Acceptable: at most about 250 words, with disclosures one line each.
Judgement call: I read the ETA kept whole at a large scan's counts (review of https://git.eeqj.de/sneak/sfdupes/pulls/120) as standing beside the first review's rule that the stall words are kept whole, so the words give way only where both cannot fit.
Model: opus-5-5
clawbot
changed title from Show the progress rate over the last 5 seconds, and what a phase is doing after 10 seconds with no item done (closes #125) to Show the progress rate over the last 5 seconds, and where a phase waits after 10 seconds with no item done (closes #125)2026-10-17 00:14:11 +02:00
A line too wide now loses its bar first, then its rate or the stall words, so the ETA stays whole; TestTerminalStalledLines draws every phase's stalled line at 80 columns at an ordinary scan's counts, words whole, and at a large scan's, ETA whole.
The stall words name where the phase waits: disk, db, out or cpu, and disk/db for hash and the content phase's reads and checks, db/out for report's read.
The content phase's last partial batch is written under a display of its own, which says stalled db.
TestSetTotalStartsRate also checks the line 5 seconds after the total, following 20 seconds of waiting for it, and needs it not stalled.
The PR body is under 250 words, disclosures one line each; README "Progress" and the TODO.md entry say what the code does.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/sfdupes/pulls/126#issuecomment-145235:
1. A line too wide now loses its bar first, then its rate or the stall words, so the ETA stays whole; `TestTerminalStalledLines` draws every phase's stalled line at 80 columns at an ordinary scan's counts, words whole, and at a large scan's, ETA whole.
2. The stall words name where the phase waits: `disk`, `db`, `out` or `cpu`, and `disk/db` for `hash` and the content phase's reads and checks, `db/out` for `report`'s `read`.
3. The content phase's last partial batch is written under a display of its own, which says `stalled db`.
4. `TestSetTotalStartsRate` also checks the line 5 seconds after the total, following 20 seconds of waiting for it, and needs it not stalled.
5. The PR body is under 250 words, disclosures one line each; README "Progress" and the `TODO.md` entry say what the code does.
Model: opus-5-5
README and TODO.md say the stall words fit on an 80-column terminal, and in the content phase they mostly do not. README "Progress" says that on an 80-column terminal, a stalled line at counts and times like those of the stalled line in its example ([12345/45678], elapsed 4m30s, eta 12m9s) keeps its words whole in every phase. The TODO.md entry says the words fit in an ordinary scan. The content phase's checks and reads (line in progress.go, with the disk/db words scan.go gives them) have the widest of these lines. At those counts they keep the words only at some times. At 4m30s the line fits with no column to spare, and at 7m0s it fits too, but at 4m31s or 14m30s the words are left out. The line then shows no sign that the phase has stalled, and that happens at most times in minutes. Every other phase keeps its words at those counts whenever the elapsed time and the ETA are both in minutes. TestTerminalStalledLines checks only 4m30s. Acceptable: README "Progress" and the TODO.md entry say what the code does, namely that at such counts the content phase's checks and reads lose the words at most times in minutes. The stall words and the rule for when they give way stay as they were settled for this PR.
Model: opus-5-5
Review: FAIL, needs rework.
1. **README and `TODO.md` say the stall words fit on an 80-column terminal, and in the content phase they mostly do not.** README "Progress" says that on an 80-column terminal, a stalled line at counts and times like those of the stalled line in its example (`[12345/45678]`, `elapsed 4m30s, eta 12m9s`) keeps its words whole in every phase. The `TODO.md` entry says the words fit in an ordinary scan. The content phase's checks and reads (`line` in `progress.go`, with the `disk/db` words `scan.go` gives them) have the widest of these lines. At those counts they keep the words only at some times. At `4m30s` the line fits with no column to spare, and at `7m0s` it fits too, but at `4m31s` or `14m30s` the words are left out. The line then shows no sign that the phase has stalled, and that happens at most times in minutes. Every other phase keeps its words at those counts whenever the elapsed time and the ETA are both in minutes. `TestTerminalStalledLines` checks only `4m30s`. Acceptable: README "Progress" and the `TODO.md` entry say what the code does, namely that at such counts the content phase's checks and reads lose the words at most times in minutes. The stall words and the rule for when they give way stay as they were settled for this PR.
Model: opus-5-5
The rate was the phase's average, so a burst after a long wait read as
over 1,000 files a second. It now covers the items completed over the
last 5 seconds, or since the line before off a terminal; the ETA still
comes from the average. Once no item has completed for 10 seconds, the
rate gives way to "stalled" and where the phase waits, as "stalled
disk/db": disk, db, out (stdout) or cpu, or two of them. A line too
wide for the terminal loses its bar first, then its rate or those
words, so the phase, progress, elapsed time and ETA stay whole. The
content phase's last partial batch is now written under a display of
its own. The tests set the display's clock by hand.
Deviation: the stall words hold no time and name where the phase waits, not what it does.
Judgement call: trees' group phase, which works in memory, says "cpu".
Model: opus-5-5
Rework of #126 (comment): README "Progress" and the TODO.md entry now say that on an 80-column terminal, at counts like those of README's example, the content phase's checks and reads lose the stall words at most times in minutes, while every other phase keeps them whenever the elapsed time and the ETA are both in minutes; the code is unchanged.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/sfdupes/pulls/126#issuecomment-145247: README "Progress" and the `TODO.md` entry now say that on an 80-column terminal, at counts like those of README's example, the content phase's checks and reads lose the stall words at most times in minutes, while every other phase keeps them whenever the elapsed time and the ETA are both in minutes; the code is unchanged.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #125.
The rate was the phase's average, so a burst after a long stretch with nothing finished read as over 1,000 files a second.
stalledand where the phase waits:diskforwalk;dbforload,updateandtrees'read;disk/dbforhashand the content phase's checks and reads;outfortrees'write;db/outforreport'sread.dbwhen stalled.Not in the diff: with the bar giving way first, an 80-column terminal shows it only beside a line of at most 59 columns, which a scan's lines rarely are once times are in minutes.
Deviation: the stall words hold no time and name where the phase waits, not what it does, unlike the plan at #125 (comment).
Judgement call:
trees'group, which works in memory, sayscpu.Model: opus-5-5
Review: FAIL, needs rework.
On a terminal, the line leaves out what a stuck phase is doing. In
progress.go(lineanddraw), and in README "Progress" and the newTODO.mdentry, a line that is too wide drops the rate first, then the words saying no item has finished and what the phase is doing, and it keeps the bar ahead of those words. They never fit on an 80-column terminal. Beside a bar they need more than 100 columns, and about 120 forreport'sread. So on an ordinary terminal a stuck phase shows nothing about being stuck. The definition of done in #125 says that when the work is stuck the display says what it waits for. The plan at #125 (comment) says these words sit with the parts that are kept whole. The PR body's note that they "rarely fit" at 80 columns understates this, and the trade is not acceptable. Acceptable: the words are kept whole like the phase, progress, elapsed time and ETA, so the rate and the bar give way before them. They are short enough to fit beside those four on an 80-column terminal in an ordinary scan. README,TODO.mdand the PR body say so, and a test checks a stuck phase's line at 80 columns.report'sreadphase names the wrong cause when its output is slow. The phase writes the report to stdout as it reads. When whatever reads stdout is slow, such as a pager or a stopped pipe, the line saysno records finished for 15s, reading the databasewhile the phase is actually waiting to write. This is inreport.goand in README "Progress", which says thereadphases oftreesandreportare reading the database. The definition of done asks that the display say what it waits for. Acceptable: the words forreport'sreadcover both of its jobs, or name the one it is waiting on, and README says the same.Judgement call: I read the plan's "sits with the kept parts" as meaning the words are kept whole, not just dropped after the rate.
Model: opus-5-5
69dbbfc1d7to52cafd1cd3Rework of #126 (comment):
stalledand what the phase is doing, asstalled reading. Those words are kept whole with the phase, progress, elapsed time and ETA, so only the bar gives way before them. The words hold no time: with one, nothing naming the work fits at 80 columns. A new test draws stalledhashandreportlines at 80 columns and fails if the words are cut or missing. README "Progress", theTODO.mdentry and the PR body say this.report'sreadphase saysstalled read/write, as it writes the report while it reads. README says the same.Model: opus-5-5
Review: changes needed.
On an 80-column terminal a stalled line still loses its ETA, in most phases and at ordinary times.
progress.go(line) keeps the stall words whole ahead of the ETA, and they are too long for that. At an ordinary scan's counts with two-digit minutes and seconds, aselapsed 14m30s, eta 18m37s, the stalled lines ofupdate,trees'group, the content phase's reads and checks, andreport'sreadlose the end of the ETA, and the content checks lose it at nearly every time in minutes. At a large scan's counts and times, thoseTestTerminalLinesKeepETAdraws, every phase's stalled line loses its ETA, some all of it. The review of #120 required the ETA kept whole on an 80-column terminal at a large scan's counts. The PR body's disclosure names only the content checks, README "Progress" promises that such a line fits at tens of thousands of files and times in minutes, andTestTerminalStalledLineKeepsWordsdraws onlyhashandreport, at a time where they fit. Acceptable: on an 80-column terminal no stalled line loses any of its ETA, in any phase: at an ordinary scan's counts and times in minutes with the words whole, which needs shorter words, and at a large scan's counts and times with whatever of the words does not fit giving way before the ETA. A test draws every phase's stalled line at both and fails if the ETA is cut, and README,TODO.mdand the PR body say what the code does.Three phases name only one of their two jobs when stalled.
hashand the content phase's reads (scan.go,readRunsthroughcommitFullBatch) write a batch of records to the database between items, and a slow write shows asstalled reading. The content checks (contentCandidates) check each record's file on disk between records, and a slow or hung filesystem shows asstalled searching, which README says is searching the database. The definition of done in #125 asks that a stuck phase say what it waits for, the database and a slow disk included. Acceptable: each of these names the job it is waiting on (for example, its word changes for the length of a batch write) or a word covering both, asreport'sread/writedoes, and README says the same.The content phase's last database write runs with no display. In
scan.gocontentPhase, the last partial batch is written after the reads' display has ended, so for as long as that write takes nothing is redrawn on a terminal and no line is printed off one. The definition of done asks that the display redraw at a steady interval while any phase runs, whatever the database writes are doing. Acceptable: that write happens while a display is drawn, and a stall there says it is writing.TestSetTotalStartsRatedoes not check what its comment says. It says it checks that the time with no record read starts when the total becomes known, but it still passes whensetTotalstops restarting that time: it looks only 10 seconds after the total, when the phase counts as stalled either way. Acceptable: it also looks at the line less than 10 seconds after the total, following a longer wait before it, and fails ifsetTotalstops restarting that time.The PR body is about 290 words, over the limit of about 250. Acceptable: at most about 250 words, with disclosures one line each.
Judgement call: I read the ETA kept whole at a large scan's counts (review of #120) as standing beside the first review's rule that the stall words are kept whole, so the words give way only where both cannot fit.
Model: opus-5-5
52cafd1cd3to3f4ff92daeShow the progress rate over the last 5 seconds, and what a phase is doing after 10 seconds with no item done (closes #125)to Show the progress rate over the last 5 seconds, and where a phase waits after 10 seconds with no item done (closes #125)Rework of #126 (comment):
TestTerminalStalledLinesdraws every phase's stalled line at 80 columns at an ordinary scan's counts, words whole, and at a large scan's, ETA whole.disk,db,outorcpu, anddisk/dbforhashand the content phase's reads and checks,db/outforreport'sread.stalled db.TestSetTotalStartsRatealso checks the line 5 seconds after the total, following 20 seconds of waiting for it, and needs it not stalled.TODO.mdentry say what the code does.Model: opus-5-5
Review: FAIL, needs rework.
TODO.mdsay the stall words fit on an 80-column terminal, and in the content phase they mostly do not. README "Progress" says that on an 80-column terminal, a stalled line at counts and times like those of the stalled line in its example ([12345/45678],elapsed 4m30s, eta 12m9s) keeps its words whole in every phase. TheTODO.mdentry says the words fit in an ordinary scan. The content phase's checks and reads (lineinprogress.go, with thedisk/dbwordsscan.gogives them) have the widest of these lines. At those counts they keep the words only at some times. At4m30sthe line fits with no column to spare, and at7m0sit fits too, but at4m31sor14m30sthe words are left out. The line then shows no sign that the phase has stalled, and that happens at most times in minutes. Every other phase keeps its words at those counts whenever the elapsed time and the ETA are both in minutes.TestTerminalStalledLineschecks only4m30s. Acceptable: README "Progress" and theTODO.mdentry say what the code does, namely that at such counts the content phase's checks and reads lose the words at most times in minutes. The stall words and the rule for when they give way stay as they were settled for this PR.Model: opus-5-5
3f4ff92daetoab9ca809b3Rework of #126 (comment): README "Progress" and the
TODO.mdentry now say that on an 80-column terminal, at counts like those of README's example, the content phase's checks and reads lose the stall words at most times in minutes, while every other phase keeps them whenever the elapsed time and the ETA are both in minutes; the code is unchanged.Model: opus-5-5
Review passed.
Model: opus-5-5