Skip to content

feat(pages): unify Agent page management with PageManage - #3619

Merged
bobleer merged 6 commits into
GCWing:mainfrom
bobleer:bob/page-manage
Oct 30, 2026
Merged

bobleer merged 6 commits into
GCWing:mainfrom
bobleer:bob/page-manage

Conversation

@bobleer

@bobleer bobleer commented Oct 30, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Unify the default Pages Agent interface in PageManage. Agents can list published Pages with name, absolute URL, visibility, and update time; publish or update complete content bundles; change access; delete Pages or individual versions; inspect versions; deploy/roll back; and unpublish.

Type and Areas

Feature. Rust tool/runtime assembly, account Relay integration, Web UI tool cards, Agent configuration compatibility, capability documentation.

Motivation / Impact

Pages previously exposed only PagePublish and PageDeploy, leaving account listing, metadata, visibility, and deletion behind UI interactions. PageManage exposes those operations through the executing host's existing account integration. Updates preserve the inspected title/access settings, and upload/freeze uses the inspected Page generation to avoid targeting a deleted-and-recreated Page. Publishing defaults to a private saved preview; deploy=true makes the version live.

New mode defaults expose only PageManage. The old tool names remain executable for existing calls and explicit legacy configurations. Legacy exclusions preserve the remaining allowed operations, and content updates continue to use page_publish permission checks so existing publication denials apply. List/version reads do not request mutation approval; writes retain fresh account-scoped approval in Ask mode.

The result card displays page metadata and distinguishes saved previews from live versions. Restricted links use the existing access-link API and stale device-switch results cannot open a URL on the newly selected surface. All three Pages cards gate account-link creation for detached observers and their child sessions, with an explicit executing-device hint. CLI peers show a clear unsupported state because they do not expose Pages access-link commands. Unknown peers remain gated until the host is identified; Desktop peers keep their existing path.

Content updates also negotiate metadata_preconditions_supported from the Relay before uploading. Version freeze checks the inspected visibility and, unless explicitly replaced, title under the Page write lease. A concurrent rename or access restriction returns a conflict without overwriting metadata or creating a version. Older Relays explicitly decline this new content-update path while legacy publishing and existing management operations remain compatible.

Desktop startup explicitly registers PageManage alongside the legacy handlers. Both Desktop and CLI call the shared operation implementation with a snapshot from their own account lifecycle and an account-change fence. The Desktop smoke fixture goes through the production registration routine and the actual tool call, so a visible tool with a missing host callback is caught.

Verification

Passed locally:

  • cargo test --locked -p openbitfun-core --no-default-features --features remote-connect,tools-pages,git,ssh-remote --lib -- page_ mode_config_canonicalizer presentation_tools_follow_permission_mode_without_weakening_denials — 42 passed, 2 existing ignored; final account adapter rerun: 14 passed.
  • cargo test --locked -p openbitfun-tool-packs --features basic — 12 passed.
  • cargo test --locked -p openbitfun-product-capabilities — 34 passed.
  • cargo test --locked -p openbitfun-services-integrations --no-default-features --features remote-connect --lib remote_connect::page_upload — 9 passed.
  • cargo test --locked -p openbitfun-desktop --lib api::remote_connect_api::page_tool_tests — 1 passed; isolated production registration, actual list/permission requests, logout gate, and account-change fencing.
  • cargo test --locked -p openbitfun-relay-service — 126 passed. The concurrent metadata regression failed before the fix (HTTP 200 instead of 409) and passes after it.
  • pnpm --dir src/web-ui exec vitest run src/flow_chat/tool-cards/PageManageToolDisplay.test.tsx src/flow_chat/tool-cards/index.test.ts — 40 passed, including all three Pages cards, detached parent ownership, hydration, CLI/unknown-peer gating, Desktop-peer support, and device changes during both lookup and access-link requests.
  • pnpm --dir packages/flow-chat-presentation run test tests/catalog.test.tsx — 819 passed.
  • pnpm run capabilities:test — 16 passed; pnpm run capabilities:check passed.
  • pnpm run check:web, pnpm run i18n:audit, pnpm run check:core-boundaries, pnpm run fmt:rs, and git diff --check passed.

Reviewer Notes

AI-assisted implementation, verified with focused automated tests. Account operations use a loopback Relay protocol fixture, including legacy payloads and account-switch fencing. Remote workspace rejection and Peer surface-switch handling use simulated contexts. Live Remote Workspace, Remote Control, Peer Device, and Detached Dispatch connections, native visual rendering, and real account publication were not exercised locally. No new Tauri, Peer HostInvoke, or dispatch commands are introduced. The Relay upload response adds a capability flag and version-freeze requests add optional metadata preconditions; older clients continue to omit them.

Checklist

  • This PR is focused and does not include secrets, temporary prompts, generated scratch files, or unrelated artifacts.
  • Relevant verification is recorded above, and untested scenarios are identified.
  • User-facing strings, docs, and locales are updated.

@bobleer
bobleer merged commit 2da1981 into GCWing:main Oct 30, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant