Qualify remote workspace bootstrap, Explorer contents, and watcher refresh

Current workspace checkpoint — 21 September 2026

Exact sources remain unchanged Code OSS 645f29cc, WebScene d3c030fa, and AppScene 080ee9c. Local demo commit 955a7a9c remains unpushed.

Single-root and multi-root restoration, real Explorer keyboard/pointer activation, collapse/expand/refresh, and visible external create/rename/modify/delete updates remain functionally qualified. Save/Save All/Auto Save/Revert/close/reopen now pass on the exact remote models under #269.

The startup observer had called explorerService.refresh() immediately after workbench.view.explorer, causing model churn: in a measured run a visible child row arrived at 2,089 ms, but the model only repopulated at 2,844 ms. The retained source observer now measures provider activation, resolve, model population, and child rows independently without that unnecessary initial refresh. The separate real toolbar-refresh computer-use gate still passes.

Three consecutive corrected diagnostic runs reconstructed exact roots/models/five rows and restored fixture bytes. First-child paint was 1,621.87, 1,717.05, and 2,955.18 ms. The last run did not meet the two-second budget because workspace readiness alone was delayed to 1,853.78 ms. This is not a passing repeated performance gate or a WebScene runtime fix. Evidence: vscode-demo/docs/validation/workspace-first-child-timing-d3c030fa-20260921.md; source tests 25/25.

Remaining scope: cold-start scheduling/performance attribution, Search/Git/tasks/terminal/language/settings binding, Chromium geometry, and repeated navigation/resource teardown. Keep the issue open.

Cross-repository parent: SceneTech/AppScene#122
Navigation/lifecycle prerequisite: SceneTech/AppScene#124
Picker prerequisite: #247

Problem

After an unchanged VS Code OSS Open Folder... flow, the native AppScene/WebScene window can disappear for same-window navigation and return with a workspace/root label while Explorer remains empty. The supplied reproduction shows an expanded WebScene root with no child rows. Related workspace consumers are also not reliably initialized: retained server evidence shows the remote extension host is alive, but Git initially discovers zero repositories and later runs outside a repository.

This is distinct from #247. That issue owns dialog enumeration and the exact selected URI handed to BrowserHostService.openWindow. This issue owns the next document: reconstructing the selected remote workspace, registering its remote file provider, resolving and rendering Explorer children, and keeping dependent workspace features synchronized.

Current evidence

Exact integration heads: VS Code OSS 645f29c, WebScene b81f594c, AppScene 9f434e0.
The real remote SimpleFileDialog enumerates the isolated fixture, including hidden entries, and pointer navigation reaches a child directory.
Final retained picker run reached a visible folder dialog in 901 ms, with 2 rendered rows and 122 dialog DOM nodes, within the current 2 s bound.
Submitting /private/tmp/webscene-247-fixture/beta/ made the current AppScene document/window unavailable before the polling observer retained the synchronous openWindow call. The only prior retained handoff was a restored vscode-userdata:/User/Workspaces/Untitled-....code-workspace, so the selected vscode-remote URI is not yet proven.
The remote extension host and Markdown language server start. No server-side readdir, stat, ENOENT, or file-provider failure appears in the retained logs.
Git reports zero repositories, then fatal: not a git repository, consistent with the new workspace context or provider not becoming authoritative.

Investigation and implementation

Finish Qualify VS Code remote file and folder picker interaction #247 with a navigation-safe, bounded handoff record emitted before workspaceProvider.open() can replace the document.
Correlate the selected URI, generated ?folder= or ?workspace= target URL, WebScene navigation request, AppScene owned-window lifecycle, new document URL, remote authority, and reconstructed IWorkspaceContextService root across the document boundary.
Observe the first IFileService.resolve/readDirectory request and result for every workspace root without logging arbitrary user paths; use isolated fixture IDs and counts.
Distinguish a data failure from an Explorer model/DOM/scene-publication failure by retaining the resolved child set, tree-model child count, visible row count, and first-paint revision.
Fix the smallest reusable owner contract in WebScene or AppScene. Preserve unchanged VS Code OSS and avoid an application-only workspace shim.
Qualify file watcher create/delete/rename events, refresh/collapse/expand, search, Git discovery, tasks, terminal working directory, language services, settings, and multi-root .code-workspace restoration after the switch.

