Bounded run-length expansion
Compressed input should not decide how much memory to allocate. OctetWeave brings byte-run expansion code and output limits into a Windows project conversation so you can review the checks before using an implementation.
def expand_runs(runs, limit):
if type(limit) is not int or limit < 0:
raise ValueError("limit.invalid")
total = 0
for value, count in runs:
if type(value) is not int or not 0 <= value <= 255:
raise ValueError("byte.invalid")
if type(count) is not int or count <= 0:
raise ValueError("count.invalid")
total += count
if total > limit:
raise ValueError("output.limit")
return bytes(value for value, count in runs for _ in range(count))Review before applying
Compare actual behavior with the expected result. If a check fails, investigate it before applying more changes.
Connection
Base URL, credentials and a reachable server.
Project
Reject zero or negative counts, values outside the byte range and a total above the cap, leaving the original run list unchanged.
def expand_runs(runs, limit):
if type(limit) is not int or limit < 0:
raise ValueError("limit.invalid")
total = 0
for value, count in runs:
if type(value) is not int or not 0 <= value <= 255:
raise ValueError("byte.invalid")
if type(count) is not int or count <= 0:
raise ValueError("count.invalid")
total += count
if total > limit:
raise ValueError("output.limit")
return bytes(value for value, count in runs for _ in range(count))Make data expansion limits visible in the code review
OctetWeave is AI coding software for working through changes to parsers and data transformations in an existing project. The Windows workspace keeps the project folder and model conversation close to the code you need to inspect. Begin by describing accepted input, expected output and the point where oversized data should be rejected. Those details help a proposed patch answer a real application requirement.
Bounded run-length expansion in runs.py provides an example. You might ask the assistant to inspect whether expanded length is checked before producing output, then review how an invalid count reaches the caller. This is an illustrative coding task, not a decompression facility included in OctetWeave. The useful result is a change whose validation and allocation behavior you can examine alongside the surrounding parser.
Follow the review with project tests for ordinary runs, malformed counts and data at the agreed limit. Check how the consumer handles rejection, since a new validation rule can change more than the transformation itself. Connect an unfiltered model only when one is available through a supported OpenAI-compatible or Anthropic endpoint, supplying credentials if needed. Model policies, server tools and context capacity still govern that connection; choosing it does not establish resource guarantees for the code it proposes.
Preparing a bounded parser change
- Where should an output limit come from?
Define it from your application requirement and operating constraints rather than accepting an arbitrary model suggestion. Identify who supplies the limit and how rejection is reported, then review that decision through both the parser and its caller.
- What should boundary tests include?
Use an ordinary input, an input exactly at the accepted limit and one that exceeds it. Add malformed values appropriate to the format. Verify the expected failure behavior as well as the successful output.
- Can OctetWeave certify a parser against resource exhaustion?
No such certification is claimed. You can inspect proposed code and discuss tests in the workspace, but assessing resource use requires checking the actual implementation and runtime under conditions relevant to your application.
- Why inspect the caller after adding validation?
The caller may expect every input to return data and may mishandle a new rejection. Review error propagation and user-visible behavior so the bound improves the application contract without turning invalid input into an unexplained failure.
OctetWeave · Updated 2026-10-25
