add TBS_LUCID_PRO_FC_V2 #962

bkleiner · 2025-11-19T05:59:43Z

New revision of the Lucid Pro redesigned layer stack for better electrical characteristics, no pinout changes, but gyro orientation changed.

Summary by CodeRabbit

New Features
- Added support for the TBS_LUCID_PRO_FC_V2 flight controller board with full hardware integration including accelerometer, gyroscope, barometer, flash storage, OSD, beeper, motor outputs, servo outputs, and camera control.

coderabbitai · 2025-11-19T05:59:52Z

Walkthrough

Adds a new board configuration header for TBS_LUCID_PRO_FC_V2 flight controller with AT32F435M MCU. Defines hardware feature support, comprehensive pin mappings for motors, servos, sensors, UARTs, I2C, SPI interfaces, timer configurations, peripheral instances, and default settings for blackbox, meters, and serial receiver.

Changes

Cohort / File(s)	Summary
TBS_LUCID_PRO_FC_V2 Board Configuration `configs/TBS_LUCID_PRO_FC_V2/config.h`	New board configuration file with MCU identifier (AT32F435M), board name and manufacturer ID. Enables accelerometer, gyro, barometer (BMP388), flash (M25P16), MAX7456 OSD, and beeper. Defines 8 motor pins, 2 servo pins, camera control, LED strip, and 8 UART interfaces with pin assignments. Configures I2C, SPI bus pin mappings, LED indicator pins, timer-to-pin associations via macro block, ADC channels for voltage/current sensing. Sets DMA options, peripheral instances, blackbox device to flash, meter sources to ADC, board alignment defaults, and serial receiver to CRSF via UART5.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pin mapping verification: Confirm no conflicting pin assignments across motor, servo, UART, SPI, and I2C interfaces
MCU compatibility: Verify AT32F435M MCU supports all configured peripherals and pin counts
Required defines: Ensure all mandatory board configuration macros are present
Default settings: Review board alignment angles (180° roll), blackbox device, and serial RX configuration for correctness

Suggested reviewers

ot0tot
haslinghuis
nerdCopter

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is incomplete and does not follow the required template structure with mandatory checklist items and hardware compliance documentation.	Complete the PR description using the provided template, including the mandatory checklist items (schematics review, hardware testing, guidelines compliance, etc.) and hardware compliance requirements acknowledgment.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely identifies the main change: adding a new board configuration for TBS_LUCID_PRO_FC_V2.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dff3467 and 28faa7f.

📒 Files selected for processing (1)

configs/TBS_LUCID_PRO_FC_V2/config.h (1 hunks)

🧰 Additional context used

🧠 Learnings (14)

📓 Common learnings

Learnt from: haslinghuis
Repo: betaflight/config PR: 835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.

Learnt from: ot0tot
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.

Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.

Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.

Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the `BOARD_NAME` define in config.h files exactly matches the directory name where the config file is located. For example, if the config file is in configs/AXISFLYINGF7AIO/config.h, then the BOARD_NAME should be defined as "AXISFLYINGF7AIO". This ensures proper board identification and configuration loading in Betaflight.

Learnt from: haslinghuis
Repo: betaflight/config PR: 656
File: configs/IFLIGHT_F745_AIO/config.h:31-35
Timestamp: 2025-07-28T16:44:59.686Z
Learning: In Betaflight board configurations, when a board design uses the same physical gyro socket but different sensor variants across production batches (e.g., MPU6000 in older batches, ICM42688P in newer batches), the correct approach is to enable both sensor drivers (USE_GYRO_SPI_MPU6000 and USE_GYRO_SPI_ICM42688P) in the same configuration. This allows runtime auto-detection of which sensor is actually present without requiring separate board configurations for each hardware variant.

Learnt from: haslinghuis
Repo: betaflight/config PR: 883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.863Z
Learning: For AT32F435 in Betaflight, UART4 supports multiple pin options including PH2 (UART4_RX) and PH3 (UART4_TX) with GPIO_MUX_8, as confirmed in the official Betaflight codebase at src/platform/AT32/serial_uart_at32f43x.c. The AT32 platform has broader pin support than initially apparent from basic searches.

Learnt from: haslinghuis
Repo: betaflight/config PR: 883
File: configs/HGLRCF435_AIO/config.h:50-58
Timestamp: 2025-08-26T14:26:11.863Z
Learning: For AT32F435 in Betaflight, UART4 can use PH2 (UART4_RX) and PH3 (UART4_TX) as confirmed in the official Betaflight codebase at src/platform/AT32/serial_uart_at32f43x.c lines 183-212. This is a valid pin mapping for the AT32F435 platform.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.