Acceptance

Schedule

The functional Explorer and watcher slice is complete. Next fix the reusable first-child paint path, then qualify dependent workspace services, matched Chromium geometry, and repeated navigation/resource teardown. This remains P0 for declaring file/folder/workspace support complete.

The file/workspace hierarchy audit confirms #252 is the provider/workspace/Explorer owner after #247 and AppScene#124, before file-model durability in #269.

Expand the correlated fixture matrix to include:

empty/single/multi-root .code-workspace files; ordered absolute and relative folder entries; workspace settings/tasks/launch/extensions; duplicate/nested roots; moved/missing roots; workspace trust; profile and restart restoration;
byte-exact URI/path rules for scheme/authority, percent encoding, spaces/#/?, Unicode normalization, dot segments, trailing separators, root/drive/UNC forms where supported, case sensitivity, symlinks/cycles, packages, traversal rejection, and cross-authority denial;
provider stat/readDirectory/readFile/writeFile/rename/copy/delete/create/watch errors and cancellation; permission, offline/reconnect, stale result, event coalescing/order, own-write de-duplication, recursive/nonrecursive watches, and watch release;
Explorer sorting/filter/exclude, hidden entries, large virtualized trees, expand/collapse/refresh/rename/create/delete/drop, file activation, selection/focus, empty/error/loading states;
Search, SCM/Git, tasks, terminals/cwd, diagnostics/language services, settings, and extensions rebinding once per active root.

Use one correlation ID from selected URI through target/new document, workspace context, provider request, model child count, rendered row, dependent-service root, and watcher event. Cross-link #259/#262/#258/#263 for common visual/accessibility/performance/WPT machinery. Proposed PR grouping: observer/oracle; smallest navigation/provider fix; Explorer/tree reconciliation; watcher/dependent-service reconciliation; multi-root/restart/large-tree cumulative acceptance.

Wave 1 exact-head checkpoint:

VS Code OSS 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
WebScene 28d1d649e927c665ff05844197af44f223edf952
AppScene 1420e227e52579a097e7ae52a2cadb41cf073e4d
exact Node 24.18.1
local-only diagnostic commits 8c199bb, cb54fb5, d5a4238, 9a14d22 (not pushed)

The merged #247 → AppScene#124 handoff now has direct next-document proof. The selected vscode-remote://<authority>/private/tmp/webscene-247-fixture/beta URI equals the new document's only workspace root. After joining stock IFileService.activateProvider, the unchanged remote provider registers and direct resolve returns the exact fixture children:

.hidden.txt
readme-link
README.md
subdir/
unicodé.txt

Explorer renders the same five rows with 64 nodes in the Explorer subtree. The earlier providerRegistered=false result was an observer error caused by checking before provider activation. The later empty model result was also observer ordering: it sampled immediately after refresh while the exact five rows appeared; the retained oracle now polls the model and DOM together. Focused overlay/native-probe tests pass 28/28.

Performance remains a real blocker. The clean native trace measured direct resolve at 8,139.3 ms and first-child paint at 12,324.0 ms. An overlapping run is excluded from qualification but independently measured resolve at 8,132.1 ms. Headless Chrome 153 against the same Code OSS server/provider/root measured 328.2 ms resolve and 714.9 ms first-child paint, with exact provider/root/resolved/model/rendered evidence and a 0.5 ms maximum observer sample.

The generic latency boundary is now native subissue #280. #252 remains open and depends on #280 before watcher, refresh, multi-root, restart, and dependent-service acceptance. No VS Code product change or upstream implementation has been made.

Retained logs:

clean native: /private/tmp/vscode-252-product-navigation-clean.log
contaminated diagnostic: /private/tmp/vscode-252-product-navigation-corrected.log
Chromium: /private/tmp/vscode-252-browser-trace.log

WebScene #280 split its first proven generic dependency into native subissue #284 / PR #285. The PR qualifies observer-independent WebSocket worker wakeup and bounded Worker/MessagePort/WebSocket fairness, but it does not claim this product gate.

