Motivation

Vera's slot references (@Int.0, @List<Int>.1, etc.) are designed for LLM consumption: canonical, unambiguous, and mechanically verifiable. But for humans reviewing Vera code, the positional indices can be hard to follow in larger functions.

A natural solution is a display layer that annotates slot references with inferred human-readable names, without changing the language itself.

Why not at the language level?

An earlier suggestion was compound syntax like @Int.1_ageAtPolicyPurchase where the compiler ignores the suffix. This breaks the canonical form constraint: the suffix becomes a channel for information that can be wrong with no consequences. The model writes @Int.1_totalCost in one place and @Int.1_ageAtPolicyPurchase in another, both referring to the same binding, and nothing catches the inconsistency. This reintroduces the naming coherence problem through the back door.

Proposed approach

A vera annotate command (or IDE extension) that:

1. Parses and type-checks the source to get full scope/type information
2. Infers a human-readable label for each binding from context (function parameter position, constructor field names, let-binding context, etc.)
3. Outputs an annotated view with inline comments or hover annotations

Example output:

let @Int = compute_age(dob);       -- @Int.0 = age
let @Int = lookup_cost(@Int.0);    -- @Int.1 = cost (using age)
@Int.0 + @Int.1                    -- age + cost

The canonical source stays clean for the model. Humans get an annotated view when they need it.

Scope

• Read-only display tool (never modifies source)
• Works with vera annotate file.vera CLI command
• Could also power LSP hover information or IDE gutter annotations
• Heuristics for label inference: parameter names from call sites, constructor field names, expression context

Related

• Signature refactoring: mechanical slot index rewriting #181 — Signature refactoring (mechanical slot index rewriting) — complementary tooling
• Spec Chapter 3 (slot references)