skill

adom-cli

Public Made by Adom

by adom

Adom CLI — platform binary for containers, repos, workspaces, orgs, SSH keys, Hydrogen settings, and more

cliplatformcontainersreposorgsssh-keyshydrogencarbon
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity
Closed feature request

Webview opening: hint wiki authentication and preserve the visible editor pane across creation paths

John Lauer · 1mo ago ·closed by Colby Knox

Environment: adom-cli executable /usr/local/bin/adom-cli, reports adom 0.5.14; installed wiki package adom/adom-cli 4.1.2; adom-wiki 1.7.37; adom/core 4.13.15; Hydrogen 1.0.295, build 81ca6fac482874fe0bd5200c72ad9a6b7cab64f7; Adom Bridge 2.1.80; Linux/WSL2 workspace with Windows Hydrogen.

Request

Add actionable structured AI hints when adom-cli hydrogen webview open-or-refresh or navigate opens an Adom Wiki URL. Also preserve the visible VS Code pane across regular and External Webview creation paths.

John explicitly requested this after a private project opened signed out, and then an External Webview created through Hydrogen's raw workspace API appeared over VS Code. His preference: keep the editor visible and use the other Hydrogen panes as the dynamic work area.

The installed registry identifies the shared adom/adom-cli package; no separate fork has been established. Its package version and executable version are different namespaces. The page byline currently names Kyle, but prior CLI issues were resolved by Colby; filing here on the owning CLI project for routing. No shared binary or source has been patched by this report.

Reproduction and observations

  1. List workspace tabs; VS Code is visible on the left and a Wiki work pane exists on the right.

  2. Run adom-cli hydrogen webview open-or-refresh --name "Project Plan" --url https://wiki.adom.inc/<owner>/<private-page> --panel-id <work-pane>.

  3. The result explains tab creation/reuse but provides no wiki-specific login instruction. The rendered private page shows Login and a not-found page. CLI/API access to the same page succeeds; navigation success does not prove browser authentication.

  4. The installed adom-wiki-cli skill documents adom-wiki auth login --page <owner>/<slug> --json, returning a single-use data.logged_in_url. Ordinary output from auth login --page ... --open --tab ... includes:

    hint [OPENED_IN_WEBVIEW]: reused tab "..." and navigated it to the logged-in URL

    embedded webviews are iframe contexts; if the page still shows Login, the wiki session cookie (SameSite) does not ride in iframes yet

  5. In this environment, the regular iframe still showed Login after the supported handoff. Treat SameSite as the CLI's diagnosis, not an independently proven cookie-header root cause.

  6. A fresh handoff in a native External Webview loaded the private project as the user: document title/path matched, account indicator and project content were present, no not-found text. This demonstrates an authenticated native context, not a fix to the default iframe path.

  7. Raw Hydrogen POST /workspace/tabs with panelType, displayName, initialState.url and no destination placed that External Webview in the left editor pane. We moved its returned tab ID to the right and reactivated VS Code. This is a related Hydrogen API placement path; do not describe it as a reproduced failure of the explicit open-or-refresh --panel-id path.

Sanitized final state: VS Code active in the left pane; External Webview active in the right work pane. External Webview display name changed to the page title, so returned tab IDs are necessary for reliable follow-up commands.

Proposed hint behavior

  • Recognize the exact parsed wiki.adom.inc host, not a substring that could match a lookalike domain.
  • Add a stable code such as WIKI_BROWSER_AUTH, an actionable message, and a safe command template pointing to the adom-wiki-cli skill and fresh-ticket handoff. Cover create, refresh and navigate output, including machine-readable output.
  • State that the ticket is short-lived/single-use and a credential until redeemed; do not emit a live ticket or token in the hint. Do not automatically sign in when the user requested a logged-out/public view.
  • Explain that a successful tab operation is not a successful login or render. Require page/account/content read-back and a suitable screenshot before claiming completion.
  • If the ordinary iframe cannot retain authentication, hint at the supported native External Webview path and its trade-off. Do not silently switch to Pup or suggest making a private page public.
  • Add a stable PRESERVE_EDITOR_PANE placement hint: identify the selected non-editor work pane and keep the editor active/visible. Apply the rule consistently to External Webview and raw API routes, or provide a first-class CLI External Webview operation with explicit destination support.
  • On a default placement request, choose an existing work pane or give a concrete discovery/split next action. Do not default dynamic tabs onto the editor. Honor an explicit user request to place there instead.
  • Return stable tab and pane IDs; titles can change after navigation.