With the corrected runtime archive rebuilt and the unchanged Code OSS package relinked, the exact provider/root/5-child/5-model-row/5-rendered-row result remains correct while resolve is 7,641.1 ms and first paint is 11,577.4 ms. #252 remains blocked on the remaining #280 attribution after #285.

Post-merge control on exact WebScene aa06172c rules out the native harness's 100 ms host-evaluation polling as the remaining delay.

The query-gated local observer stopped all host state evaluations and invalidations immediately after the first navigation handoff, then relied only on the in-page terminal console record. The unchanged Code OSS result was:

host workspace-state polls during resolve: 0
exact selected URI/workspace root: yes
provider registered: yes
exact resolved/model child set: 5
rendered Explorer rows / DOM nodes: 5 / 64
resolve: 8,055.1 ms
first child paint: 12,034.7 ms
observer sampling maximum: 51.43 ms
peak child-process RSS: 801,800,192 bytes

This matches the original 8.14 s boundary, so observer polling is excluded. #284's merged socket queue/wakeup gate remains independently qualified (max 23 competing MessagePort deliveries and stable V8 heap), while the remaining delay stays under #280. Investigation-only local vscode-demo commit: a3ab610; product log: /private/tmp/vscode-252-product-navigation-280-no-host-poll.log.

Exact-package attribution for the remaining provider/Explorer latency is retained under parent #280 and new native subissue #287.

On WebScene aa06172c + AppScene 1420e227 + unchanged Code OSS 645f29cc + Node 24.18.1, the query-gated no-host-poll trace again retained the exact selected/root URI, registered remote provider, exact five resolved/model children, five Explorer rows, and 64 Explorer DOM nodes.

The trace separates the delay:

151 WebSocket events / 13.119 MB; receive-to-runtime-dispatch maximum 3,563 ms
socket callback maximum 4.916 ms; callback microtask maximum 1.100 ms
146 FileReader reads matched 13.116 MB
underlying Blob copies took 1.532 ms total / 0.041 ms maximum
FileReader completion reached 14,940.7 ms maximum
exact-root stat wave took about 5,416 ms and the following readdir wave about 2,299 ms

WebScene currently services all ready async-message sources before any due timer, while FileReader needs two zero-delay timer tasks per read. #287 now owns that generic task-source fairness defect as a native subissue of #280. #252 remains blocked on #287 → #280, followed by one unchanged-product rerun of its 2 s resolve/paint gate.

Attribution log: /private/tmp/vscode-252-product-navigation-280-attribution.log. Local observer commit: 74b3b94 atop a3ab610; neither is pushed. The instrumented run is not used as a performance qualification baseline.

The #287 direct timer/async-message fairness candidate is not sufficient to requalify this product gate.

Exact unchanged-product rerun on local WebScene 0f92cf47 + AppScene 1420e227 + Code OSS 645f29cc + Node 24.18.1:

selected URI == only workspace root; provider registered
exact five resolved/model children
five rendered Explorer rows; 64 DOM nodes
resolve 7,749.84 ms
first child paint 11,788.09 ms
sampling maximum 48.46 ms
peak child-process RSS 860,160,000 bytes

Log: /private/tmp/vscode-252-product-navigation-287-candidate.log.

#287 independently passes its 256-frame product-neutral FileReader fairness oracle, but #280/#252 stay open. Further attribution must locate the remaining runtime source/non-task phase before another implementation.

The exact candidate timeline identifies existing #81 as the earliest remaining dependency before this Explorer/provider gate.

The remote AgentHost reports connected only at console timestamp 1789655993265. The exact five-child IFileService.resolve completes about 90 ms later, and the five Explorer rows paint about 152 ms later. Before that connection, Code OSS reports the remote extension host as unresponsive; after it, provider/model/DOM output is immediate and exact.

No duplicate issue is needed. Dependency order: #81 packaged iframe/Worker/MessagePort handshake and latency (coordinated with #288/PR #245) → #280 provider response requalification → #252 Explorer requalification.

Retained log: /private/tmp/vscode-252-product-navigation-287-candidate.log.

The bounded unchanged-product trace still passes exact root/provider/five resolved children/five Explorer children/five rendered rows (64 maximum Explorer DOM nodes) but misses the 2 s timing gate. #81 instrumentation shows the local transferred-port handshake is healthy; the distinct remote extension-host Ready/Initialized delay is now #289.

Current dependency order: #289 → #280 → #252. The later AgentHost service connection is separate from the extension host; exact Explorer terminal evidence follows it by 99 ms. No Code OSS behavior change or VS Code patch is proposed.

Receiver-side instrumentation isolates the breach before Node parsing or extension initialization.

On the retained second workspace document:

Node remote extension host sent Ready at 1789658968549
WebScene browser received Ready at 1789658969571: 1,022 ms inbound delivery
WebScene serialized and sent the 1,071,425-byte init message at 1789658969991
Node remote extension host received that exact 1,071,425-byte message at 1789658973482: 3,491 ms outbound browser → Node delivery
receiver UTF-8 decode: 0.133 ms
receiver JSON parse: 3.589 ms
total receiver hydrate/watchdog work before Initialized: 12.204 ms
Node sent Initialized at 1789658973495
WebScene browser received Initialized at 1789658973588: 93 ms return delivery

ExtensionHostMain construction begins only after Initialized is sent, so extension scanning/activation cannot own the Ready → Initialized breach. The exact root/provider/five resolved children/five model children/five rendered rows/64-node result still passes functionally. The 50 s bounded observer waited for the later constructor completion marker, then terminated the complete process group; no app/server/extension-host descendants remained. Peak process-group RSS was 843,184 KiB.

A size-matched control preserves the earlier fast baseline: the product-neutral native oracle sends a binary-compatible 1,071,424-byte payload for 20 cycles and reports Initialized p95 6.140 ms; Chromium passes 43/43 in 89 ms. The next reduced gate must add the actual Code OSS binary framing/compression and concurrent traffic/queue shape, retain enqueue → wire → server-receipt timing, and preserve this fast size-only control before any WebScene implementation.

Retained evidence:

app log: /private/tmp/vscode-252-product-receiver-289.log (SHA-256 51d5b4d696b5474e2210a1f13851b39531443030927fa148f6705ffc79aed160)
server/receiver log: /private/tmp/vscode-252-product-receiver-289-server.log (SHA-256 372b41c577260eb7787ceeaaca6c7f6655ced1259f4a4d4e9715e6280cf2e9db)
process/RSS summary: /private/tmp/vscode-252-product-receiver-289-process.txt
matched-size native control: /private/tmp/webscene-289-one-mib.log
matched-size Chromium control: /private/tmp/webscene-289-chrome-one-mib-2/results.json
local query-gated receiver observer commit (not pushed): da9db1a

The actual browser WebSocket send boundary rejects the earlier wire-delay hypothesis and moves the earliest breach into the deferred Code OSS protocol-writer flush.

Exact second-document timestamps:

protocol.send(...) returned after init serialization at 1789659699540
native WebSocket.send entered at 1789659703082: 3,542 ms later
WebSocket.send returned in 0.743 ms, with bufferedAmount 0 before and after
its next Promise microtask ran at 0.788 ms, still with bufferedAmount 0
Node received the framed payload at 1789659703087: 5 ms after actual WebSocket send
Node decode/parse/hydrate completed in 14.55 ms
Node sent Initialized at 1789659703101; the browser received it at 1789659703467: 366 ms later

Pinned Code OSS ProtocolWriter._scheduleWriting() coalesces writes behind a zero-delay timer. This run shows that timer-backed flush, rather than JSON serialization, native WebSocket enqueue, loopback wire delivery, Node parsing, or extension scanning, owns nearly all of the Ready → Initialized breach.

The product-shaped control now uses a 13-byte IPC header, 1,071,425-byte binary body, 200 competing 64 KiB inbound frames per cycle, a shared FileReader queue, and 20 cycles. Direct native send remains fast (outbound p95 1 ms, send return p95 0.708 ms, drain p95 0.004 ms, receive-queue HWM 199). A deferred flush under a single independently paced WebSocket source also remains fast (flush timer p95 0.019 ms). The remaining reduction must model the product's combined/coalesced protocol writer plus simultaneous Worker, MessagePort, and multiple WebSocket task sources; no runtime fix is proposed yet.

The bounded run reached exact root/provider/five-child/five-model/five-row evidence, terminated its process group, and left no app/server/extension-host descendants. Peak group RSS was 845,648 KiB.

