| Q1 |
Does Rider's LSP client handle cross-language textDocument/definition into .cs files without a PSI bridge? (F5, F17) |
— |
Resolved: PSI bridge required. Confirmed by LSP.Plugin PoC (ReqnrollFeatureDefinitionReferenceProvider). See Architecture §6.3. |
| Q2 |
Does Rider's formatter override textDocument/formatting? (F11, F12) |
TBD |
Needs testing |
| Q3 |
What is the minimum supported Rider version for the built-in LSP client? |
TBD |
Research needed |
| Q4 |
Should the Binding Connector be a separate long-running process per workspace, or launched per-request? |
— |
Resolved (as-built): launched per-request. OutProcReqnrollConnector calls ProcessHelper.RunProcess(...) — a short-lived child process per discovery run, not a reused long-running process. See Q15 (same as-built answer covers the IPC mechanism). |
| Q5 |
Per-file Gherkin language overrides via # language: <code> first-line header are now handled by the Document Buffer (see Architecture §5 Workspace Model). Should we also support a per-directory dialect override (e.g., a reqnroll.json subdirectory entry), or is per-file + per-project sufficient? |
TBD |
Open |
| Q6 |
Is VS.Extensibility Code Lens support planned for a future VS version, which would remove the VSSDK dependency for F18? |
TBD |
Monitor VS roadmap |
| Q7 |
Is it worth standardizing on a single LSP transport (e.g., stdio) across all three IDE clients, rather than using named pipe for Visual Studio? |
— |
Resolved: all three clients use stdio. |
| Q8 |
Should the Reqnroll.IdeSupport.Common assemblies be referenced directly by IDE clients (enabling client-side telemetry and logging for installation/upgrade events) rather than having all telemetry flow through the LSP server? |
TBD |
Open |
| Q9 |
How does the LSP server reliably detect that the solution has been rebuilt across all three IDEs? Watching the output assembly path via workspace/didChangeWatchedFiles is the current assumption. |
TBD |
Needs testing |
| Q10 |
Should the VisualStudio.* projects be nested under the clients/ folder alongside the VS Code and Rider clients, or remain in src/? |
TBD |
Open |
| Q11 |
Which telemetry architecture should be used? Three options: (a) Direct HTTP from LSP server (via Reqnroll.IdeSupport.Common) — centralized, but misses pre-server events; (b) Direct HTTP from each IDE client — captures installation events, but requires telemetry code in three clients; (c) LSP telemetry/event notification (server → client) — server fires events, client relays to HTTP endpoint — best of both but requires all three clients to handle the notification. See Architecture §9 Telemetry. |
— |
Resolved (as-built): option (c). The server emits telemetry/event; each IDE host owns the concrete transmitter (TelemetryTransmitter in VS's VSSDKIntegration, telemetry.ts/TelemetryReporter in VS Code — both point at the same Application Insights resource). See archived build-plan-telemetry-capture.md and plan-refactor-analytics-appinsights.md in docs/Archive/. |
| Q12 |
Should we plan for debug support for feature files (breakpoints, step-into, etc.) in a future phase? |
TBD |
Open |
| Q13 |
For F14, do the target IDEs reliably dispatch textDocument/references to the Reqnroll server vs. the C# server based on caret position (attribute vs. method body)? If not, what is the fallback UX? |
Resolved — dispatch is unreliable in VS. The VS built-in Find All References does not route to the Reqnroll server; it always resolves via the C# server (finding C# attribute usages or string literals). A custom VS.Extensibility command (ReqnrollFindStepUsagesCommand) is required. VS Code and Rider are untested. |
Resolved (VS); Needs testing (VS Code, Rider) |
| Q14 |
When finding candidate step matches for Step Completion - how sophisticated of a matching algorithm is required? |
Resolved — client-side matching first. Ship ReturnAllCompletionMatcher (pass-through, IsIncomplete=false) so the LSP client handles filtering. The ICompletionMatcher abstraction allows a FuzzySharp-backed matcher as a future drop-in replacement if user feedback indicates the client-side filter is insufficient. |
Resolved |
| Q15 |
What IPC mechanism connects the LSP server to the out-of-process Binding Connector? Candidates: (a) stdin/stdout child process — simplest, no port conflict; (b) local named pipe — supports long-running Connector reused across builds; (c) localhost TCP with randomized port. Choice also affects Q4 (Connector lifecycle) and security posture (Architecture §9 Security). |
— |
Resolved (as-built): option (a). ProcessHelper.RunProcess launches the Connector executable with the target assembly path as an argument and captures stdout (JSON discovery result) / exit code synchronously — no persistent pipe or port. |
| Q16 |
What degree of support should be provided for progress support notifications ($/progress, window/workDoneProgress)? Long-running operations (workspace scan, reflection discovery) are candidates. |
TBD |
Open |
| Q17 |
How should the LSP server associate files with the correct project registry when a .csproj links files (feature files and/or binding .cs files) that live outside the project folder, or excludes files inside it? A linked/excluded file is a many-to-many relationship (one physical file ↔ zero, one, or several projects) that the folder-prefix membership model cannot express. Reproduced in the Minimal/ExternalReferences corpus (logs 2026-06-07). |
Chris |
Resolved (design) — authoritative path → {projects} index populated by a new optional reqnroll/projectFiles notification; folder-prefix retained only as fallback. See Architecture §5 Workspace Model and Feature Designs — Infrastructure for the full analysis and implementation plan. |
| Q18 |
Should the LSP server write to a local log file in addition to routing entries via window/logMessage to the IDE output channel? A file sink would help users who cannot easily access the IDE output panel. If yes, where should the log file be written and how should it be configured? |
— |
Resolved (as-built): yes. The server writes reqnroll-<ide>-debug-<date>.log to %LocalAppData%\Reqnroll\ (Windows) / ~/.local/share/Reqnroll/ (macOS/Linux), and each client additionally writes its own JSON-RPC inspector trace to the same folder (reqnroll-<ide>-inspector-<datetime>.log). Not user-configurable beyond the client-side trace-level setting (e.g. VS Code's reqnroll.trace.server). |
| Q19 |
Should the server support diagnostic pull (textDocument/diagnostic request, LSP 3.17+) in addition to the current push model (textDocument/publishDiagnostics)? Pull allows IDEs to request diagnostics on demand rather than receiving them asynchronously. See F3. |
— |
Resolved — abandoned (2026-06-25). OmniSharp.Extensions.LanguageServer 0.19.9's server-side (write) JSON converters for the pull-diagnostics report types are NotImplementedException stubs — verified against the shipped DLL. The server stays on push diagnostics; see the abandoned docs/PullDiagnostics-Implementation-Plan.md (archived) for the full verification. |
| Q20 |
For step-to-binding navigation (F5), should the server respond to textDocument/definition or textDocument/implementation? In LSP semantics, a step text is more analogous to an interface/specification (definition) while the binding method is the implementation. The correct choice affects how IDEs route the navigation command. |
TBD |
Open |
| Q21 |
Should the server support textDocument/documentLink for step-to-binding navigation? This would render step lines as clickable hyperlinks when the user holds Ctrl and hovers — an alternative or complement to Go to Definition (F5) that requires no keystroke. |
TBD |
Open |
| Q22 |
What VS-specific integration should we provide for F9 (Document Outline)? The generic LSP textDocument/documentSymbol handler is implemented and functional for VS Code and Rider, but VS never sends that request — its Document Outline window (Ctrl+Alt+T) uses legacy COM/IVsHierarchy APIs, not LSP. Confirmed by LSP inspector log (2026-06-13): VS registered documentSymbol capability but issued zero requests during an active editing session. Options: (A) Implement a COM/IVsHierarchy-based provider that populates the Document Outline window — significant VS-specific work. (B) Register an IVsDropdownBarClient so the Navigation Bar dropdowns above the editor reflect Feature/Scenario hierarchy — moderate VS-specific work, more discoverable for developers. (C) Both A and B. (D) Defer VS outline navigation; ship the generic handler for VS Code/Rider and revisit when VS extensibility priorities are clearer. See F9 · Document Outline. |
TBD |
Open |
| Q23 |
(RA-1, promoted from the Rename Change Annotations plan) When VS's RenamePostApplyCoordinator.PushEditIfVisualStudioAsync pushes a multi-file rename edit via workspace/applyEdit, does VS apply it as a single undo transaction or one per file? A per-file undo would surprise a user expecting one Ctrl+Z to revert the whole rename. |
TBD |
Needs a live VS manual-verification pass; see Feature Designs — Rename change annotations as-built. |
| Q24 |
(IH-3, promoted from the Inlay Hints plan) If parameter-type inlay hints are ever built, how should regex capture-group offsets be mapped onto the visible step text when they diverge — e.g. a Scenario Outline placeholder (<amount>) vs. the expanded example value? |
TBD |
Not yet applicable — F23 as-built shipped only the binding-target hint kind; parameter-type hints were not built, so this has no current code to verify against. Revisit if/when that scope is picked up. |