fix: list server tools

.brv/context-tree/facts/conventions/rlm_curate_single_pass_workflow.md

@@ -1,38 +1,44 @@
 ---
 title: RLM Curate Single-Pass Workflow
-summary: Curation workflow guidance for single-pass RLM processing, including recon-aware execution and verification.
+summary: 'Single-pass RLM curation workflow: use recon first, skip chunking for small contexts, curate directly with UPSERT, and verify via result.applied[].filePath.'
 tags: []
-related: []
+related: [facts/project/current_runtime_timestamp.md, facts/conventions/rlm_curate_workflow.md]
 keywords: []
 createdAt: '2026-05-26T18:08:33.384Z'
-updatedAt: '2026-05-26T18:08:33.384Z'
+updatedAt: '2026-05-26T21:53:06.950Z'
 ---
 ## Reason
-Preserve the curation workflow requirement inferred from the task instructions.
+Document the single-pass RLM curation workflow requirements and execution guidance
 
 ## Raw Concept
 **Task:**
-Document the single-pass RLM curation workflow and verification rule.
+Document the RLM curate single-pass workflow and execution requirements.
 
 **Changes:**
 - Used precomputed recon output to proceed directly
 - Captured the requirement to verify via applied file paths
+- Captured the single-pass recommendation for the current context
+- Recorded the no-chunking rule for small contexts
+- Recorded verification requirements for curate results
 
 **Flow:**
-recon -> single-pass extraction -> curate -> verify applied paths
+recon -> inspect suggestedMode -> skip chunking when single-pass -> curate directly -> verify applied file paths
 
-**Timestamp:** 2026-05-26T18:08:21.401Z
+**Timestamp:** 2026-05-26T21:52:59.866Z
 
 ## Narrative
 ### Structure
-This entry records the operational guidance for handling small contexts in one pass.
+This knowledge entry captures the execution path for single-pass RLM curation, including the expected control flow and verification approach.
 
 ### Dependencies
-Relies on precomputed recon metadata and the curated result summary.
+Depends on precomputed recon metadata and the curate result object; mapExtract is optional and only relevant when chunking is needed.
 
 ### Highlights
-Emphasizes efficiency by skipping chunking when the context is already small enough.
+The workflow emphasizes minimal steps for small contexts, direct UPSERT curation, and strict verification through applied file paths.
 
 ## Facts
-- **curation_mode**: The recon result already computed suggests single-pass processing. [convention]
-- **verification_method**: Verification should use applied file paths rather than readFile reads. [convention]
+- **rlm_suggested_mode**: Recon was already computed and suggestedMode is single-pass for this context. [convention]
+- **rlm_chunking_policy**: For single-pass contexts, chunking should be skipped entirely. [convention]
+- **rlm_single_pass_steps**: When a context is small, it should be curated in two code_exec calls: recon and curate. [convention]
+- **mapextract_timeout**: If mapExtract is used, code_exec must set timeout: 300000 on the tool call itself. [convention]
+- **verification_method**: Verification for curation should use result.applied[].filePath and should not call readFile for verification. [convention]

.brv/context-tree/facts/conventions/rlm_curation_single_pass_workflow.md

@@ -1,45 +1,50 @@
 ---
-title: RLM Curation Single-pass Workflow
-summary: Single-pass RLM curation workflow uses recon data, direct extraction, dedup/grouping, UPSERT curation, and verification via applied file paths.
+title: RLM Curation Single-Pass Workflow
+summary: RLM curation workflow uses recon results to proceed directly to single-pass curation when suggestedMode is single-pass, with verification via applied file paths and mandatory status reporting.
 tags: []
 related: [facts/project/rlm_curate_execution_guidance.md, facts/conventions/rlm_curate_single_pass_workflow.md]
 keywords: []
 createdAt: '2026-05-26T18:31:24.268Z'
-updatedAt: '2026-05-26T18:31:24.268Z'
+updatedAt: '2026-05-26T22:27:38.282Z'
 ---
 ## Reason
-Curate the single-pass RLM workflow guidance from the provided context
+Document the single-pass RLM curation workflow and requirements from the provided context.
 
 ## Raw Concept
 **Task:**
-Document the RLM curation approach for a single-pass context.
+Document the RLM single-pass curation workflow and execution requirements.
 
 **Changes:**
 - Use pre-computed recon output to avoid redundant analysis
 - Proceed directly to extraction when suggestedMode is single-pass
 - Organize extracted facts with deduplication and grouping
 - Curate via UPSERT and verify through applied file paths
+- Use recon output to choose single-pass mode when suggestedMode is single-pass
+- Skip chunking entirely for small contexts
+- Curate directly without additional extraction steps
 
 **Flow:**
-pre-computed recon -> extraction -> dedup/group -> curate -> verify
+recon -> single-pass decision -> curate -> verify applied file paths -> report status
 
-**Timestamp:** 2026-05-26T18:31:12.025Z
+**Timestamp:** 2026-05-26T22:27:31.244Z
 
 **Author:** ByteRover context engineer
 
 ## Narrative
 ### Structure
-The guidance is an execution recipe for small RLM curation jobs: rely on the existing recon result, skip chunking, and complete the operation in one pass.
+This context describes the small-context RLM path where recon already determined the mode and no chunking or map extraction is needed.
 
 ### Dependencies
-Depends on the pre-computed recon result, the curation history variable, the metadata variable, and the taskId variable supplied by the caller.
+Depends on precomputed recon metadata and the curation result object for verification.
 
 ### Highlights
-Emphasizes direct extraction, use of tools.curation.dedup() and tools.curation.groupBySubject(), and final verification through applied file paths.
+The workflow is optimized for concise contexts by skipping extraction overhead and relying on direct UPSERT curation.
+
+### Rules
+Do not call tools.curation.recon when recon is already precomputed. Do not print raw context. Verify via result.applied[].filePath.
 
 ## Facts
-- **curation_mode**: The context was small enough for single-pass curation. [convention]
-- **recon_status**: Recon had already been computed before curation. [convention]
-- **recon_usage**: The task requires proceeding directly to extraction without recomputing recon. [convention]
-- **mapextract_task_id**: Map extraction should pass the taskId as a bare variable when used. [convention]
-- **verification_method**: Verification should use result.applied[].filePath and not readFile. [convention]
+- **rlm_single_pass_mode**: When recon suggests single-pass, chunking is skipped entirely. [convention]
+- **rlm_single_pass_calls**: For single-pass contexts, the workflow should proceed in 2 code_exec calls: recon and curate. [convention]
+- **rlm_verification_method**: Verification should use result.applied[].filePath rather than readFile. [convention]
+- **mapextract_timeout_ms**: Any code_exec call containing mapExtract must use timeout 300000 on the tool call itself. [convention]

.brv/context-tree/facts/conventions/rlm_curation_workflow_guidance.md

@@ -1,18 +1,18 @@
 ---
 title: RLM Curation Workflow Guidance
-summary: RLM curation workflow guidance covering recon, single-pass handling, mapExtract timeouts, and verification rules.
+summary: RLM curation uses single-pass processing when suggested, prefers UPSERT, and verifies applied file paths rather than rereading files.
 tags: []
 related: []
 keywords: []
 createdAt: '2026-05-26T10:51:08.735Z'
-updatedAt: '2026-05-26T14:26:07.876Z'
+updatedAt: '2026-05-26T19:32:46.985Z'
 ---
 ## Reason
-Capture curation workflow guidance and verification rules from the provided context.
+Curate the current RLM curation instructions and verification conventions from the provided context
 
 ## Raw Concept
 **Task:**
-Document the RLM curation workflow guidance for context-driven knowledge curation.
+Curate the provided context using the RLM approach
 
 **Changes:**
 - Use precomputed recon results when available
