{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"bulkhead_isolation__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["multi-root language server separate process per workspace root fault isolation memory","language server per workspace folder worker process restart isolation","language server multi root memory explosion issue workspace server process"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["LSP multi-root multi-process server workspace folder isolation","language server process per project workspace folder crash","language client different server instance per workspace folder"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"products_practices_and_standards":{"queries":["Language Server Protocol workspace folders specification 3.17","VS Code lsp-multi-server-sample server instance per workspace folder","Ruby LSP multi-root separate language server each workspace"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"component_combination":{"queries":["per workspace root language server worker resource limits cross root symbols","language server separate processes cross project references symbol index","language server slow request editor responsiveness mutable state"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":"No retained source described the full combination of per-root enforceable budgets, root-local mutable indexes and restart fate, plus bounded immutable cross-root symbol summaries."}},"sources":[{"source_id":"SRC1","title":"Language Server Protocol Specification 3.17","publisher":"Microsoft","url":"https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/","source_type":"OFFICIAL_STANDARD","claims_supported":["LSP defines workspace features and the standardized client-server interface available to a multi-root implementation.","The specification does not prescribe hard per-workspace resource budgets, isolated index ownership, or root-local restart policy."]},{"source_id":"SRC2","title":"Language Server Extension Guide","publisher":"Microsoft Visual Studio Code","url":"https://code.visualstudio.com/api/language-extensions/language-server-extension-guide","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Language analysis can require significant CPU and memory for parsing, AST construction, and static analysis.","Microsoft provides an advanced multi-server sample that starts a different language-server instance for each workspace folder.","Separate language-server processes and per-folder server routing are therefore established implementation patterns."]},{"source_id":"SRC3","title":"VS Code extension — Multi-root workspaces","publisher":"Shopify Ruby LSP","url":"https://shopify.github.io/ruby-lsp/vscode-extension#multi-root-workspaces","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Ruby LSP supports multi-root workspaces by spawning a separate language server for every workspace.","Shopify explicitly prefers this over one process serving multiple workspaces because roots can require incompatible Ruby versions and dependencies.","This is direct product prior art for per-root process and analysis-state separation, although hard quotas and cross-root summary exchange are not documented."]},{"source_id":"SRC4","title":"Ruby LSP Add-ons — Guidelines","publisher":"Shopify Ruby LSP","url":"https://shopify.github.io/ruby-lsp/add-ons.html#guidelines","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Ruby LSP warns that one slow request can make the editor unresponsive.","Its guidance identifies request performance, shared analysis state, asynchronous notifications, and index mutation as operational concerns relevant to the proposed failure mechanism."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The problem is visible at the mechanism level: first-party documentation confirms that language analysis is CPU- and memory-intensive and that a single slow request can impair editor responsiveness. Multi-root sessions and both single-server and per-folder-server architectures are documented. The retained sources do not directly demonstrate the proposal's complete incident pattern—one pathological root exhausting a shared server and forcing healthy sibling roots to lose service and rebuild indexes—so support is partial.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"closest_prior_art":[{"name":"VS Code lsp-multi-server-sample","source_ids":["SRC2"],"overlap":"Starts a distinct language-server instance for each workspace folder, providing process and state separation at the same root boundary proposed by the candidate.","remaining_difference":"The documentation does not specify enforceable per-root memory and CPU/concurrency budgets, isolated persistent-index namespaces, health-based root-local quarantine, or cross-root lookup through immutable bounded summaries."},{"name":"Ruby LSP multi-root architecture","source_ids":["SRC3","SRC4"],"overlap":"A production language-server integration spawns one server per workspace, avoids incompatible workspace state in one process, and exposes separate start, stop, and restart controls. Its performance guidance recognizes that individual slow requests threaten responsiveness.","remaining_difference":"No retained documentation shows selected cross-root navigation between isolated servers, hard resource ceilings, coordinator containment testing, or automatic restart limited to the failed root."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"Beyond the established practice of one language-server instance per workspace folder, adding enforceable per-root memory and CPU/concurrency budgets, separately owned mutable index stores and health-triggered restart lifecycles, while retaining cross-root navigation solely through bounded immutable symbol-summary messages, will allow a healthy root to meet a fixed diagnostics-and-navigation latency target while a sibling root undergoes injected runaway analysis and local restart.","contrastive_claim_falsifier":"The claim is falsified if the healthy root misses its request-completion or latency target because the coordinator, watcher, compiler daemon, operating-system limit, or another shared dependency saturates; if recovery still requires session-wide restart; if resource consumption cannot be enforced and attributed per root; or if the summary boundary makes ordinary cross-root navigation unusable.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct formulations, historical and synonymous multi-root terminology, the LSP standard, first-party implementations, and component combinations. Exactly four opened sources from two publishers were retained, including an official standard and first-party product documentation.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"First-party sources support the underlying CPU, memory, slow-request, and shared-responsiveness hazard, while the exact sibling-root propagation scenario remains only partly documented.","source_ids":["SRC2","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"Per-folder server processes are established, but the remaining conjunction of hard per-root budgets, isolated persistent state and restart fate, summary-only cross-root coupling, and measurable healthy-root continuity is distinct and falsifiable against the retained art.","source_ids":["SRC2","SRC3"]},"bounded_next_test":{"status":"PASS","rationale":"The documented per-folder multi-server pattern makes a two-root local prototype technically bounded. Synthetic fixtures can compare a shared-server baseline with isolated workers while measuring request latency, worker and coordinator resource use, local restart, and cross-root lookup correctness.","source_ids":["SRC2","SRC3"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"A maintainer-authorized, opt-in harness using only synthetic roots, temporary indexes, and harness-owned processes presents no obvious safety or authority stop. It must not access user repositories, terminate unrelated processes, alter production defaults, or be represented as a security boundary.","source_ids":["SRC2","SRC3"]}},"screen_survival":true,"world_novelty_boundary":"This bounded public-web screen establishes adjacent prior art for per-workspace language-server processes but found no retained source disclosing the entire budgeted-compartment and immutable-summary-interface combination. It cannot establish world novelty, patentability, freedom to operate, market size, expert acceptance, production effect size, safety, or realized value."}