fix(provenance): record why a resolved-secret registry became incomplete - #6478

Why

ResolvedSecretTraceRegistry fails closed: when it can no longer vouch for what it projects, it marks itself incomplete. That state is one-way — isPermanentlyIncomplete() never resets — so a single trip fails every later model projection in the run, and the user gets one opaque sentence (... model input could not be safely projected) with no recourse.

Many separate guards can set that state, and none of them recorded which one fired. resolved-secret-trace-registry.ts imported no logger at all, so after the fact there was no way to tell a genuine containment from a matcher that simply could not decide.

What this changes

No behaviour change. Each guard now names itself with a static reason literal:

Log level

Three levels, defaulting to the safe one:

• error — reasons that mean something went wrong on a path that should have succeeded: projection-mismatch, entry-decrypt-failed, unverified-resolved-entry, unresolved-placeholder, provenance-capacity-exceeded, tool-call-scope-mismatch, untrusted-provenance, and the two value-provenance-* import guards. None is reachable on a healthy run.
• warn — the default for everything else: an upstream bundle that already declared itself incomplete, a fork inheriting a parent that reported moments earlier, and unspecified from the ~50 call sites outside this file that have not been audited yet.
• silent — constructed-incomplete. createIncompleteResolvedSecretTraceRegistry states outright that no trusted catalog was available; it carries nothing actionable.

Defaulting to warn is deliberate. Incompleteness is the designed state wherever there is no catalog to vouch with, and those paths are hot — background/webhook-execution.ts:586 builds an incomplete registry on every webhook execution before replacing it with the real one. Logging that at error would have put a per-webhook error line on a completely healthy path. A reason added later without thought now stays quiet rather than paging someone.

Error still matters for reach: getMinLogLevel() falls back to ERROR under NODE_ENV=production and under test, and helm/sim/templates/deployment-app.yaml sets no LOG_LEVEL at all, so on a default self-hosted chart only error survives. The reasons that indicate a real fault — including projection-mismatch — are the ones that get it.

Decrypt failures are summarised once per import rather than once per entry: one rotated key fails every entry, and a bundle may carry up to MAX_PROVENANCE_ENTRIES of them.

No secret material is logged

Reasons are static literals, the logged inputPath is block/field names, and the remaining fields are cardinalities. The decrypt path records getErrorMessage(error) and whether the entry was named — never the value, the ciphertext, or the entry name. There is a test asserting the secret value and name are absent from the log record.

The failure mode this was built to identify

Driving the real classes reproduces the latch:

const reg = await createResolvedSecretTraceRegistry({ /* SHORT_FLAG = 'true' */ })
reg.recordResolvedAtInputPath('SHORT_FLAG', 'true', ['flag'])
reg.recordResolvedInputProjection(['flag'], 'true', '{{SHORT_FLAG}}')
reg.recordResolvedAtInputPath('SHORT_FLAG', 'true', ['context'])
reg.recordResolvedInputProjection(['context'], 'true', 'true')  // literal, from third-party text
reg.recordTransformedInputProjection(
  { flag: 'true', context: 'true' },
  { flag: '{{SHORT_FLAG}}', context: '{{SHORT_FLAG}}' },
  { targetPaths: [['flag'], ['context']] }
)
// isPermanentlyIncomplete() === true

A secret whose plaintext is very short (a flag, an emoji, a two-letter code) binds to an input path where those same characters occur only incidentally. The resolver records that path's projection as the literal; the handler's transform records it as a placeholder. Same raw value, different projected value, so recordState marks the path incomplete — and incompleteness is one-way, so the rest of the run's model projections fail.

recordResolvedInputProjection is worth noting: it overwrites rawValue/projectedValue without the mismatch guard, so only the handler's later recordState can observe the disagreement.

The behavioural fix is intentionally not in this PR. #6416 solved this class for the logging path with MIN_UNANCHORED_MATCH_LENGTH + word-boundary anchoring, and the same policy plausibly belongs where short values bind to input paths. But resolved-secret-matcher.ts documents its wider detection set as deliberate — "a narrow policy can never talk one of them out of failing closed" — so narrowing the wrong guard would convert a fail-closed into a silent leak. That change needs the author's intent and evidence of which guard actually fires, which is exactly what this PR produces.

Type of Change

• Bug fix (diagnosability; no behaviour change)

Testing

Registry suite 66/66. Nine new tests cover the error level for genuine faults, the warn default for propagated/unaudited reasons, silence for the by-design construction, the named reason replacing unspecified, the split between a scope mismatch and an already-incomplete merged child, single-report attribution for an arriving-incomplete bundle, once-per-import decrypt summarisation, and the absence of secret material in the record. Each was verified to fail when its specific change is reverted.

Wider run across executor, lib, background, app/api, providers, tools: 15,486 passing, 0 test failures. Typecheck and biome clean. (83 suites fail to collect in my worktree from a local tailwind v4/v3 resolution artifact — byte-identical list on a clean tree with this change stashed, so unrelated to this PR.)

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)