@@ -23,31 +23,36 @@ Document the RLM curation workflow guidance for context-driven knowledge curatio
 - Confirmed single-pass processing for the current context.
 - Captured the no-rerun recon rule for precomputed contexts.
 - Captured the mapExtract timeout requirement and verification rule.
+- Use single-pass RLM processing when recon suggests single-pass
+- Prefer UPSERT for curation operations
+- Verify curation through result.applied[].filePath
+
+**Files:**
+- .brv/context-tree/facts/conventions/context.md
 
 **Flow:**
-recon precomputed -> extract context -> curate knowledge -> verify applied file paths
+recon already computed -> extract key facts -> dedup/group -> curate -> verify applied file paths
 
-**Timestamp:** 2026-05-26T14:25:50.483Z
+**Timestamp:** 2026-05-26T19:32:39.707Z
 
 **Author:** ByteRover context engineer
 
 ## Narrative
 ### Structure
-This guidance defines how to process curated context when recon is already available and when to switch to mapExtract for chunked inputs.
+This guidance documents the curation workflow conventions used in the project context tree.
 
 ### Dependencies
-Relies on precomputed recon metadata, task-scoped context variables, and curate result inspection.
+Depends on the RLM flow and the curated knowledge store under .brv/context-tree.
 
 ### Highlights
-The workflow emphasizes avoiding redundant recon calls, preserving raw context privacy, enforcing the 300000 ms timeout for mapExtract, and verifying via applied file paths.
+The context emphasizes single-pass processing for small contexts and a no-readback verification pattern.
 
 ### Rules
-Do NOT print raw context. Do NOT call tools.curation.recon when recon has already been precomputed. For chunked extraction use tools.curation.mapExtract() with timeout: 300000 on the code_exec call itself. Use tools.curation.groupBySubject() and tools.curation.dedup() to organize extractions. Verify via result.applied[].filePath — do NOT call readFile for verification.
+Do NOT print raw context. Do NOT call tools.curation.recon when recon has already been computed. Proceed directly to extraction. Verify via result.applied[].filePath and do NOT call readFile for verification.
 
 ## Facts
-- **rlm_curation_workflow**: The curation workflow uses the RLM approach with precomputed recon, single-pass extraction for small contexts, and mapExtract for chunked contexts. [convention]
-- **single_pass_recon_rule**: For single-pass contexts, recon is already computed and should not be called again before curating. [convention]
-- **mapextract_timeout**: When mapExtract is used, code_exec must set timeout: 300000 on the tool call itself. [convention]
-- **verification_rule**: Verification after curation must use result.applied[].filePath and must not use readFile for verification. [convention]
-- **no_raw_context_printing**: Context variables should not be printed raw during curation. [convention]
-- **current_task_id**: The current curation task references task ID __taskId_ed34ca7d_1074_42ed_966f_0e77b7807351. [project]
+- **context_tree**: The project uses a centralized curated context tree under .brv/context-tree for durable knowledge. [project]
+- **rlm_mode**: Curation workflows in this project prefer RLM single-pass processing when recon suggests single-pass. [convention]
+- **curate_operation_preference**: Curation operations should use UPSERT by default rather than ADD or UPDATE. [convention]
+- **verification_method**: The current curation guidance emphasizes verifying results via result.applied[].filePath instead of reading files back for verification. [convention]
+- **current_task**: The active task is to curate the provided context via the RLM approach. [other]

.brv/context-tree/facts/project/current_runtime_timestamp.md

@@ -34,16 +34,25 @@ timestamp supplied -> normalize as ISO 8601 fact -> curate into facts/project
 
 ## Narrative
 ### Structure
-A single timestamp fact stored as a project-level knowledge entry for session reference.
+A timestamp fact stored as a project-level knowledge entry for session reference, with chronological context preserved rather than overwritten.
 
 ### Dependencies
 Depends on the injected curate context, history, metadata, and task ID variables supplied by the caller.
 
