/**
 * `velar/serve`: the surface, and the runtime module a build renders it from.
 *
 * D115 §三: one file per `velar/*` surface, holding that surface's `ValueType`
 * tables and the `nodeModuleInterfaces` entry they build. `velar/serve` is the
 * one module whose emitted JavaScript a build parameterizes, so the function
 * that assembles that source is here too, below the contract it serves.
 */
import { type ModuleInterface, type ValueType } from "@velarscript/compiler";
export declare const serveResponseAlias: ValueType;
export declare const providerType: ValueType;
export declare const velarServeModuleEntry: readonly [string, ModuleInterface];
/**
 * `velar/serve`, closed over the one route-shape definition and the one fact
 * about its own placement that only a build knows.
 *
 * D90 R19(c): a route's shape — its method-independent collision key — is one
 * concept with one definition, in `route-shape.ts`. The static analyzer calls
 * that function; the emitted module carries its **compiled source**, so the two
 * referees cannot drift. That source is therefore not a generation-time
 * constant: it reads differently depending on whether `route-shape.ts` was
 * type-stripped from `src` or compiled into `dist`. Resolving either form into
 * `runtime/serve.js` would silently change what the other one emits, so the
 * runtime is cut at that line and this function is what puts it back — the same
 * treatment `velar/server` gets for the configuration path a project selected
 * (D115 §一.4, `runtime/manifest.json` `assemblies`).
 *
 * D114 F7-node-b item 2 adds the second such line. The config a build renders
 * this module from carries `projectRootOffset`: the path from the directory the
 * emitted entry lands in back to the project root — `..` for a directory build
 * inside the project, `../..` for the `velar run` sandbox under
 * `<project>/.velar/` — and it is what lets a relative static `root` mean the
 * directory the author wrote it against rather than wherever this build
 * happened to put the entry. Only the build knows it, so it cannot be resolved
 * into the runtime file either. No config is the honest answer for every caller
 * that is not a build — an editor, a test host, the module read straight out of
 * the sources map — and leaves the entry's own directory as the only candidate,
 * which is what `velar/serve` did before.
 *
 * D114 F9-node-cli (audit NO-D1) adds the third and fourth. `projectIdentity` is
 * who the project at that offset has to be, and `__velarServeProjectIdentityOf`
 * is the compiled source of the one function that decides it, so the build and
 * the emitted module read a `velar.json` the same way. Without them the offset
 * named a *place*, and any directory standing in that place was believed.
 *
 * `project-config.ts`'s `velarNodeServeProjectConfig` is where those facts are
 * put, for every extension set that carries this module rather than for
 * `@velarscript/node` alone (D114 SV-X1).
 */
export declare function velarNodeServeSource(projectConfig?: unknown): string;
//# sourceMappingURL=serve.d.ts.map