RFC: Drift detection tests for CRD-to-runtime type mappings

[ChrisJBurns]

Summary

• Proposes reflection-based drift detection tests for CRD-to-runtime conversion functions in the ToolHive operator
• Tests enumerate JSON fields on both CRD and runtime types, failing when a field is neither mapped nor explicitly excluded
• Catches silent configuration drift (e.g., PR #3118, issue #3125) at test time instead of in production

Documents

• rfcs/THV-0058-crd-drift-detection-tests.md — concise proposal
• rfcs/THV-XXXX-crd-runtime-drift-detection-tests.md — full RFC with detailed design, alternatives, and implementation plan

Test plan

• Review both documents for accuracy and completeness
• Validate the proposed jsonFieldNames helper design
• Confirm the scope covers all relevant CRD conversion boundaries

🤖 Generated with Claude Code

[jerm-dro]

Thanks for getting this down while the ideas were fresh. The drift detection idea has legs, but I think we need to frame the full problem before going deep on a solution. The telemetry conversion is one instance of a broader pattern:

1. Type separation — CRD types must be separate from runtime config types. Not all fields belong in the CRD schema, and Go embedding doesn't let us selectively hide them.
2. Conversion layers — each separation creates bespoke conversion code that's easy to miss and expensive to validate. Can we reduce or automate this?
3. Divergent implementations — bespoke patterns increase cognitive load, boilerplate, bugs, and inconsistencies. Can we make these consistent enough that a reviewer can spot what's wrong — and an agent can get it right the first time?
4. Boilerplate — adding a new CRD type or referencing an existing one requires a lot of repetitive wiring: lifecycle management, watches, conditions, hash tracking, runconfig resolution. How much of this can be shared or generated? What's the minimum a developer should have to write to add a new config knob end-to-end?

I'd like to restructure this RFC to lead with the full problem statement and treat drift detection as one piece of the solution. Wdyt? Is this a reasonable direction?