Inspiration

The starting point was a saved n8n experiment with an uncomfortable result: Customer D’s synthetic order went to Customer A. The parent and child workflows both reported success. Across the original and repaired recordings, all 11 business-node JSON snapshots matched. The useful clue lived in the item-pairing metadata.

An automation delivery engineer needs a short route from “this item looks wrong” to “here is the exact saved record that explains it.” Threadbare gives that investigation a desk, a thread to follow, and a report someone else can verify.

What it does

Threadbare is a local browser inspector for one saved n8n parent–child execution boundary. Its midnight dispatch board draws two evidence roles: the input recorded by the parent and the input resolved through the child. Select a returned item and follow its actual saved pairedItem and source entries, with node, run, output, and item coordinates at every step.

The opening case has two crossed pairings. Returned output 0, item 0 resolves to caller input item 3, Customer D; the parent records item 0, Customer A. Switching to Repaired loads the previously recorded repair and reruns the same audit, producing zero mismatches. A separate panel shows the synthetic case’s recorded HTTP recipients.

For an operator’s own records, import a complete parent execution response first. Threadbare reads the child ID from the actual saved call and gives that child’s API download command. Add the full child response, audit locally, and download a structural JSON report. The report carries findings, coordinates, pairing/source metadata, and original-file pointers; business item JSON stays out.

How we built it

The application is static HTML, CSS, and bundled JavaScript. A small MIT auditor and four synthetic recordings from my earlier n8n-check project provide the native execution contract. Their pinned source and pre-existing status are disclosed in docs/reuse.md.

The new work is the browser desk, local acquisition/import flow, portable report, and evidence captured during the actual ancestry traversal. Each displayed address points back to the value the walker read. The auditor checks a successful, waiting, once-mode Execute Workflow 1.2 call with a passthrough child trigger and complete matching records.

Kiro CLI v3 performed substantive spec-driven core development. It read the repository’s requirements and evidence steering, wrote JSON structural equality, adapted the auditor for the browser, added traversal evidence, and implemented and ran fixture checks. Its implementation checkpoint is preserved in Git. Focused integration review then refined the shared walker and raw addresses. The public root .kiro/ includes the actual specs, steering, tasks, and custom-agent check-hook configuration.

Challenges we ran into

The difficult part was making a pretty line earn its place on the screen. A trace must preserve the consumer’s input choice and the producer’s saved output and run. At Select, input 1 is decisive. Using the wrong run or turning an internal traversal marker into an address would produce a convincing picture with bad evidence.

Browser adaptation also needed a precise JSON contract while retaining the existing CLI behavior. The checks compare every captured pairing/source pointer with its original value and preserve the mismatch/consistent/incomplete states. When a saved piece is missing, the desk names the path or boundary requirement and the next record to obtain.

Accomplishments that we’re proud of

A user can follow the original crossed line, open raw evidence, compare the saved repair, exercise parent-first file import, and take a report away from one page. The same core runs in the browser and the original CLI. Focused integration checks pass for the saved cases and exact evidence addresses.

The Costume theme is part of the task: copper and magenta threads distinguish the two recorded relationships; the empty socket represents missing evidence. Large, legible type and the narrow-screen layout keep the investigation usable under its midnight-switchboard costume.

The current demonstration uses saved synthetic recordings. External-operator imports are currently zero; that operator trial is the next evidence to collect.

What we learned

“Get the files” was a product problem of its own. Reading the child ID from a parent’s saved call gives an operator a concrete next action before the audit can begin.

An explanation also becomes much stronger when its address is produced at the moment the value is read. Specifying that invariant before Kiro touched the core gave implementation and review a concrete test.

What’s next for Threadbare

Have an n8n delivery engineer use their own scope-matching saved executions, obtain the child response, and bring the downloaded finding back into a real repair review. Use that completed task to improve acquisition help and evidence readability. Expand supported boundaries as complete native recordings establish each additional contract.

Built With

Share this project:

Updates

Submission history