fix(interaction): disclose label-fallback when the native-ref preflight recovers by label

Merged
AI
5h ago
+47-19

Summary

The native-ref fast path always disclosed exact, even when its preflight recovered a stale @ref through its trailing label. The preflight already resolves through tryResolveRefNode → buildRefResolution, so it now returns that disclosure, and the response reports label-fallback when the node came back by label. Dispatch keeps exact only when the preflight observed no tree.

The ADR 0011 registry anchor now cites buildRefResolution, the coverage manifest gains a label-fallback scenario with a contract test, and resolution-disclosure.md describes the new rule. 6 files.

Refs #4332.

Validation

Tested 6aa853832 (on 093341a60). pnpm check:affected --run --head 6aa853832: 8 passed, 7 skipped (web smoke and replay lanes).

The new contract test failed first on the base (exact instead of label-fallback).

Open for maintainers:

  • No-op preflight. The issue asks for not-observed "if the daemon cannot tell". With no stored snapshot, or a ref that is missing from it with no label match, this PR still discloses exact. not-observed exists only for source: "direct-ios" today, so that needs a public-schema change. I left it for a decision rather than widening the schema here.
  • Provenance. When the preflight recovers node X by label, the backend still dispatches the stale ref (ADR 0011: the preflight never changes which element the backend acts on). label-fallback therefore describes what the preflight checked. The daemon backend drops fallbackLabel, so it does no label recovery of its own.
  • Only click is tested on this path; fill and hover share the same dispatch.

šŸ¤– Generated with Claude Code


Autofix with [code]smith
Open in [code]smith Ā· Need help on this PR? Tag @codesmith-bot with what you need.