docs/roadmaps/lsp/LSP - base PRs.md

@@ -462,6 +462,8 @@ Campos:
 * `sortText`: prefixado para impor bucket (ex.: `"1_"`, `"2_"`)
 * `filterText`: label
 
+Callable completion details and snippets must consume parameter names from the compiler semantic callable model. LSP/editor code must not invent display names such as `arg0` or `arg1`; missing semantic names should remain visibly incomplete rather than being presented as API names.
+
 ---
 
 ## Tarefas de implementação

docs/roadmaps/lsp/LSP - roadmap remain.md

@@ -65,6 +65,8 @@ Habilitar `references`, `prepareRename`, `rename` com regras de segurança.
 
 * Type facts básicos: `NodeId -> TypeId`
 * Modelo de assinatura: para functions (params, retorno)
+* Parameter names for signatureHelp and hover come from the compiler semantic callable model, including stdlib, host-backed, builtin, and intrinsic callables.
+* Generated placeholders such as `arg0` must not appear in LSP completion, signatureHelp, or hover output.
 
 ### Testes
 

docs/specs/compiler-languages/pbs/4. Static Semantics Specification.md

@@ -167,6 +167,8 @@ The following constructs are callable in v1 core:
 Rules:
 
 - All callable categories use the same input/output tuple model.
+- Every user-visible callable category MUST expose a semantic parameter list for editor and tooling consumers.
+- Each semantic parameter record MUST carry its canonical source/API name, zero-based order, type when known, and origin/source sufficient for implementation and diagnostics.
 - A struct method is identified by `(struct type, method name, input tuple shape excluding the receiver slot, output tuple shape)`.
 - A contract value is identified at the type level by its contract type and at runtime by an underlying concrete struct instance or service singleton value plus its selected implementation.
 - A callback declaration defines a nominal callable type with exactly one input/output tuple shape.
@@ -177,6 +179,9 @@ Rules:
 - A callback value is identified at the type level by its declared callback type and signature.
 - Contract signatures and barrel signatures must preserve the same callable shape.
 - Canonical host primitive identity and binding are governed by the Host ABI Binding specification rather than by ordinary v1 core declaration identity alone.
+- The compiler semantic model is the canonical owner of callable parameter names for completion, signature help, hover, diagnostics, and other editor-facing surfaces.
+- Generated ordinal placeholders such as `arg0`, `arg1`, or equivalent names are internal implementation fallbacks only and MUST NOT be exposed as public parameter names.
+- If a user-visible callable lacks a real canonical parameter name, semantic metadata MUST represent that name as missing or unresolved rather than fabricating an ordinal placeholder.
 
 ### 3.3 Declaration validity
 

docs/specs/compiler-languages/pbs/5. Manifest, Stdlib, and SDK Resolution Specification.md

@@ -343,6 +343,18 @@ This list fixes the currently required declarative role of interface modules, bu
 
 An interface module is not runtime code.
 
+### 9.2.1 Callable parameter identity
+
+Stdlib and SDK interface modules define public callable surfaces. Their method and function signatures MUST preserve stable canonical parameter names in the compiler semantic callable model.
+
+Rules:
+
+- Stdlib and SDK-hosted callable definitions MUST carry parameter names, zero-based order, type when known, and source/origin metadata.
+- Stdlib and host-backed parameter names are part of the public API surface.
+- Renaming a public stdlib or host-backed parameter is API compatibility-sensitive and MUST be reviewed with the same discipline as other public callable-shape changes.
+- Interface-module loaders MUST NOT replace missing or unavailable public parameter names with generated ordinal placeholders such as `arg0` or `arg1`.
+- Missing canonical parameter identity MUST be represented as incomplete semantic metadata, not as a fabricated public name.
+
 ### 9.3 Interface-module restrictions
 
 At minimum, an interface module MUST remain declarative.

docs/specs/compiler-languages/pbs/6. VM-owned vs Host-backed.md

@@ -82,6 +82,8 @@ This document depends on, at minimum:
 
 PBS distinguishes three ownership categories for callable behavior.
 
+All categories share the callable parameter identity contract from the Static Semantics Specification. A PBS-visible callable MUST project canonical parameter names, order, type when known, and origin into the semantic callable model regardless of whether the behavior is program-owned, VM-owned, or host-backed.
+
 ### 5.1 Program-owned function
 
 A program-owned function is authored by the program and compiled from a PBS body.
@@ -129,6 +131,8 @@ Properties:
 Host-backed operations are the domain of `declare host`, PBX `SYSC`, loader
 resolution, and final `SYSCALL`.
 
+Host-backed ownership changes runtime authority and lowering, but it does not remove source/API parameter identity. Host-backed callable parameter names remain public semantic metadata and MUST NOT be replaced with generated ordinal placeholders in editor-facing surfaces.
+
 ## 6. The Boundary Question
 
 The normative classification question is:

docs/specs/compiler-languages/pbs/6.1. Intrinsics and Builtin Types Specification.md

@@ -106,6 +106,8 @@ reserved top-level `declare const` shell carrying builtin metadata.
 An intrinsic operation is a VM-owned callable behavior with canonical
 definition in the VM contract.
 
+Visible intrinsic operations and builtin method surfaces MUST be projected into the same semantic callable parameter shape used by ordinary PBS callables. Each visible intrinsic parameter MUST expose a canonical name, order, type when known, and VM/intrinsic origin metadata. If an intrinsic registry entry or builtin descriptor lacks a real public parameter name, compiler/editor metadata MUST represent the name as missing or unresolved rather than publishing `arg0`, `arg1`, or another generated ordinal placeholder.
+
 ### 5.5 Canonical intrinsic registry artifact
 
 Final intrinsic ids are owned by one canonical ISA-scoped registry artifact.

docs/specs/compiler-languages/pbs/6.2. Host ABI Binding and Loader Resolution Specification.md

@@ -110,6 +110,9 @@ Rules:
 - `declare host` exists to define compile-time interface shape, not executable PBS bodies.
 - The compiler is responsible for mapping each host-backed member to its canonical host identity.
 - The PBX must not depend on source spellings such as `Gfx` for runtime resolution.
+- Host-backed source/API signatures MUST preserve their canonical parameter names in compiler semantic callable metadata.
+- Host-backed parameter names are public API surface and are compatibility-sensitive.
+- Loader-facing slot counts and canonical host identity do not license compiler or editor surfaces to publish generated parameter names such as `arg0` or `arg1`.
 
 Example:
 

docs/specs/compiler/13. Conformance Test Specification.md

@@ -98,6 +98,18 @@ At minimum, each language corpus must retain:
 
 Regression grouping by language is expected; one shared monolithic corpus is not required.
 
+### 6.1 Callable parameter identity regressions
+
+PBS conformance tests MUST protect user-visible callable parameter identity.
+
+At minimum, tests MUST prove that:
+
+1. user-authored callable parameters preserve canonical names, order, type when known, and origin in semantic metadata,
+2. stdlib, builtins, host-backed APIs, and visible intrinsics project parameter identity through the same semantic callable model,
+3. editor-facing compiler outputs for completion, signature help, hover, and parameter documentation do not leak generated ordinal placeholders such as `arg0` or `arg1`,
+4. missing canonical parameter names are represented as incomplete metadata rather than fabricated public names,
+5. and stdlib or host-backed parameter renames are treated as public API compatibility changes.
+
 ## 7. Claims and Evidence
 
 For PBS quality claims at this stage: