HAL9000
30c93bc95e
CI / lint (pull_request) Successful in 53s
CI / quality (pull_request) Successful in 48s
CI / typecheck (pull_request) Successful in 59s
CI / build (pull_request) Successful in 54s
CI / push-validation (pull_request) Successful in 39s
CI / helm (pull_request) Successful in 45s
CI / security (pull_request) Successful in 1m30s
CI / unit_tests (pull_request) Successful in 6m53s
CI / integration_tests (pull_request) Successful in 8m21s
CI / docker (pull_request) Successful in 1m36s
CI / coverage (pull_request) Successful in 8m54s
CI / status-check (pull_request) Successful in 2s
features/lsp_actor_service_wiring.feature scenarios "handles multiple LSP servers" and "tool specs have correct schema": add an explicit `| CAPABILITIES |` header to the capability tables. Behave treats the first table row as the heading, so `| DIAGNOSTICS |` (the only row) was being silently dropped, leaving the registered server with zero capabilities and the adapter generating no tool specs. features/steps/lsp_actor_service_steps.py: strip surrounding double quotes from each entry in the comma-separated `fields` placeholder of the `requires "..."` Then step so a feature line like `requires "file_path", "line", "column"` resolves to the three unquoted field names rather than `file_path"`, `"line"`, `"column"`. features/steps/tui_persona_cycle_steps.py: include the surrounding double quotes in the step pattern for "the registry last persona should be set to ..." so the feature literal `"p2"` matches as `p2` (without the quotes the placeholder captured `"p2"` and the equality check against the registry value failed). src/cleveragents/tui/persona/registry.py: reject absolute paths from `resolve_export_path` and `resolve_import_path` with the messages the "Persona export/import rejects absolute path targets" scenarios in features/repl_input_modes.feature expect. The previous behaviour silently accepted absolute paths, defeating the working-directory sandboxing intent. ISSUES CLOSED: #5663
96 lines
3.8 KiB
Gherkin
96 lines
3.8 KiB
Gherkin
Feature: LSP Actor Service — wire LspRuntime and LspToolAdapter into actor execution
|
|
|
|
Background:
|
|
Given a clean LSP actor service registry
|
|
And a test workspace directory
|
|
|
|
Scenario: LspActorService activates bindings and generates tool specs
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| DIAGNOSTICS |
|
|
| HOVER |
|
|
| COMPLETIONS |
|
|
And an actor with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/pyright |
|
|
When the actor bindings are activated with workspace path
|
|
Then the LSP runtime has started the "local/pyright" server
|
|
And tool specs are generated for the actor:
|
|
| local/pyright/diagnostics |
|
|
| local/pyright/hover |
|
|
| local/pyright/completions |
|
|
|
|
Scenario: LspActorService handles multiple LSP servers
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| CAPABILITIES |
|
|
| DIAGNOSTICS |
|
|
And an LSP server "local/eslint" is registered with capabilities:
|
|
| CAPABILITIES |
|
|
| DIAGNOSTICS |
|
|
And an actor with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/pyright |
|
|
| local/eslint |
|
|
When the actor bindings are activated with workspace path
|
|
Then the LSP runtime has started the "local/pyright" server
|
|
And the LSP runtime has started the "local/eslint" server
|
|
And tool specs are generated for both servers
|
|
|
|
Scenario: LspActorService deactivates bindings on shutdown
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| DIAGNOSTICS |
|
|
And an actor with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/pyright |
|
|
And the actor bindings are activated with workspace path
|
|
When the actor bindings are deactivated
|
|
Then the LSP runtime has released the "local/pyright" server
|
|
|
|
Scenario: LspActorService handles missing servers gracefully
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| DIAGNOSTICS |
|
|
And an actor with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/missing |
|
|
When the actor bindings are activated with workspace path
|
|
Then the activation completes with warnings
|
|
And no tool specs are generated for the missing server
|
|
|
|
Scenario: LspActorService validates input parameters
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| DIAGNOSTICS |
|
|
And an actor with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/pyright |
|
|
When activation is attempted with empty actor name
|
|
Then a ValueError is raised with message "actor_name must be a non-empty string"
|
|
When activation is attempted with empty workspace path
|
|
Then a ValueError is raised with message "workspace_path must be a non-empty string"
|
|
|
|
Scenario: LspActorService integrates with actor execution
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| DIAGNOSTICS |
|
|
And an actor "local/code-reviewer" with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/pyright |
|
|
When the actor is loaded and activated
|
|
Then the actor has access to LSP tools:
|
|
| local/pyright/diagnostics |
|
|
And the LSP server is running in the background
|
|
|
|
Scenario: LspActorService tool specs have correct schema
|
|
Given an LSP server "local/pyright" is registered with capabilities:
|
|
| CAPABILITIES |
|
|
| DIAGNOSTICS |
|
|
| HOVER |
|
|
And an actor with LSP bindings:
|
|
| lsp_server_name |
|
|
| local/pyright |
|
|
When the actor bindings are activated with workspace path
|
|
Then each tool spec has required fields:
|
|
| name |
|
|
| description |
|
|
| handler |
|
|
| input_schema |
|
|
And the input_schema for "local/pyright/diagnostics" requires "file_path"
|
|
And the input_schema for "local/pyright/hover" requires "file_path", "line", "column"
|