morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #4267] [CLOSED] fix(go): report a missing main-module record as an unknown dependency list #6147

New issue

Closed

opened 2026-10-31 01:12:13 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:12:13 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4267
Author: @Y0UW1SH
Created: 10/15/2026
Status: ❌ Closed

Base: main ← Head: fix/4191-go-missing-main-module-limitation

📝 Commits (1)

50d4639 fix(go): report a missing main-module record as an unknown dependency list

📊 Changes

3 files changed (+102 additions, -21 deletions)

View changed files

📝 docs/go-binaries.md (+4 -0)
📝 src/go/GoBinaryProvider.ts (+32 -21)
📝 tests/boundary/go/goBinaryProvider.test.ts (+66 -0)

📄 Description

Status: incorporated upstream

The maintainer incorporated this fix into main in a05092726f1283d32b2afe761f430abd2de18386. That commit explicitly references #4191 and #4267 and credits @Y0UW1SH as co-author.

The upstream version retains the same missing-main-module condition, improves the wording to distinguish unknown dependency coverage from successfully decoded dependency records, documents parse completeness separately, and adds public CLI Evidence coverage. This draft is superseded; its original implementation does not need another submission.

Verification of the incorporated change

Executed against upstream d52a488476e7c41f573f23a1965d3f32d4e6a7f2 on Linux x64 with the pinned Node 24.18.0/npm 11.16.0 and locked dependencies:

npm run test:focused -- tests/boundary/go/goBinaryProvider.test.ts tests/boundary/go/goBinaryMappings.test.ts tests/boundary/go/goBinaryImage.test.ts tests/boundary/go/goModuleText.test.ts tests/boundary/mcp/goBinaryMcp.test.ts tests/acceptance/goBinaryCli.test.ts: runtime build succeeded; all 160 tests passed across six files.
Six additional authored scenarios passed through both the public compiled CLI and SDK stdio MCP: GOPATH metadata, legacy nil-pointer/zero-length module metadata, decoded dependencies without a main record, malformed main metadata with a valid dependency, non-UTF-8 main metadata with a valid dependency, and module-mode metadata with no dependencies. Checked retained dependency fields, parse completeness, matching normalized results, and limitation propagation into Evidence; the MCP session remained responsive.
Source/diff review found no additional correctness defect in the incorporated coverage semantics.
npm run check did not pass: it stopped on an existing formatting issue in src/adb/AdbProvider.ts on this unchanged upstream checkout. This is unrelated to the Go fix; later check stages are not claimed as passing.
No new real Go toolchain or Windows/macOS verification was performed. The additional scenarios use authored executable-format fixtures.

Original draft proposal and earlier validation

Summary

inspect_go_binary / inspect-go-binary returned module.dependencies: [] with module.complete: true and no limitation for Go binaries whose embedded build information has no mod record, which is how Debian's dh-golang GOPATH-mode builds (gh, hugo, rclone, restic, …) embed their metadata. An agent or SBOM workflow reads that as "no third-party modules", although those binaries carry dozens of dependencies that the record simply does not list. Evidence for such binaries now carries a limitation stating that the main module and dependency list are unknown, not empty. Fixes #4191.

Problem and expected behavior

Trigger: a build-info record whose module text holds a path line and build settings but no mod/dep lines (GOPATH mode), or an empty module string (moduleless Go 1.12–1.17 builds). GoModuleText parses both completely, so complete is true, and GoBinaryProvider only added limitations for a missing build-info record, non-UTF-8 strings and incomplete parsing. Nothing marked the dependency list as unknown.

Violated invariant: explicit unknowns must stay visible. docs/go-binaries.md promises that unfamiliar, malformed or undecodable records "do not disappear behind a complete result", and AGENTS.md requires preserving omission and explicit unknowns across boundaries.

Expected: module.main: null and module.dependencies: [] stay as observed, and the result and Evidence limitations state that the main module and dependency list are unknown rather than empty. A module-mode build with a mod record and no dep lines keeps its genuinely empty list without that limitation.

Change and scope

src/go/GoBinaryProvider.ts: the limitations list now comes from a limitationsFor(info, module) helper. It adds No main-module record was decoded from the embedded module information, as in GOPATH-mode builds; the main module and dependency list are unknown, not empty. whenever parsed module metadata has main === null. The existing limitation strings and their conditions are unchanged; moving them into the helper keeps inspect within the lint complexity budget it already exceeded (the complexity warning on inspect is gone, the pre-existing one on failureForPrimary is untouched).
docs/go-binaries.md: documents the behavior.
tests/boundary/go/goBinaryProvider.test.ts: regression coverage (below).

