Publish a Code OSS Web API capability ledger and expand WPT coverage

[wieslawsoltes]

Current capability-ledger checkpoint — 20 September 2026

Exact merged heads: WebScene a46b62e14eb197603f7e227c1558afb9088633b0; AppScene 97702daeb9ad71341ced7226f0aa966dc77ea53c; unchanged Code OSS 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c; local vscode-demo 123ad63a345dd77ceb0d75aed4c8eda244cf1288 (clean, intentionally unpushed). Open consolidations remain WebScene #76 085bba760fa571c8f08ea866dc5dd1ec27c4d376, AppScene #65 ce66ef6ceb776b3f14e129f853bfc08b5c5e608c, and vscode-demo #1; do not merge them. One-agent mode is active.

#799/#806 is merged and cataloged with touch-action CSSOM/non-inheritance plus mouse/touch/pen ABI decoding, stable IDs, primary state, capture-by-ID, cancellation, frozen policy, and retained panning. The generated Web API report and stale CSS catalog sentinels were refreshed. Metadata CI passed; WPT/native/hardware/package/visual/accessibility/memory/lifecycle/performance execution remains evidence debt.

Parent epic: #227.
CSS-specific capability ownership remains #236.

Problem

Code OSS compatibility currently grows through focused regressions, but there is no single versioned ledger mapping every reachable Web API to imported/derived WPT coverage, native contracts, packaged consumer evidence, unsupported states, and performance/security limits. That makes silent partial APIs and missing regression coverage easy to overlook.

Investigation first

Generate a reachability inventory from unchanged Code OSS 1.137 and its bundled extensions for DOM/HTML, events/focus, URL/origin/resource loading, fetch/WebSocket, storage, workers/ports/structured clone, iframe/webview, File System Access, clipboard/drag-drop, Web Crypto, timing, accessibility, canvas/media/GPU feature detection, and lifecycle. Reconcile every entry with existing WebScene/AppScene issues and tests before creating any implementation ticket.

Proposed direction

Publish a machine-readable, revisioned capability ledger with states such as supported, partial, intentionally absent, consumer-unreachable, and blocked. Every supported/partial claim names WPT or browser-oracle cases, native/runtime tests, packaged Code OSS evidence, platform scope, and limits. The validator fails on stale revisions, claims without evidence, unexpected newly reachable APIs, or regressions.

Acceptance

• The ledger covers every API reached by the accepted scenarios and records exact VS Code/AppScene/WebScene/WPT revisions.
• Selected upstream WPTs are imported or translated with provenance and local modifications documented; exclusions have concrete reasons.
• WPT/browser/native/package denominators are explicit, with no passing percentage that hides skipped or unsupported cases.
• Realm, teardown, cancellation, malformed input, quota/queue, origin/security, memory, and performance boundaries accompany feature tests.
• CI shards by changed capability and runs the cumulative top of a related PR stack; the final release runs the full ledger.
• Generated reports are deterministic and compact, and old large browser traces/artifacts are pruned by policy.

Proposed PR stack

1. reachability scanner + schema + reconciliation report;
2. fail-closed validator and generated documentation;
3. prioritized WPT imports for P0/P1 Code OSS paths;
4. installed SDK/package consumer lane.

[wieslawsoltes]

No duplicate CSS capability implementation should be created here. #236 remains the authoritative CSS-specific schema/report/validator and derives claims from CSS WPT/native/browser evidence. This global ledger should compose the versioned #236 output as its CSS slice, preserving its exact revision, evidence links, partial boundaries, and pass/fail/skipped/unavailable totals rather than copying CSS claims into a second hand-maintained table.

Reachability and release inputs should come from #260's accepted scenarios and #259's common capture manifest; #262 supplies accessibility coverage. Add a reconciliation check that fails when the global ledger's CSS slice is missing, stale relative to #236, or changes state/denominators during ingestion. Non-CSS Web API schema/scanner/WPT work remains owned here.

[wieslawsoltes]

CSS source dependency is now concrete: PR #271 merged to main as aa121fe. Consume tests/WebPlatformSubset/css-capability-matrix.json under schema tests/WebPlatformSubset/css-capability-matrix.schema.json; the generated human view is docs/validation/css-capability-matrix.md. Do not copy CSS rows into a second table.

The CSS slice is version 1.0.0, native 32/0/0/0/32 and browser 25/7/0/0/32, with exact WPT/profile/file-manifest/engine provenance. #263 ingestion should preserve matrixVersion, profileSha256, wptFilesSha256, both lane denominators, and each bounded status, and fail if any changes during ingestion.

[wieslawsoltes]

Implementation stack started with #272, based on the merged CSS matrix #271/#236.

Part 1 is now reviewable:

• exact Code OSS revision 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c;
• 25/25 non-CSS API groups reachable across 9,379 scanned authored/bundled files;
• every entry has an explicit state, issue owner, boundary, and evidence rule;
• all 25 initial non-CSS claims remain visibly blocked until contract plus accepted product evidence supports promotion;
• CSS is composed rather than copied: matrix SHA-256, schema/version, profile digest, 4 supported + 5 partial capability denominator, native 32/32, browser 25/32 with seven explicit failures;
• fail-closed checks cover catalog gaps, newly changed reachability, revision drift, unknown metadata, unsupported promotion, missing/duplicate evidence, CSS digest/denominator drift, and bounded deterministic reports.

Direct gates: 8/8 ledger tests, 12/12 inherited CSS tests, exact-source rescan and generated-report checks pass. CI now runs the ledger checks on both build runners.

The issue remains open for the next stack entries: evidence-backed state promotion, prioritized WPT imports, and the installed SDK/package consumer lane.

[wieslawsoltes]

PR #272 merged as dff367ed3a49b59ea1a0faa6dc2980076f21ab4f after the exact Code OSS rescan, 8/8 ledger tests, generated-report freshness, inherited CSS 12/12, and the current-head Linux runner passed. Remaining queued and superseded workflows were canceled after merge.

The issue remains open as the evidence tracker. Current baseline:

• unchanged VS Code OSS 645f29cc3176500b4b5762ba887cf2a7f0ffdf2c
• 9,379 files scanned
• 25/25 non-CSS API groups reachable
• CSS evidence imported by digest with native 32/32 and Chromium 25/32
• all claims remain fail-closed until native, product, and browser/WPT evidence satisfy their declared platform scope

Next work fills evidence through the focused feature stacks and promotes ledger rows only when all required gates exist.

[wieslawsoltes]

Focused evidence-accounting follow-up is open as #275 at f79bfb33.

It advances the ledger to schema v2 and fails closed unless each evidence entry records an exact source digest/revision, release-platform scope, SceneTech run/review URL, and complete pass/fail/skipped/unavailable denominator. partial and supported promotion now requires passing native and unchanged-product evidence on every platform in the claim.

The first populated row is deliberately still blocked: #253 sandbox Wave 0 records Chromium 153 6/6 on macOS and native 6/6 on Linux, while missing Windows, packaged product, ServiceWorker/resource/nested-document/interaction evidence remains visible under #265-#268.

Direct gates: ledger 10/10, inherited CSS 12/12, exact Code OSS 25/25 rescan, deterministic report, and diff check pass.

[wieslawsoltes]

PR #275 merged as 2355a4a3c691810514732c42ed7e75c3a83959bd after the exact 25/25 Code OSS rescan, ledger 10/10, inherited CSS 12/12, deterministic report, and current-head Linux runner passed. Remaining queued package jobs were canceled after merge.

The ledger now fails closed on evidence digest/revision drift, malformed or hidden denominators, out-of-scope platforms, non-SceneTech run provenance, and native/product evidence that does not cover every platform in a promoted claim. #253's two passing Wave 0 bundles are recorded while the iframe row stays blocked pending #265-#268, Windows/native breadth, and unchanged packaged webview evidence.