fix(threads): name a thread from our own words, never the member's #1058

Merged

coilysiren merged 1 commit from fix/thread-names into main

2026-08-19 05:12:52 +00:00

coilyco-ops commented

2026-08-19 05:09:15 +00:00

Member

Closes #1036.

One correction to the issue's premise

#1036 says Discord takes the thread name from the summoning message and truncates it. Discord never chose those names - we did.

threadCreationName fell back to threadNameFor, which lifts the member's message and trims it to threadTitleRunes, which is 60. That is exactly the "about 60 characters" the issue measured. The mechanism is ours and it is one function.

This matters because it makes the fix smaller and more certain than the issue expected: nothing needs to be worked around, one fallback needs to stop existing.

What changed

The derivation is deleted rather than bounded. Bounding it better would still put somebody else's sentence under "Dowel started a thread:".

A generated title is still used whenever there is one. threadTitle and its one regeneration are untouched, so #1036's second rejected alternative is not being introduced - it already shipped and this does not extend it.
An untitled thread takes threadNameFallback, which the harness already owned for the all-punctuation case. Nothing new was invented to name a thread.
threadNameFrom stays. It still cleans the titler's own output at line 95, so removing it would be removing a different guard.

Acceptance, against the issue's own wording

Every thread the lane opens carries a name the harness chose. No THREAD_CREATED notice contains truncated text lifted from another author's message.

Both hold by construction now: there is no code path from a member's message to a thread name.

Tests

Two tests asserted the old behaviour, one of them named TestAThreadNameComesFromTheMemberNotFromUs. Keeping them would have locked in the defect, so they are replaced by one asserting the opposite, run against the real string from the export:

Content: "feed cracked 104 exhibitors full roster attached endpoint follows"

and checking that none of exhibitors, cracked, roster reaches the name. A second test covers the half that must not regress: a generated title still survives, and still gets bounded.

go test ./... clean apart from TestRenderedPromptsStayInsideTheirBudget, which is main's and which #1055 fixes.

Scope

One file plus its test. No deploy config, no roster, no chart. It rides the next image with everything else.

Closes #1036. ## One correction to the issue's premise #1036 says Discord takes the thread name from the summoning message and truncates it. **Discord never chose those names - we did.** `threadCreationName` fell back to `threadNameFor`, which lifts the member's message and trims it to `threadTitleRunes`, which is 60. That is exactly the "about 60 characters" the issue measured. The mechanism is ours and it is one function. This matters because it makes the fix smaller and more certain than the issue expected: nothing needs to be worked around, one fallback needs to stop existing. ## What changed The derivation is **deleted rather than bounded**. Bounding it better would still put somebody else's sentence under "Dowel started a thread:". * A generated title is still used whenever there is one. `threadTitle` and its one regeneration are untouched, so #1036's second rejected alternative is not being introduced - it already shipped and this does not extend it. * An untitled thread takes `threadNameFallback`, which the harness already owned for the all-punctuation case. Nothing new was invented to name a thread. * `threadNameFrom` stays. It still cleans the **titler's own output** at line 95, so removing it would be removing a different guard. ## Acceptance, against the issue's own wording > Every thread the lane opens carries a name the harness chose. No THREAD_CREATED notice contains truncated text lifted from another author's message. Both hold by construction now: there is no code path from a member's message to a thread name. ## Tests Two tests asserted the old behaviour, one of them named `TestAThreadNameComesFromTheMemberNotFromUs`. Keeping them would have locked in the defect, so they are replaced by one asserting the opposite, run against **the real string from the export**: ```go Content: "feed cracked 104 exhibitors full roster attached endpoint follows" ``` and checking that none of `exhibitors`, `cracked`, `roster` reaches the name. A second test covers the half that must not regress: a generated title still survives, and still gets bounded. `go test ./...` clean apart from `TestRenderedPromptsStayInsideTheirBudget`, which is main's and which #1055 fixes. ## Scope One file plus its test. No deploy config, no roster, no chart. It rides the next image with everything else.

coilyco-ops added 1 commit

2026-08-19 05:09:15 +00:00

fix(threads): name a thread from our own words, never the member's

ci / image-build (pull_request) Successful in 46s

Details

ci / test (pull_request) Successful in 1m11s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

f631885f5f

Seven THREAD_CREATED notices in #moxn-temporal carried somebody else's
sentence cut mid-word, under "Dowel started a thread:". It reads as the
agent parroting.

The mechanism is ours rather than Discord's, which #1036 assumed:
threadCreationName fell back to threadNameFor, which lifted the summoning
message and trimmed it to threadTitleRunes. Discord never chose those
names, we did.

The derivation is deleted rather than bounded. A generated title is still
used when there is one, and an untitled thread now takes threadNameFallback,
which the harness already owned for the all-punctuation case. threadNameFrom
stays: it still cleans the titler's own output.

The two tests asserting the name came from the member are replaced by one
asserting it cannot, checked against the real string from the export.

Closes #1036.

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-19 05:09:15 +00:00