PBS autocomplete parameter names for stdlib and method calls

discussion/index.ndjson

@@ -1,5 +1,5 @@
-{"type":"meta","next_id":{"DSC":38,"AGD":41,"DEC":36,"PLN":78,"LSN":52,"CLSN":1}}
-{"type":"discussion","id":"DSC-0037","status":"open","ticket":"pbs-autocomplete-parameter-names","title":"PBS autocomplete parameter names for stdlib and method calls","created_at":"2026-05-08","updated_at":"2026-05-08","tags":["compiler-pbs","studio","lsp","autocomplete","signature-help","stdlib"],"agendas":[{"id":"AGD-0040","file":"AGD-0040-pbs-autocomplete-parameter-names-for-stdlib-and-method-calls.md","status":"open","created_at":"2026-05-08","updated_at":"2026-05-08"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"meta","next_id":{"DSC":38,"AGD":41,"DEC":37,"PLN":81,"LSN":52,"CLSN":1}}
+{"type":"discussion","id":"DSC-0037","status":"in_progress","ticket":"pbs-autocomplete-parameter-names","title":"PBS autocomplete parameter names for stdlib and method calls","created_at":"2026-05-08","updated_at":"2026-05-08","tags":["compiler-pbs","studio","lsp","autocomplete","signature-help","stdlib"],"agendas":[{"id":"AGD-0040","file":"AGD-0040-pbs-autocomplete-parameter-names-for-stdlib-and-method-calls.md","status":"accepted","created_at":"2026-05-08","updated_at":"2026-05-08"}],"decisions":[{"id":"DEC-0036","file":"DEC-0036-canonical-parameter-names-in-the-pbs-callable-semantic-model.md","status":"accepted","created_at":"2026-05-08","updated_at":"2026-05-08","ref_agenda":"AGD-0040"}],"plans":[{"id":"PLN-0078","file":"PLN-0078-specify-pbs-callable-parameter-identity-in-the-semantic-model.md","status":"open","created_at":"2026-05-08","updated_at":"2026-05-08","ref_decisions":["DEC-0036"]},{"id":"PLN-0079","file":"PLN-0079-project-canonical-parameter-names-through-pbs-compiler-callables.md","status":"open","created_at":"2026-05-08","updated_at":"2026-05-08","ref_decisions":["DEC-0036"]},{"id":"PLN-0080","file":"PLN-0080-propagate-semantic-parameter-names-to-pbs-lsp-editor-assistance.md","status":"open","created_at":"2026-05-08","updated_at":"2026-05-08","ref_decisions":["DEC-0036"]}],"lessons":[]}
 {"type":"discussion","id":"DSC-0036","status":"open","ticket":"pbs-symbol-documentation-and-hover-markdown","title":"Modelo de documentacao de simbolos em PBS e consumo markdown no hover","created_at":"2026-05-08","updated_at":"2026-05-08","tags":["compiler","compiler-pbs","studio","lsp","vscode","editor","hover","documentation","markdown"],"agendas":[{"id":"AGD-0039","file":"AGD-0039-pbs-symbol-documentation-and-hover-markdown.md","status":"open","created_at":"2026-05-08","updated_at":"2026-05-08"}],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0035","status":"done","ticket":"pbs-lsp-editor-assistance-wave-1","title":"Wave 1 de assistencia editorial via LSP para PBS no VS Code","created_at":"2026-05-08","updated_at":"2026-05-08","tags":["studio","lsp","vscode","compiler","compiler-pbs","editor","completion","hover","signature-help"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0051","file":"discussion/lessons/DSC-0035-pbs-lsp-editor-assistance-wave-1/LSN-0051-compiler-backed-editor-assistance-for-pbs.md","status":"done","created_at":"2026-05-08","updated_at":"2026-05-08"}]}
 {"type":"discussion","id":"DSC-0034","status":"done","ticket":"frontend-semantic-host-projection-flexibility","title":"Frontend semantic vocabulary flexibility and declarative host projection","created_at":"2026-05-06","updated_at":"2026-05-07","tags":["compiler","compiler-general","frontend","semantics","vscode","host-projection","lsp"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0048","file":"discussion/lessons/DSC-0034-frontend-semantic-host-projection-flexibility/LSN-0048-frontend-owned-semantic-vocabularies-with-declarative-host-projection.md","status":"done","created_at":"2026-05-07","updated_at":"2026-05-07"}]}

discussion/workflow/agendas/AGD-0040-pbs-autocomplete-parameter-names-for-stdlib-and-method-calls.md

@@ -2,7 +2,7 @@
 id: AGD-0040
 ticket: pbs-autocomplete-parameter-names
 title: PBS autocomplete parameter names for stdlib and method calls
-status: open
+status: accepted
 created: 2026-05-08
 resolved:
 decision:
@@ -46,15 +46,21 @@ This agenda is narrower than `DSC-0036`.
 
 ## Open Questions
 
-- [ ] Where should canonical parameter names for stdlib and builtins live?
-- [ ] Should parameter names be part of the compiler semantic model, external stdlib metadata, authored documentation, or derived from declarations?
-- [ ] How should completion snippets, signature help, and hover consume the same parameter identity?
-- [ ] Should generated fallback names like `arg0` be allowed to reach user-facing editor UI at all?
-- [ ] Do user-authored PBS functions already preserve parameter names well enough, or is the problem shared by all callable symbols?
-- [ ] Are stdlib APIs represented as PBS declarations, Java/Kotlin host descriptors, compiler intrinsics, generated metadata, or a mix?
-- [ ] Should parameter names be normative API surface, meaning renames require compatibility/release discipline?
-- [ ] How should optional/default/rest parameters be represented if PBS supports or later adds them?
-- [ ] Should completion snippets include placeholders named from canonical parameters, or should names appear only in detail/signature help?
+- [x] Should canonical parameter names be owned by the compiler semantic callable model, or is stdlib/API metadata allowed to remain a separate source of truth?
+  - Answer: canonical parameter names should be offered through the compiler semantic model.
+- [x] Is `arg0`/`arg1` allowed to reach any user-facing LSP/editor surface, or must it be treated as an internal fallback only?
+  - Answer: `arg0`/`arg1` should not reach user-facing editor or LSP surfaces.
+- [x] For the first implementation slice, should the decision cover all callable symbols or explicitly target stdlib/host-backed APIs first?
+  - Answer: the decision should cover all callable symbols.
+- [x] Are parameter names part of the normative public API contract for stdlib and host-backed surfaces?
+  - Answer: parameter names should be treated as part of the normative public API contract.
+
+Non-blocking implementation investigations:
+
+- Determine how stdlib APIs are represented today: PBS declarations, Java/Kotlin host descriptors, compiler intrinsics, generated metadata, or a mix.
+- Verify whether user-authored PBS functions already preserve source parameter names through the compiler-backed LSP path.
+- Decide exact snippet formatting after the canonical parameter source is settled.
+- Defer optional/default/rest parameter representation until PBS has that callable shape.
 
 ## Options
 
@@ -134,6 +140,13 @@ The real question is ownership:
 - does the editor receive them as structured data?
 - can tests assert that stdlib APIs do not leak fallback names?
 
+Questions that do not need to block the decision:
+
+- The current storage shape of stdlib declarations is implementation discovery; it affects the plan, but not the ownership decision.
+- User-authored function behavior should be verified, but the target contract can still require every callable symbol to expose the same parameter shape eventually.
+- Snippet placeholder details belong in plan/spec once the canonical parameter identity is decided.
+- Optional/default/rest parameters are future callable-shape concerns unless current PBS or stdlib APIs already expose them.
+
 The minimum acceptable outcome is that a user can discover a stdlib call from autocomplete and understand what each argument is supposed to represent without leaving the call site.
 
 Potential acceptance examples for a later decision/plan:
@@ -146,8 +159,14 @@ Potential acceptance examples for a later decision/plan:
 
 ## Resolution
 
-Ainda em aberto.
+Proposed resolution:
+
+- canonical parameter names are owned by the compiler semantic callable model;
+- stdlib, host-backed, builtin, and user-authored callables should all expose parameter names through the same semantic callable shape;
+- generated fallback names such as `arg0` and `arg1` are internal only and must not appear in completion, signature help, hover, or other user-facing editor/LSP surfaces;
+- parameter names for stdlib and host-backed APIs are normative public API surface, so renaming them should be treated as an API compatibility concern;
+- implementation may still be staged, but the normative decision should cover all callable symbols rather than defining a stdlib-only contract.
 
 ## Next Step
 
-Discutir se a equipe aceita `compiler/pbs` como owner dos nomes canonicos de parametros e se `argN` deve ser banido de qualquer surface LSP user-facing.
+If this resolution matches the intended direction, the next step is to accept the agenda and create a decision artifact from it.

discussion/workflow/decisions/DEC-0036-canonical-parameter-names-in-the-pbs-callable-semantic-model.md

@@ -0,0 +1,126 @@
+---
+id: DEC-0036
+ticket: pbs-autocomplete-parameter-names
+title: Canonical parameter names in the PBS callable semantic model
+status: accepted
+created: 2026-05-08
+ref_agenda: AGD-0040
+tags: [compiler-pbs, studio, lsp, autocomplete, signature-help, stdlib]
+---
+
+## Context
+
+PBS editor assistance is becoming compiler-backed through completion, hover, and signature help.
+
+The current call assistance can expose callable parameters as generated names such as `arg0`, `arg1`, and `arg2`, especially for stdlib and host-backed APIs. That output is not useful at the call site because it hides the meaning of each argument at the moment autocomplete and signature help are supposed to reduce lookup cost.
+
+This decision follows `AGD-0040`. The agenda resolved four blocking questions:
+
+- canonical parameter names should be offered through the compiler semantic model;
+- `arg0` and similar fallback names should not reach user-facing editor/LSP surfaces;
+- the contract should cover all callable symbols, not only stdlib;
+- stdlib and host-backed parameter names should be treated as public API surface.
+
+Related context:
+
+- `DSC-0035` established compiler-backed PBS editor assistance.
+- `DSC-0036` discusses authored symbol documentation and markdown hover, but documentation is not the owner of structural parameter identity.
+
+## Decision
+
+PBS callable parameter names are normative semantic metadata.
+
+Every callable symbol exposed by the PBS compiler semantic model **MUST** provide a structured parameter list containing, at minimum:
+
+- parameter name;
+- parameter type when known;
+- parameter order;
+- callable origin sufficient for implementation/debugging.
+
+This applies to all callable symbols:
+
+- user-authored PBS functions and methods;
+- stdlib callables;
+- builtins;
+- host-backed APIs;
+- compiler intrinsics that are visible as callables to users or editor tooling.
+
+The compiler semantic callable model is the canonical source of parameter names. Editor adapters, LSP protocol surfaces, completion items, signature help, and hover **MUST** consume parameter names from that semantic callable model rather than inventing independent display names.
+
+Generated fallback names such as `arg0`, `arg1`, `arg2`, or equivalent ordinal placeholders are internal implementation fallbacks only. They **MUST NOT** appear in user-facing editor or LSP surfaces, including:
+
+- completion labels;
+- completion details;
+- completion snippets;
+- signature help;
+- hover signatures;
+- parameter documentation surfaces.
+
+If a callable lacks a real canonical parameter name, the compiler/editor boundary **MUST** represent that as missing or unresolved metadata rather than presenting a fabricated `argN` name to users. Plans may define the exact fallback UI, but the UI must not imply that `argN` is the public API name.
+
+For stdlib and host-backed APIs, parameter names are part of the normative public API contract. Renaming a public parameter **MUST** be treated as an API compatibility concern and should be reviewed with the same discipline as other public API shape changes.
+
+## Rationale
+
+The editor should not need to know whether a callable came from user PBS code, stdlib declarations, host descriptors, builtins, or compiler intrinsics in order to display a usable signature. A single semantic callable model gives completion, hover, signature help, diagnostics, documentation, and future refactoring tools the same source of truth.
+
+Keeping parameter names in LSP-only metadata would make the UI look better quickly, but it would split callable truth between compiler semantics and editor presentation. That split is fragile because later surfaces would need to decide which source is authoritative.
+
+Binding parameter names to authored documentation is also the wrong ownership boundary. Documentation can describe what a parameter means, but the parameter name itself is structural callable identity.
+
+Treating `argN` as user-facing output makes the product worse exactly where assistance should be strongest: stdlib discovery and call construction. It also risks normalizing generated placeholders as if they were API names.
+
+## Implications
+
+Compiler implications:
+
+- PBS semantic analysis must preserve or produce real parameter names for every user-visible callable.
+- Stdlib, builtin, host-backed, and intrinsic callable definitions must be projected into the same parameter shape.
+- Any internal descriptor that currently lacks real names must be enriched, adapted, or treated as incomplete metadata.
+
+LSP/editor implications:
+
+- Completion, signature help, and hover must use semantic callable parameter names.
+- LSP adapters must not patch over missing semantic names with guessed UI names.
+- Completion snippets may use canonical parameter names as placeholders, but snippet formatting is a plan/spec detail.
+
+API governance implications:
+
+- Public stdlib and host-backed parameter names become compatibility-sensitive.
+- Renames require explicit review because they affect editor help, documentation, and user-facing API shape.
+
+Scope implications:
+
+- The normative contract covers all callable symbols.
+- Implementation may be staged, but staging must not narrow the final contract to stdlib only.
+- Optional/default/rest parameter representation is out of scope unless an existing callable shape already requires it.
+
+Documentation implications:
+
+- `DSC-0036` may attach prose descriptions to parameters later.
+- Documentation must not become the canonical owner of parameter identity.
+
+## Propagation Targets
+
+- specs: update PBS/compiler semantic model specs to define callable parameter identity and fallback constraints; update LSP/editor assistance specs if present.
+- plans: create an execution plan that discovers current stdlib/host/intrinsic callable representation, updates semantic callable projection, and propagates names to LSP surfaces.
+- code: compiler semantic model, stdlib/builtin/host-backed callable descriptors, PBS LSP completion/signature/hover providers, VS Code consumer if it formats snippets locally.
+- tests: semantic model tests for callable parameter preservation; stdlib/host-backed conformance tests rejecting public `argN`; LSP completion/signature/hover tests proving `argN` does not leak.
+- docs: future lesson after implementation; any affected README or API documentation for stdlib parameter naming discipline.
+
+## References
+
+- Agenda: AGD-0040
+- Related: DSC-0035
+- Related: DSC-0036
+
+## Constraints
+
+- Do not implement an editor-only rename map as the canonical solution.
+- Do not use authored documentation as the canonical source of parameter names.
+- Do not expose generated ordinal placeholders to users as if they were API names.
+- Do not limit the normative model to stdlib only; plans may stage implementation but must preserve the all-callables target.
+
+## Revision Log
+
+- 2026-05-08: Initial decision drafted from accepted agenda `AGD-0040`.

discussion/workflow/plans/PLN-0078-specify-pbs-callable-parameter-identity-in-the-semantic-model.md

@@ -0,0 +1,100 @@
+---
+id: PLN-0078
+ticket: pbs-autocomplete-parameter-names
+title: Specify PBS callable parameter identity in the semantic model
+status: open
+created: 2026-05-08
+ref_decisions: [DEC-0036]
+tags: [compiler-pbs, studio, lsp, autocomplete, signature-help, stdlib]
+---
+
+## Briefing
+
+`DEC-0036` makes callable parameter names normative semantic metadata. Before implementation, the PBS and compiler specs need a clear contract for callable parameter identity so code changes do not invent a narrower interpretation.
+
+This plan is the specification and conformance planning slice. It does not implement Java code. It defines the target semantic shape, public API compatibility rule, and test expectations that downstream plans must satisfy.
+
+## Objective
+
+Update normative documentation so every PBS user-visible callable has a canonical semantic parameter list with stable names, order, type when known, and origin. Define that generated ordinal placeholders such as `arg0` are internal only and must not appear in user-facing editor/LSP surfaces.
+
+## Dependencies
+
+- Depends on accepted decision `DEC-0036`.
+- Must precede `PLN-0079` and `PLN-0080` because those plans implement and consume the contract defined here.
+- Related but not blocked by `DSC-0036`; parameter documentation can attach prose later, but docs do not own structural names.
+
+## Scope
+
+- Update PBS static semantics and stdlib/SDK specs to define canonical callable parameter identity.
+- Update compiler conformance/spec-to-test documentation to require `argN` leak prevention.
+- Update LSP/editor assistance roadmap/spec text if a current spec surface exists for completion, hover, or signature help.
+- Record that stdlib and host-backed parameter names are public API surface.
+- Define the minimum semantic parameter record:
+  - name;
+  - order;
+  - type when known;
+  - origin/source sufficient for implementation and diagnostics.
+
+## Non-Goals
+
+- No Java/Kotlin implementation changes.
+- No VS Code extension changes.
+- No authored parameter prose documentation design.
+- No optional/default/rest parameter design unless an existing PBS callable already exposes that shape.
+- No editor-only rename map.
+
+## Execution Method
+
+1. Update PBS static semantic documentation:
+   - Target: `docs/specs/compiler-languages/pbs/4. Static Semantics Specification.md`.
+   - Add a section for resolved callable parameter identity.
+   - State that every user-visible callable symbol MUST expose canonical parameter names through the compiler semantic model.
+   - State that generated ordinal placeholders MUST NOT be treated as public parameter names.
+
+2. Update stdlib/SDK resolution documentation:
+   - Target: `docs/specs/compiler-languages/pbs/5. Manifest, Stdlib, and SDK Resolution Specification.md`.
+   - Add the requirement that stdlib and SDK/host-backed callable definitions carry stable public parameter names.
+   - State that parameter renames are API compatibility-sensitive.
+
+3. Update host-backed and intrinsic documentation:
+   - Targets:
+     - `docs/specs/compiler-languages/pbs/6. VM-owned vs Host-backed.md`
+     - `docs/specs/compiler-languages/pbs/6.1. Intrinsics and Builtin Types Specification.md`
+     - `docs/specs/compiler-languages/pbs/6.2. Host ABI Binding and Loader Resolution Specification.md`
+   - Clarify that visible host-backed and intrinsic callables must be projected into the same semantic callable parameter shape.
+
+4. Update compiler conformance documentation:
+   - Target: `docs/specs/compiler/13. Conformance Test Specification.md`.
+   - Add conformance expectations for semantic callable parameter preservation and LSP/editor `argN` leak prevention.
+
+5. Update roadmap/spec references for LSP if still current:
+   - Targets:
+     - `docs/roadmaps/lsp/LSP - base PRs.md`
+     - `docs/roadmaps/lsp/LSP - roadmap remain.md`
+   - Add a short reference that editor assistance consumes compiler semantic parameter names.
+
+## Acceptance Criteria
+
+- Specs explicitly state the compiler semantic model is the canonical owner of parameter names.
+- Specs explicitly cover user-authored PBS, stdlib, builtins, host-backed APIs, and visible intrinsics.
+- Specs explicitly ban generated ordinal placeholders from user-facing editor/LSP output.
+- Specs state stdlib and host-backed parameter names are public API compatibility surface.
+- The plan leaves no permission for an editor-only rename map as the canonical solution.
+
+## Tests
+
+- Run `discussion validate`.
+- If spec conformance tests exist for docs links or matrices, run the relevant Gradle test target.
+- Manual review gate: confirm every MUST from `DEC-0036` is represented in the updated specs.
+
+## Affected Artifacts
+
+- `docs/specs/compiler-languages/pbs/4. Static Semantics Specification.md`
+- `docs/specs/compiler-languages/pbs/5. Manifest, Stdlib, and SDK Resolution Specification.md`
+- `docs/specs/compiler-languages/pbs/6. VM-owned vs Host-backed.md`
+- `docs/specs/compiler-languages/pbs/6.1. Intrinsics and Builtin Types Specification.md`
+- `docs/specs/compiler-languages/pbs/6.2. Host ABI Binding and Loader Resolution Specification.md`
+- `docs/specs/compiler/13. Conformance Test Specification.md`
+- `docs/roadmaps/lsp/LSP - base PRs.md`
+- `docs/roadmaps/lsp/LSP - roadmap remain.md`

discussion/workflow/plans/PLN-0079-project-canonical-parameter-names-through-pbs-compiler-callables.md

@@ -0,0 +1,114 @@
+---
+id: PLN-0079
+ticket: pbs-autocomplete-parameter-names
+title: Project canonical parameter names through PBS compiler callables
+status: open
+created: 2026-05-08
+ref_decisions: [DEC-0036]
+tags: [compiler-pbs, studio, lsp, autocomplete, signature-help, stdlib]
+---
+
+## Briefing
+
+`DEC-0036` requires all user-visible callables to expose canonical parameter names through the PBS compiler semantic callable model. This plan implements that compiler-side projection.
+
+The immediate pain is visible in stdlib/editor assistance, but the implementation target is all callable symbols: user-authored PBS functions and methods, stdlib callables, builtins, host-backed APIs, and visible compiler intrinsics.
+
+## Objective
+
+Add or complete compiler semantic callable parameter metadata so every user-visible callable carries canonical parameter names, order, type when known, and origin. Ensure generated names such as `arg0` remain internal and are represented as missing/incomplete metadata rather than public names.
+
+## Dependencies
+
+- Depends on accepted decision `DEC-0036`.
+- Should follow `PLN-0078` so implementation matches the updated spec wording.
+- Must complete before `PLN-0080` can fully consume semantic parameter names in LSP/editor assistance.
+
+## Scope
+
+- Inspect and update PBS callable semantic types and resolution paths.
+- Preserve source parameter names for user-authored PBS declarations.
+- Project stdlib resource declarations into the same callable parameter model.
+- Project host-backed, builtin, and visible intrinsic callables into the same model.
+- Add semantic/conformance tests for parameter names and `argN` leak prevention at the compiler boundary.
+
+## Non-Goals
+
+- No LSP protocol formatting work; that belongs to `PLN-0080`.
+- No VS Code extension behavior changes.
+- No authored parameter descriptions.
+- No generated editor-side alias table.
+- No broad refactor of name resolution beyond callable parameter identity.
+
+## Execution Method
+
+1. Locate the current semantic callable model:
+   - Inspect:
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsCallableShape.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsEditorialSignature.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsEditorialResolvedSymbol.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsEditorialSupportService.java`
+   - Identify where parameter lists currently lose real names or synthesize ordinal placeholders.
+
+2. Preserve user-authored parameter names:
+   - Inspect parser/AST sources:
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/ast/PbsAst.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/parser/PbsDeclarationParser.java`
+   - Ensure declaration parameter identifiers survive into semantic callable shapes.
+
+3. Project stdlib parameter names:
+   - Inspect stdlib resources:
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/resources/stdlib/1/**/main.pbs`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/resources/stdlib/1/**/mod.barrel`
+   - Inspect loaders:
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/stdlib/InterfaceModuleLoader.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/stdlib/StdlibEnvironmentResolver.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/services/PbsImportedSemanticContextService.java`
+   - Ensure stdlib declarations expose authored parameter names through the same semantic callable model.
+
+4. Project builtin, host-backed, and intrinsic parameters:
+   - Inspect:
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsBuiltinLayoutResolver.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/PbsHostAdmissionValidator.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/lowering/PbsCallableShapeSurfaceService.java`
+     - `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/irvm/IRVMIntrinsicRegistry.java`
+   - Enrich descriptors that currently lack stable names.
+   - If a descriptor genuinely lacks a real public name, represent that as incomplete metadata rather than `argN`.
+
+5. Add compiler tests:
+   - Extend or add tests near:
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/test/java/p/studio/compiler/pbs/semantics/PbsEditorialSupportServiceTest.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/test/java/p/studio/compiler/pbs/semantics/PbsSemanticsDeclarationsTest.java`
+     - `prometeu-compiler/frontends/prometeu-frontend-pbs/src/test/java/p/studio/compiler/pbs/stdlib/InterfaceModuleLoaderTest.java`
+   - Assert user-authored and stdlib callables expose real parameter names.
+   - Assert public semantic callable output does not contain `arg0`, `arg1`, or equivalent generated ordinal placeholders.
+
+## Acceptance Criteria
+
+- Every semantic callable exposed to editor assistance has a structured parameter list with names, order, type when known, and origin.
+- User-authored PBS functions preserve declared parameter names.
+- Stdlib declarations expose stable authored parameter names.
+- Builtin, host-backed, and visible intrinsic callables either expose real names or report missing metadata without fabricating public `argN` names.
+- Compiler tests fail if public semantic callable metadata leaks `argN`.
+- No editor/LSP-only rename map is introduced.
+
+## Tests
+
+- `./gradlew :prometeu-compiler:frontends:prometeu-frontend-pbs:test` if the Gradle path is valid in the current build.
+- If module targeting differs, run the nearest available PBS frontend test task from `./gradlew projects`.
+- Run focused tests for:
+  - `PbsEditorialSupportServiceTest`
+  - `PbsSemanticsDeclarationsTest`
+  - `InterfaceModuleLoaderTest`
+- Run `discussion validate`.
+
+## Affected Artifacts
+
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsCallableShape.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsEditorialSignature.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsEditorialResolvedSymbol.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/PbsEditorialSupportService.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/stdlib/InterfaceModuleLoader.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/services/PbsImportedSemanticContextService.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/resources/stdlib/1/**`
+- PBS frontend semantic and stdlib tests.

discussion/workflow/plans/PLN-0080-propagate-semantic-parameter-names-to-pbs-lsp-editor-assistance.md

@@ -0,0 +1,112 @@
+---
+id: PLN-0080
+ticket: pbs-autocomplete-parameter-names
+title: Propagate semantic parameter names to PBS LSP editor assistance
+status: open
+created: 2026-05-08
+ref_decisions: [DEC-0036]
+tags: [compiler-pbs, studio, lsp, autocomplete, signature-help, stdlib]
+---
+
+## Briefing
+
+`DEC-0036` requires completion, signature help, and hover to consume callable parameter names from the compiler semantic model and prevents generated ordinal placeholders from reaching user-facing editor/LSP output.
+
+This plan implements the LSP/editor consumption slice after compiler semantic callable metadata exists.
+
+## Objective
+
+Propagate canonical semantic parameter names into PBS completion, signature help, hover, and VS Code-facing protocol mapping. Add tests proving `arg0`, `arg1`, and equivalent generated placeholders do not leak through user-facing LSP/editor surfaces.
+
+## Dependencies
+
+- Depends on accepted decision `DEC-0036`.
+- Should follow `PLN-0078` for spec contract alignment.
+- Requires `PLN-0079` or equivalent compiler semantic metadata before final acceptance.
+
+## Scope
+
+- Update PBS editorial support outputs consumed by the LSP bridge.
+- Update LSP baseline messages/mappers if the protocol shape needs richer parameter metadata.
+- Update completion item construction to use semantic parameter names in labels/details/snippets.
+- Update signature help to display semantic parameter names and types.
+- Update hover signatures to use the same parameter identity.
+- Update VS Code extension only if it formats snippets or signatures locally.
+- Add LSP/protocol tests that reject `argN` leakage.
+
+## Non-Goals
+
+- No compiler semantic model implementation; that belongs to `PLN-0079`.
+- No authored parameter prose documentation.
+- No final design for optional/default/rest parameter UI unless already surfaced by compiler metadata.
+- No UI-only guesswork for missing names.
+
+## Execution Method
+
+1. Identify current LSP/editor assistance boundary:
+   - Inspect:
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/compiler/CompilerLanguageServiceBridge.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/LanguageServiceBridge.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineCompletionItem.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineSignature.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineSignatureHelp.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineHover.java`
+   - Map which fields currently carry callable signatures and parameters.
+
+2. Consume semantic parameter names from compiler outputs:
+   - Update bridge/mapping code so completion/signature/hover surfaces use parameter names from PBS semantic callable metadata.
+   - Do not generate display names from method names, types, docs, or local maps.
+   - Treat missing semantic names as incomplete metadata and apply a non-misleading fallback UI that does not show `argN`.
+
+3. Update protocol mapping:
+   - Inspect:
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/protocol/mapping/Lsp4jProtocolMessageMapper.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/protocol/mapping/ProtocolMessageMapper.java`
+   - Ensure LSP4J completion/signature/hover conversion preserves semantic parameter names.
+   - Ensure snippet placeholders, if emitted, use canonical parameter names.
+
+4. Update VS Code extension if required:
+   - Inspect:
+     - `tools/vscode-extension/src/extension.ts`
+   - If the extension formats call snippets or signatures locally, remove any generated ordinal placeholders and consume protocol-provided semantic names.
+
+5. Add LSP/editor tests:
+   - Extend:
+     - `prometeu-lsp/prometeu-lsp-v1/src/test/java/p/studio/lsp/services/compiler/CompilerLanguageServiceBridgeTest.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/test/java/p/studio/lsp/services/protocol/PrometeuTextDocumentServiceTest.java`
+     - `prometeu-lsp/prometeu-lsp-v1/src/test/java/p/studio/lsp/services/protocol/PrometeuLanguageServerTest.java`
+   - Assert completion labels/details/snippets do not contain `arg0` or `arg1`.
+   - Assert signature help parameter labels use semantic names.
+   - Assert hover callable signatures use the same semantic names.
+
+## Acceptance Criteria
+
+- Completion surfaces use canonical semantic parameter names and do not leak `argN`.
+- Signature help surfaces use canonical semantic parameter names and do not leak `argN`.
+- Hover callable signatures use canonical semantic parameter names and do not leak `argN`.
+- The same callable uses the same parameter names across completion, signature help, and hover.
+- Missing parameter metadata is represented without fabricating public ordinal names.
+- VS Code extension behavior remains compatible with protocol outputs.
+
+## Tests
+
+- Run focused LSP tests:
+  - `CompilerLanguageServiceBridgeTest`
+  - `PrometeuTextDocumentServiceTest`
+  - `PrometeuLanguageServerTest`
+- Run the LSP Gradle test task for `prometeu-lsp-v1` if available.
+- Run VS Code extension tests/build if the extension code changes:
+  - `npm test` or `npm run compile` in `tools/vscode-extension`, depending on available scripts.
+- Run `discussion validate`.
+
+## Affected Artifacts
+
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/compiler/CompilerLanguageServiceBridge.java`
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/LanguageServiceBridge.java`
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineCompletionItem.java`
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineSignature.java`
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineSignatureHelp.java`
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/messages/BaselineHover.java`
+- `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/protocol/mapping/Lsp4jProtocolMessageMapper.java`
+- `tools/vscode-extension/src/extension.ts` if local formatting is present.
+- LSP protocol and bridge tests.