📚 Learning: 2025-07-03T04:33:57.480Z

Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-07-14T16:16:56.822Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-07-03T04:33:57.480Z

Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the `BOARD_NAME` define in config.h files exactly matches the directory name where the config file is located. For example, if the config file is in configs/AXISFLYINGF7AIO/config.h, then the BOARD_NAME should be defined as "AXISFLYINGF7AIO". This ensures proper board identification and configuration loading in Betaflight.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-06-23T18:43:31.746Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-08-22T17:08:23.283Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-07-23T13:43:50.456Z

Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines (like ESC_SENSOR_UART, MSP_UART, GPS_UART, etc.) use valid SERIAL_PORT identifiers that match those defined in the Betaflight codebase at src/main/io/serial.h. Common valid identifiers include SERIAL_PORT_USART1, SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, etc. Invalid identifiers like SERIAL_PORT_UART3 (should be SERIAL_PORT_USART3) will cause build failures.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-07-23T13:43:50.456Z

Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines use valid identifiers from the serialPortIdentifier_e enum in src/main/io/serial.h. Valid identifiers include: SERIAL_PORT_USB_VCP (20), SERIAL_PORT_SOFTSERIAL1 (30), SERIAL_PORT_SOFTSERIAL2 (31), SERIAL_PORT_LPUART1 (40), SERIAL_PORT_UART0 (50, if SERIAL_UART_FIRST_INDEX == 0), SERIAL_PORT_USART1 (51 or 50), SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, SERIAL_PORT_USART6, SERIAL_PORT_USART7, SERIAL_PORT_USART8, SERIAL_PORT_UART9, SERIAL_PORT_USART10. While some aliases exist (like SERIAL_PORT_UART3 = SERIAL_PORT_USART3), prefer using the primary identifiers as referenced in the serialPortIdentifiers array to avoid build failures.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-07-28T16:44:59.686Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 656
File: configs/IFLIGHT_F745_AIO/config.h:31-35
Timestamp: 2025-07-28T16:44:59.686Z
Learning: In Betaflight board configurations, when a board design uses the same physical gyro socket but different sensor variants across production batches (e.g., MPU6000 in older batches, ICM42688P in newer batches), the correct approach is to enable both sensor drivers (USE_GYRO_SPI_MPU6000 and USE_GYRO_SPI_ICM42688P) in the same configuration. This allows runtime auto-detection of which sensor is actually present without requiring separate board configurations for each hardware variant.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-07-03T15:17:30.040Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T15:17:30.040Z
Learning: In Betaflight configurations, when a target name suggests dual IMUs (like JHEF7DUAL) but specific hardware variants only have one gyro available, the preferred solution is to use DEFAULT_GYRO_TO_USE macro to specify which gyro to use by default rather than pruning gyro defines or creating redundant configurations. This approach maintains compatibility when the same target is used by multiple hardware variants from the same manufacturer.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-08-20T02:54:58.596Z

Learnt from: ot0tot
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-06-02T16:16:20.197Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-08-28T20:45:36.652Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

📚 Learning: 2025-08-28T20:45:36.652Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PB0 can use multiple timer options including TIM1_CH2N, TIM3_CH3, and TIM8_CH2N as defined in timer_stm32h7xx.c. For CAMERA_CONTROL_PIN assignments, TIM3_CH3 (timer index 3) is the appropriate choice.

Applied to files:

configs/TBS_LUCID_PRO_FC_V2/config.h

🔇 Additional comments (5)

configs/TBS_LUCID_PRO_FC_V2/config.h (5)

24-28: Board identity macros look consistent

FC_TARGET_MCU is set to AT32F435M, BOARD_NAME is TBS_LUCID_PRO_FC_V2 which matches the directory name, and MANUFACTURER_ID is a 4‑character code. This aligns with Betaflight board‑ID conventions; no changes needed.

Based on learnings.

29-50: Sensor and SPI peripheral wiring is coherent

The IMU (MPU6000 on SPI1 with PA4 CS and PC4 EXTI), baro (BMP388 on I2C1), flash (M25P16 on SPI3 with PA15 CS), and MAX7456 on SPI2 with PB12 CS are all on distinct, sensible SPI/I2C instances with no apparent pin conflicts in this config. This matches typical Betaflight patterns for such hardware.

51-96: PWM‑type outputs and GPIO assignments match the declared pins

Motor pins (PC6, PB5, PC8, PC9, PA0–PA3), servos (PB7, PB8), LED strip (PA8), camera control (PC5), beeper (PC13), and status LEDs (PC14, PC15) are all uniquely assigned and have corresponding entries where needed in TIMER_PIN_MAPPING. There are no duplicated pins or obvious cross‑use conflicts within this file.

70-93: UART pinout and I2C mapping align with platform expectations

UART1/2/3/4/5/7/8 pins are uniquely assigned. In particular, UART4 uses PH3 (TX) and PH2 (RX), which is an explicitly supported mapping for AT32F435 in Betaflight’s AT32 UART implementation, and I2C1 on PB6/PC7 is only referenced via BARO_I2C_INSTANCE and MAG_I2C_INSTANCE with no conflicting uses.

Based on learnings.

