Increase progress indicator delay and long-reply thread threshold ~50-66% #901

New issue

Closed

opened 2026-08-17 14:37:54 +00:00 by coilyco-ops-gaming · 1 comment

coilyco-ops-gaming commented

2026-08-17 14:37:54 +00:00

Member

Ask

Increase both of these by roughly 50-66%:

the delay before the progress indicator appears
the duration before a reply counts as long and should thread

Keep the resulting values whole numbers, and make sure downstream numbers still derive from the same base value so they scale together instead of drifting.

## Ask Increase both of these by roughly 50-66%: * the delay before the progress indicator appears * the duration before a reply counts as long and should thread Keep the resulting values whole numbers, and make sure downstream numbers still derive from the same base value so they scale together instead of drifting.

coilyco-ops-gaming added the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-17 14:37:54 +00:00

coilyco-ops added the

labels

2026-08-17 16:33:57 +00:00

coilysiren removed the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-17 17:27:47 +00:00

coilyco-ops referenced this issue from a commit

2026-08-17 18:39:38 +00:00

feat: raise the turn progress cadence 60%

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-17 18:39:52 +00:00

feat: raise the turn progress cadence 60% #920

coilyco-ops commented

2026-08-17 18:40:07 +00:00

Member

Built and in review at #920. Angie (ENG, claude seat).

Both up 60%, inside your 50 to 66%, and every value a whole number of seconds:

progress delay      5s ->  8s
beat               10s -> 16s
long-reply window  25s -> 40s

One edit does it. SIRENS_ECHO_PROGRESS_AFTER is the only knob; the beat is twice it and the window is the wait plus two beats, both computed in deriveKnobs. So your last requirement was already satisfied by construction, and picking 8 was the whole decision: it is the only whole second that puts both requested numbers inside the band.

The drift you were guarding against exists one layer up, and this fixes that too. The expected values were pinned as literals in three separate test files, so raising the base failed all three, each with its own hardcoded copy. They now read one var block in cadencederivation_test.go and the next raise edits one file. TestTheCadenceIsDerivedAndNotThreeCoincidences still asserts the relationship on its own, so a derivation that quietly stopped deriving still fails.

Built and in review at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/920. Angie (ENG, `claude` seat). Both up **60%**, inside your 50 to 66%, and every value a whole number of seconds: ``` progress delay 5s -> 8s beat 10s -> 16s long-reply window 25s -> 40s ``` **One edit does it.** `SIRENS_ECHO_PROGRESS_AFTER` is the only knob; the beat is twice it and the window is the wait plus two beats, both computed in `deriveKnobs`. So your last requirement was already satisfied by construction, and picking 8 was the whole decision: it is the only whole second that puts *both* requested numbers inside the band. **The drift you were guarding against exists one layer up, and this fixes that too.** The expected values were pinned as literals in three separate test files, so raising the base failed all three, each with its own hardcoded copy. They now read one `var` block in `cadencederivation_test.go` and the next raise edits one file. `TestTheCadenceIsDerivedAndNotThreeCoincidences` still asserts the relationship on its own, so a derivation that quietly stopped deriving still fails.

coilyco-ops referenced this issue

2026-08-17 18:56:39 +00:00

fix: keep the progress line updating past the wait-column cap #922

coilysiren closed this issue

2026-08-17 19:11:16 +00:00