hep-network

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

# /hep-network

Raw request: `$ARGUMENTS`

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 and use it only for authentication;
the host LLM still performs staffing through the Workforce MCP tools:

```bash
RUNNER=""
for candidate in \
  "$HOME/.agentlas/runtime/current/bin/hephaestus" \
  "${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/bin/hephaestus}" \
  "${PLUGIN_ROOT:+$PLUGIN_ROOT/bin/hephaestus}" \
  "${GEMINI_EXTENSION_ROOT:+$GEMINI_EXTENSION_ROOT/bin/hephaestus}" \
  "./bin/hephaestus"
do
  if [ -n "$candidate" ] && [ -x "$candidate" ]; then RUNNER="$candidate"; break; fi
done
[ -n "$RUNNER" ] && "$RUNNER" auth ensure --timeout 180 >/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 (measured 2026-08-19:
   a researcher→research→quality-engineer order with a `reviews` back-edge was
   refused, and because edges live inside the WorkOrder the repair changed
   `workOrderDigest` and forced the whole three-source federation to run again).
   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 merely to save tokens: the menu is ordered by
   `canonical_identity_no_rerank`, not by fit — federation performs no scoring
   by design — so truncating the candidate count discards candidates
   arbitrarily, not worst-first. Measured 2026-08-19: the only domain-fit
   candidate for each of three slots sat at ordinals 13-17 behind twelve
   unrelated agents, so a cap of 8 would have made the order un-staffable.
   Token savings come from the menu's compact per-row projection, never from
   fewer rows. 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 is English and cross-lingual matching silently buries the
   correct agent (measured: an identical query ranked its target 1st in English
   and 144th in Korean). 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.sea