113-143: Timer map, DMA options, and defaults look reasonable; please confirm gyro orientation in-flight

TIMER_PIN_MAPPING covers motors 1–8 plus LED strip, both servos, and camera control with unique timer indices; this matches the GPIO macros above and should provide the expected resources assuming the timer indices match the AT32 timer table for this target.

ADC1_DMA_OPT, SPI3_TX_DMA_OPT, ADC_INSTANCE, and the default meter/blackbox settings are consistent with the chosen pins and SPI3 flash.

SERIALRX_PROVIDER is CRSF on SERIAL_PORT_UART5, which is a valid serial port identifier and matches the UART5 pins defined earlier.

Given the PR note that only the gyro orientation changed versus the previous revision, encoding that via DEFAULT_ALIGN_BOARD_ROLL = 180 and DEFAULT_ALIGN_BOARD_YAW = 0 seems plausible, but this is hard to verify from the config alone. Please double‑check with a bench test that attitude and axis directions are correct out of the box for this V2 board (no unexpected axis flips vs V1).

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

Provide your own instructions using the high_level_summary_instructions setting.
Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

📝 Description — Summarize the main change in 50–60 words, explaining what was done.

📓 References — List relevant issues, discussions, documentation, or related PRs.

📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.

📊 Contributor Summary — Include a Markdown table showing contributions:
| Contributor | Lines Added | Lines Removed | Files Changed |

✔️ Additional Notes — Add any extra reviewer context.
Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

haslinghuis · 2025-11-19T12:08:59Z

configs/TBS_LUCID_PRO_FC_V2/config.h

+#define LED0_PIN                            PC14
+#define LED1_PIN                            PC15


Does not follow design guidelines.
Checkout https://www.betaflight.com/docs/development/manufacturer/manufacturer-design-guidelines#3146-leds

haslinghuis · 2025-11-19T12:14:53Z

configs/TBS_LUCID_PRO_FC_V2/config.h

+#define DEFAULT_ALIGN_BOARD_ROLL            180
+#define DEFAULT_ALIGN_BOARD_YAW             0


Did you mean

Suggested change

#define DEFAULT_ALIGN_BOARD_ROLL 180

#define DEFAULT_ALIGN_BOARD_YAW 0

#define GYRO_1_ALIGN CW0_DEG_FLIP

haslinghuis · 2025-11-19T12:16:17Z

configs/TBS_LUCID_PRO_FC_V2/config.h

+#define ADC1_DMA_OPT                        0
+#define SPI3_TX_DMA_OPT                     5
+
+#define ADC_INSTANCE                        ADC1


ADC1 is default instance.

Suggested change

#define ADC_INSTANCE ADC1

haslinghuis · 2025-11-19T12:19:29Z

configs/TBS_LUCID_PRO_FC_V2/config.h

+#define MOTOR1_PIN                          PC6
+#define MOTOR2_PIN                          PB5
+#define MOTOR3_PIN                          PC8
+#define MOTOR4_PIN                          PC9


Does not follow design guidelines
See: https://www.betaflight.com/docs/development/manufacturer/manufacturer-design-guidelines#32-resource-selection-considerations

bkleiner · 2025-11-20T09:55:08Z

Will re-submit once we have incorporated the feedback.

add TBS_LUCID_PRO_FC_V2

28faa7f

coderabbitai bot approved these changes Nov 19, 2025

View reviewed changes

haslinghuis requested changes Nov 19, 2025

View reviewed changes

haslinghuis reviewed Nov 19, 2025

View reviewed changes

bkleiner closed this Nov 20, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

add TBS_LUCID_PRO_FC_V2 #962

add TBS_LUCID_PRO_FC_V2 #962

Uh oh!

bkleiner commented Nov 19, 2025 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Nov 19, 2025 •

edited

Loading

Uh oh!

haslinghuis Nov 19, 2025

Uh oh!

haslinghuis Nov 19, 2025

Uh oh!

haslinghuis Nov 19, 2025

Uh oh!

haslinghuis Nov 19, 2025

Uh oh!

bkleiner commented Nov 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		#define DEFAULT_ALIGN_BOARD_ROLL 180
		#define DEFAULT_ALIGN_BOARD_YAW 0

	#define DEFAULT_ALIGN_BOARD_ROLL 180
	#define DEFAULT_ALIGN_BOARD_YAW 0
	#define GYRO_1_ALIGN CW0_DEG_FLIP

add TBS_LUCID_PRO_FC_V2 #962

add TBS_LUCID_PRO_FC_V2 #962

Uh oh!

Conversation

bkleiner commented Nov 19, 2025 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Suggested reviewers

Pre-merge checks and finishing touches

Uh oh!

haslinghuis Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

haslinghuis Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

haslinghuis Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

haslinghuis Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

bkleiner commented Nov 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

bkleiner commented Nov 19, 2025 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Nov 19, 2025 •

edited

Loading