noCV
CFRAME-102 · Define frame boundaries

Reject emulated device frames above the receiver limit

Practice briefBugFoundational

An untrusted length prefix causes a large allocation. Validate declared size before reserving payload storage.

Focused work estimate
1h 15m + prerequisites
Priority in the scenario
High
Engineering practice
Resource limits · Input validation

Estimated field mix

  • Embedded and edge50%
  • Security30%
  • Networking20%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

Fictional environmental-display devices send synthetic noncritical readings to a local gateway. Implement a byte-stream emulator; no physical device, radio, credentials or safety-critical control is involved.

Setup prerequisites

  • Specify a small frame format with length sequence payload and checksum.
  • Generate local byte streams with fragmentation corruption and reconnects.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Supported sizes pass
  • Oversized lengths fail before allocation
  • Zero-length policy is explicit

Implementation constraints

  • Keep receiver limits independent from sender claims.

Verification to include

  • Decode small fixture
  • Declare maximum integer length

Deliverables

  • Frame admission guard and allocation checks

Rollout and recovery

Stop reception if bounded allocation cannot be guaranteed.

Value of the work

For the engineer: Practice incremental parsing, fixed resource limits and protocol recovery.

For the team: Inspect whether a device adapter survives malformed input without corrupting accepted readings.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.