+### Chronology
+1. Historical runtime reference: `current_runtime_timestamp.md` captured 2026-05-26T10:04:55.754Z as the session runtime timestamp.
+2. Later planning snapshot: `context_and_plan_execution_notes.md` records the 2026-05-26T09:22:02.646Z planning context for the LSP MCP server workstream.
+
+### Current State
+The runtime timestamp remains a historical session fact. For current planning context, prefer `context_and_plan_execution_notes.md`; that newer planning note supersedes this runtime-only reference when deciding what project plan, execution guidance, or workstream context is current.
+
 ### Highlights
-Preserves the exact runtime timestamp for recall and temporal reasoning.
+Preserves the exact runtime timestamp for recall and temporal reasoning while distinguishing historical timestamp context from current planning state.
 
 ## Facts
 - **current_runtime_timestamp**: Current date and time is 2026-05-26T10:04:55.754Z [project]
+- **historical_context**: This file preserves a runtime timestamp as historical session context rather than current planning guidance. [project]
+- **current_planning_context**: Use context_and_plan_execution_notes.md as the current planning-context reference for the LSP MCP workstream. [project]
 
 ---
 

.brv/context-tree/facts/project/lsp_caplet_smoke_test_findings.md

@@ -0,0 +1,59 @@
+---
+title: LSP Caplet Smoke Test Findings
+summary: Broad smoke test across 49 LSP caplet tools succeeded end-to-end; unsupported TypeScript capabilities failed structurally, and edit-tool success schemas were fixed in commit 66e22fa.
+tags: []
+related: [facts/project/rlm_curate_single_pass_workflow.md]
+keywords: []
+createdAt: '2026-05-26T22:53:58.838Z'
+updatedAt: '2026-05-26T22:53:58.838Z'
+---
+## Reason
+Curate durable findings from a broad smoke test of LSP caplet tools, including success, expected failures, and fixes.
+
+## Raw Concept
+**Task:**
+Document the results and fixes from a comprehensive LSP caplet tool smoke test.
+
+**Changes:**
+- Validated all 49 caplet tools through the CLI
+- Confirmed unsupported TypeScript-language features fail structurally rather than crashing
+- Fixed edit-tool success output schemas and added a regression test
+
+**Files:**
+- tests/fixtures/fake-lsp-server.ts
+
+**Flow:**
+smoke test -> observe structured failures/successes -> fix schema issue -> add regression test -> restart stale backend -> confirm success
+
+**Timestamp:** 2026-05-26T22:53:39.920Z
+
+**Author:** assistant
+
+## Narrative
+### Structure
+The smoke test covered server/control, raw request/notify, diagnostics/edit, and navigation/query tool groups. The outcome separated true transport/schema regressions from expected capability gaps in the TypeScript LSP.
+
+### Dependencies
+Relies on the caplet CLI, TypeScript LSP capability behavior, and the edit-tool schema validation path that was corrected in commit 66e22fa.
+
+### Highlights
+This run confirmed end-to-end tool plumbing and surfaced a stale-backend issue that masked the schema fix until the backend was restarted.
+
+### Rules
+Safe edit tools were tested with apply: false. Stop tools were tested at the end.
+
+### Examples
+Examples of working control tools include list_servers and server_status; examples of expected failures include declaration and document_colors.
+
+## Facts
+- **caplet_tool_count**: Broad smoke test completed across all 49 LSP caplet tools. [project]
+- **caplet_cli_result**: 49/49 tools returned through the caplet CLI without downstream transport/schema failure. [project]
+- **unsupported_tools_behavior**: Tools unsupported by the TypeScript LSP returned structured per-server failures instead of crashing. [project]
+- **safe_edit_test_mode**: Safe edit tools were tested with apply set to false. [project]
+- **stop_tools_tested**: Stop tools were tested at the end of the smoke test. [project]
+- **working_tool_examples**: The following tools worked as key examples: list_servers, server_status, search_servers, stop_server, stop_workspace, request, notify, diagnostics, rename, format_document, format_range, code_actions, hover, completion, definition, references, document_symbols, folding_ranges, semantic_tokens_*, and inlay_hints. [project]
+- **expected_structured_failures**: Expected structured failures were observed for declaration, document_links, document_colors, call_hierarchy_*, type_hierarchy_*, monikers, inline_values, format_on_type, and some resolve tools with synthetic test items. [project]
+- **format_document_schema_fix**: A schema issue was fixed for format_document success results through the caplet wrapper. [project]
+- **edit_tool_schema_fix**: Edit-tool success output schemas were fixed and a regression test was added. [project]
+- **commit_reference**: The fix was committed as 66e22fa with message: fix: validate edit tool success outputs. [project]
+- **backend_restart_effect**: After restarting the stale caplet backend, format_document returned structured success correctly. [project]