Intentionally not included: the optional module_mode field suggested in #4191. It would change the inspect_go_binary output contract and generated catalog, while the limitation delivers the same information within the existing contract. complete keeps its meaning (every module-text line was parsed). GoModuleText.ts is untouched: it reports what the record contains, and the provider owns the statement of what remains unknown, as for the other limitations.

Maintainer scope decision: not applicable (ordinary fix within an existing read-only inspection).

Contract and boundary impact

Semantic owner and earliest changed stage: GoBinaryProvider.inspect limitation assembly, after module-text parsing and before output-schema validation.
Contribution scope fit and linked maintainer decision: existing read-only format inspection; none required.
CLI and MCP/tool-catalog contract: input and output schemas unchanged; one additional conditional string in the existing limitations array of the normalized result and of the Evidence.
Provider, bridge, target-format, or platform compatibility: none; built-in TypeScript reader, all supported containers.
Evidence, artifact, provenance, or reconstruction contract: Evidence limitations gain the conditional entry; observed fields, digests and source ranges unchanged.
Target selection, authority, upstream behavior, and cleanup details: not applicable.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: none; limitation strings are not catalog content (metadata:check passed inside npm run check).

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated: tests/boundary/go/goBinaryProvider.test.ts gains three cases on authored ELF fixtures from tests/fixtures/go/image.ts: (1) GOPATH-mode module text (path + build lines only) and (2) a moduleless legacy pointer-encoded image whose module string header holds a nil pointer and zero length both return main: null, dependencies: [], complete: true and the new limitation; (3) control: a module-mode record with mod and no dep lines keeps dependencies: [] with no such limitation.

Base reproduction or other evidence: executed. On the base revision 2202e3f0b the GOPATH-mode case fails with exactly the three fixed limitations and nothing about the dependency list:

AssertionError: expected [ …(3) ] to deep equally contain StringContaining{…}
+ Received:
[
  "Embedded build metadata is observed file content, not proof of compiler identity, dependency authenticity or runtime behavior.",
  "Only Go build information is inspected; function names, source mappings, type metadata and decompiled code are not recovered.",
  "Resource guards bound stable artifact reads and cumulative header searches to 256 MiB each, aggregate embedded strings to 1 MiB, structural table decoding to 16 MiB and complete metadata payloads to 8 MiB; these are not operating-system memory or CPU limits.",
]

User-visible CLI/MCP output: built CLI (node scripts/rea.mjs inspect-go-binary <file> --json, isolated HOME/XDG_*) on three authored fixtures, exit 0 and empty stderr each time. Printed fields are go_version, the module record (settings abbreviated to its count) and the limitations array of the returned Evidence.

GOPATH-mode fixture (path + five build settings, no mod/dep):

{"go_version":"go1.19.6","module":{"path":"example.com/tool/cmd/tool","main":null,"dependencies":[],"settings":5,"complete":true}}

limitations (4): the three fixed entries, then
 - No main-module record was decoded from the embedded module information, as in GOPATH-mode builds; the main module and dependency list are unknown, not empty.

Moduleless Go 1.17 fixture (pointer encoding, empty module string):

{"go_version":"go1.17","module":{"path":null,"main":null,"dependencies":[],"settings":0,"complete":true}}

limitations (4): the three fixed entries, then the same main-module limitation.

Control, module mode with no dependencies:

{"go_version":"go1.26.0","module":{"path":"example.com/tool","main":{"path":"example.com/tool","version":"(devel)","sum":"","replacement":null},"dependencies":[],"settings":1,"complete":true}}

limitations (3): only the three fixed entries.

The MCP route shares the provider, and GoBinaryService passes the limitations into the Evidence unchanged; tests/boundary/mcp/goBinaryMcp.test.ts keeps covering that propagation.

Remaining proof gaps: no real GOPATH-built binary (the Debian gh/hugo packages from the issue) was run; the fixtures are authored images from the repository's Go fixture builder that reproduce the record shape go version -m shows for them. npm run verify:go:binary needs a Go toolchain and was not run; it compares build information against debug/buildinfo and does not assert limitations.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Windows 11 x64, Node 24.21.0, npm 11.19.0, locked dependencies (npm ci), base main at 2202e3f0b.

