Verify coverage counts, firmware addresses and Notebook source before handoff
Three concrete delivery checks: distinguish unknown LCOV branches, refuse overlapping HEX regions and recover Notebook code without executing outputs.
An export that opens can still answer the wrong question
A coverage percentage can conceal a missing denominator, two firmware files can both pass checksums while overlapping, and a small cleaned Notebook can still contain every secret in its source. Start from the receiving task and keep evidence that directly checks it.
| Observation | Useful conclusion | Next action |
|---|---|---|
| BRDA count is “-” | Execution count unknown; branch still found | Keep unknown visible and review test coverage |
| Two files store the same address | Merge is ambiguous even if bytes match | Resolve address ownership in the build |
| Notebook output shrinks dramatically | Saved display data was removed | Compare preserved source/attachments before running code |
Coverage: keep the trace beside the complete report
Use the starter’s three DA lines as a check: one hit gives 1/3 line coverage. Two functions with one hit give 1/2; the hit branch plus an unknown branch also gives 1/2. Zero found functions means n/a. These figures describe the supplied trace, not a newly measured test run.
The report keeps stale LF/LH and related counter differences visible. It never opens the source path to repair missing points. Download the complete HTML, JSON and CSV; a first-200 preview is not the full handoff.
Firmware: a record checksum does not establish a safe merge
Before merging bootloader and application exports, compare stored regions and entry-point declarations. The browser merger refuses any overlap and returns no partial result. Identical overlapping bytes still need an explicit ownership decision in the producer.
For a high sparse address, compare exact segment bytes and exclusive bounds rather than padding a raw image across the gap. Check the downloaded HEX with the receiving tool; board compatibility, startup and application CRC are separate checks.
Notebook: compare the code, then decide whether to execute it
Large output data can make opening a Notebook fail. Cleaning reads saved MIME values as data and discards outputs without rendering them. It preserves source representation and metadata numbers, with a visible root-widget choice.
The source manifest gives cell index/type/ID, original string or array and a source hash. Verify the cleaned copy against the original and keep Markdown/raw attachments. The cleaner does not judge code safety, remove secrets from source or run a kernel.
- Keep the original export unchanged.
- Review the widget policy and the count of removed output items.
- Open the cleaned copy in the receiver and compare a representative source cell, CRLF and attachment.
- Treat retained metadata and source as potentially sensitive when sharing the result.
Keep a small receiver record with the handoff
Record the producer/version, original file, selected options, complete downloads and the receiver check. When a supported budget fails, correct or split in the producer only if the task remains meaningful. A successful local tool run establishes its stated transformation; the receiving application still needs to accept the artifact.
References
- Flutter LCOV report question
Task source: an actual exported lcov report needs readable coverage; no demand-scale estimate.
- Bootloader/application HEX merge question
Task source: two firmware exports must merge. Browser output does not automate Eclipse or prove flash suitability.
- Open a Notebook without rendering outputs question
Task source: saved image/DataFrame output makes opening consume excessive memory while code must remain. No performance guarantee inferred.
- Official LCOV project
Correctness source only; supports the scoped 1.x trace contract, not new extensions.
- IntelHex merge reference
Correctness/independent-reader source, not demand evidence.
- Jupyter nbformat description
Correctness source; no cell execution or PII-removal guarantee.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
LCOV offline coverage reportRead one local LCOV 1.x tracefile, recompute coverage totals, retain unknown branches and download a complete offline HTML report.
Review coverage exported by your test runner without reading source paths. Inspect the real line/function/branch counts, compare stale declared counters and keep a standalone HTML report beside the tracefile.
Steps
- Paste or open one complete LCOV 1.x tracefile from the test runner.
- Check recomputed totals, unknown branches and declared-versus-actual summary differences.
- Download coverage.html plus complete JSON/CSV. Open HTML locally and retain the original tracefile.
Available options
- Protect CSV formula-like text
- On by default
Capabilities and limits
- One UTF-8 file or pasted tracefile up to 5 MiB, 50,000 coverage points (DA + FN + BRDA) and 1,000 complete source records. One record per exact source path; duplicate paths reject instead of silently merging test contexts. Selected file takes precedence. Total downloads up to 10 MiB; table preview first 200 records.
- Supports LCOV 1.x TN, SF, FN, FNDA, DA, BRDA, LF/LH/FNF/FNH/BRF/BRH and optional VER. FNDA and FN order may differ; every function needs both location and count. Counts and branch identifiers are nonnegative uint64; source lines are 1–2147483647. DA checksum, when supplied, is 32 hexadecimal characters. New FN end-line, FNL/FNA and MC-DC extensions reject.
- Coverage totals are recomputed from actual points. Declared summary differences stay visible in the report; they do not become the denominator. BRDA “-” remains unknown, contributes to found branches and is never changed into a hit count of zero. A zero denominator is n/a/null rather than 100%.
- Full HTML lists every point and summary difference, escapes all file/test/function text and contains no scripts or links that read source paths. JSON preserves uint64 hit counts as decimal strings. CSV contains every source record; spreadsheet protection may prefix formula-like labels. No source fetching, tracefile merging, test execution or coverage measurement.
Intel HEX address mergerMerge local Intel HEX 00–05 files by sparse 32-bit addresses, checking record checksums, overlaps and entry-point conflicts before output.
Combine bootloader and application HEX exports only when their stored address bytes do not overlap. Review complete segments and entry metadata, then deliver canonical HEX and a sparse address map without filling large address gaps.
Steps
- Select the original bootloader/application HEX files, or paste one complete HEX file for inspection.
- Check stored ranges, segment bounds and retained entry-point kind; any overlap fails before a download.
- Download merged.hex, the complete address-map JSON and segment report. Verify the result with the receiving firmware tool before flashing.
Available options
- Protect CSV formula-like text
- On by default
Capabilities and limits
- Paste one HEX file or select up to 64 UTF-8 files, combined at most 2 MiB. Selected files take precedence. At most 50,000 nonempty records and 1 MiB stored bytes; sparse addresses are independent of their span. Total complete artifacts up to 10 MiB; segment preview first 200.
- Supports records 00 data, 01 EOF, 02 extended segment address, 03 CS:IP start, 04 extended linear address and 05 EIP start. Count, checksum, record address and type-specific length must be exact. Every file needs one EOF; later records, invalid hex/whitespace, duplicate start records and unknown types reject. Empty lines and an optional leading UTF-8 BOM are accepted.
- Addresses range 0x00000000–0xFFFFFFFF. Data that exceeds this range rejects. Any repeated stored address, even with the same byte, rejects the entire merge. One compatible entry-point declaration is retained; different kinds or values conflict. No partial result is supplied on failure.
- Output uses 16-byte data records with extended linear bases and retains the start-record kind. Address-map JSON contains every contiguous segment and its exact hex bytes; report/CSV provide complete segment bounds with exclusive ends (0x100000000 is permitted as an end). No gap filling, hardware flashing, target suitability, firmware-signature authentication or application CRC validation.
Notebook output cleaner and source recoveryRemove outputs and execution counts from a local nbformat 4 notebook while preserving cell source, attachments and precise metadata numbers.
Recover code from a notebook made difficult to open by large display outputs. Remove saved output data without rendering it, choose the root widget-state policy explicitly, and download a cleaned notebook plus an indexed source manifest.
Steps
- Open the original .ipynb without rendering its outputs, or paste a small supported notebook.
- Choose whether root widget state should be removed and check the removed-output and execution-count summary.
- Download cleaned.ipynb and cell-sources.json. Open the cleaned copy in Jupyter and verify source/attachments before executing anything.
Available options
- Remove root metadata.widgets state
- On by default
Other metadata and attachments remain; this is not automatic sensitive-data removal.
- Protect CSV formula-like text
- On by default
Capabilities and limits
- One selected UTF-8 .ipynb file up to 64 MiB or pasted JSON up to 8 MiB. Selected file takes precedence. nbformat 4 minor 0–5, at most 200,000 JSON values, depth 128 and 10,000 cells. All downloads together at most 10 MiB; first 200 cells appear in the table. Large retained source/attachments/metadata can still exceed output limits.
- Supports code, Markdown and raw cells, plus saved stream/error/display_data/execute_result outputs. Structural fields, unique IDs for minor 5, source representation and recognized metadata fields are validated; duplicate JSON keys, future cell/output types, unknown structural extensions and unsupported format versions reject. Arbitrary custom metadata remains data. Lone surrogate code units in joined cell source reject rather than changing its UTF-8 hash.
- Clears every code cell outputs array and sets execution_count to null. The explicit option controls only root metadata.widgets. Source string/array representation, cell order, IDs, CRLF/Unicode, Markdown/raw attachments, other metadata and original large integer/decimal number tokens are preserved. JSON formatting changes; original file is never overwritten.
- No MIME rendering, script/cell execution, kernel start or automatic PII removal. Preserved source, attachments, timing/trust/custom metadata may still contain sensitive information. Cell-source JSON retains exact source representation and SHA-256 of joined source encoded as UTF-8; it does not claim the notebook has run or passed tests.