Stubs

An example

A visible file imports from an Occluded one:

// src/web/InvoicePanel.tsx  (Visible)
import { calculateInvoice } from "../lib/billing/calculateInvoice";

On the person's side, calculateInvoice.ts does not exist. What resolves is its stub:

// defined in a protected module
export declare function calculateInvoice(order: Order, options?: InvoiceOptions): Invoice;

On the build's side, the compiler reads the real file, so the build is the build you ship.

How they are made

Each stub comes from the language's own declaration tooling: TypeScript and JavaScript today, Python next. It is stripped of anything that encodes logic, marked as protected, and checked before it is served. The person's tools find it where the module would be.

Rules

• Public signatures only. No bodies, private members, literal constants, inline comments, or defaults that encode business logic.
• Docstrings are stripped by default, and allowlisted per profile.
• Generation is deterministic.
• A stub that fails to generate degrades to `unknown`, never to the source. Reduced autocomplete is an acceptable failure. A leak is not.

Which modules get one

Only modules that visible code imports, directly or through their signatures. A stub never reveals a module the person's own code does not already name.

What cannot be stubbed

Code the compiler reaches by a route other than an import path: bundler aliases that point into Occluded folders, and code generated during the build. Those need the build configuration or the generated output on a visible path. In languages without stubs (Go, Rust and Java today), the build still compiles Occluded code; the person's language server does not resolve it.

No filtering proxy

The language server runs on the person's side against visible files, stubs and dependencies. It cannot read a body, because none is mounted. Nothing sits in between deciding what to show it.