Plan future matcher and flow support for retained semantic fact identities

Summary

The canonical semantic fact stream intentionally retains several identities that are not yet consumed by current
matchers:

• Reference.value
• MemberRead.value
• PropertyWrite.source
• Call.callee
• Construction.callee
• Construction.result
• FunctionSummary.owner

These fields currently have narrowly scoped #[allow(dead_code)] directives. They are retained because computing
them during the shared semantic pass preserves information needed for future matcher expansion without requiring
another AST traversal or a parallel semantic model.

This issue tracks the intended consumers for those fields and the conditions under which their allowances can be
removed.

Planned uses

1. Reference value identity

Field: Reference.value

Use the resolved ValueId to represent an identifier use as a connected semantic event.

Potential capabilities:

• Match a proven value when it is referenced or consumed.
• Connect declarations and assignments to later uses.
• Express generic value-use sinks that are not calls or property writes.
• Distinguish same-name bindings across scopes and assignment versions.

The matcher must never fall back to the raw identifier spelling in strict mode.

The allowance can be removed when at least one production semantic projection reads Reference.value.

2. Member-read value identity

Field: MemberRead.value

Use the resolved member value to connect reads such as:

const handler = object.callback;
consume(object.callback);

Potential capabilities:

• Treat a member read as a flow source or sink.
• Follow a proven member value through aliases.
• Connect property writes to later reads of the same receiver, property, and binding version.
• Support lifecycle matching where reading a configured member is significant.

Dynamic property names or invalidated receiver provenance must fail closed.

The allowance can be removed when member-read flow consumes this identity.

3. Property-write source identity

Field: PropertyWrite.source

Use the RHS identity to model the value being stored:

  container.handler = callback;
  options.transport = client;

Potential capabilities:

• Match a proven value flowing into a property.
• Connect the stored value to a later read or call.
• Support property-write sinks whose condition depends on RHS identity or provenance.
• Extend current static-string property matching to connected values without weakening it.

This must remain distinct from:

• target: identity of the complete member expression;
• receiver: identity of the object being mutated;
• static_value: bounded static-string projection of the RHS.

The allowance can be removed when the flow projector or a matcher index consumes source.

4. Call callee identity

Field: Call.callee

Use the callee identity for callable value flow:

  const invoke = importedFunction;
  invoke(value);

  let callback = handler;
  callback();

Potential capabilities:

• Connect calls to callable aliases by identity.
• Model higher-order functions where a callable is passed, returned, stored, and later invoked.
• Match invocation of a proven value independently of its current spelling.
• Improve interprocedural call edges where target_function alone is insufficient.

Call.callee complements rather than replaces call provenance, rooted chains, or target_function.

The allowance can be removed when call matching or summary construction consumes the callee identity.

5. Construction identities

Fields:

• Construction.callee
• Construction.result

Use callee to identify the constructor value and result to identify the newly allocated object:

  const instance = new Constructor();
  instance.configure(value);
  consume(instance);

Potential capabilities:

• Treat construction as an object-flow source.
• Follow the constructed result through aliases.
• Apply configuration and lifecycle requirements to constructed objects.
• Match constructors passed through aliases or higher-order transformations.
• Connect a constructed instance to later member calls, property writes, and sinks.

The result identity must remain allocation-specific and bounded. Separate construction sites must not share
object state accidentally.

Both allowances can be removed when construction-source flow consumes these fields.

6. Function ownership

Field: FunctionSummary.owner

Use the lexical owner relationship for closure-aware summary propagation:

  function outer(value) {
      function inner() {
          consume(value);
      }

      return inner;
  }

Potential capabilities:

• Represent nested-function relationships without reconstructing scope ancestry.
• Propagate proven captured-value effects into closure summaries.
• Distinguish lexical capture from ordinary argument flow.
• Invalidate summaries conservatively when capture, reassignment, or dynamic scope cannot be proven.
• Support returned or passed closures while keeping same-name sibling functions isolated by FunctionId.

Ownership alone is not proof of capture. Capture identities and assignment versions must still be established
explicitly.

The allowance can be removed when closure-aware summary construction consumes owner.

Start by locating the canonical semantic fact definitions and their narrowly scoped dead-code allowances. Review the semantic projection, flow projector, matcher index, call or summary construction, and closure-summary paths named in the issue. Done means the intended consumers are implemented for the retained identities and the corresponding allowances can be removed without weakening strict identity or provenance behavior.