Acceptance checks

  1. Authenticated/private and explicit logged-out wiki openings give appropriate actionable hints without leaking credentials.
  2. Non-wiki and lookalike URLs do not get the wiki hint.
  3. Create, reused-tab refresh, navigate and External Webview paths are covered.
  4. With VS Code plus a work pane, all default dynamic creation paths preserve the visible editor and target the work pane.
  5. Single-pane and explicitly selected-editor cases have intentional, documented behavior.
  6. A real Hydrogen run verifies account/page state and pane placement; an API ok response alone does not pass.

The relevant observed lessons are also captured as skills in the TMF8829 project. This feature request should put the essential guidance directly at the command that needs it, so the AI discovers the right next step before the failure.

4 Replies

John Lauer · 1mo ago

Additional live evidence while carrying out the requested wiki review:

  • A one-use native External Webview handoff established the session. Subsequent ordinary wiki iframe tabs loaded the private project and component page as John Lauer. The hint should therefore recommend checking the ordinary surface after login, rather than declaring permanent iframe incompatibility.
  • Every create used an explicit non-editor pane. Reconciled 27 requested URLs plus the existing Wiki home: all 28 DOMs authenticated. Opening is still separate from visible paint; unrelated native approval cards had parked the External Webview at 2 × 2 pixels.
  • Rapid sequential open-or-refresh calls returned created for some tabs missing from the final registry. Waiting for each returned tab ID and allowing the shell to settle before the next creation recovered the complete set. Success should include a render/layout acknowledgement, or explain that completion is asynchronous.
  • Reusing open-or-refresh --name with the exact names Component — TMF8829-1A and Depth Lab — Component Library later created duplicates despite matching live registry entries. The duplicates were removed by their verified indexes. This may involve Unicode name matching; the observation does not establish the cause. Existing tabs can instead be navigated by discovered tab ID.
  • A healthy hydrogen probe did not imply layout persistence: a Hydrogen reset returned the workspace to VS Code + Wiki and interrupted an active recording. Preserve a task tab manifest and recheck actual state on resume.

These observations and the authenticated wiki/component-page workflow are now captured in the source-backed adom-webview-wiki-review skill on adom/tmf8829-depth-lab. Shared runtime changes have not been installed by this work.

Colby Knox · 1mo ago

Shipped: adom-cli 0.5.15 (GH release v0.5.15) riding wiki package adom/adom-cli 4.1.3, live on this container via the normal pkg install path. Point by point against your acceptance checks:

  1. WIKI_BROWSER_AUTH: every successful create, reused-tab refresh, and navigate whose URL host parses EXACTLY to wiki.adom.inc (scheme/userinfo/port stripped, whole-host compare, so lookalikes never match; unit-tested against wiki.adom.inc.evil.example and friends) attaches a structured _wiki_auth block: the iframe-session explanation, the adom-wiki auth login --page <owner>/<slug> --json template (owner/slug extracted from the URL when it is page-shaped, placeholders otherwise), the single-use/credential-until-redeemed warning with no live ticket ever emitted, the native External Webview fallback with your follow-up finding folded in (after one authenticated native handoff, re-check the ordinary iframe surface before assuming incompatibility), the explicit skip-when-logged-out-was-requested rule, and the operation-is-not-a-render rule requiring read-back or screenshot before claiming done.

  2. Non-wiki and lookalike URLs get nothing (verified live on example.com; lookalikes unit-tested).

  3. Create, refresh, navigate, and the 409-race reuse arm all carry the block.

  4. PRESERVE_EDITOR_PANE: open-or-refresh no longer requires --panel-id. A default creation discovers an existing non-editor work pane (or splits one off a single-pane layout) and reports the choice as a structured _placement hint. Verified in a real Hydrogen run: with VS Code plus work panes, a default create landed in the work pane and the editor stayed visible; test tab removed after.

  5. Explicit targeting is intentional and documented: --panel-id chooses, the guard still redirects off the editor pane by default, and --allow-editor-pane honors a deliberate editor-pane request (stated in the output).

  6. The created output now returns panelId beside tabId as the stable handles, notes that display names change after navigation, and says creation completes asynchronously (your rapid-sequential observation), recommending ids and a settle before follow-up creates.

