discussion/index.ndjson

@@ -12,15 +12,15 @@
 {"type":"discussion","id":"DSC-0056","status":"done","ticket":"multi-frontend-remove-pbs-branches","title":"Generalizar o contrato LSP/editorial para frontends","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","studio","frontend","coupling","multi-frontend"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0058","file":"discussion/lessons/DSC-0056-multi-frontend-remove-pbs-branches/LSN-0058-generic-frontend-editorial-contract-for-lsp.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15"}]}
 {"type":"discussion","id":"DSC-0055","status":"done","ticket":"multi-frontend-compiler-vs-language-services","title":"Separar compilacao de servicos editoriais de frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","lsp","editor","frontend","multi-frontend"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0056","file":"discussion/lessons/DSC-0055-multi-frontend-compiler-vs-language-services/LSN-0056-compile-first-frontends-with-optional-editorial-capabilities.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15"}]}
 {"type":"discussion","id":"DSC-0054","status":"done","ticket":"multi-frontend-provider-contract","title":"Introduzir provider completo de frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","frontend","registry","multi-frontend"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0055","file":"discussion/lessons/DSC-0054-multi-frontend-provider-contract/LSN-0055-static-frontend-providers-before-plugin-architecture.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15"}]}
-{"type":"discussion","id":"DSC-0053","status":"abandoned","ticket":"pbs-lsp-call-and-type-hierarchy","title":"PBS LSP Call and Type Hierarchy","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","call-hierarchy","type-hierarchy"],"agendas":[{"id":"AGD-0056","file":"AGD-0056-pbs-lsp-call-and-type-hierarchy.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0053","status":"done","ticket":"pbs-lsp-call-and-type-hierarchy","title":"PBS LSP Call and Type Hierarchy","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","call-hierarchy","type-hierarchy"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0052","status":"abandoned","ticket":"pbs-lsp-document-links","title":"PBS LSP Document Links","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","document-links","imports"],"agendas":[{"id":"AGD-0055","file":"AGD-0055-pbs-lsp-document-links.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0052","status":"done","ticket":"pbs-lsp-document-links","title":"PBS LSP Document Links","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","document-links","imports"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0051","status":"abandoned","ticket":"pbs-lsp-diagnostics-ux","title":"PBS LSP Diagnostics UX","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","diagnostics","ux"],"agendas":[{"id":"AGD-0054","file":"AGD-0054-pbs-lsp-diagnostics-ux.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0051","status":"done","ticket":"pbs-lsp-diagnostics-ux","title":"PBS LSP Diagnostics UX","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","diagnostics","ux"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0050","status":"abandoned","ticket":"pbs-lsp-folding-and-selection-ranges","title":"PBS LSP Folding and Selection Ranges","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","folding","selection-range"],"agendas":[{"id":"AGD-0053","file":"AGD-0053-pbs-lsp-folding-and-selection-ranges.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0050","status":"done","ticket":"pbs-lsp-folding-and-selection-ranges","title":"PBS LSP Folding and Selection Ranges","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","folding","selection-range"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0049","status":"abandoned","ticket":"pbs-lsp-completion-depth","title":"PBS LSP Completion Depth","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","completion"],"agendas":[{"id":"AGD-0052","file":"AGD-0052-pbs-lsp-completion-depth.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0049","status":"done","ticket":"pbs-lsp-completion-depth","title":"PBS LSP Completion Depth","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","completion"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0048","status":"abandoned","ticket":"pbs-lsp-performance-cache-and-snapshots","title":"PBS LSP Performance Cache and Snapshots","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","performance","caching"],"agendas":[{"id":"AGD-0051","file":"AGD-0051-pbs-lsp-performance-cache-and-snapshots.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0048","status":"done","ticket":"pbs-lsp-performance-cache-and-snapshots","title":"PBS LSP Performance Cache and Snapshots","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","performance","caching"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0047","status":"abandoned","ticket":"pbs-lsp-semantic-tokens-semantic-classification","title":"PBS LSP Semantic Token Classification","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","semantic-tokens"],"agendas":[{"id":"AGD-0050","file":"AGD-0050-pbs-lsp-semantic-token-classification.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0047","status":"done","ticket":"pbs-lsp-semantic-tokens-semantic-classification","title":"PBS LSP Semantic Token Classification","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","semantic-tokens"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0046","status":"abandoned","ticket":"pbs-lsp-import-assistance","title":"PBS LSP Import Assistance","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","imports","completion"],"agendas":[{"id":"AGD-0049","file":"AGD-0049-pbs-lsp-import-assistance.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0046","status":"done","ticket":"pbs-lsp-import-assistance","title":"PBS LSP Import Assistance","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","imports","completion"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0045","status":"abandoned","ticket":"pbs-lsp-formatting","title":"PBS LSP Formatting","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","formatting"],"agendas":[{"id":"AGD-0048","file":"AGD-0048-pbs-lsp-formatting.md","status":"abandoned","created_at":"2026-07-15","updated_at":"2026-09-22","_override_reason":"Merged into DSC-0066 / AGD-0069 on 2026-09-22. Separate agendas were stale against the shipped LSP. Explicit user request to consolidate before any decision."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0045","status":"done","ticket":"pbs-lsp-formatting","title":"PBS LSP Formatting","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","formatting"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0044","status":"done","ticket":"pbs-lsp-code-actions","title":"PBS LSP Code Actions and Quick Fixes","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","code-actions","quick-fix"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0073","file":"discussion/lessons/DSC-0044-pbs-lsp-code-actions/LSN-0073-pbs-quick-fixes-are-frontend-repairs-transported-by-the-lsp.md","status":"done","created_at":"2026-09-22","updated_at":"2026-09-22"}]}
 {"type":"discussion","id":"DSC-0043","status":"done","ticket":"pbs-lsp-rename-symbol","title":"PBS LSP Rename Symbol","created_at":"2026-07-15","updated_at":"2026-09-22","tags":["studio","lsp","vscode","compiler-pbs","editor","rename"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0072","file":"discussion/lessons/DSC-0043-pbs-lsp-rename-symbol/LSN-0072-pbs-rename-is-a-validated-physical-workspace-edit.md","status":"done","created_at":"2026-09-22","updated_at":"2026-09-22"}]}
 {"type":"discussion","id":"DSC-0042","status":"done","ticket":"pbs-lsp-workspace-symbols","title":"PBS LSP Workspace Symbols","created_at":"2026-07-15","updated_at":"2026-09-21","tags":["studio","lsp","vscode","compiler-pbs","editor","workspace-symbols"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0071","file":"discussion/lessons/DSC-0042-pbs-lsp-workspace-symbols/LSN-0071-pbs-workspace-symbols-are-a-physical-named-declaration-search.md","status":"done","created_at":"2026-09-21","updated_at":"2026-09-21"}]}

discussion/workflow/agendas/AGD-0048-pbs-lsp-formatting.md

@@ -1,62 +0,0 @@
----
-id: AGD-0048
-ticket: pbs-lsp-formatting
-title: PBS LSP Formatting
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, formatting]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS formatting is not automated, so style drifts across files, especially around attributes, services, blocks, imports, and multi-line Doc text blocks.
-
-## Context
-
-The LSP does not announce documentFormattingProvider. PBS has a parser and AST, but formatting must preserve documentation text block content while normalizing surrounding syntax and indentation.
-
-## Open Questions
-
-- [ ] Should formatting be AST-based, token-based, or hybrid to preserve comments and text blocks?
-- [ ] What canonical style should PBS use for attributes, braces, imports, params, and text blocks?
-- [ ] Should the first wave support full document formatting only, or also range/on-type formatting?
-
-## Options
-
-### Option A - Token-preserving formatter
-
-- **Approach:** Format from tokens and trivia, preserving comments and documentation text block contents.
-- **Pro:** Safer for active editing and text blocks.
-- **Con:** Harder to enforce deep structural layout.
-- **Maintainability:** Good if PBS formatting remains mostly syntactic.
-
-### Option B - AST pretty-printer
-
-- **Approach:** Reprint code from the AST using canonical style rules.
-- **Pro:** Produces consistent output.
-- **Con:** Risks losing comments/trivia and cannot handle malformed files well.
-- **Maintainability:** Strong only after AST/trivia ownership is explicit.
-
-## Tradeoffs
-
-Formatting must not damage `Doc` text blocks. That makes trivia preservation a first-class requirement rather than an implementation detail.
-
-## Recommendation
-
-Prefer Option A or a hybrid token/AST formatter. Avoid a pure AST pretty-printer until comments/trivia are modeled.
-
-## Discussion
-
-Formatter decision should define canonical style before implementation.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Decide PBS canonical formatting rules for attributes, braces, imports, params, and text blocks.

discussion/workflow/agendas/AGD-0049-pbs-lsp-import-assistance.md

@@ -1,62 +0,0 @@
----
-id: AGD-0049
-ticket: pbs-lsp-import-assistance
-title: PBS LSP Import Assistance
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, imports, completion]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS users do not get import-aware assistance, so discovering exported symbols and adding the right import from barrels, stdlib, or project modules remains manual.
-
-## Context
-
-Completion already exists for local/editorial contexts, and stdlib imports are understood by the compiler pipeline. The LSP does not yet provide auto-import completion, organize imports, or import quick fixes.
-
-## Open Questions
-
-- [ ] Should auto-import target project modules, stdlib modules, or both in the first wave?
-- [ ] How should barrels and explicit module imports be ranked and rendered in completion?
-- [ ] Should organize imports be a code action, source action, formatter responsibility, or separate feature?
-
-## Options
-
-### Option A - Import completion only
-
-- **Approach:** Suggest symbols from known modules and include import detail, but do not edit imports automatically.
-- **Pro:** Low risk and improves discovery.
-- **Con:** Still leaves manual import edits.
-- **Maintainability:** Good as a stepping stone.
-
-### Option B - Auto-import and organize imports
-
-- **Approach:** Completion/code actions insert missing imports and source actions sort/remove unused imports.
-- **Pro:** Matches modern editor expectations.
-- **Con:** Requires robust module export indexing and edit placement rules.
-- **Maintainability:** Strong if built on a proper import graph.
-
-## Tradeoffs
-
-Auto-import depends on knowing canonical exports and choosing an edit location. Doing that ad hoc in completion would create formatting and duplicate import issues.
-
-## Recommendation
-
-Prefer Option B as the target, but start with import-aware suggestions plus a limited missing-import quick fix.
-
-## Discussion
-
-This should be coordinated with code actions and formatter.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Decide first-wave import sources: stdlib only, project modules only, or both.

discussion/workflow/agendas/AGD-0050-pbs-lsp-semantic-token-classification.md

@@ -1,62 +0,0 @@
----
-id: AGD-0050
-ticket: pbs-lsp-semantic-tokens-semantic-classification
-title: PBS LSP Semantic Token Classification
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, semantic-tokens]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS semantic highlighting exists, but parts of the token classification can remain lexical or superficial, which limits visual accuracy for same-looking identifiers with different semantic roles.
-
-## Context
-
-The current LSP announces full semantic tokens and maps frontend semantic presentation to VS Code. The compiler has semantic read surfaces that can classify symbols more accurately than raw tokenization.
-
-## Open Questions
-
-- [ ] Which token categories must become semantic identity-based first?
-- [ ] Should semantic tokens be produced from compiler semantic surfaces, parser AST, lexer tokens, or layered output?
-- [ ] How should tokens behave in files with syntax or semantic errors during active editing?
-
-## Options
-
-### Option A - Lexical tokens with semantic overlays
-
-- **Approach:** Keep lexer-based tokenization as baseline and overlay semantic categories where resolution succeeds.
-- **Pro:** Stable during broken edits and incremental to improve.
-- **Con:** Some unresolved identifiers remain visually generic.
-- **Maintainability:** Strong because fallback behavior is explicit.
-
-### Option B - Fully semantic token stream
-
-- **Approach:** Generate all semantic tokens from compiler semantic surfaces.
-- **Pro:** Maximum accuracy when analysis succeeds.
-- **Con:** Highlighting may disappear or degrade sharply on incomplete code.
-- **Maintainability:** Risky unless snapshot/error recovery is excellent.
-
-## Tradeoffs
-
-Highlighting must be resilient while the user is typing. A perfect semantic pass that fails on partial code is worse than a layered model.
-
-## Recommendation
-
-Prefer Option A: lexical baseline plus semantic overlays from resolved symbols.
-
-## Discussion
-
-This can proceed independently but benefits from LSP snapshot/cache work.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Choose semantic overlay categories for the first pass.

discussion/workflow/agendas/AGD-0051-pbs-lsp-performance-cache-and-snapshots.md

@@ -1,62 +0,0 @@
----
-id: AGD-0051
-ticket: pbs-lsp-performance-cache-and-snapshots
-title: PBS LSP Performance Cache and Snapshots
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, performance, caching]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-Several PBS LSP requests rebuild or reanalyze substantial project state, which can become slow or jittery as projects grow and as richer features are added.
-
-## Context
-
-The current bridge favors correctness and simplicity by invoking compiler pipeline analysis for diagnostics and editorial documents. A complete LSP needs snapshot caching, invalidation, cancellation, and predictable latency.
-
-## Open Questions
-
-- [ ] What is the canonical project/document snapshot boundary for LSP requests?
-- [ ] Which requests can reuse semantic read surfaces safely across document changes?
-- [ ] How should cancellation, stale responses, and background reanalysis be handled?
-
-## Options
-
-### Option A - Request-local analysis
-
-- **Approach:** Keep each LSP request self-contained and rebuild analysis as needed.
-- **Pro:** Simple, deterministic, and less stateful.
-- **Con:** Latency grows with project size and feature richness.
-- **Maintainability:** Good for correctness, weak for interactive performance.
-
-### Option B - Project snapshot cache
-
-- **Approach:** Maintain per-project analysis snapshots with document overlays, invalidation, and cancellation-aware request handling.
-- **Pro:** Required for responsive definition, references, rename, and semantic tokens.
-- **Con:** Introduces lifecycle complexity and stale-result risks.
-- **Maintainability:** Strong if snapshot ownership and invalidation are explicit.
-
-## Tradeoffs
-
-A complete LSP needs shared state, but shared state must not leak stale analysis into edits. The decision is about the boundary, not just caching.
-
-## Recommendation
-
-Prefer Option B before implementing workspace-wide features like references and rename.
-
-## Discussion
-
-Define snapshot lifecycle, invalidation triggers, and cancellation policy.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Decide whether snapshot caching is a prerequisite for references/rename or can be staged later.

discussion/workflow/agendas/AGD-0052-pbs-lsp-completion-depth.md

@@ -1,62 +0,0 @@
----
-id: AGD-0052
-ticket: pbs-lsp-completion-depth
-title: PBS LSP Completion Depth
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, completion]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS completion works for core cases, but a complete daily-use experience needs ranking, resolve details, snippets, overload handling, context-aware suggestions, and richer documentation.
-
-## Context
-
-The current LSP announces completion with trigger character '.' and returns detail/documentation for resolved compiler candidates. It does not use resolveProvider, snippets, broad trigger contexts, or advanced ranking.
-
-## Open Questions
-
-- [ ] Which completion contexts should be supported first beyond member access?
-- [ ] Should completion use resolveProvider for expensive documentation/details or return everything eagerly?
-- [ ] How should overloads, snippets, imports, keywords, and stdlib candidates be ranked?
-
-## Options
-
-### Option A - Eager rich completion
-
-- **Approach:** Return labels, details, docs, and snippets directly in every completion response.
-- **Pro:** Simple client behavior and immediate docs.
-- **Con:** Can become expensive for broad/global completion.
-- **Maintainability:** Good while candidate sets remain small.
-
-### Option B - Completion resolve provider
-
-- **Approach:** Return lightweight candidates first and populate expensive docs/details through `completionItem/resolve`.
-- **Pro:** Scales better for large candidate sets and import-aware suggestions.
-- **Con:** Requires client/server resolve plumbing and stable candidate identities.
-- **Maintainability:** Strong for a full LSP.
-
-## Tradeoffs
-
-The current eager model is fine for scoped completions, but global/import-aware completion may need resolve to avoid latency.
-
-## Recommendation
-
-Prefer a staged approach: keep eager for current contexts, design resolve before broad workspace/import completion.
-
-## Discussion
-
-Define completion contexts and ranking before adding snippets or resolve.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-List first-wave completion contexts beyond member access.

discussion/workflow/agendas/AGD-0053-pbs-lsp-folding-and-selection-ranges.md

@@ -1,62 +0,0 @@
----
-id: AGD-0053
-ticket: pbs-lsp-folding-and-selection-ranges
-title: PBS LSP Folding and Selection Ranges
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, folding, selection-range]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS users do not get structural folding or smart selection ranges, so navigating and selecting nested functions, blocks, services, attributes, and Doc text blocks is more manual than it should be.
-
-## Context
-
-The parser knows syntactic spans for declarations and blocks. The LSP currently does not announce foldingRangeProvider or selectionRangeProvider.
-
-## Open Questions
-
-- [ ] Should folding ranges be computed from AST spans, token pairs, or a hybrid that handles malformed files?
-- [ ] Which constructs should fold in the first wave: imports, declarations, blocks, attributes, text blocks, or all of them?
-- [ ] What selection range hierarchy should VS Code expose for identifiers, calls, params, blocks, and declarations?
-
-## Options
-
-### Option A - Parser span ranges
-
-- **Approach:** Use AST spans for declarations, blocks, parameter lists, and text blocks.
-- **Pro:** Accurate for well-formed code and easy to map to LSP ranges.
-- **Con:** Can degrade when parsing fails mid-file.
-- **Maintainability:** Good because parser owns structure.
-
-### Option B - Token pair scanning
-
-- **Approach:** Compute ranges from brace/paren/text-block tokens without relying on full AST validity.
-- **Pro:** More resilient during malformed edits.
-- **Con:** Less semantically meaningful and can produce noisy ranges.
-- **Maintainability:** Good only as fallback.
-
-## Tradeoffs
-
-Folding and selection should keep working while typing. AST ranges are higher quality, but token fallback may be needed for broken files.
-
-## Recommendation
-
-Prefer a hybrid: AST ranges first, token fallback for unmatched/incomplete constructs.
-
-## Discussion
-
-This is an editor UX feature with low semantic dependency and can be planned independently.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Decide first-wave foldable constructs and selection hierarchy.

discussion/workflow/agendas/AGD-0054-pbs-lsp-diagnostics-ux.md

@@ -1,62 +0,0 @@
----
-id: AGD-0054
-ticket: pbs-lsp-diagnostics-ux
-title: PBS LSP Diagnostics UX
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, diagnostics, ux]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS diagnostics reach VS Code, but the editor experience can still be hard to act on when ranges, related information, severity, and phase context are too generic.
-
-## Context
-
-The LSP maps compiler diagnostics to LSP diagnostics. Compiler diagnostics include phase/code/message/range in several paths, but not all editor-friendly fields are consistently exposed.
-
-## Open Questions
-
-- [ ] Which diagnostics need better ranges or related information first?
-- [ ] Should diagnostic source include compiler phase, frontend, or both?
-- [ ] What structured diagnostic metadata is needed for future quick fixes without coupling UI to text messages?
-
-## Options
-
-### Option A - Mapper-only UX improvements
-
-- **Approach:** Improve LSP diagnostic mapping using existing diagnostic fields.
-- **Pro:** Quick improvements to source, severity, and display consistency.
-- **Con:** Cannot add missing related spans or repair metadata that compiler diagnostics do not expose.
-- **Maintainability:** Good for presentation-only changes.
-
-### Option B - Structured diagnostic contract
-
-- **Approach:** Extend compiler diagnostics with editor-facing metadata such as phase, related locations, stable quick-fix hints, and refined ranges.
-- **Pro:** Enables better diagnostics and future code actions without parsing message text.
-- **Con:** Requires compiler/core diagnostic API changes.
-- **Maintainability:** Strong as the foundation for quick fixes and richer UX.
-
-## Tradeoffs
-
-Some improvements belong in the LSP mapper, but the most valuable changes require structured information at diagnostic creation time.
-
-## Recommendation
-
-Prefer Option B as the target, with mapper-only cleanup allowed for low-risk display fixes.
-
-## Discussion
-
-This agenda should inform code actions before quick fixes become broad.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Inventory high-frequency diagnostics and identify which need better ranges, related information, or repair hints.

discussion/workflow/agendas/AGD-0055-pbs-lsp-document-links.md

@@ -1,62 +0,0 @@
----
-id: AGD-0055
-ticket: pbs-lsp-document-links
-title: PBS LSP Document Links
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, document-links, imports]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS import/module references and asset-like surfaces are plain text in VS Code, so users cannot click through to imported modules or related project resources.
-
-## Context
-
-The compiler understands module references and project files. The LSP does not announce documentLinkProvider, and the VS Code extension delegates all language behavior to the server.
-
-## Open Questions
-
-- [ ] Which references should become document links first: imports, barrels, stdlib modules, assets/addressables, or docs?
-- [ ] How should virtual or stdlib resources be represented as link targets?
-- [ ] Should document links overlap with go-to-definition or remain a separate lightweight navigation feature?
-
-## Options
-
-### Option A - Import/module links only
-
-- **Approach:** Expose `documentLink` for module references such as `@sdk:gfx` and barrel paths.
-- **Pro:** Narrow, useful, and mostly aligned with existing module resolution.
-- **Con:** Does not cover assets/addressables or documentation links.
-- **Maintainability:** Strong first wave.
-
-### Option B - General resource links
-
-- **Approach:** Link imports, stdlib modules, assets, addressables, and possibly documentation/resource surfaces.
-- **Pro:** Richer navigation across project resources.
-- **Con:** Requires resource-specific target policy and may overlap with definition.
-- **Maintainability:** Good only after resource ownership is defined.
-
-## Tradeoffs
-
-Document links should remain lightweight. If a link requires semantic identity and symbol resolution, it may belong in go-to-definition instead.
-
-## Recommendation
-
-Prefer Option A first: imports and module references only.
-
-## Discussion
-
-Coordinate stdlib target handling with go-to-definition.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Decide first-wave link targets and how stdlib/module URIs are represented.

discussion/workflow/agendas/AGD-0056-pbs-lsp-call-and-type-hierarchy.md

@@ -1,62 +0,0 @@
----
-id: AGD-0056
-ticket: pbs-lsp-call-and-type-hierarchy
-title: PBS LSP Call and Type Hierarchy
-status: abandoned
-created: 2026-07-15
-resolved:
-decision:
-tags: [studio, lsp, vscode, compiler-pbs, editor, call-hierarchy, type-hierarchy]
----
-
-## Pain
-
-Domain owner: `studio/lsp`
-
-PBS users cannot inspect call relationships or type/member relationships from the editor, which limits understanding of larger projects after basic navigation exists.
-
-## Context
-
-Call hierarchy and type hierarchy are advanced LSP features. They depend on reliable semantic identity, references, callsite classification, and type ownership surfaces, so they should probably follow definition/references rather than precede them.
-
-## Open Questions
-
-- [ ] Should call hierarchy and type hierarchy be one discussion or split after dependencies are clearer?
-- [ ] Which relationships are valuable for PBS: function call graph, service method calls, struct methods, contract implementations, host/intrinsic calls, or all of them?
-- [ ] What prerequisite symbol/reference infrastructure must be completed before this feature is safe to implement?
-
-## Options
-
-### Option A - Call hierarchy only
-
-- **Approach:** Implement incoming/outgoing calls for functions and methods after callsite references are stable.
-- **Pro:** Directly useful and builds on executable call resolution.
-- **Con:** Does not cover type ownership, contracts, or implementations.
-- **Maintainability:** Strong if based on the reference/callsite index.
-
-### Option B - Split call hierarchy and type hierarchy
-
-- **Approach:** Treat call graph and type/member/contract hierarchy as separate decisions and implementations.
-- **Pro:** Avoids mixing two different semantic models.
-- **Con:** Creates more workflow artifacts and sequencing work.
-- **Maintainability:** Strong; each feature can evolve on its own contract.
-
-## Tradeoffs
-
-Call hierarchy and type hierarchy share LSP vocabulary but not the same compiler data. Coupling them too early would make the first implementation harder to reason about.
-
-## Recommendation
-
-Prefer Option B: split after this agenda confirms dependencies, likely implementing call hierarchy first.
-
-## Discussion
-
-This should wait until definition and references are complete.
-
-## Resolution
-
-Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
-
-## Next Step
-
-Decide whether to split into two discussions before moving to decisions.

prometeu-studio/src/test/java/p/studio/debug/runtime/StudioRuntimeHandshakeServiceTest.java

@@ -10,6 +10,8 @@ import java.io.BufferedReader;
 import java.io.BufferedWriter;
 import java.io.InputStreamReader;
 import java.io.OutputStreamWriter;
+import java.net.InetAddress;
+import java.net.InetSocketAddress;
 import java.net.ServerSocket;
 import java.net.Socket;
 import java.nio.charset.StandardCharsets;
@@ -22,10 +24,12 @@ import static org.junit.jupiter.api.Assertions.*;
 final class StudioRuntimeHandshakeServiceTest {
     @Test
     void connectsPublishesRuntimeHandshakeAndStreamsLogEvents() throws Exception {
-        try (final ServerSocket serverSocket = new ServerSocket(0)) {
+        try (final ServerSocket serverSocket = new ServerSocket()) {
+            serverSocket.bind(new InetSocketAddress(InetAddress.getByName("127.0.0.1"), 0));
             final CountDownLatch clientStarted = new CountDownLatch(1);
             final CountDownLatch eventDelivered = new CountDownLatch(1);
             final Thread serverThread = new Thread(() -> serveSuccessfulHandshake(serverSocket, clientStarted, eventDelivered));
+            serverThread.setDaemon(true);
             serverThread.start();
 
             final StudioExecutionSessionService session = new StudioExecutionSessionService();
@@ -36,7 +40,7 @@ final class StudioRuntimeHandshakeServiceTest {
                 final StudioRuntimeHandshakeService service = new StudioRuntimeHandshakeService(new ObjectMapper(), backgroundTasks);
                 final StudioRuntimeHandshakeResult result = service.connect(session, settings);
 
-                assertTrue(result.success());
+                assertTrue(result.success(), result.failureMessage());
                 assertEquals(StudioExecutionState.RUNNING, session.snapshot().state());
                 assertTrue(clientStarted.await(2, TimeUnit.SECONDS));
                 assertTrue(eventDelivered.await(2, TimeUnit.SECONDS));
@@ -90,6 +94,9 @@ final class StudioRuntimeHandshakeServiceTest {
             writer.flush();
             eventDelivered.countDown();
         } catch (Exception exception) {
+            if (serverSocket.isClosed()) {
+                return;
+            }
             throw new RuntimeException(exception);
         }
     }