[PR #5361] feat(firmware): map STM32, GD32, and ESP32 SoC peripherals and auto-detect target platform #6897

Open
opened 2026-11-01 21:43:54 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5361
Author: @liziye627-design
Created: 10/20/2026
Status: 🔄 Open

Base: main ← Head: feat/firmware-peripheral-reconstruction-service


📝 Commits (10+)

  • 4c37af3 feat(firmware): attribute hardware MMIO peripheral memory regions in native disassembly
  • bebfffe feat(firmware): introduce hardware register catalog and peripheral reconstruction service
  • 0344086 feat(firmware): map STM32, GD32, and ESP32 SoC peripherals and auto-detect target platform
  • db9c4c0 fix(firmware): accept Ghidra procedure reference identities
  • cf540f9 fix(firmware): leave tied SoC catalogs unresolved
  • 950f8cc feat(firmware): disassemble Cortex-M raw images from the vector table
  • bd157a7 feat(firmware): record whether a peripheral name comes from the chip manual
  • 59eb843 fix(firmware): name controllers only from observed addresses
  • 9cf2ec2 feat(firmware): apply one claim rule to hardware facts
  • 87b0af5 feat(firmware): attach hardware claim rules to reconstruction

📊 Changes

47 files changed (+6357 additions, -86 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/references/native-and-artifacts.md (+7 -4)
📝 bridge/ghidra/ReaGhidraBridge.java (+4 -2)
📝 bridge/ghidra/ReaGhidraPrepareRaw.java (+84 -3)
📝 docs/installation.md (+1 -1)
📝 docs/native-investigation.md (+1 -1)
📝 docs/raw-binary.md (+44 -12)
📝 docs/windows-ghidra-p0.md (+5 -4)
📝 scripts/verify-real-ghidra-raw.mjs (+7 -0)
➕ src/application/firmware/HardwarePeripheralReconstructionService.test.ts (+662 -0)
➕ src/application/firmware/HardwarePeripheralReconstructionService.ts (+569 -0)
📝 src/contracts/toolOutputSchemaGroups.ts (+2 -12)
📝 src/domain/binaryTargetTypes.ts (+1 -0)
➕ src/domain/firmware/boardDriverLayer.ts (+247 -0)
➕ src/domain/firmware/boardPeripheralProfile.test.ts (+82 -0)
➕ src/domain/firmware/boardPeripheralProfile.ts (+498 -0)
📝 src/domain/firmware/firmwareAnalysis.ts (+3 -0)
➕ src/domain/firmware/hardwareFactBasis.test.ts (+145 -0)
➕ src/domain/firmware/hardwareFactBasis.ts (+364 -0)
➕ src/domain/firmware/hardwareMemoryMap.test.ts (+333 -0)
➕ src/domain/firmware/hardwareMemoryMap.ts (+427 -0)

...and 27 more files

📄 Description

Summary

Note: Builds on top of #5348 (feat(firmware): attribute hardware MMIO peripheral memory regions in native disassembly). Will be automatically clean once #5348 is merged.

Enrich hardware peripheral reconstruction by introducing architectural hardware register catalogs (ARM Cortex-M SCS, RISC-V CLINT/PLIC, x86 APIC, ARM64 GIC), comprehensive SoC peripheral memory maps for STM32F1, STM32F4, GD32F1, and ESP32 (covering classic DPort/RTC and ESP32-C RISC-V), and automated candidate SoC platform detection from observed MMIO access patterns.

Cortex-M raw disassembly

Opening a headerless STM32F407 flash image found five repository problems. This commit follows the SoC catalogs already on this branch.

  1. Windows path stat reports device 0 while an open handle reports the volume serial. Exact device equality made every raw open fail as target changed while being read, and snapshot publish fail as Staged file identity changed.
  2. Raw-binary architectures stopped at generic arm (ARM:LE:32:v7). File offset 0 is a vector table. The reset handler is Thumb at the reset vector with bit 0 cleared.
  3. Windows Ghidra P0 accepted only PE, so a headerless Cortex-M dump never reached the engine. ELF on Windows stays unsupported, and the session stays read-only.
  4. The hardware memory map, SCS catalog, and STM32/GD32 CPU lists did not accept architecture cortex-m, so a target opened that way could not be classified or detected.
  5. The board model was a flat BSP catalog. Optional Kconfig devices were not separated from drivers linked in one captured image. W25Q64 versus W25Q128 stays uncertain. Software I2C is not an I2C register block. USB device and host stay unbound to OTG_FS versus OTG_HS.

The change admits cortex-m as Ghidra ARM:LE:32:Cortex, names reset_handler from the reset vector, admits headerless raw-binary on Windows P0 read-only, treats a zero Windows device id as the same volume, and records RT-Spark driver linkage for image SHA-256 e2c7d06f5c3a9c0e12e220dcd7335110b447bce2310263ad668c1729ed828776. Hopper and IDA still refuse raw-binary. cortex-m is not a PE or Mach-O architecture.

Ghidra 12.1.4 headless, with entry 0x08000000, reported language ARM:LE:32:Cortex, 2415 procedures, and reset_handler at 0x0800c6b4 starting ldr.w sp, [0x0800c6e8]. Pre-push npm run check:fast passed. The focused reconstruction, SoC, board, memory-map, raw-binary, filesystem, and Ghidra load-image tests passed (92) before one test describe was split to satisfy the test function-length limit.

Problem and expected behavior

  • Architectural Register Gap: Even within standard MMIO regions, core architectural control registers (e.g., ARM SysTick 0xe000e010, NVIC, SCB; RISC-V CLINT mtimecmp / PLIC; x86 APIC ICR) were only recognized as broad 4 KiB peripheral blocks without register mnemonic identification.
  • Microcontroller Controller Disambiguation: In popular microcontroller families like STM32, GD32, and ESP32, multiple distinct peripheral controllers (e.g. AFIO, EXTI, GPIOA, GPIOB) share adjacent address spaces within the same 4 KiB memory page (0x40010000). Without SoC peripheral definitions, accesses to GPIOA (0x40010800) were lumped into page base 0x40010000 (AFIO), and ESP32 peripheral ranges (0x3ff40000 / 0x60000000) were not recognized under default MCU profiles.
  • Target Platform Identification: Analysts reverse-engineering raw firmware blobs often lack explicit board/SoC metadata. The toolchain lacked automated heuristics to identify candidate SoC platforms from the set of observed MMIO addresses.

Expected behavior:

  • lookupHardwareRegister resolves canonical addresses to standard architectural register definitions (SysTick_CTRL, NVIC_ISER0, CLINT_MTIME, etc.).
  • lookupSocPeripheral accurately resolves addresses to peripheral controllers and buses (e.g. GPIOA on APB2 or AHB1, UART0 on DPort or System).
  • detectSocPlatform computes platform match candidates with confidence scores and lists matched peripheral names.
  • reconstructHardwareFromReferences and reconstructProcedureHardwareInteractions enrich output with socPeripheralName, socPeripheralBus, and inferred detectedPlatforms.

Change and scope

  • Added src/domain/firmware/hardwareRegisterCatalog.ts providing standard core registers for ARM Cortex-M SCS, RISC-V CLINT/PLIC, x86 Local APIC, and ARM64 GIC.
  • Added src/domain/firmware/socPeripheralDatabase.ts with peripheral dictionaries for STM32F1, STM32F4, GD32F1, and ESP32 (Xtensa & RISC-V).
  • Enhanced attributeHardwareAccess in src/domain/firmware/hardwarePeripheralAttribution.ts to accept optional platform parameter for exact peripheral base and offset calculation.
  • Expanded src/application/firmware/HardwarePeripheralReconstructionService.ts to integrate architectural catalogs, SoC dictionaries, and automated platform detection.
  • Added 27 new tests across hardwareRegisterCatalog.test.ts, socPeripheralDatabase.test.ts, and updated service/attribution test suites.

Contract and boundary impact

  • Semantic owner and earliest changed stage: Firmware domain and Application analysis services.
  • Contribution scope fit and linked maintainer decision: Additive domain and application primitives; follows existing domain memory models.
  • CLI and MCP/tool-catalog contract: Zero schema breaking changes; adds optional platform field to procedure hardware reconstruction input and enriched peripheral summary fields.
  • Provider, bridge, target-format, or platform compatibility: Provider-decoupled; works with Ghidra and offline analyzed references.
  • Evidence, artifact, provenance, or reconstruction contract: Preserves provenance and explicitly distinguishes observed addresses from inferred platform candidates.
  • Process execution, authorization, cleanup, or containment impact: None (pure deterministic read-only analysis).
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact: None.

Expected effects:

  • 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:
    • src/domain/firmware/hardwareRegisterCatalog.ts & hardwareRegisterCatalog.test.ts
    • src/domain/firmware/socPeripheralDatabase.ts & socPeripheralDatabase.test.ts
    • src/domain/firmware/hardwarePeripheralAttribution.ts & hardwarePeripheralAttribution.test.ts
    • src/application/firmware/HardwarePeripheralReconstructionService.ts & HardwarePeripheralReconstructionService.test.ts
  • Base reproduction or other evidence: Verified against STM32F1 reference manual (RM0008), STM32F4 (RM0090), GD32F10x, and ESP32 Technical Reference Manual.
  • Remaining proof gaps: The Cortex-M section records one real Ghidra 12.1.4 run on a captured STM32F407 image. String linkage is presence in that image, not boot-time enablement. Not every one of the 2415 procedures was reviewed by hand.

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

  • npm run check:fast — passed (Turbo typecheck and Oxlint clean with 0 errors and 0 warnings)
  • npm run test:local -- src/domain/firmware/hardwareMemoryMap.test.ts src/domain/firmware/hardwarePeripheralAttribution.test.ts src/domain/firmware/hardwareRegisterCatalog.test.ts src/domain/firmware/socPeripheralDatabase.test.ts src/application/firmware/HardwarePeripheralReconstructionService.test.ts — passed (68/68 tests passed)

Compatibility, safety, and release

  • Breaking changes or migration steps: None.
  • Real Hopper/Ghidra, browser, or OS coverage: Validated on Windows local host.
  • Package or release metadata impact: None.
  • Security, privacy, process, or containment review: Read-only domain additions.

Author readiness

Human owner: @liziye627-design

  • 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/5361 **Author:** [@liziye627-design](https://github.com/liziye627-design) **Created:** 10/20/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `feat/firmware-peripheral-reconstruction-service` --- ### 📝 Commits (10+) - [`4c37af3`](https://github.com/morluto/rea/commit/4c37af319599d2b4be503460c6a10648b83f90d2) feat(firmware): attribute hardware MMIO peripheral memory regions in native disassembly - [`bebfffe`](https://github.com/morluto/rea/commit/bebfffeb08caf9ed53b4845f875fe93c0dc4b6a2) feat(firmware): introduce hardware register catalog and peripheral reconstruction service - [`0344086`](https://github.com/morluto/rea/commit/0344086d53c5ea28a32d7e129ce857805ff8825b) feat(firmware): map STM32, GD32, and ESP32 SoC peripherals and auto-detect target platform - [`db9c4c0`](https://github.com/morluto/rea/commit/db9c4c05e327f9b462abf43c0a578d3d5f19dcab) fix(firmware): accept Ghidra procedure reference identities - [`cf540f9`](https://github.com/morluto/rea/commit/cf540f9da7791304cbee28fd3e968f2a8d242c63) fix(firmware): leave tied SoC catalogs unresolved - [`950f8cc`](https://github.com/morluto/rea/commit/950f8cce86ebd21b84e3fc7b5d9a6199755e6c55) feat(firmware): disassemble Cortex-M raw images from the vector table - [`bd157a7`](https://github.com/morluto/rea/commit/bd157a715f0190e2fa12107c45920e6caab184bc) feat(firmware): record whether a peripheral name comes from the chip manual - [`59eb843`](https://github.com/morluto/rea/commit/59eb84388ae767014353df3bc51f51cdbb58b51a) fix(firmware): name controllers only from observed addresses - [`9cf2ec2`](https://github.com/morluto/rea/commit/9cf2ec228ac6febd383583d970be581c99a31b45) feat(firmware): apply one claim rule to hardware facts - [`87b0af5`](https://github.com/morluto/rea/commit/87b0af5d267cddb09afc80650c5a1e840d8be10a) feat(firmware): attach hardware claim rules to reconstruction ### 📊 Changes **47 files changed** (+6357 additions, -86 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/references/native-and-artifacts.md` (+7 -4) 📝 `bridge/ghidra/ReaGhidraBridge.java` (+4 -2) 📝 `bridge/ghidra/ReaGhidraPrepareRaw.java` (+84 -3) 📝 `docs/installation.md` (+1 -1) 📝 `docs/native-investigation.md` (+1 -1) 📝 `docs/raw-binary.md` (+44 -12) 📝 `docs/windows-ghidra-p0.md` (+5 -4) 📝 `scripts/verify-real-ghidra-raw.mjs` (+7 -0) ➕ `src/application/firmware/HardwarePeripheralReconstructionService.test.ts` (+662 -0) ➕ `src/application/firmware/HardwarePeripheralReconstructionService.ts` (+569 -0) 📝 `src/contracts/toolOutputSchemaGroups.ts` (+2 -12) 📝 `src/domain/binaryTargetTypes.ts` (+1 -0) ➕ `src/domain/firmware/boardDriverLayer.ts` (+247 -0) ➕ `src/domain/firmware/boardPeripheralProfile.test.ts` (+82 -0) ➕ `src/domain/firmware/boardPeripheralProfile.ts` (+498 -0) 📝 `src/domain/firmware/firmwareAnalysis.ts` (+3 -0) ➕ `src/domain/firmware/hardwareFactBasis.test.ts` (+145 -0) ➕ `src/domain/firmware/hardwareFactBasis.ts` (+364 -0) ➕ `src/domain/firmware/hardwareMemoryMap.test.ts` (+333 -0) ➕ `src/domain/firmware/hardwareMemoryMap.ts` (+427 -0) _...and 27 more files_ </details> ### 📄 Description ## Summary > **Note:** Builds on top of #5348 (`feat(firmware): attribute hardware MMIO peripheral memory regions in native disassembly`). Will be automatically clean once #5348 is merged. Enrich hardware peripheral reconstruction by introducing architectural hardware register catalogs (ARM Cortex-M SCS, RISC-V CLINT/PLIC, x86 APIC, ARM64 GIC), comprehensive SoC peripheral memory maps for **STM32F1, STM32F4, GD32F1, and ESP32** (covering classic DPort/RTC and ESP32-C RISC-V), and automated candidate SoC platform detection from observed MMIO access patterns. ## Cortex-M raw disassembly Opening a headerless STM32F407 flash image found five repository problems. This commit follows the SoC catalogs already on this branch. 1. Windows path stat reports device 0 while an open handle reports the volume serial. Exact device equality made every raw open fail as `target changed while being read`, and snapshot publish fail as `Staged file identity changed`. 2. Raw-binary architectures stopped at generic `arm` (`ARM:LE:32:v7`). File offset 0 is a vector table. The reset handler is Thumb at the reset vector with bit 0 cleared. 3. Windows Ghidra P0 accepted only PE, so a headerless Cortex-M dump never reached the engine. ELF on Windows stays unsupported, and the session stays read-only. 4. The hardware memory map, SCS catalog, and STM32/GD32 CPU lists did not accept architecture `cortex-m`, so a target opened that way could not be classified or detected. 5. The board model was a flat BSP catalog. Optional Kconfig devices were not separated from drivers linked in one captured image. W25Q64 versus W25Q128 stays uncertain. Software I2C is not an I2C register block. USB device and host stay unbound to OTG_FS versus OTG_HS. The change admits `cortex-m` as Ghidra `ARM:LE:32:Cortex`, names `reset_handler` from the reset vector, admits headerless raw-binary on Windows P0 read-only, treats a zero Windows device id as the same volume, and records RT-Spark driver linkage for image SHA-256 `e2c7d06f5c3a9c0e12e220dcd7335110b447bce2310263ad668c1729ed828776`. Hopper and IDA still refuse raw-binary. `cortex-m` is not a PE or Mach-O architecture. Ghidra 12.1.4 headless, with entry `0x08000000`, reported language `ARM:LE:32:Cortex`, 2415 procedures, and `reset_handler` at `0x0800c6b4` starting `ldr.w sp, [0x0800c6e8]`. Pre-push `npm run check:fast` passed. The focused reconstruction, SoC, board, memory-map, raw-binary, filesystem, and Ghidra load-image tests passed (92) before one test describe was split to satisfy the test function-length limit. ## Problem and expected behavior - **Architectural Register Gap**: Even within standard MMIO regions, core architectural control registers (e.g., ARM SysTick `0xe000e010`, NVIC, SCB; RISC-V CLINT `mtimecmp` / PLIC; x86 APIC ICR) were only recognized as broad 4 KiB peripheral blocks without register mnemonic identification. - **Microcontroller Controller Disambiguation**: In popular microcontroller families like STM32, GD32, and ESP32, multiple distinct peripheral controllers (e.g. `AFIO`, `EXTI`, `GPIOA`, `GPIOB`) share adjacent address spaces within the same 4 KiB memory page (`0x40010000`). Without SoC peripheral definitions, accesses to `GPIOA` (`0x40010800`) were lumped into page base `0x40010000` (`AFIO`), and ESP32 peripheral ranges (`0x3ff40000` / `0x60000000`) were not recognized under default MCU profiles. - **Target Platform Identification**: Analysts reverse-engineering raw firmware blobs often lack explicit board/SoC metadata. The toolchain lacked automated heuristics to identify candidate SoC platforms from the set of observed MMIO addresses. Expected behavior: - `lookupHardwareRegister` resolves canonical addresses to standard architectural register definitions (`SysTick_CTRL`, `NVIC_ISER0`, `CLINT_MTIME`, etc.). - `lookupSocPeripheral` accurately resolves addresses to peripheral controllers and buses (e.g. `GPIOA` on `APB2` or `AHB1`, `UART0` on `DPort` or `System`). - `detectSocPlatform` computes platform match candidates with confidence scores and lists matched peripheral names. - `reconstructHardwareFromReferences` and `reconstructProcedureHardwareInteractions` enrich output with `socPeripheralName`, `socPeripheralBus`, and inferred `detectedPlatforms`. ## Change and scope - Added `src/domain/firmware/hardwareRegisterCatalog.ts` providing standard core registers for ARM Cortex-M SCS, RISC-V CLINT/PLIC, x86 Local APIC, and ARM64 GIC. - Added `src/domain/firmware/socPeripheralDatabase.ts` with peripheral dictionaries for STM32F1, STM32F4, GD32F1, and ESP32 (Xtensa & RISC-V). - Enhanced `attributeHardwareAccess` in `src/domain/firmware/hardwarePeripheralAttribution.ts` to accept optional `platform` parameter for exact peripheral base and offset calculation. - Expanded `src/application/firmware/HardwarePeripheralReconstructionService.ts` to integrate architectural catalogs, SoC dictionaries, and automated platform detection. - Added 27 new tests across `hardwareRegisterCatalog.test.ts`, `socPeripheralDatabase.test.ts`, and updated service/attribution test suites. ## Contract and boundary impact - Semantic owner and earliest changed stage: Firmware domain and Application analysis services. - Contribution scope fit and linked maintainer decision: Additive domain and application primitives; follows existing domain memory models. - CLI and MCP/tool-catalog contract: Zero schema breaking changes; adds optional `platform` field to procedure hardware reconstruction input and enriched peripheral summary fields. - Provider, bridge, target-format, or platform compatibility: Provider-decoupled; works with Ghidra and offline analyzed references. - Evidence, artifact, provenance, or reconstruction contract: Preserves provenance and explicitly distinguishes observed addresses from inferred platform candidates. - Process execution, authorization, cleanup, or containment impact: None (pure deterministic read-only analysis). - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: None. Expected effects: - [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: - `src/domain/firmware/hardwareRegisterCatalog.ts` & `hardwareRegisterCatalog.test.ts` - `src/domain/firmware/socPeripheralDatabase.ts` & `socPeripheralDatabase.test.ts` - `src/domain/firmware/hardwarePeripheralAttribution.ts` & `hardwarePeripheralAttribution.test.ts` - `src/application/firmware/HardwarePeripheralReconstructionService.ts` & `HardwarePeripheralReconstructionService.test.ts` - Base reproduction or other evidence: Verified against STM32F1 reference manual (RM0008), STM32F4 (RM0090), GD32F10x, and ESP32 Technical Reference Manual. - Remaining proof gaps: The Cortex-M section records one real Ghidra 12.1.4 run on a captured STM32F407 image. String linkage is presence in that image, not boot-time enablement. Not every one of the 2415 procedures was reviewed by hand. 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 - `npm run check:fast` — passed (Turbo typecheck and Oxlint clean with 0 errors and 0 warnings) - `npm run test:local -- src/domain/firmware/hardwareMemoryMap.test.ts src/domain/firmware/hardwarePeripheralAttribution.test.ts src/domain/firmware/hardwareRegisterCatalog.test.ts src/domain/firmware/socPeripheralDatabase.test.ts src/application/firmware/HardwarePeripheralReconstructionService.test.ts` — passed (68/68 tests passed) ## Compatibility, safety, and release - Breaking changes or migration steps: None. - Real Hopper/Ghidra, browser, or OS coverage: Validated on Windows local host. - Package or release metadata impact: None. - Security, privacy, process, or containment review: Read-only domain additions. ## Author readiness Human owner: @liziye627-design - [x] 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. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#6897
No description provided.