/hep-network

name: hep-network
description: Staff a task from registered Local, owner Cloud, and public Hub agents.

Update fallback: 자동 업데이트가 안 되면 `hephaestus update`를 한 번 실행하세요. 업데이트하지 않아도 현재 버전 명령은 그대로 동작합니다.

<!-- prompt-module: {"id":"os.commands.network-body","revision":3,"stability":"versioned-content","changeTriggers":["release"],"channel":"user"} -->

/hep-network

<!-- prompt-module: {"id":"command.hep-network.host-execution","revision":3,"stability":"fixed-policy","changeTriggers":["release"],"order":0} -->

You are the active top-level workforce orchestrator. Use the local Agentlas OS MCP server named `hephaestus-network`, the only host-visible Workforce MCP. Core reaches Cloud and Hub through its internal upstream client. Network means all registered Local agents, the signed-in owner's Cloud agents, and public Hub agents.

Before every unpinned discovery, Core refreshes the current safe snapshot for each active registered Local source. A changed Local folder therefore becomes a new candidate release in this search without requiring `network reindex`; the selected and prepared release remains immutable after that discovery.

The user does not need to say `goal`. First call `workforce.goal_context` for the current project, passing `knownRevisions` with any `goalId -> rosterRevision` pairs already in this conversation so unchanged goals come back as one line. If it returns an active binding for this ongoing work, reuse that exact roster and `goalId` before considering recruitment. If it returns `pendingExecution`, those releases were prepared and never run: either run them now or say so plainly — preparation is not delivery, and the session-end checkpoint reports the same fact to the user.

Before the first Cloud or Hub source call, reuse the installed Agentlas sign-in. Resolve the runner in this order for authentication and supported host-adapter execution; the host LLM still staffs through Workforce MCP tools:

RUNNER=""
for candidate in \
  "$HOME/.agentlas/runtime/current/bin/hephaestus" \
  "${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/bin/hephaestus}" \
  "${PLUGIN_ROOT:+$PLUGIN_ROOT/bin/hephaestus}" \
  "./bin/hephaestus"
do
  if [ -n "$candidate" ] && [ -x "$candidate" ]; then RUNNER="$candidate"; break; fi
done
[ -n "$RUNNER" ] && "$RUNNER" auth ensure >/dev/null 2>&1 || true

1. Call `workforce.preflight_work_order` with a compact draft: `taskBrief`, one `roles` entry per materially distinct responsibility, and `edges` by 1-based role ordinal. Core compiles the exact redacted `agentlas.workforce-work-order.v1`, generates every transaction/slot/artifact id, fills omitted arrays, validates the privacy boundary and returns a one-hour `workOrderRef`. Write required skills as plain English phrases when no ontology id is obvious — Core normalizes them and reports each rewrite as `normalizedConcepts`. Give each role a specific `task`, `cardinality`, `criticality`, and — only when they genuinely constrain semantic fit — required communities/roles/skills/ knowledge. The title, task, publisher summary, and sample request sentences remain the primary fit evidence. Execution requirements are a separate contract: include `requiredToolCapabilities`, required/forbidden authorities, runtimes, languages, or modalities only when the requested action genuinely requires the host to prove them. They do not rank or exclude semantic candidates; Core carries them unchanged into the ExecutionContext, where the host must bind its actual tool inventory and permission receipt. Leave every unconstrained list absent (the wire normalizes absent to `[]`). Keep `consumes`/`produces` absent and describe ordinary inputs/outputs in the task text and inter-slot handoffs in `edges`. An edge is a declaration of handoff and never a qualification requirement. Only semantic communities, roles, skills, and knowledge explicitly required by the task may narrow menu fit. Tool capability, authority, runtime, language, and modality fields never filter or rank that menu; they remain post-selection execution proof. Hand-off edges must be acyclic: a review or feedback edge that points back to an earlier slot is rejected as `task_force_cycle:<the loop path>` — model review as a forward hand-off to the reviewer, not a back-edge. Changing an edge changes `workOrderDigest` and requires a fresh federation for that WorkOrder. Keep the default `selectionPolicy.maximumCandidatesPerSlot` at 30 unless a measured recall need justifies widening it (the schema allows up to 100), and never shrink it yourself to save tokens. The Hub and Cloud sources already shrink safely: they order each slot by fit with a decision model and, for a default-sized menu, send only their best 8. Core still presents the merged menu in `canonical_identity_no_rerank` order and Local candidates are not fit-ranked, so a smaller cap you set would cut rows arbitrarily, not worst-first. When a slot needs more rows, set the maximum above 30: the sources then return that many, still in fit order. In the returned menu, `candidateOrdinal` restarts at 1 inside every slot — it is a per-slot position, not a running number across the menu. Keep private files, memory, secrets, direct identifiers, and raw local context on-host. Write every discovery-facing natural-language field (statement, role descriptions, required skills/knowledge) in English, faithfully translating a non-English request rather than passing its original wording through: the candidate corpus uses English for discovery. Keep an untranslatable proper term alongside a short English gloss, e.g. `종합소득세 (Korean comprehensive income tax)`. The `languages` slot is the delivery requirement, not the search language — set it to the language the work product must be produced in (e.g. `ko`) even though the order itself is written in English. 2. Call `workforce.search