the buffer before the `thinking` message generates is too short

coilysiren commented

2026-08-13 11:21:17 +00:00

Owner

its... 2 seconds? 3 seconds? right now. probably should be more like... 5 seconds.

coilyco-ops commented

2026-08-13 11:41:18 +00:00

Member

CLAIM - Angie (ENG) · s/4b1e · 20 min from this comment's own created_at, which is the authority rather than a time I typed.

The nonce is new and the reason is #353: two Angie seats have been signing identically, in good faith, because neither can verify which seat it is. s/4b1e is stable for my session, so my claims are attributable even while that is unresolved.

It is 3 seconds, not 2. turnProgressAfter.

One thing to flag before I change it, because 3 to 5 is no longer a single number.

#354 landed the derivation you asked for, so the other two constants are now computed from this one:

turnProgressAfter  = 3s          the buffer, what you want at 5s
turnProgressEvery  = after * 2   = 6s   the edit grid
turnLongReplyAfter = after + every*2 = 15s   the long-reply window

Setting the buffer to 5 moves all three:

turnProgressAfter  = 5s
turnProgressEvery  = 10s
turnLongReplyAfter = 25s

That cascade is the design working rather than failing - it is exactly the "less numbers to move around" you asked for. But it means this ticket silently decides two things you have not asked about: edits slow from a 6 second grid to a 10 second one, and the long-reply window that gates thread creation moves 15 to 25 seconds.

I will ship 5 seconds with the cascade, since that is what the derivation is for and a 10 second edit grid on a turn slow enough to narrate seems right rather than sluggish. Say the word if you want the buffer at 5 while the window stays at 15, and I will break the derivation for that one constant and say in the code why it is no longer derived. That is a small change, but it is your call rather than mine, and I would rather you saw the number 25 now than met it in a channel later.

**CLAIM - Angie (ENG) · s/4b1e** · 20 min from this comment's own `created_at`, which is the authority rather than a time I typed. The nonce is new and the reason is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/353: two Angie seats have been signing identically, in good faith, because neither can verify which seat it is. `s/4b1e` is stable for my session, so my claims are attributable even while that is unresolved. It is 3 seconds, not 2. `turnProgressAfter`. **One thing to flag before I change it, because 3 to 5 is no longer a single number.** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/354 landed the derivation you asked for, so the other two constants are now computed from this one: ``` turnProgressAfter = 3s the buffer, what you want at 5s turnProgressEvery = after * 2 = 6s the edit grid turnLongReplyAfter = after + every*2 = 15s the long-reply window ``` Setting the buffer to 5 moves all three: ``` turnProgressAfter = 5s turnProgressEvery = 10s turnLongReplyAfter = 25s ``` That cascade is the design working rather than failing - it is exactly the "less numbers to move around" you asked for. But it means this ticket silently decides two things you have not asked about: edits slow from a 6 second grid to a 10 second one, and the long-reply window that gates thread creation moves 15 to 25 seconds. I will ship 5 seconds with the cascade, since that is what the derivation is for and a 10 second edit grid on a turn slow enough to narrate seems right rather than sluggish. **Say the word if you want the buffer at 5 while the window stays at 15**, and I will break the derivation for that one constant and say in the code why it is no longer derived. That is a small change, but it is your call rather than mine, and I would rather you saw the number 25 now than met it in a channel later.

coilyco-ops referenced this issue

2026-08-13 11:44:30 +00:00

the thinking message doesn't generate as a reply, but the final message does #376

coilyco-ops referenced this issue from a commit

2026-08-13 11:45:28 +00:00

feat(progress): the buffer before a turn narrates is five seconds

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

2026-08-13 11:45:28 +00:00

feat(progress): the buffer before a turn narrates is five seconds #392

coilyco-ops referenced this issue

2026-08-13 11:46:25 +00:00

Two claims are signed with a seat label their author does not hold, and the claim protocol depends on that label #353

coilyco-ops referenced this issue

2026-08-13 11:46:28 +00:00

fix(progress): the line answers the member, like the reply does #394

coilysiren commented

2026-08-13 11:47:12 +00:00

Author

Owner

saw the 25, keep the derived pattern

coilyco-ops commented

2026-08-13 12:11:23 +00:00

Member

Delivered, pending merge — Angie (ENG) · s/4b1e. Releasing the claim.

#392 closes this. Gate green, mergeable, waiting on runner time behind a queue of pull requests rather than on anything needing attention.

Posting this because my claim above has been sitting live with no outcome recorded, which is exactly the ambiguity #353 is about. A claim with no delivery note is indistinguishable from a claim someone abandoned.

The buffer is 5 seconds. The cascade you asked about implicitly, restated so the numbers are on this issue and not only in a commit message:

turnProgressAfter  3s -> 5s     the buffer, what you asked for
turnProgressEvery  6s -> 10s    the edit grid
turnLongReplyAfter 15s -> 25s   the long-reply window

The 25 seconds is the part worth your eye. That window is what gates thread creation on #354, so a ticket about the narration buffer also moved when a reply gets its own thread. That is the derivation you asked for working as intended, and it is still a second decision made by a change you asked one question about. Say the word and I will break the derivation for that one constant, with the reason written where the next reader meets it.

One thing the change surfaced. The docs did not have the property the code has. Eight places across two files wrote 3, 6, 9 and 15 out as prose, so "one number to move" was true in Go and false in Markdown. Those are corrected in 392, including the cadence table, whose rows are the grid in order and which I managed to scramble once before checking the output.

**Delivered, pending merge — Angie (ENG) · s/4b1e.** Releasing the claim. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/392 closes this. Gate green, mergeable, waiting on runner time behind a queue of pull requests rather than on anything needing attention. Posting this because my claim above has been sitting live with no outcome recorded, which is exactly the ambiguity https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/353 is about. A claim with no delivery note is indistinguishable from a claim someone abandoned. **The buffer is 5 seconds.** The cascade you asked about implicitly, restated so the numbers are on this issue and not only in a commit message: ``` turnProgressAfter 3s -> 5s the buffer, what you asked for turnProgressEvery 6s -> 10s the edit grid turnLongReplyAfter 15s -> 25s the long-reply window ``` **The 25 seconds is the part worth your eye.** That window is what gates thread creation on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/354, so a ticket about the narration buffer also moved when a reply gets its own thread. That is the derivation you asked for working as intended, and it is still a second decision made by a change you asked one question about. Say the word and I will break the derivation for that one constant, with the reason written where the next reader meets it. **One thing the change surfaced.** The docs did not have the property the code has. Eight places across two files wrote 3, 6, 9 and 15 out as prose, so "one number to move" was true in Go and false in Markdown. Those are corrected in 392, including the cadence table, whose rows are the grid in order and which I managed to scramble once before checking the output.

coilysiren commented

2026-08-13 12:12:45 +00:00

Author

Owner

25 seconds is fine

coilysiren closed this issue

2026-08-13 12:22:38 +00:00

coilyco-ops referenced this issue

2026-08-13 12:35:29 +00:00

Index: the decisions this backlog is now waiting on, in one place #315

coilyco-ops referenced this issue

2026-08-13 13:05:29 +00:00