Make sensor scaffold standalone-buildable + CI pipeline smoke test

[widgetii]

Follow-up to #145.

Summary

• trace_to_driver.py now emits self-contained C that passes gcc -Wall -Wextra -fsyntax-only and gcc -c standalone, without any vendor SDK headers
• tools/test_pipeline.sh runs the full segment → generate → compile flow on a synthetic trace, wired into pr-build-check.yml as a new test-extraction-pipeline job
• Default-mode ipctool trace (no --output=) regression-checked on real hardware: behaviour unchanged from pre-Add sensor driver extraction toolkit and trace --output= flag #145

Why

#145's review of the original plan flagged two real gaps:

(1) The generated scaffold didn't compile. It had #include \"hi_comm_video.h\" / #include \"hi_sns_ctrl.h\" and used VI_PIPE / sensor_write_register with no declarations or stubs, so a researcher couldn't even syntax-check the output let alone build it. Worse, the previous extern void <sensor>_write_register(...) was never actually called (the body uses sensor_write_register(...), the vendor's macro form), so the declaration was just noise.

(2) Default-mode trace had no regression baseline. #145 added --output=PATH as an opt-in flag but never explicitly verified that the no-flag codepath still produced the same output as pre-#145. Took a fresh capture on the same Majestic camera with no --output= — identical to the pre-#145 run, with the well-understood fd-1 corruption pattern (single-byte truncation of 0x3034=0x01 inside the [rtsp] rtsp_init log line that interleaves on shared stdout).

Scaffold change

Before:

#include \"hi_comm_video.h\"
#include \"hi_sns_ctrl.h\"

extern void sc2315e_write_register(VI_PIPE ViPipe, HI_U32 addr, HI_U32 data);

void sc2315e_linear_init(VI_PIPE ViPipe) {
  sensor_write_register(0x0100, 0x00);   /* <- not declared */
  ...
}

After:

#include <unistd.h>

/* --- SDK stubs (delete when integrating into a vendor SDK) --- */
typedef int VI_PIPE;
static inline void sensor_write_register(unsigned int addr, unsigned int val)
{
    (void)addr;
    (void)val;
}
/* --- end SDK stubs --- */

void sc2315e_linear_init(VI_PIPE ViPipe) {
  (void)ViPipe;  /* implicit pipe ID in the vendor SDK; void-cast for the standalone scaffold */
  sensor_write_register(0x0100, 0x00);
  ...
}

The diff against widgetii/smart_sc2315e/sc2315e_sensor_ctl.c::sc2315e_linear_1080P30_init is byte-for-byte unchanged in the function body — just header surroundings differ.

CI integration

$ tools/test_pipeline.sh
== trace_segment.py ==
  phases: {'pre_sensor': 1, 'init': 6, 'post_init': 1, 'runtime': 4}
== trace_to_driver.py ==
== gcc -fsyntax-only ==
== gcc -c (full compile) ==
== trace_diff.py self-diff (must be 100%) ==
  address match:  4 / 4 ref regs present (100.0%)
  value match:    4 / 4 matching addrs (100.0%)
  sequence (LCS): 100.0% of max(len)
OK: pipeline test passed

The synthetic trace embedded in the script exercises every phase (pre_sensor, init, post_init, runtime), so a regression in segmenter heuristics, generator output shape, or diff reporting is caught at PR time.

Test plan

• gcc -Wall -Wextra -fsyntax-only on a real captured + generated scaffold passes
• gcc -c on the same scaffold produces an object
• tools/test_pipeline.sh exits 0
• Generated scaffold's diff against widgetii/smart_sc2315e reference unchanged
• Default-mode ipctool trace (no --output=) on real hardware: same output structure as pre-Add sensor driver extraction toolkit and trace --output= flag #145

🤖 Generated with Claude Code