dangernoodle-io / breadboard / 29563487477

96%

push

github

feat: bb_data core binding table (#908)

Adds bb_data (B1-832), the key -> (desc, gather) binding table for the
future bidirectional data path (B1-828 epic). Stores bindings in a
bb_registry instance and delegates only the wire-format step to the
existing bb_serialize format-dispatch registry -- no dependency on
bb_cache/bb_cache_serialize.

EGRESS ONLY -- ingress/populate is deferred. bb_serialize's opaque
`parse` slot has no stable cross-format shape today (JSON registers a
token-scan handle, not a one-shot deserialize fn), so a generic
bb_data populate path would have to cast through a mismatched
function-pointer type (UB, firmware-review HIGH finding). Resolving
that format-registry parse-contract fork is out of scope here; this
ships the render half only.

- bb_data_bind/render with a fixed 8-slot table (BB_DATA_MAX_BINDINGS),
  no Kconfig knob
- bb_data_bind() rejects an over-length key (>= BB_DATA_KEY_MAX) as
  BB_ERR_INVALID_ARG instead of silently truncating it
- bb_data_bind() is documented as composition-time-only (single-threaded,
  before any render traffic) -- the existing bb_registry lock-free model,
  no new freeze/lock primitive
- bb_data_render() looks up the format renderer before invoking gather,
  so an unsupported format is a true no-op with no gather side effects
- host tests cover bind/render happy paths, capacity exhaustion,
  useless-binding rejection, key-length boundary, and the
  unsupported-format/no-gather/no-space/gather-failure error paths
- fence --approve bb_data (new_component baseline)

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

7096 of 7733 branches covered (91.76%)

Branch coverage included in aggregate %.

34 of 34 new or added lines in 1 file covered. (100.0%)

12116 of 12337 relevant lines covered (98.21%)

2378.91 hits per line