node node_modules/vitest/vitest.mjs run tests/boundary/go/goBinaryProvider.test.ts before the fix — 2 new tests failed as shown above, 5 passed, 1 skipped.
Same command after the fix — 7 passed, 1 skipped (the symlink case is skipped on Windows).
node node_modules/vitest/vitest.mjs run tests/boundary/go/ tests/boundary/mcp/goBinaryMcp.test.ts — 5 files, 131 passed, 2 skipped.
npm run build:cached — passed.
node node_modules/vitest/vitest.mjs run tests/acceptance/goBinaryCli.test.ts against the rebuilt runtime — 26 passed, 1 skipped.
npm run check (typecheck, lint, format, knip, metadata, architecture guards) — passed, 0 lint errors.
npx tsc --noEmit — passed.
node scripts/verify-test-discovery.mjs — Discovered all 1368 test files exactly once.
node scripts/check-doc-facts.mjs — passed.
npx oxlint src/go/GoBinaryProvider.ts tests/boundary/go/goBinaryProvider.test.ts — no errors; one pre-existing complexity warning on failureForPrimary (also present on main), none on inspect any more.
npx oxfmt --check src/go/GoBinaryProvider.ts tests/boundary/go/goBinaryProvider.test.ts docs/go-binaries.md — formatted.
Not run: npm run verify:go:binary (no Go toolchain), Linux/macOS.

Compatibility, safety, and release

Breaking changes or migration steps: none; one additive, conditional limitation string.
Real Hopper/Ghidra, browser, or OS coverage: not applicable, no external provider; Windows only, verify:go:binary not run.
Package or release metadata impact: none.
Security, privacy, process, or containment review: none; the inspection stays a read-only file read without subprocesses or network access.

Author readiness

