Skip to content

Portal command pages

The portal (hadronmemory.com) has a family of command pages — form-and-result or list views that give the CLI's operational commands a point-and-click surface, for people who don't reach for the terminal.

Reach a command page two ways:

  • The ⌘K command bar — press ⌘K (or Ctrl K), type the command name, and pick it from the list.
  • A direct URL — /app/commands/<id> (e.g. /app/commands/access-check).

Every command page shares the same chrome: a breadcrumb (Commands → <command>), a title, and a short description. All strings route through the portal's localization layer, so the pages are translation-ready.

Command pages come in two shapes:

  • Form pages take inputs, submit, and render a result inline (Check access, Merge node, Merge memory).
  • List pages render a searchable read-only table (List tasks).

The four pages below mirror the same server operations the CLI and GraphQL API expose, so a result is identical whichever surface you drive it from.

Check access

/app/commands/access-check · ⌘K: "access check", "check access"

Audits a principal's effective access to a resource — the portal front-end for the CLI hadron access check (GraphQL effectiveAccess).

Inputs

  • User — a @handle, an hrn:user:<handle> URN, or a user id. Defaults to the signed-in user, so a one-click submit answers "what can I access?"
  • Resource — a fully-qualified hrn:<type>: URN (memory, node, agent, app, org, or user) or an AI-service-config id.

Output

  • A capability matrix — READ / WRITE / MANAGE / DELETE, each ✓ or ✗.
  • The highest role the principal holds on the resource.
  • A Grants table explaining why: each row is a grant with its source (e.g. PUBLIC_VISIBILITY, ORG_ROLE), the role it confers, and the via path it travels.

Permissions — you can always check your own access. Checking another user requires being able to see the resource (today that means an admin/owner of it; broadening is tracked upstream in hadron-server#364). A disallowed audit shows a friendly message, not an error.

Merge node

/app/commands/merge-node · ⌘K: "merge node", "merge"

Folds a source node into a target node (the survivor). Backs the GraphQL mergeNodes mutation (see the GraphQL API reference).

Inputs

  • Source and Target — a node id or hrn:node:… URN each.
  • Fields to merge — a multiselect over Content, Abstract, Description, Tags, Data, Properties, Edges. Everything selected merges the whole node; narrow it to fold only some fields.
  • Delete the source after merging — a checkbox.

Behavior — text fields (content, abstract, description) concatenate target-first; tags take the union; data and properties shallow-merge with the target winning on key collisions; edges re-point from the source onto the target. The result links to the surviving node.

Permissions — write access to the target, plus the source when you're deleting it or moving its edges.

Merge memory

/app/commands/merge-memory · ⌘K: "merge memory"

Empties a source memory into a target memory. Backs the GraphQL mergeMemories mutation (see the GraphQL API reference).

Inputs

  • Source and Target — a memory id or hrn:memory:… URN each.
  • Collision fold strategy — the same field multiselect as Merge node. It applies to source nodes whose loc collides with an existing target node (each is folded by the Merge-node rules); non-colliding nodes move over unchanged, loc preserved.
  • Delete the source memory after merging — a checkbox.

Permissions — write access to both memories. Deleting the source additionally requires being its owner (for a personal/private memory) or an org admin. The v1 of this operation rejects encrypted memories and the system/app memory classes.

List tasks

/app/commands/list-tasks · ⌘K: "list tasks", "tasks"

The read/list shape — no form. Lists every runnable node (Node.isRunnable = true) across the memories you can access, in a searchable table; clicking a row opens that node. Backed by nodes(isRunnable: true) — the same predicate behind hadron node ls --runnable and the gate for hadron task run.

See also