feature - RFC 107 public API metadata, tooling, and boundary-invariant conformance

[dannymeijer]

Area

• Compiler (frontend/backend/codegen)
• Tooling (CLI/formatter/test runner)
• Editor integration (LSP/VS Code extension)
• Documentation

Problem statement

RFC 107 requires type-directed APIs to remain explainable through package metadata, documentation, LSP, semantic inspection, decorators, aliases, and reexports. A compiler-only implementation would recreate the generated-Rust identity leaks the RFC rejects.

Proposed solution

Implement the public metadata and tooling contract for complete RFC 107 behavior, with a conformance corpus across same-module, import, facade, package, alias, decorator, and tolerant-tooling paths.

Alternatives considered

• Let each public boundary reconstruct overload metadata: creates divergence.
• Expose generated backend names: breaks source callable identity.

Scope / acceptance criteria

• In scope:
  • Checked API/package metadata for token parameters, overload sets, return mappings, aliases, decorators, defaults, reexports, and degraded-state markers.
  • Source-callable identity in decorators, docs, diagnostics, generated API docs, LSP, and semantic inspection.
  • Explanation of selected overloads and type-directed mappings.
  • Boundary-invariant fixtures covering direct, imported, facade, package, alias, decorator, and test-harness use.
• Out of scope:
  • New runtime reflection beyond RFC 107.
• Done when:
  • Every supported public route exposes the same selected overload and return type.
  • Users can explain behavior without reading generated backend code.