Human owner: @Y0UW1SH

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/4267 **Author:** [@Y0UW1SH](https://github.com/Y0UW1SH) **Created:** 10/15/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/4191-go-missing-main-module-limitation` --- ### 📝 Commits (1) - [`50d4639`](https://github.com/morluto/rea/commit/50d46393e2b8a41731194fb6085b9eeb94a91f48) fix(go): report a missing main-module record as an unknown dependency list ### 📊 Changes **3 files changed** (+102 additions, -21 deletions) <details> <summary>View changed files</summary> 📝 `docs/go-binaries.md` (+4 -0) 📝 `src/go/GoBinaryProvider.ts` (+32 -21) 📝 `tests/boundary/go/goBinaryProvider.test.ts` (+66 -0) </details> ### 📄 Description ## Status: incorporated upstream The maintainer incorporated this fix into `main` in [a05092726f1283d32b2afe761f430abd2de18386](https://github.com/morluto/rea/commit/a05092726f1283d32b2afe761f430abd2de18386). That commit explicitly references #4191 and #4267 and credits @Y0UW1SH as co-author. The upstream version retains the same missing-main-module condition, improves the wording to distinguish unknown dependency coverage from successfully decoded dependency records, documents parse completeness separately, and adds public CLI Evidence coverage. This draft is superseded; its original implementation does not need another submission. ### Verification of the incorporated change Executed against upstream `d52a488476e7c41f573f23a1965d3f32d4e6a7f2` on Linux x64 with the pinned Node 24.18.0/npm 11.16.0 and locked dependencies: - `npm run test:focused -- tests/boundary/go/goBinaryProvider.test.ts tests/boundary/go/goBinaryMappings.test.ts tests/boundary/go/goBinaryImage.test.ts tests/boundary/go/goModuleText.test.ts tests/boundary/mcp/goBinaryMcp.test.ts tests/acceptance/goBinaryCli.test.ts`: runtime build succeeded; all 160 tests passed across six files. - Six additional authored scenarios passed through both the public compiled CLI and SDK stdio MCP: GOPATH metadata, legacy nil-pointer/zero-length module metadata, decoded dependencies without a main record, malformed main metadata with a valid dependency, non-UTF-8 main metadata with a valid dependency, and module-mode metadata with no dependencies. Checked retained dependency fields, parse completeness, matching normalized results, and limitation propagation into Evidence; the MCP session remained responsive. - Source/diff review found no additional correctness defect in the incorporated coverage semantics. - `npm run check` did **not** pass: it stopped on an existing formatting issue in `src/adb/AdbProvider.ts` on this unchanged upstream checkout. This is unrelated to the Go fix; later check stages are not claimed as passing. - No new real Go toolchain or Windows/macOS verification was performed. The additional scenarios use authored executable-format fixtures. <details> <summary>Original draft proposal and earlier validation</summary> ## Summary `inspect_go_binary` / `inspect-go-binary` returned `module.dependencies: []` with `module.complete: true` and no limitation for Go binaries whose embedded build information has no `mod` record, which is how Debian's dh-golang GOPATH-mode builds (`gh`, `hugo`, `rclone`, `restic`, …) embed their metadata. An agent or SBOM workflow reads that as "no third-party modules", although those binaries carry dozens of dependencies that the record simply does not list. Evidence for such binaries now carries a limitation stating that the main module and dependency list are unknown, not empty. Fixes #4191. ## Problem and expected behavior Trigger: a build-info record whose module text holds a `path` line and `build` settings but no `mod`/`dep` lines (GOPATH mode), or an empty module string (moduleless Go 1.12–1.17 builds). `GoModuleText` parses both completely, so `complete` is `true`, and `GoBinaryProvider` only added limitations for a missing build-info record, non-UTF-8 strings and incomplete parsing. Nothing marked the dependency list as unknown. Violated invariant: explicit unknowns must stay visible. `docs/go-binaries.md` promises that unfamiliar, malformed or undecodable records "do not disappear behind a complete result", and `AGENTS.md` requires preserving omission and explicit unknowns across boundaries. Expected: `module.main: null` and `module.dependencies: []` stay as observed, and the result and Evidence `limitations` state that the main module and dependency list are unknown rather than empty. A module-mode build with a `mod` record and no `dep` lines keeps its genuinely empty list without that limitation. ## Change and scope - `src/go/GoBinaryProvider.ts`: the limitations list now comes from a `limitationsFor(info, module)` helper. It adds `No main-module record was decoded from the embedded module information, as in GOPATH-mode builds; the main module and dependency list are unknown, not empty.` whenever parsed module metadata has `main === null`. The existing limitation strings and their conditions are unchanged; moving them into the helper keeps `inspect` within the lint complexity budget it already exceeded (the `complexity` warning on `inspect` is gone, the pre-existing one on `failureForPrimary` is untouched). - `docs/go-binaries.md`: documents the behavior. - `tests/boundary/go/goBinaryProvider.test.ts`: regression coverage (below). Intentionally not included: the optional `module_mode` field suggested in #4191. It would change the `inspect_go_binary` output contract and generated catalog, while the limitation delivers the same information within the existing contract. `complete` keeps its meaning (every module-text line was parsed). `GoModuleText.ts` is untouched: it reports what the record contains, and the provider owns the statement of what remains unknown, as for the other limitations. Maintainer scope decision: not applicable (ordinary fix within an existing read-only inspection). ## Contract and boundary impact - Semantic owner and earliest changed stage: `GoBinaryProvider.inspect` limitation assembly, after module-text parsing and before output-schema validation. - Contribution scope fit and linked maintainer decision: existing read-only format inspection; none required. - CLI and MCP/tool-catalog contract: input and output schemas unchanged; one additional conditional string in the existing `limitations` array of the normalized result and of the Evidence. - Provider, bridge, target-format, or platform compatibility: none; built-in TypeScript reader, all supported containers. - Evidence, artifact, provenance, or reconstruction contract: Evidence `limitations` gain the conditional entry; observed fields, digests and source ranges unchanged. - Target selection, authority, upstream behavior, and cleanup details: not applicable. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none; limitation strings are not catalog content (`metadata:check` passed inside `npm run check`). Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `tests/boundary/go/goBinaryProvider.test.ts` gains three cases on authored ELF fixtures from `tests/fixtures/go/image.ts`: (1) GOPATH-mode module text (`path` + `build` lines only) and (2) a moduleless legacy pointer-encoded image whose module string header holds a nil pointer and zero length both return `main: null`, `dependencies: []`, `complete: true` and the new limitation; (3) control: a module-mode record with `mod` and no `dep` lines keeps `dependencies: []` with no such limitation. - Base reproduction or other evidence: executed. On the base revision `2202e3f0b` the GOPATH-mode case fails with exactly the three fixed limitations and nothing about the dependency list: ```text AssertionError: expected [ …(3) ] to deep equally contain StringContaining{…} + Received: [ "Embedded build metadata is observed file content, not proof of compiler identity, dependency authenticity or runtime behavior.", "Only Go build information is inspected; function names, source mappings, type metadata and decompiled code are not recovered.", "Resource guards bound stable artifact reads and cumulative header searches to 256 MiB each, aggregate embedded strings to 1 MiB, structural table decoding to 16 MiB and complete metadata payloads to 8 MiB; these are not operating-system memory or CPU limits.", ] ``` - User-visible CLI/MCP output: built CLI (`node scripts/rea.mjs inspect-go-binary <file> --json`, isolated `HOME`/`XDG_*`) on three authored fixtures, exit 0 and empty stderr each time. Printed fields are `go_version`, the `module` record (`settings` abbreviated to its count) and the `limitations` array of the returned Evidence. GOPATH-mode fixture (`path` + five `build` settings, no `mod`/`dep`): ```json {"go_version":"go1.19.6","module":{"path":"example.com/tool/cmd/tool","main":null,"dependencies":[],"settings":5,"complete":true}} ``` ```text limitations (4): the three fixed entries, then - No main-module record was decoded from the embedded module information, as in GOPATH-mode builds; the main module and dependency list are unknown, not empty. ``` Moduleless Go 1.17 fixture (pointer encoding, empty module string): ```json {"go_version":"go1.17","module":{"path":null,"main":null,"dependencies":[],"settings":0,"complete":true}} ``` ```text limitations (4): the three fixed entries, then the same main-module limitation. ``` Control, module mode with no dependencies: ```json {"go_version":"go1.26.0","module":{"path":"example.com/tool","main":{"path":"example.com/tool","version":"(devel)","sum":"","replacement":null},"dependencies":[],"settings":1,"complete":true}} ``` ```text limitations (3): only the three fixed entries. ``` The MCP route shares the provider, and `GoBinaryService` passes the limitations into the Evidence unchanged; `tests/boundary/mcp/goBinaryMcp.test.ts` keeps covering that propagation. - Remaining proof gaps: no real GOPATH-built binary (the Debian `gh`/`hugo` packages from the issue) was run; the fixtures are authored images from the repository's Go fixture builder that reproduce the record shape `go version -m` shows for them. `npm run verify:go:binary` needs a Go toolchain and was not run; it compares build information against `debug/buildinfo` and does not assert limitations. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed Windows 11 x64, Node 24.21.0, npm 11.19.0, locked dependencies (`npm ci`), base `main` at `2202e3f0b`. - `node node_modules/vitest/vitest.mjs run tests/boundary/go/goBinaryProvider.test.ts` before the fix — 2 new tests failed as shown above, 5 passed, 1 skipped. - Same command after the fix — 7 passed, 1 skipped (the symlink case is skipped on Windows). - `node node_modules/vitest/vitest.mjs run tests/boundary/go/ tests/boundary/mcp/goBinaryMcp.test.ts` — 5 files, 131 passed, 2 skipped. - `npm run build:cached` — passed. - `node node_modules/vitest/vitest.mjs run tests/acceptance/goBinaryCli.test.ts` against the rebuilt runtime — 26 passed, 1 skipped. - `npm run check` (typecheck, lint, format, knip, metadata, architecture guards) — passed, 0 lint errors. - `npx tsc --noEmit` — passed. - `node scripts/verify-test-discovery.mjs` — `Discovered all 1368 test files exactly once.` - `node scripts/check-doc-facts.mjs` — passed. - `npx oxlint src/go/GoBinaryProvider.ts tests/boundary/go/goBinaryProvider.test.ts` — no errors; one pre-existing `complexity` warning on `failureForPrimary` (also present on `main`), none on `inspect` any more. - `npx oxfmt --check src/go/GoBinaryProvider.ts tests/boundary/go/goBinaryProvider.test.ts docs/go-binaries.md` — formatted. - Not run: `npm run verify:go:binary` (no Go toolchain), Linux/macOS. ## Compatibility, safety, and release - Breaking changes or migration steps: none; one additive, conditional limitation string. - Real Hopper/Ghidra, browser, or OS coverage: not applicable, no external provider; Windows only, `verify:go:binary` not run. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none; the inspection stays a read-only file read without subprocesses or network access. ## Author readiness Human owner: @Y0UW1SH - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. </details> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:12:13 +00:00