Retained evidence:

app log: /private/tmp/vscode-252-product-websocket-send-289.log (SHA-256 52296aa1c97c11c8c696577e7a0cb0dd27e2605a4a9c8fe26ee8f225ddb64ef5)
server log: /private/tmp/vscode-252-product-websocket-send-289-server.log (SHA-256 4b6c06cf87e5e709431486b64d5920ca76041821290d0bea93f5297f85411228)
process/RSS summary: /private/tmp/vscode-252-product-websocket-send-289-process.txt
direct product-shaped oracle: /private/tmp/webscene-289-product-shape.log
async paced/deferred control: /private/tmp/webscene-289-paced-async-deferred-flush.log
local query-gated observer commit (not pushed): 4c7c662

Upstream attribution is now exact: #289 reduces to #287's due-timer starvation. On exact main 4040058e, the product-shaped multi-source oracle retains a 3,581.35 ms ProtocolWriter timer wait; the same 20-cycle workload with local commit 26694871 passes at 0.1539 ms max / 0.0475 ms p95. The retained product's actual send→Node receipt is only 5 ms, so the earlier boundary must not be described as wire delay.

The local fix remains unpushed until overlapping #281 merges and it is rebased while preserving ServiceWorker in the async-source rotation. #252 remains open: its exact-root/five-child/five-row and two-second unchanged-Code product acceptance will be rerun only after that rebase and direct gates.

Unchanged Code OSS #252 result on candidate WebScene b75d3795 rebased to exact main 1bd8596e:

Functional path reached the exact selected root vscode-remote://127.0.0.1:54759/private/tmp/webscene-247-fixture/beta.
Provider registration succeeded; the expected five children resolved and five Explorer rows rendered (DOM bound 64).
Performance gate failed: Ready 1789661803717 → Initialized 1789661807949 was ~4232 ms.
The decisive delay was protocol-send request 1789661804067 → native WebSocket.send entry 1789661807765: 3698 ms.
Native send was fast once invoked: 0.783 ms return, 0.834 ms microtask, bufferedAmount=0.

Thus the reduced #287 timer-fairness candidate passes its own generic oracle but does not qualify #252. No PR/push. The next gate requires attribution of the remaining pre-send product task tier after #292 resolves its collision in webscene_v8_runtime_tasks.inc.

Query-gated observer only; unchanged Code OSS source. App/server/helper/extension-host descendants were terminated and port 54759 released. Evidence: /private/tmp/vscode-252-product-b75d3795.log, SHA-256 f58b40413fe5dd30567d0d6a3d207b668fd07bea96b594aae9c5568509a38252.

Reopening because exact current packaged acceptance still violates this issue's first-child <=2-second requirement after a byte-exact successful folder handoff.

Package pins: AppScene f52fb46b2fc494b78520f7102ae960606ab618cb; WebScene 348ea440501c4059da6f95d1fbd6f6159a5df47b; unchanged Code OSS; executable SHA-256 cb522668d7b2a80de82def67f529899c1b64e9d439811249903389bce1c126af.

selected URI: vscode-remote://127.0.0.1:53305/private/tmp/a131/beta
options: all of forceNewWindow, forceReuseWindow, and addMode false
verified-input acceptance -> handoff: 486.368 ms
Explorer visibly rendered the exact beta root and visible.txt child
first-child paint: 4,594.291 ms (gate: <=2,000 ms)
observer p95/max: 0.625/1.020 ms; dialog DOM peak 512
runtime evidence: 3,191 timers scheduled, 2,183 fired, 979 cancelled, 1,250 late, aggregate lateness 209,700 ms; 4,361 microtasks; 294 scene builds
peak RSS 894,386,176 bytes, one process; cleanup/listener/port release passed

Evidence: /private/tmp/appscene-131-new-release-absolute-v4/absolute-explorer/{case-evidence.json,workspace.png,stdout.log,stderr.log}. This is a functional pass and performance failure; no behavior patch is proposed without reducing the current owner boundary.

Phase attribution for the retained exact-current absolute case aligns existing #289 and does not justify another issue: after same-window navigation, the Management socket appears at approximately 8069111/8069115, AgentHost initialization at 8069286, and AgentHost Connected at 8072002—about 2.7 seconds downstream—before Explorer content appears. The exact functional handoff itself completed in 486.368 ms.

