Documentation

Usage Cookbook

This cookbook turns the higher-level AgentHub docs into task recipes. Use it when you know what you want to do and need the shortest safe path through Desktop, Local Edge, Hub, Web, runtime adapters, or public release work.

Current scope

The recipes below are public-safe operating patterns. Local Desktop + Local Edge + mock runtime is preview-ready. Hub-backed Web, Feishu/Lark, Remote/Cloud Edge, and stable third-party adapter packaging remain in progress or in development unless the owning repository has newer release evidence.

Recipe Map

GoalStart hereRequired surfacesStatus
Verify a workstationInstallationGit, Go, Node.js, pnpm, mock runtimeCurrent
Run a read-only agent taskQuickstartDesktop, Local Edge, mock or real runtimePreview-ready
Produce a reviewable diffDesktop GuideDesktop, Local Edge, diff/artifact panel, approval policyPreview-ready
Compare runtime adaptersAgent ProfilesMock, Claude Code, Codex, OpenCode profilesContract shaped
Triage a failed runTroubleshootingEdge health, run events, runtime status, error codeCurrent
Prepare a team-visible taskHub And EdgeHub session, project, target Edge, auditIn progress
Plan Feishu/Lark entryFeishu/Lark IntegrationIntegration Gateway, TokenDance ID binding, Hub taskIn development
Publish docs/site changesRelease Checklistbuild, test, lint, sitemap, llms, visual QACurrent

Local Read-Only Review

Use this recipe for the first successful task on a new machine or with a new runtime profile.

  1. Start Local Edge with the mock runtime on loopback.
  2. Start Desktop and connect it to the same Local Edge URL.
  3. Select an allowlisted workspace.
  4. Ask for a read-only review, for example:
Text
Review the README and suggest the smallest documentation improvement.

Expected evidence:

EvidenceHealthy shape
Edge healthprocess is reachable and runtime inventory includes the mock runtime
Desktop connectionLocal Edge appears online and the selected workspace is allowed
Event streamrun.started, run.message.delta, run.artifact.ready, run.completed appear in order
Transcriptuser prompt and agent output render without overflow
Safetyno file write happens without explicit approval

Public screenshots should replace private absolute paths with short placeholders such as workspace/app.

Reviewable Diff

Use this recipe when an agent should propose changes but a human should decide whether they are applied.

  1. Start from a clean or intentionally reviewed Git state.
  2. Run a focused task that names the target files or behavior.
  3. Keep writes in proposal mode until the diff panel has rendered.
  4. Review the changed files, generated artifacts, and event timeline.
  5. Approve apply, commit, or publish only as separate actions.

The UI should make the boundary visible:

StepOwnerUI expectation
Runtime outputRuntime adapternormalized message, tool, and file events
File change detectionEdgerelative paths and diff metadata
ReviewDesktop/Webread-only diff until approved
ApplyEdge + user approvalexplicit approval id and final result event
AuditHub when routed through Hubactor, project, run id, action, result, request id

Do not treat a completed model response as an applied change. Completion means the run reached a terminal state; the repository is still governed by diff review, approvals, commits, and CI.

Runtime Adapter Comparison

Use this recipe when comparing Claude Code, Codex, OpenCode, or a custom adapter.

Keep the task, workspace, approval policy, and expected output the same:

Text
Inspect the docs navigation and report one missing consistency check. Do not edit files.

Compare:

DimensionWhat to compare
Availabilityinstalled or authenticated, ready, unavailable, or timeout
Event qualitymessage deltas, tool calls, file reads, errors, terminal state
Diff disciplinewhether proposed changes are surfaced as reviewable diffs
Cancellationwhether canceling leaves a clear terminal event
Privacywhether paths, prompts, and provider output can be redacted for public evidence

Adapter examples in these docs are contract previews. Do not copy placeholder import paths into production code until the owning SDK or package is published and versioned.

Failed Run Triage

Use this recipe when a task fails or stalls.

  1. Record the run id and the last event type.
  2. Check Local Edge health and runtime inventory.
  3. Reproduce with the mock runtime.
  4. If the mock runtime passes, check the real runtime CLI install, login, quota, and adapter profile.
  5. If Hub/Web is involved, check Hub authorization and target Edge presence before changing the UI.
  6. If Feishu/Lark is involved, check gateway verification, idempotency, queue handoff, TokenDance ID binding, and Hub task creation.

First useful error codes:

CodeFirst owner to inspect
runtime_unavailableruntime CLI and Edge adapter profile
workspace_outside_allowlistEdge workspace policy
permission_deniedHub permission or Edge approval policy
unauthorized_targetHub project or device target authorization
target_offlineHub target presence and Edge heartbeat
schema_validation_failedAPI or event schema and adapter normalization

Public issues should include the route class, error code, request id or run id placeholder, and the last safe event type. Private logs, raw prompts, real file content, provider keys, and callback payloads belong in private operator evidence.

Team Task Preparation

Use this recipe before moving a local-only run into a team-visible workflow.

Minimum readiness checklist:

  • TokenDance ID login and Hub product session are distinct and both understood.
  • Project membership and target Edge authorization are checked before queueing work.
  • The task references a project or workspace target by id, not by private absolute path.
  • Reviewable diffs and artifacts are available before apply or publish.
  • Audit records denied actions as well as successful actions.
  • Web renders Hub-owned state and does not directly access Local Edge or local files.

If any item is missing, keep the task in local preview or controlled integration testing rather than calling it generally available.

Feishu/Lark Task Preparation

Use this recipe for bot messages, card actions, and H5/workbench entry planning.

The durable shape is:

  1. Integration Gateway verifies and decrypts the provider event.
  2. Gateway acknowledges quickly.
  3. Slow work moves to an async queue.
  4. TokenDance ID binding maps the Feishu/Lark actor to a product identity.
  5. Hub creates or updates an AgentHub task under product authorization.
  6. Progress returns through card, message, H5, or Web without leaking full workspace context.

Do not put verification tokens, app secrets, tenant tokens, full prompts, raw provider payloads, or absolute local paths into cards, frontend code, or public docs.

Docs And Site Release

Use this recipe when adding or changing public documentation.

Every new docs route needs:

SurfaceRequired update
MDXEnglish and Chinese page under the same slug
Navigationdocs sidebar labels and prev/next order
TOCEnglish and Chinese headings
Metadatalocalized title and description
Searchbody text for English and Chinese search
Discoverysitemap.xml and llms.txt
Reader mapREADME docs inventory and docs landing page
Verificationtests, build, lint, public-surface and i18n checks

Public release notes should say what changed and how readers verify it. They should not include production web-root paths, SSH aliases, rollback commands, logs, or secrets.

Evidence Template

Use this template for a private PR, internal issue, or handoff note:

Text
goal:
route_or_surface:
language:
theme:
viewport:
edge:
runtime:
run_id:
last_event:
artifact_or_diff:
checks:
result:
private_evidence_location:

Public docs should keep only redacted status and stable boundaries. The actual local path, raw logs, provider output, and deployment path should remain private.