[derek-miller]

The shared Light V2 library (DRV-152) joins the template as an opt-in module, ported as it stands from T3 (e33d44bf21, built on v0.9.41). It behaves exactly as T3 did and no driver uses it yet. It is the base the v4 contract PRs build on (design revision 4.1, section 8).

What a repo gets with light in vendor_modules, gated like expressions and ui:

• src/lib/light.lua and src/lib/light/, the library (13 parts).
• test/light_harness.lua and test/light_setup/, the kit: a fake proxy, a reference device and the contract run.
• test/test_light_proxy.lua (1,454 checks) and test/test_light_fuzz.lua. A repo's make test runs the fuzzer's first 300 seeded runs from seed 1, about 3 s.
• A "Writing a Light Driver" section in CONTRIBUTING.

Derek's 11-09 call puts the library's tests in template/test/, rendered into each light repo like the template's other libraries, with a short fixed seed set in driver CI and a long run in the template's CI.

What every repo gets (test support only): F.virtualClock in c4_fixtures.lua, the shim's C4:Color* conversions, C4:SendUIRequest answerable through ShimSetUIRequest, C4:GetProxyDevices, GetBoundConsumerDevices answering no value at all when unbound (as 4.3.0 does), and test_lib_dependencies.lua walking src/lib at any depth.

Template CI. A new light render (light plus cloud_diagnostics, as every light repo has it) with its snapshot. Its build leg adds example_light and builds it in both distributions, the only proof that every lib.light part squishes. The render leg's new render-light-fuzz runs the fuzzer 20,000 runs; make render-light-fuzz NAME=light LIGHT_FUZZ_SEED=<n> runs other seeds before a library change. CONTRIBUTING's light section is checked against the token. Every other render's snapshot is unchanged, so nothing outside the token renders a light file.

Redone by hand rather than merged (six files conflicted):

• Main's CI is data now, so T3's matrix edit became the light render and a copy in template_renders.py example.
• example_light follows main's example driver: lib.drivercentral startClient and startGate, the Support Code, the update settings, a DYNAMIC_LIST Log Level.
• "colour" became "color" and "behaviour" "behavior" throughout. One dead read went with it: MemoryLight's start color came from o.colour, which no caller set, and the rename would have read the fuzzer's boolean o.color instead. The device starts at D65 as before.

After merge. The ruleset needs render (light) and build (light).

Memory. Not measured here: zigbee3's move PR records its light items' Lua memory before and after on dev.

[svc-finitelabs]

One must-fix, inline: the shim's color header carries a plan for two conversions it leaves out, tied to another repo's test suites. Plus one nit.

Beyond CI, I ran make render-checks NAME=light here, including the 20,000-run fuzz, and it passes. I also mutated a rendered src/lib/light/fade.lua to call GetDriverVersion without its require. test_lib_dependencies.lua now fails on it, and passes once the file is restored, so the recursive walk does reach the subdirectory. I checked F.virtualClock's repeating timer too: cancelling it from inside its own callback cancels the entry it just re-armed.

[svc-finitelabs]

Must-fix: "ColorRGBtoXY and ColorXYtoRGB stay out until zigbee3's light suites stop stubbing them only where the shim has none" says why two functions are missing and when they will be added. It also hangs that on one consumer repo's test code. That reasoning belongs in the PR, and it goes stale the moment zigbee3 changes. The rest of the header already describes what the shim answers. Drop the sentence.

[svc-finitelabs]

Nit: "as zigbee3's device driver reads one back" points the kit at one consumer. In the template, this reads better as the behavior it models: the device side reading back after a command's transition.

[svc-finitelabs]

Both findings are fixed in bdf69d8: the color header in c4_shim.lua now ends at what the shim models, and the light_harness.lua read-back comment no longer names another repo. The commit changes only those two comment lines, and nothing the PR adds still names zigbee3. The remaining "Zigbee bulb" mentions describe the device being modelled, so they hold.