GeezerVison

Why

A provenance bundle that arrives already incomplete latches the registry one-way, so every later model projection in the run refuses. #6483 made the refusal say what went wrong. It could not say who.

That gap is not theoretical — it is exactly where the last investigation stopped. Production produced:

site=router.contextModelInput  cause=registry-latched
reason=source-provenance-incomplete  activeEntryCount=0

Correct, actionable up to a point, and then a dead end: 23 call sites import provenance, any of which could have accepted that bundle, and nothing distinguishes them. Narrowing by log timing produced a confident wrong answer.

What this changes

An optional origin on the import boundary, carried into the guards that latch:

await registry.importProvenance(bundle, { trusted: true, origin: 'workflowHandler.childCrossing' })

All 23 import sites are tagged; none are untagged. Tool crossings take the tool id (tool.${toolId}), threaded through the metadata consumers, so a tool-sourced bundle identifies itself instead of being inferred from timestamps.

The origin is retained on the registry beside the reason and inherits through forks and merges. That step matters: a tool crossing forks, imports, then merges back, and that is precisely where attribution was being erased. The refusal therefore names the importer even though the latch happened many frames earlier:

site=router.contextModelInput  reason=source-provenance-incomplete
origins=["workflowHandler.childCrossing"]

Unlike reasons — a closed 16-member union that bounds itself — origins are caller-supplied strings, so they carry an explicit MAX_RETAINED_ORIGINS bound.

Behaviour

None. The field is optional and additive; it is read only when building a log record. markIncomplete's second parameter moves from a positional source to a { source, origin } context object — five internal call sites, no external ones (it is only ever called with a reason outside this file).

Testing

410 passing in executor/utils, including new coverage for: attribution recorded at the import guard, attribution surviving the fork-and-merge that hid it in production, and the origin bound. Each verified to fail when its specific guard is reverted.

Wider run across executor, lib, app, tools, providers: 16,784 passing, 0 test failures. Typecheck, biome, and check:api-validation clean. (141 suites fail to collect in my worktree from a local tailwind v4/v3 artifact — identical list on a clean tree with this change stashed.)

Eight tests genuinely broke and were fixed properly. They pinned the exact options object passed to importProvenance, so the added field failed them. Loosening the assertions would have discarded coverage, and a blanket replace would have been wrong — one file expects two different origins depending on which mock is asserted. Each assertion now asserts the attribution it should see.

What this does not do

It does not fix the failing workflow. It converts the remaining unknown — which importer accepted the untrustworthy bundle — from an investigation into a field on the next log line.

Type of Change

• Bug fix (diagnosability; no behaviour change)

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)