.brv/context-tree/facts/project/lsp_mcp_interface_cleanup.md

@@ -1,43 +1,45 @@
 ---
 title: LSP MCP Interface Cleanup
-summary: Documents the LSP MCP interface cleanup work, including CLI/MCP consolidation, command policy handling, tool registration behavior, and verification outcomes.
+summary: LSP MCP interface cleanup work covering tool naming consistency, output schema handling, server discovery, and verification updates.
 tags: []
 related: []
 keywords: []
 createdAt: '2026-05-26T14:39:23.671Z'
-updatedAt: '2026-05-26T14:55:55.578Z'
+updatedAt: '2026-05-26T22:44:47.552Z'
 ---
 ## Reason
-Curate project guidance about cleaning up the LSP MCP interface and related implementation details
+Curate RLM context about cleanup of the LSP MCP interface and related tooling
 
 ## Raw Concept
 **Task:**
-Document the LSP MCP interface cleanup effort and its implementation notes.
+Document the LSP MCP interface cleanup work captured in the curated context.
 
 **Changes:**
 - Standardize tool naming and method wiring
 - Align generated LSP output schemas with server/tool interfaces
 - Record cleanup and implementation notes in durable knowledge
 - Captured interface cleanup guidance
 - Recorded implementation details and verification outcomes
+- Captured cleanup-related implementation and review notes
+- Recorded interface, schema, discovery, and verification concerns
 
 **Flow:**
-identify interface cleanup concerns -> document implementation details -> verify readiness
+cleanup work -> review findings -> verification updates -> curated knowledge
 
-**Timestamp:** 2026-05-26
+**Timestamp:** 2026-05-26T22:44:41.174Z
 
 **Author:** ByteRover context engineer
 
 ## Narrative
 ### Structure
-This knowledge entry captures the interface cleanup task and the related implementation/verification notes.
+The knowledge captures a compact project-facing record of interface cleanup efforts for the LSP MCP codebase.
 
 ### Dependencies
-Relates to LSP server implementation, MCP server behavior, tool registration, and command policy handling.
+This context is tied to review, tooling, schema, and verification materials in the project tree.
 
 ### Highlights
-Preserves the cleanup scope and the associated project notes for future recall.
+The preserved knowledge is intended to support future recall of interface cleanup decisions and associated implementation notes.
 
 ## Facts
-- **lsp_mcp_interface_cleanup**: The project has a cleanup task focused on the LSP MCP interface. [project]
-- **lsp_mcp_interface_boundaries**: The cleanup work involves consolidating or clarifying LSP and MCP interface boundaries. [project]
+- **lsp_mcp_interface_cleanup**: The context documents cleanup work for the LSP MCP interface. [project]
+- **lsp_mcp_interface_cleanup_scope**: The project includes tool naming, output schema handling, server discovery, and verification updates. [project]