Schedule #289 before re-qualifying and re-closing #252/#131. No duplicate performance ticket is needed.

Upstream scheduler owner #289 has landed through PR #347 at WebScene merge dbd7351a88415d369ea322c692153474fb7a933c.

The exact-main product-shaped control now keeps the timer-coalesced protocol flush at 0.157 ms p95 / 0.274 ms max, Initialized at 49.98 ms p95, task queues at high-water 4, and V8 heap flat at 725,308 bytes. Linux/macOS native, portable V8, and the 45/45 focused browser-shaped profile pass.

The next #252 package must use dbd7351a and rerun the unchanged Code OSS exact-root/first-child gate. #289 remains open until that product result confirms the previously observed ~2.716 s remote AgentHost interval is removed.

Current exact-package computer-use result is partial and identifies an evidence-harness blocker, not a failed provider/runtime path.

Inputs: AppScene cac13616, WebScene d355d3f, unchanged Code OSS 645f29cc. The real navigation selected the exact vscode-remote BETA fixture, replaced the document, reconnected management and extension-host sockets in 528 ms and 94 ms, and visibly rendered all five root children (subdir, .hidden.txt, readme-link, README.md, unicodé.txt). The captured process tree contains only the AppScene host/guardian and bundled Node server/watcher/extension/agent/Copilot processes, with no browser helper; teardown is clean.

The terminal workspace state was absent because the demo navigation target dropped scene-workspace-bootstrap=1 while preserving the extension-host diagnostic. SceneTech/vscode-demo#7 is attached here and owns the evidence correction. Its local conditional query propagation passes the combined Node 24 contracts 35/35.

#252 remains open until a rebuilt package records exact root/provider/resolved/model/render counts, <=2 s resolve/paint, watcher refresh, dependent services, repeated timing, and lifecycle/memory evidence. The visible Explorer row-background artifact remains under the existing CSS/visual owners rather than this provider ticket.

Exact current-package workspace result — 18 September 2026

The installed-SDK Release from AppScene d4a73888, WebScene dd39f118, and unchanged Code OSS 645f29cc proves the functional navigation/bootstrap path:

navigation target retains scene-workspace-bootstrap=1 and the extension-host diagnostic query;
selected URI and new document root both equal vscode-remote://127.0.0.1:<port>/private/tmp/webscene-247-fixture/beta;
remote provider is registered;
direct resolve returns exactly .hidden.txt, readme-link, README.md, subdir, and unicodé.txt;
Explorer model contains the same five children;
five rows render, with 64 maximum Explorer DOM nodes.

The issue remains open for performance/watcher/dependent-service closure. The 2-second gate fails. The trace records 149 FileReader completions over 13,209,295 bytes with 88,463.6 ms summed elapsed time and a 2,219.39 ms maximum. Blob arrayBuffer() for the same bytes totals 1.11 ms / 0.040 ms maximum. Initial provider stat calls take roughly 1.21-1.27 s and root readdir calls roughly 332 ms. This points to the response/completion scheduling path already owned by #280 rather than filesystem enumeration or Explorer reconstruction.

Screenshot: /private/tmp/vscode-demo-workspace-dd39f11-d4a7388/screen-active.png. The complete provider-call console payload exceeded the bounded record before its terminal fields; vscode-demo #8 now owns a compact summary and prompt failed-report handling. The local harness fix passes Python 183/183 and Node 24 35/35.

Current exact package acceptance now passes the complete functional workspace/Explorer boundary: selected BETA URI, new document root, provider registration, exact children .hidden.txt, readme-link, README.md, subdir, unicodé.txt, five Explorer model entries, five rendered rows, and 64 maximum Explorer DOM nodes.

The remaining failure is performance. 149 FileReader operations over 13,209,295 bytes include a 2,219.394 ms maximum while all underlying Blob reads total only 1.111 ms. #287 / PR #423 owns the generic FileReader task-source fix; its exact-main reduced control improves 57.847 ms to 0.405 ms and native/Chrome pass 48/48 with preserved event order and bytes.

