You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(harness): verify preview open and page load end to end #5235
Provide verified preview opening on top of managed Artifact preview and capability preflight. Return structured opened, loaded, URL, title and error evidence. Distinguish successful launch from confirmed page load. Validate generated H5 interaction when requested. Acceptance: success, load failure, timeout and unsupported capability tests, plus Maka Dev end-to-end verification. Depends on #5234 and #5238. Relates to #5213.
Observed failure mode: the session could not establish a verified chain from local HTML generation to browser page load. navigation was rejected with , and the shell localhost workaround failed its later connection check. A completion result must distinguish process launch, browser navigation request, and confirmed document load.
Observed failure mode: the session could not establish a verified chain from local HTML generation to browser page load. Local file navigation was rejected because the browser requires an HTTP origin, and the localhost workaround failed its later connection check. Completion must distinguish process launch, navigation request, and confirmed document load.
This depends on #5234 and #5238, and #5238 has since closed as completed: managed HTML artifact previews now go through a loopback HTTP endpoint (#5316, 512605fd10f1cef0a9f65c1605c15eb5e2cf31fb), which was the failure the original observations rested on. Could you check on current main whether a verified chain from generated HTML to confirmed document load is still missing, and if so which of launch, navigation request and load confirmation cannot be distinguished today? That determines whether this stays a separate slice.
Could you check on current main whether a verified chain from generated HTML to confirmed document load is still missing, and if so which of launch, navigation request and load confirmation cannot be distinguished today?
I’d like to investigate this on current main, starting with the re-measurement requested above. I’ll test the managed HTML Artifact preview path and record endpoint reachability, browser opening, confirmed document load, and a simple interaction separately. I’ll report any remaining gap before proposing implementation changes, keeping capability preflight under #5234.
Could you check on current main whether a verified chain from generated HTML to confirmed document load is still missing, and if so which of launch, navigation request and load confirmation cannot be distinguished today?
Re-measured at commit 3597abe84356409ccc9fb649c761c1649abe941d on macOS, using npm run dev:worktree. The only untracked file was the test fixture, preview-5235.html.
The managed HTML Artifact preview happy path works with the existing browser tools:
counter changed from 0 to 1 after the agent clicked it
I then manually clicked again in Maka’s browser tab and confirmed 1 to 2.
ArtifactPreview returned reachable: true and loaded: false.
Document load and interaction were verified separately through browser observations.
Separately, the Generated Files inline preview rendered the HTML, but CSP blocked its inline script at about:srcdoc:48, so the counter did not respond there. “Open in default app” worked.
Failure, timeout, and unsupported cases have not been tested yet.
Given this result, should the remaining scope of #5235 focus on structured verification results and regression coverage for this workflow? I’ll keep capability preflight under #5234.
Thanks @echonesis, that re-measurement answers the question. Yes, narrow the remaining scope to structured verification results and regression coverage for this workflow.
loaded: false is by contract, not a gap. The ArtifactPreview tool description (apps/desktop/src/main/managed-artifact-preview-tools.ts:30) says reachable confirms a Desktop HTTP check, not browser load, and that rendering and interaction are verified through browser navigation and observation. Your run shows that chain already distinguishes launch (reachable), confirmed load (snapshot title and marker) and interaction (the counter). So #5235 no longer needs a new load authority. What it still lacks is proof that the chain fails honestly:
Success: the ArtifactPreview → navigate → snapshot → click → snapshot chain as a regression test, asserting the same three signals you recorded.
Load failure: an expired or revoked preview URL and an unreachable endpoint each surface as a failure, with no "opened" claim.
Timeout: a page that never finishes loading is reported as a timeout, not as success.
The Generated Files inline preview blocking inline scripts under CSP (about:srcdoc) is a separate question. Please open it as its own issue, so the srcdoc sandbox policy is decided deliberately rather than inside this slice.
@echonesis, #5234's capability preflight has landed in #5254 (3ab4ef76d), so the "unsupported" case of the scope agreed above is now unblocked. Consume its classification (gui_surface, browser_view, url_schemes, loopback_endpoint, each verified, unsupported or unknown) rather than re-deriving it here.
One boundary from that review is worth keeping in mind for the regression cases: loopback_endpoint: verified only shows that something on the Desktop machine answered. When the Runtime Host runs remotely over SSH, it doesn't prove the listener is the server the agent started.
Activity
liugddx commentedon Sep 12, 2026
Observed failure mode: the session could not establish a verified chain from local HTML generation to browser page load. navigation was rejected with , and the shell localhost workaround failed its later connection check. A completion result must distinguish process launch, browser navigation request, and confirmed document load.
liugddx commentedon Sep 12, 2026
Observed failure mode: the session could not establish a verified chain from local HTML generation to browser page load. Local file navigation was rejected because the browser requires an HTTP origin, and the localhost workaround failed its later connection check. Completion must distinguish process launch, navigation request, and confirmed document load.
Astro-Han commentedon Sep 17, 2026
This depends on #5234 and #5238, and #5238 has since closed as completed: managed HTML artifact previews now go through a loopback HTTP endpoint (#5316,
512605fd10f1cef0a9f65c1605c15eb5e2cf31fb), which was the failure the original observations rested on. Could you check on currentmainwhether a verified chain from generated HTML to confirmed document load is still missing, and if so which of launch, navigation request and load confirmation cannot be distinguished today? That determines whether this stays a separate slice.fix(harness): narrow preview preflight to what it can prove
echonesis commentedon Oct 5, 2026
I’d like to investigate this on current main, starting with the re-measurement requested above. I’ll test the managed HTML Artifact preview path and record endpoint reachability, browser opening, confirmed document load, and a simple interaction separately. I’ll report any remaining gap before proposing implementation changes, keeping capability preflight under #5234.
echonesis commentedon Oct 6, 2026
Re-measured at commit
3597abe84356409ccc9fb649c761c1649abe941don macOS, using npm run dev:worktree. The only untracked file was the test fixture, preview-5235.html.The managed HTML Artifact preview happy path works with the existing browser tools:
The raw snapshots confirmed:
I then manually clicked again in Maka’s browser tab and confirmed 1 to 2.
ArtifactPreview returned reachable: true and loaded: false.
Document load and interaction were verified separately through browser observations.
Separately, the Generated Files inline preview rendered the HTML, but CSP blocked its inline script at about:srcdoc:48, so the counter did not respond there. “Open in default app” worked.
Failure, timeout, and unsupported cases have not been tested yet.
Given this result, should the remaining scope of #5235 focus on structured verification results and regression coverage for this workflow? I’ll keep capability preflight under #5234.
liugddx commentedon Oct 8, 2026
Thanks @echonesis, that re-measurement answers the question. Yes, narrow the remaining scope to structured verification results and regression coverage for this workflow.
loaded: falseis by contract, not a gap. TheArtifactPreviewtool description (apps/desktop/src/main/managed-artifact-preview-tools.ts:30) saysreachableconfirms a Desktop HTTP check, not browser load, and that rendering and interaction are verified through browser navigation and observation. Your run shows that chain already distinguishes launch (reachable), confirmed load (snapshot title and marker) and interaction (the counter). So #5235 no longer needs a new load authority. What it still lacks is proof that the chain fails honestly:ArtifactPreview→ navigate → snapshot → click → snapshot chain as a regression test, asserting the same three signals you recorded.The Generated Files inline preview blocking inline scripts under CSP (
about:srcdoc) is a separate question. Please open it as its own issue, so the srcdoc sandbox policy is decided deliberately rather than inside this slice.Assigning this to you if you'd like to take it.
fix(harness): narrow preview preflight to what it can prove
fix(harness): publish the preview offer through one tested seam
feat(harness): add local preview capability preflight (#5254)
liugddx commentedon Oct 10, 2026
@echonesis, #5234's capability preflight has landed in #5254 (
3ab4ef76d), so the "unsupported" case of the scope agreed above is now unblocked. Consume its classification (gui_surface,browser_view,url_schemes,loopback_endpoint, eachverified,unsupportedorunknown) rather than re-deriving it here.One boundary from that review is worth keeping in mind for the regression cases:
loopback_endpoint: verifiedonly shows that something on the Desktop machine answered. When the Runtime Host runs remotely over SSH, it doesn't prove the listener is the server the agent started.