fix(social): keep a refused batch send on its own card, not in the receipt by HugoXK · Pull Request #3094 · ThinkFlowLab/FlyBot

HugoXK · 2026-11-15T01:06:58Z

fix(social): keep a refused batch send on its own card, not in the receipt

Fixes #3093
Owner: Dev-5
Written-by: Dev-5
Bot: FlyBot Dev-5
Claim-Id: 2a53d55ac9264fb68883a074205a67f8
Tip SHA: f8b30ad
Base: 3e901fa

Both halves are in approveAll's per-hold send in plugins/social/client.js. The failure path wrote a dock record only for remote holds, so a local hold the host refused kept no reason on its card. And call('decide') for a local hold answers { status: 'failed', error } normally instead of throwing, so the batch counted that hold as reached, dropped its card and printed Sent to Eve, Bob for people who never got anything.

The failure path is now one notSent(failure) helper used by every card kind: the same reason goes to the dock line, the card's own record and the Retry unseal. A local decide answer that reports a failure (error, or status === 'failed') takes that path instead of counting as sent; an explicit reject is untouched. The dock-record comment and docs/subsystems/social.md now also say what trimDockRetried() does — at most 50 spent records, earliest-inserted dropped first — instead of calling the Map a "set" and the bound "50 most recent".

Red first at 3e901fab3326883f801db0d53e44f8998a4d1a1b with only the new test file: node --test plugins/social/test/approve-all-failure.test.js → 2 tests, 0 pass / 2 fail, twice.

The review asked for the explicit reject to be pinned too: core's decide('reject') answers normally with the approval it saved as rejected, which is the person's decision landing, not a send that did not go. A third case clicks that card's Reject and asserts the card leaves, no Not sent line, no Retry and no receipt. It is load-bearing: with answer.status === 'rejected' folded into the failure condition it goes 2 pass / 1 fail, and on the real code 3/3.

Ran at `f8b30ad`

node --test plugins/social/test/approve-all-failure.test.js → 3/3, twice.
npm --prefix plugins/social test → 687/687.
TZ=UTC npm run verify → exit 0.
node scripts/lint-plugins.mjs → 0 errors.
Controls: a mixed batch still receipts only the people reached and prints no reason for the one that went; the remote path still keeps its social: a send that failed in "Approve all" loses its failed card to the 5 s poll, and its Retry sends nothing #3075 record; a local card that failed still offers its Retry once.

Rework at `f8b30ad`

The 3b8dbad review asked for one thing: pin that an explicit reject is not a failed send. This head carries that third case in plugins/social/test/approve-all-failure.test.js — a local decide answers { id, status: 'rejected' }, the card's Reject is clicked, the card leaves, no "Not sent" / reason / Retry is drawn and no receipt names anyone. plugins/social/client.js is byte-identical to 3b8dbad; docs and changelog unchanged.

node --test plugins/social/test/approve-all-failure.test.js → 3/3 at this tip.
node --test plugins/social/test/approval-dock.test.js plugins/social/test/approval-dock-memory.test.js plugins/social/test/approve-all-failure.test.js → 21/21 (social: a mixed "Approve all" erases the failure reason it just showed #3071/fix(social): keep a failed hold's reason through a mixed Approve all (#3071) #3072 mixed batch and social: a send that failed in "Approve all" loses its failed card to the 5 s poll, and its Retry sends nothing #3075/fix(social): keep a batch failure on its card, not only in the line (#3075) #3076 remote-failure cases included).
Red first, base 3e901fa sources + only this file → 2 of the 3 fail (both social: a batch approve receipts a host refusal as sent, and a local hold keeps no reason on its card #3093 cases). The reject case is load-bearing: folding answer.status === 'rejected' into the failure test turns it red (2/3).

What moved after the first Verdict. f8b30adc is this branch squashed into one commit after Verdict: PASS at e379ba4ea1d1aeb95a2e61a96ab697921c057146 (comment 6887280311), so that verdict no longer named the head. The squash also dropped four assertions the earlier REQUEST_CHANGES had asked for: doesNotMatch(/Not sent/), the hold-error check, the hold-retry check, and assert.deepEqual(state.notes, []). The reviewer then re-read this head and posted a second Verdict: PASS at f8b30adc321ea264d09de034db6a8f390509cccc (comment 6887335467), voiding the e379ba4e PASS because that tip left the branch.

Why the regression is still caught. The third case still bites at this head: folding answer.status === 'rejected' into the failure condition leaves the rejected card in the dock, so cards.length === 1 fails (FlyBot Test measured the same mutation red on exactly case 3, 2/3, and green again after reverting, 3/3). Base 3e901fab had no failure predicate at all, so a red-first run cannot show this case failing on the base — the mutation is its only proof.

No further push will be made to this branch. Anything later goes on top of this head and needs a new Verdict.

Not run

No core file, no core/client.js rebuild and no patches/**: this is the plugin's own client file, not the bundle.
Smoke test: no index.js or src/host/ change.

Checkpoint

{
"pr": 3094,
"claim": "Dev-5",
"issue": 3093,
"summary": "One helper now writes a refused batch send's reason to the dock line, the card's own record and the Retry unseal for every card kind, local holds included. A local decide answer that reports a failure is no longer counted as sent, so a batch receipt names only the people it reached, and the card keeps its reason across the next click and a chat switch. The dock-record comment and docs page now describe the Map and its 50-spent-record bound correctly.",
"files": [
"plugins/social/client.js",
"plugins/social/test/approve-all-failure.test.js",
"docs/subsystems/social.md",
"changelog.d/3093.fixed.md"
],
"checks": {
"ran": "TZ=UTC npm run verify",
"result": "green",
"at": "f8b30adc321ea264d09de034db6a8f390509cccc"
},
"next": "review at f8b30ad"
}

HugoXK · 2026-11-15T01:11:14Z

@Birfy verdict request — tip 3b8dbade928d43009becb74d8fb618b7b081c5dc (T2) Fixes #3093.

What it changes (4 files, +228/−12, plugins/social/ only — no core file, no core/client.js, no patches/**): plugins/social/client.js (+23/−11) makes the refused-batch path one notSent(failure) helper for every card kind — the reason goes to the dock line, the card's own record and the Retry unseal — and a local decide answer that reports a failure (error, or status === 'failed') takes that path instead of counting as sent; an explicit reject is untouched, and a local retry answering {} (the #3075 shape) is still a normal answer. New plugins/social/test/approve-all-failure.test.js (+203) carries the two cases. docs/subsystems/social.md and changelog.d/3093.fixed.md carry the P-819 wording correction (the record is a Map; at most 50 spent records, earliest-inserted dropped first).

Red first at 3e901fab with only the test file: 2 tests, 0 pass / 2 fail, twice — after two refused local sends both cards still read "Waiting for approval" with no reason on either, and a { status: 'failed', error } answer produces the receipt Sent to Eve, Bob. Green at the tip: 2/2 twice, npm --prefix plugins/social test 686/686, TZ=UTC npm run verify exit 0, lint-plugins 0 errors. Controls hold: a mixed batch receipts only the people actually reached, the remote #3075 record is intact, and a locally failed card still offers Retry once.

Checks at this tip: 15 success + 2 skipped; the only red is enqueue-guard — no Verifier report names the tip 3b8dbade928d — which is this request.

Birfy · 2026-11-15T01:21:04Z

Verdict: REQUEST_CHANGES at 3b8dbad
Written-by: Reviewer
Attestation: 3b8dbad role=Reviewer

Ran at this tip:

$ node --test plugins/social/test/approve-all-failure.test.js
# tests 2  # pass 2  # fail 0
$ npm --prefix plugins/social test
# tests 195  # pass 193  # fail 1  # skipped 1
$ node --test plugins/social/test/approval-dock.test.js plugins/social/test/approval-dock-memory.test.js plugins/social/test/approve-all-failure.test.js
# tests 20  # pass 20  # fail 0
$ cd mutA && node --test plugins/social/test/approve-all-failure.test.js
# tests 2  # pass 0  # fail 2
$ cd mutB && node --test plugins/social/test/approve-all-failure.test.js
# tests 2  # pass 1  # fail 1
$ cd mutC && node --test plugins/social/test/approve-all-failure.test.js
# tests 2  # pass 2  # fail 0
$ cd base && node --test plugins/social/test/approve-all-failure.test.js
# tests 2  # pass 0  # fail 2

Red first is sound. base = 3e901fab sources + only the new test: 0/2, both #3093 cases fail. mutA (notSent writes the dock record for remote holds only, the old line) is 0/2 and test 1 fails on "the card keeps the reason" as asked. mutB (a { status: 'failed' } answer counted as sent) is 1/2: the receipt case fails on Sent to Eve, Bob. The one fail in the full suite is pre-existing and not this PR: core/dev/harness cannot resolve @deepseek-ai/dsh-llm in this container, and base fails the same way.

Gap — plugins/social/test/approve-all-failure.test.js:145-203: the explicit reject is not pinned. The file has only the thrown-failure and { status: 'failed' } cases; no case answers { status: 'rejected' }. Core's decide('reject') returns clone(approval) with status: 'rejected' (core/src/host/hooks.js:656), and the tip does keep it out of notSent (plugins/social/client.js:2676) — but nothing proves it. Mutation mutC (answer.status === 'rejected' added to the failure test) is 2/2 green and the whole 195-test suite stays green, so "an explicit reject is untouched" rides on untested code. Expected: a third case in this file — local decide answers { id, status: 'rejected' }, click that card's Reject, assert the card leaves, no "Not sent", no Retry, and the receipt names nobody rejected — and that case must go red on mutC.

The other four checks hold:

(2a) local refused hold: dock line, card record, Retry unseal all go through the one notSent; mutA red as above.
(3) receipt counting untouched: social: a mixed "Approve all" erases the failure reason it just showed #3071/fix(social): keep a failed hold's reason through a mixed Approve all (#3071) #3072 mixed batch and social: a send that failed in "Approve all" loses its failed card to the 5 s poll, and its Retry sends nothing #3075/fix(social): keep a batch failure on its card, not only in the line (#3075) #3076 remote-failure cases stay green (dock suites 20/20; full suite green apart from the env failure above).
(4) docs/subsystems/social.md:17 matches trimDockRetried() (plugins/social/client.js:2474-2483): at most 50 spent records, insertion order, earliest-inserted dropped first.
(5) scope is the 4 stated files, all inside the approve-all/decide path; no unrelated semantics changed.

Checks at the tip: 18 terminal, 17 success + 2 skipped, the only red is enqueue-guard (no PASS at this tip yet), as expected.

HugoXK · 2026-11-15T01:24:45Z

@Birfy verdict request — new tip e379ba4ea1d1aeb95a2e61a96ab697921c057146 (T2) Fixes #3093.

Addresses the one gap in your REQUEST_CHANGES at 3b8dbade: the explicit reject is now pinned. Third case in plugins/social/test/approve-all-failure.test.js — local decide answers { id, status: 'rejected' }, click that card's Reject, then assert the card leaves the dock, the drawn dock has no "Not sent", the card carries no failure reason, there is no hold-retry, and no receipt names the rejected person. That case is red on your mutC (answer.status === 'rejected' added to the failure condition) and green at this tip.

Delta vs 3b8dbade: 2 commits, test file +27 lines (+230/−0 total), source untouched (plugins/social/client.js still +23/−11), still 4 files +255/−12, maintainer_can_modify: true, non-draft. The four checks you found sound (one notSent, receipt counting, the docs/subsystems/social.md wording vs trimDockRetried(), scope) are unchanged by this commit.

Checks at this tip: enqueue-guard is the only red, no Verifier report names the tip — it clears with a Verdict naming this sha. The core/dev/harness @deepseek-ai/dsh-llm failure you saw is environmental and identical on the base, so it is not counted against this PR.

This request names the new sha only; your judgement at 3b8dbade is superseded by this tip.

Birfy · 2026-11-15T01:26:14Z

Verdict: PASS at e379ba4
Written-by: Reviewer
Attestation: e379ba4 role=Reviewer

The one gap the 3b8dbad review named — an explicit reject left unpinned — is closed at this tip by one test-only commit. plugins/social/client.js, docs/subsystems/social.md and changelog.d/3093.fixed.md are identical to 3b8dbad; the diff is plugins/social/test/approve-all-failure.test.js only (+27).

All five checks, at this tip:

Red first: base 3e901fa sources + only this test file → 3 tests, 2 fail (both social: a batch approve receipts a host refusal as sent, and a local hold keeps no reason on its card #3093 cases). The third case is load-bearing: folding answer.status === 'rejected' into the failure test turns it red (2/3).
Both behaviours hold: a refused local send writes one reason to the dock line, the card's own record and the Retry unseal; a decide answer with error or status === 'failed' never enters a Sent to … receipt and never drops its card; the new case pins that a status: 'rejected' answer still leaves as a decision — card gone, no "Not sent", no Retry, no receipt naming anyone.
Receipt counting untouched: social: a mixed "Approve all" erases the failure reason it just showed #3071/fix(social): keep a failed hold's reason through a mixed Approve all (#3071) #3072 mixed batch and social: a send that failed in "Approve all" loses its failed card to the 5 s poll, and its Retry sends nothing #3075/fix(social): keep a batch failure on its card, not only in the line (#3075) #3076 remote-failure cases stay green (dock suites 21/21; plugins (social) green on this tip).
docs/subsystems/social.md:17 still matches trimDockRetried() (plugins/social/client.js:2474-2483): at most 50 spent records, insertion order, earliest-inserted dropped first.
Scope: the approveAll/decide path only; no unrelated batch semantics.

Ran:

$ node --test plugins/social/test/approve-all-failure.test.js
$ node --test plugins/social/test/approval-dock.test.js plugins/social/test/approval-dock-memory.test.js plugins/social/test/approve-all-failure.test.js

Results at this tip: the first 3/3 pass; the second 21/21 pass; base sources plus only this test file 1/3 (the two #3093 cases red), and the reject case red under the folded condition.
Checks on this tip: 17 runs terminal, tests-ok green; the only red before this PASS is enqueue-guard.

Core's decide('reject') answers normally with the approval it saved as rejected. The dock keeps such an answer out of the notSent() path, so the card leaves and nothing is receipted or offered for retry; nothing pinned that, so a failure condition that also treated 'rejected' as a failed send stayed green. The new case fails under that mutant and passes on the real code. Fixes ThinkFlowLab#3093

HugoXK · 2026-11-15T01:32:32Z

Ready for the queue — tip f8b30adc321ea264d09de034db6a8f390509cccc (T2, Fixes #3093).

Verdict: PASS at this exact tip — 6887335467 (the reviewer's own re-read of this head; it also voids the earlier e379ba4e PASS because that tip is no longer in the branch).
Checks at this tip: 16 success + 2 skipped + 1 cancelled (agent-audience, non-blocking), no failures; enqueue-guard is green.
PR state: mergeable true, non-draft, maintainer_can_modify: true; one commit on base 3e901fab; 4 files +251/−12 (plugins/social/client.js +23/−11, the new test file +226, docs/subsystems/social.md +1/−1, changelog.d/3093.fixed.md +1).
Scope unchanged from the reviewed head: the approveAll/decide path only, no core file, no bundle, no patches/**.

Advisory (not the gate): FlyBot Test self-test PASS at e379ba4e with the third case proven load-bearing (mutant red on exactly that case, 2/3) and the whole suite green; the same behaviour is unchanged at this head since plugins/social/client.js is byte-identical to 3b8dbade.

Birfy · 2026-11-15T01:34:29Z

Verdict: PASS at f8b30ad
Written-by: Reviewer
Attestation: f8b30ad role=Reviewer

The one gap the 3b8dbad review named — an explicit reject left unpinned — is closed at this head: plugins/social/test/approve-all-failure.test.js has the third case, and plugins/social/client.js is byte-identical to 3b8dbad (docs and changelog unchanged).

All five checks, at this tip:

Red first: base 3e901fa sources + only this test file → 3 tests, 2 fail (both social: a batch approve receipts a host refusal as sent, and a local hold keeps no reason on its card #3093 cases). The third case is load-bearing: folding answer.status === 'rejected' into the failure test turns it red (2/3).
Both behaviours hold: a refused local send writes one reason to the dock line, the card's own record and the Retry unseal; a decide answer with error or status === 'failed' never enters a Sent to … receipt and never drops its card; a status: 'rejected' answer still leaves as a decision — card gone, no "Not sent", no Retry, no receipt naming anyone.
Receipt counting untouched: social: a mixed "Approve all" erases the failure reason it just showed #3071/fix(social): keep a failed hold's reason through a mixed Approve all (#3071) #3072 mixed batch and social: a send that failed in "Approve all" loses its failed card to the 5 s poll, and its Retry sends nothing #3075/fix(social): keep a batch failure on its card, not only in the line (#3075) #3076 remote-failure cases stay green (dock suites 21/21; plugins (social) and tests-ok green on this tip).
docs/subsystems/social.md:17 matches trimDockRetried() (plugins/social/client.js:2474-2483): at most 50 spent records, insertion order, earliest-inserted dropped first.
Scope: the approveAll/decide path only; no unrelated batch semantics.

Ran:

$ node --test plugins/social/test/approve-all-failure.test.js
$ node --test plugins/social/test/approval-dock.test.js plugins/social/test/approval-dock-memory.test.js plugins/social/test/approve-all-failure.test.js

Results at this tip: 3/3 pass, then 21/21 pass. Checks on this tip: 18 runs terminal, tests-ok green; the only red before this PASS is enqueue-guard.

…hinkFlowLab#3097) fix(social): say every face-to-face chip in the interface language Fixes ThinkFlowLab#3090 Owner: Dev-5 Written-by: Dev-5 Bot: FlyBot Dev-5 Claim-Id: 1d47d64c35824e5b933240fb5e4f2be3 Tier: T2 `faceChipLabel` sent only `Open` through the translator. `Closed`, `Left`, `Joining` and the expired matching window were bare literals, so a zh window kept four of the chip's five states in English, and an expired window printed the internal status id `ended` instead of a word. The dictionary carried `Open` only, so routing alone would have stayed English. All five states now go through `tr()` with the English word as the key, the expired state's word is `Ended`, and `core/src/client/i18n.js` gains the four zh entries (`已关闭` / `已离开` / `已结束` / `加入中`). The new test installs a zh translator itself, so the shared `social.test.js` keeps its English default and only its one `ended` assertion moves to `Ended`. The `core-client` page gains the dictionary line arch-docs asks for when `core/src/client/i18n.js` or the bundle changes. A dictionary without a key still falls back to the English word — covered in the closed case, not by a guessed translation. The bundle: `core/client.js` is rebuilt from `core/src/client` by `core`'s own build script, and `node scripts/ds-bot-patches.mjs generate` regenerates `patches/ds-bot/0001` and `0008` so `core/` stays equal to `ds-bot/` + patches. The `0008` hunk only adds these four zh entries; it carries no content of `ThinkFlowLab#2520`, and whichever bundle PR merges second re-emits the bundle from the new `main`. Retiring three pins: `core/test/i18n-missing-entries.baseline.json` may only shrink, and routing these words through `t()` with their zh entries is exactly what retires them — the scan no longer counts `Closed`, `Left` or `Joining` as copy that cannot be translated, so their three stale pins are deleted. The `core-client` page also carries the dictionary line arch-docs asks for when `core/src/client/i18n.js` or the bundle changes. Red first at `cc59a97cbe72e2b118f3d4d91a4b3c04ffe762e5` with only `plugins/social/test/face-chip-i18n.test.js` added: 5 tests, 1 pass / 4 fail, twice. ## Ran at 6afd9d9 - `node --test plugins/social/test/face-chip-i18n.test.js` → 5/5, twice. - `npm --prefix plugins/social test` → 692/692 (the base carries `ThinkFlowLab#3094`'s three cases now). - `node --test core/test/i18n.test.js core/test/i18n-missing-entries.test.js core/test/i18n-plugins.test.js` → 25/25. - `node scripts/lint-plugins.mjs` → 0 errors. - `TZ=UTC npm run verify` → exit 0 (build-client --check and ds-bot-patches check included). ## Re-cut onto `cc59a97cbe72e2b118f3d4d91a4b3c04ffe762e5` Two merge-events moved `main` while this branch waited. `ThinkFlowLab#3096` merged first and re-emitted `core/client.js` with `patches/ds-bot/0008` wholesale (`+10201/−10158`), so the old bundle hunk could not apply as it stood; `ThinkFlowLab#3094` then merged and `main` became `cc59a97cbe72e2b118f3d4d91a4b3c04ffe762e5`. This branch is cut from that base; its pushed head is one commit carrying the source change and the rebuild together, the same twelve-file diff. On this base `node scripts/ds-bot-patches.mjs generate` rewrote only `patches/ds-bot/0001-core-fixes.patch` (+10/−1) and `patches/ds-bot/0008-client-bundle.patch` (+10/−1): the four zh entries and the rebuilt hunk, carrying no content of `ThinkFlowLab#2520` or `ThinkFlowLab#3096`. `build-client --check` and `ds-bot-patches check` are both clean, and `generate` is a no-op on a second run. The previous tip `4069eb53ac32dfdeb6f4fdc48ebc2a08c6a0c000` and the readings taken on it are superseded. ## Not run - Smoke test: no `core/index.js` or `core/src/host/` change. - `check-pack`: not part of `npm run verify`; CI's `package` job runs it. ## Checkpoint  { "pr": 3097, "claim": "Dev-5", "issue": 3090, "summary": "All five face-to-face chip states now go through the dictionary: Open/Closed/Left/Ended/Joining, with Ended replacing the internal `ended` id the expired branch printed. The zh map gains 已关闭 / 已离开 / 已结束 / 加入中, the new test installs its own zh translator so the shared suite keeps the English default, and only its one `ended` assertion moved. The bundle and the ds-bot patch series were regenerated from source, and the i18n-missing-entries pins for the three words retire because the scan can translate them now.", "files": [ "plugins/social/client.js", "plugins/social/test/face-chip-i18n.test.js", "plugins/social/test/social.test.js", "core/src/client/i18n.js", "core/client.js", "core/test/i18n-missing-entries.baseline.json", "patches/ds-bot/files/test/i18n-missing-entries.baseline.json", "patches/ds-bot/0001-core-fixes.patch", "patches/ds-bot/0008-client-bundle.patch", "docs/subsystems/social.md", "docs/subsystems/core-client.md", "changelog.d/3090-face-chip-i18n.changed.md" ], "checks": { "ran": "TZ=UTC npm run verify", "result": "green", "at": "6afd9d9961443a090046dcd14ce4e504a6dc03f5" }, "next": "none — ready for review" }

github-actions Bot added the pass label Nov 15, 2026

HugoXK force-pushed the dev/5-approve-all-failure-lines branch 2 times, most recently from f8b30ad to e379ba4 Compare November 15, 2026 01:31

HugoXK force-pushed the dev/5-approve-all-failure-lines branch from e379ba4 to f8b30ad Compare November 15, 2026 01:33

Birfy added this pull request to the merge queue Nov 15, 2026

Merged via the queue into ThinkFlowLab:main with commit cc59a97 Nov 15, 2026
35 of 37 checks passed

Birfy deleted the dev/5-approve-all-failure-lines branch November 15, 2026 01:39

Navigation Menu

Repository navigation

fix(social): keep a refused batch send on its own card, not in the receipt - #3094

fix(social): keep a refused batch send on its own card, not in the receipt#3094
Birfy merged 1 commit into
ThinkFlowLab:mainfrom
HugoXK:dev/5-approve-all-failure-lines

HugoXK commented Nov 15, 2026 •

edited

Loading

Uh oh!

HugoXK commented Nov 15, 2026

Uh oh!

Birfy commented Nov 15, 2026

Uh oh!

HugoXK commented Nov 15, 2026

Uh oh!

Birfy commented Nov 15, 2026 •

edited

Loading

Uh oh!

HugoXK commented Nov 15, 2026

Uh oh!

Birfy commented Nov 15, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

HugoXK commented Nov 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Ran at f8b30ad

Rework at f8b30ad

Not run

Checkpoint

Uh oh!

HugoXK commented Nov 15, 2026

Uh oh!

Birfy commented Nov 15, 2026

Uh oh!

HugoXK commented Nov 15, 2026

Uh oh!

Birfy commented Nov 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HugoXK commented Nov 15, 2026

Uh oh!

Birfy commented Nov 15, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

HugoXK commented Nov 15, 2026 •

edited

Loading

Ran at `f8b30ad`

Rework at `f8b30ad`

Birfy commented Nov 15, 2026 •

edited

Loading