Dependency is now PR #423 merge → exact SDK/package rebuild → repeat this same computer-use workspace scenario → AppScene #131 absolute-path/cancel/watcher matrix. Keep this issue open until the unchanged product meets the two-second resolve/first-paint budget.

Focused local watcher implementation merged through #441 as WebScene 622a955c512dbf1853a042effe6a5b41cad53052.

The unchanged VS Code 1.137 HTMLFileSystemProvider.watch() previously returned immediately because FileSystemObserver was absent. WebScene now exposes FileSystemObserver, observe, unobserve, and disconnect over existing opaque file/directory grants. It establishes bounded non-overlapping snapshots, supports recursive observation with entry/depth caps, emits appeared, disappeared, modified, and errored records with relativePathComponents, and clears polling timers on unobserve/disconnect/document retirement. No paths, bookmarks, native descriptors, VS Code patches, AppScene changes, or consolidation changes are involved.

Under the current implementation-only priority, no tests, benchmarks, packaged scenario, or CI wait was performed. Issue #438 records the outstanding Chrome/WPT, native create/modify/delete, recursive/lifecycle/resource, exact Explorer refresh, own-write de-duplication, and external-edit gates. #252 remains open for those watcher gates plus the current installed-SDK package timing/dependent-service matrix.

Implementation-first re-audit at WebScene 488b9790 confirms the generic workspace prerequisites are merged: protocol timer fairness (#347), dedicated bounded FileReader scheduling (#423), and FileSystemObserver/watcher lifecycle (#441). The next required step is the recorded fresh unchanged-product package run proving <=2 s resolve/first paint, watcher/dependent-service behavior, and repeated cleanup; no separate scheduler/network/filesystem mutation is justified. No code or runtime validation was run; git diff --check passed.

Current exact-package workspace checkpoint — 21 September 2026

The installed-SDK Release from AppScene cd0a02e, WebScene a99eaf23, and unchanged Code OSS 645f29cc passes the root/provider/Explorer performance slice:

exact selected URI and only root;
provider registered;
exact five resolved/model/rendered fixture children;
resolve 757.40 ms;
first-child paint 1,880.02 ms;
64 maximum Explorer DOM nodes;
transport → Ready 939 ms and Ready → Initialized 295 ms;
no remaining app/server/helper processes after bounded termination.

This closes the scheduler/provider children #280, #287, #289, and #293. #252 remains open for its broader acceptance: .code-workspace and multi-root restoration; Explorer interaction/file activation; create/delete/rename/external watcher refresh without duplicates; Search/Git/tasks/terminal/language-service/settings binding; A→B→A/cancel/denied/large/restart lifecycle; Chromium geometry/visual comparison; repeated cold/warm resource bounds; and packaged WPT/native acceptance.

Exact product log SHA-256: c78d19651bf5615b9db7595ea2aa16bc252ad1395d19b83b610088639c864fc2.

Watcher and repeated-latency investigation — 21 September 2026

The second exact a99eaf2 package run preserved the exact root/provider/five-child result but painted at 2,179.19 ms after a 1,110.87 ms resolve, so the repeated product performance gate is still red.

The same run externally created, modified, renamed, and deleted a file under the selected fixture. Every semantic event reached unchanged Code OSS, but the file-service observer received each notification twice:

add watcher-created.txt: 2 identical events;
update watcher-created.txt: 2 identical events;
rename: 2 identical add watcher-renamed.txt + delete watcher-created.txt events;
delete watcher-renamed.txt: 2 identical events.

The fixture returned to its original five entries. This proves watcher ingress exists and isolates the next correctness question to duplicate notification ownership. Compare the same remote-provider mutation sequence in Chromium and retain provider/watch registration identity before changing WebScene or the unchanged product. Explorer row duplication and refresh latency also need direct capture.

Chromium watcher oracle — duplicate raw notifications are upstream-identical

The same unchanged Code OSS server/payload and exact remote fixture were run in Chrome 152 with the query-gated workspace observer. Chromium produces the same paired raw file-service notifications as AppScene/WebScene, so WebScene is not the duplicate-event owner.

Chromium stage results:

operation	one-row refresh	latency
create watcher-created.txt	exactly one visible row	507.75 ms
modify watcher-created.txt	row remains exactly once	757.54 ms observation window
rename to watcher-renamed.txt	old row absent; new row exactly once	619.11 ms
delete watcher-renamed.txt	row absent; original five rows restored	403.22 ms

The underlying observer records the same 2 add, 2 update, 2 rename, and 2 delete notifications seen natively. Despite those upstream-identical provider events, Explorer coalesces them into one correct row at every stage and finishes with the exact original five rows and 64-node initial tree. Chromium bootstrap resolve/paint was 309.30/583.10 ms.

Evidence: /private/tmp/chrome-workspace-watch-stages.json, SHA-256 2ebd4bc73c2e3b151790d0615469351ecc09efcec7b40ce71d8b8ce50d3ffe45.

Do not add a WebScene deduplication layer for browser-identical provider notifications. Native #252 still needs stage-by-stage visible-row/latency proof and the repeated first-paint p50/p95 fix.

The repeated exact product gate and browser watcher oracle are now complete.

All 20 native launches reconstructed the requested workspace and exact five Explorer entries, but first-child paint was 2,164.26 ms p50 / 2,262.03 ms p95, so the 2,000 ms repeated gate remains open. A rejected 8 ms worker task-batch experiment made paint worse and was discarded.

Chromium 152 produced the same paired raw file-service notifications as WebScene for external create, modify, rename, and delete. Chromium's Explorer coalesced them to one correct visible row and returned to the exact original five rows. This rules out WebScene-level notification deduplication; product-visible watcher correctness should be asserted at the Explorer/model boundary.

Remaining #252 scope is unchanged: workspace-file/multi-root restoration, Explorer interactions and visible mutation refresh, dependent workspace services, visual comparison, and repeated lifecycle/resource qualification.

21 September exact-head diagnostic: unchanged Code OSS 645f29cc, WebScene 5b4739c8, AppScene 36d7a82e. During the controlled Markdown-preview native acceptance run, the real remote workspace and README file lifecycle completed byte-exactly. Two preceding native launches missed the existing 2000 ms Explorer first-child paint bound at 2198.78 and 2318.83 ms; the final run passed. This is intermittent cold-start evidence, not a passing repeated performance gate. The accepted 20/20 direct-subject run remains the earlier isolated measurement, and further source attribution/repeated cold runs are needed before closing #252/#243. Local logs: vscode-demo/build/appscene-webview-398/native-preview-36d7a82-frame-probe.log, native-preview-36d7a82-frame-probe-rerun.log, and native-preview-36d7a82-final-diagnostic.log.

Navigation Menu

Repository navigation

Qualify remote workspace bootstrap, Explorer contents, and watcher refresh #252

Current workspace checkpoint — 21 September 2026

Problem

Current evidence

Investigation and implementation

Acceptance

Schedule

2 remaining items

Exact current-package workspace result — 18 September 2026

Current exact-package workspace checkpoint — 21 September 2026

Watcher and repeated-latency investigation — 21 September 2026

Chromium watcher oracle — duplicate raw notifications are upstream-identical

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Qualify remote workspace bootstrap, Explorer contents, and watcher refresh #252

Description

Current workspace checkpoint — 21 September 2026

Problem

Current evidence

Investigation and implementation

Acceptance

Schedule

Activity

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

wieslawsoltes commented on Sep 17, 2026

2 remaining items

wieslawsoltes commented on Sep 18, 2026

wieslawsoltes commented on Sep 18, 2026

wieslawsoltes commented on Sep 18, 2026

wieslawsoltes commented on Sep 18, 2026

wieslawsoltes commented on Sep 18, 2026

Exact current-package workspace result — 18 September 2026

wieslawsoltes commented on Sep 18, 2026

wieslawsoltes commented on Sep 18, 2026

wieslawsoltes commented on Sep 19, 2026

wieslawsoltes commented on Sep 21, 2026

Current exact-package workspace checkpoint — 21 September 2026

wieslawsoltes commented on Sep 21, 2026

Watcher and repeated-latency investigation — 21 September 2026

wieslawsoltes commented on Sep 21, 2026

Chromium watcher oracle — duplicate raw notifications are upstream-identical

wieslawsoltes commented on Sep 21, 2026

wieslawsoltes commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions