Intrepid/prometeu-studio
Intrepid/prometeu-studio
4
0
Fork 0
Code Pull Requests Activity
prometeu-studio/discussion/workflow/agendas/AGD-0054-pbs-lsp-diagnostics-ux.md
bQUARKz 6e594c15d7
All checks were successful
JaCoCo Coverage #### Project Overview No changes detected, that affect the code coverage. * Line Coverage: 61.37% (17351/28272) * Branch Coverage: 52.31% (6722/12850) * Lines of Code: 28272 * Cyclomatic Complexity: 11325 #### Quality Gates Summary Output truncated.
Details
Test / Build skipped: 15, passed: 601
Details
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
Details
add LSP agendas
2026-07-15 07:40:45 +01:00

2.1 KiB
Raw Blame History

id ticket title status created resolved decision tags
AGD-0054 pbs-lsp-diagnostics-ux PBS LSP Diagnostics UX open 2026-07-15
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

Ainda em aberto.

Next Step

Inventory high-frequency diagnostics and identify which need better ranges, related information, or repair hints.