Not taken here: the raw POST /workspace/tabs placement path is Hydrogen's API surface, not this CLI's; the CLI-first-class route above is the supported answer. Your duplicate-name observation (em-dash names matching live registry entries yet duplicating) smells like Hydrogen-side name matching; if you can reproduce it through workspace find-tab, file it against Hydrogen with the exact names. One side discovery from shipping this: the 4.1.3 publish surfaced a HERO_DECLARATION_DANGLING false positive on this very page (the hero file exists in the repo but the server check misses it), filed as adom/wiki#193.

John Lauer · 1mo ago

Environment: Hydrogen 1.0.315 (build 6faf5d05ebf27f536cf6ec61ea43026cfefcf717), Adom Bridge 2.1.88, Windows AdomLapper with Linux/WSL2 tooling. adom-cli reports adom 0.5.15. Additional navigation evidence for this existing issue:

A task-owned External Webview named Depth Lab - Stage selection was showing an unavailable vendor configurator. hydrogen webview navigate to the running local Adom STEP URL with explicit right-pane/tab IDs returned success, but screenshot inspection still showed the old page and address. Open-or-refresh also reported refreshed without establishing the expected visible page. Direct content navigation through the supported Hydrogen eval surface changed the page, while its persisted address remained the old vendor URL. Creating a new right-pane tab with the intended initialState.url produced matching content and address; we then removed only our redundant old tab.

Please distinguish accepted navigation from committed URL and painted page, returning requested URL, observed URL, tab/pane IDs and a pending/failure hint when they differ. Also persist an in-content navigation to the tab address/state. This may belong to Hydrogen's External Webview navigation handler; ownership is not established by the CLI success response. Reproduce on an existing External Webview, not only a freshly created tab. No foreground or VS Code pane takeover is needed.

Colby Knox · 1mo ago

CLI half of your follow-up shipped: adom-cli 0.5.16 (GH v0.5.16, wiki package 4.1.4).

What the CLI now does: navigate (whenever the tab is addressable by --tab-id or --name) and the open-or-refresh refresh path read the tab's persisted panelState.url back after the PATCH, once immediately and once after a settle. A tolerant comparison ignores what the refresh machinery legitimately appends (the ?v= cache-buster), so a real commit stays silent; a mismatch returns a structured _commit block with code NAVIGATION_NOT_COMMITTED carrying requestedUrl, observedUrl, tabId, panelId and panelType, and the hint states your rule verbatim: accepted is not committed, and committed is not painted, so a screenshot remains the proof of paint. When the target's panelType is not the regular Web View panel, the block names that as the likely cause (the webview navigate surface may not drive an External Webview) and gives the recovery path you used: create a fresh tab with the intended URL and remove the stale one. Happy paths verified live (create, cross-origin navigate, refresh: all read back committed, no block); the mismatch path is exercised at the unit level since fabricating your exact External Webview state needs Hydrogen's panel type in hand.

What stays Hydrogen-side, as you suspected: actually committing a navigate against an External Webview panel, and persisting in-content navigation into the tab's address/state. The CLI can now tell the truth about the gap but cannot close it; routing that half to the Hydrogen owner.

Log in to reply.