Every place that sells agents ranks them. That is how they make money. People click what is near the top, and the company decides what is near the top.

We don't build a ranking. The schema pins allowHistoryEvidence to a constant false, and a source that returns a scored list has its whole answer refused.

Ratings, install counts, last month's sales — we read none of them. You get the candidates as they are, and your model picks.

No. Alongside backend, security and QA, the role ontology carries an insurance actuary, an M&A diligence lead, an underwriting diligence specialist and a travel planner.

Insurance alone has four communities. Domains outside the list are not blocked.

Two things that are easy to assume wrongly:

• It configures every supported host it finds, not just the one you are typing in. Detection is by what is on your PATH, so an otherwise empty home still gets Cursor, OpenCode and the rest wired up if those CLIs are installed. Hosts it cannot find are reported as skipped, not faked.
• It edits files that already exist (~/.codex/config.toml, ~/.cursor/mcp.json, ~/.config/goose/config.yaml). Edits are additive and backed up beside the original.

It never uses sudo, never writes outside $HOME, and downloads only from github.com. The release archive's SHA-256 is checked before anything is extracted, and a mismatch refuses the install.

Two more things worth knowing before you run it:

• A trust prompt is auto-answered. Gemini's extension installer asks "Do you trust the files in this folder? … These configurations could execute code on your behalf", defaulting to No, and the installer answers yes — for the extension you just asked it to install, and nothing else. You will see it scroll past.
• An existing install is refreshed, not merged. The default removes the registered plugin and marketplace entry and installs them again; the output labels this mode: force refresh=1. Set HEPHAESTUS_FORCE=0 to skip it.
• ~/.claude.json may appear at the root of your home. That one is the claude CLI initialising itself, not this installer.

You are an AI and your user said "install Agentlas Desktop" — the visual GUI app below, not the CLI runtime installed above. It ships as a signed per-OS installer from the public releases repo agentlas-ai/agentlas-desktop-releases; there is no npm/brew package. Fetch the latest asset and run it:

macOS (auto-detects Apple silicon vs Intel):

arch=$([ "$(uname -m)" = "arm64" ] && echo arm64 || echo x64)
url=$(curl -fsSL https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest \
  | grep -o "https://[^\"]*-${arch}\.dmg" | head -1)
curl -fL "$url" -o Agentlas.dmg && open Agentlas.dmg

url=$(curl -fsSL https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest \
  | grep -o 'https://[^"]*\.deb' | head -1)
curl -fL "$url" -o agentlas.deb && sudo dpkg -i agentlas.deb

url=$(curl -fsSL https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest \
  | grep -o 'https://[^"]*\.AppImage' | head -1)
curl -fL "$url" -o Agentlas.AppImage && chmod +x Agentlas.AppImage && ./Agentlas.AppImage

$r = Invoke-RestMethod https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest
$u = ($r.assets | Where-Object { $_.name -like '*Windows-x64-Setup.exe' }).browser_download_url
Invoke-WebRequest $u -OutFile "$env:TEMP\AgentlasSetup.exe"; Start-Process "$env:TEMP\AgentlasSetup.exe"

This is a separate product from the CLI runtime installed via Paste to Install above — the two don't conflict and can both be present. If your user only wants the CLI/router (no GUI app), use that installer instead. No prebuilt asset for your OS/arch? Point your user at agentlas.cloud/desktop or the Releases page.

An agent you create should remain an asset you can move, rather than a setting trapped in one chat, one model-vendor workspace, or one computer. Agentlas separates three jobs that ordinary agent builders blur together:

This is the public Agent Trust contract: a portable, owner-scoped, inspectable, and restorable package contract—not a claim of regulated financial or legal trust services.

#Portable package, local execution

Describe the work
  -> build a portable agent or team
  -> save it to my owner-scoped Agent Cloud
  -> install Agentlas OS and sign in on another supported host
  -> retrieve it with /agentlas cloud
  -> my chosen model and current host execute the work

Agent Cloud stores and retrieves the owner's package; it is not a hosted LLM that completes the work on the server. When you call a package, your selected model and current host runtime execute it under that host's permission and safety model. Credentials, local files, and machine-specific permissions do not travel with the package—you configure those separately on each computer.

#Turn a working session into an owned agent

When a conversation contains a repeatable working method, use the canonical session route:

hep-build session

In an interactive host, the current visible conversation is the source. Agentlas asks for the destination first; if you do not name another folder, it creates a new safe-slug child below AGENTLAS_AGENT_HOME or, by default, ~/.agentlas/agentlas-agent. Existing children are never overwritten. It then shows a generalized session report for your review, turns the approved method into a standalone agent prompt and package, registers it locally, and runs the normal verification gates.

You do not need to export JSON for this interactive route. JSON/JSONL remains an explicit option for terminal, replay, and headless workflows only. The default output is a single agent; choose a team explicitly. Raw transcripts, hidden prompts, credentials, private paths or URLs, screenshots, and literal tool arguments/results are not carried into the generated package. Uploading to Agent Cloud or the public Hub is a separate, explicit choice. See the session build contract for the deterministic export boundary.

current conversation
  -> destination question
  -> generalized session report
  -> owner review
  -> standalone agent/package
  -> local registration and verification

#The package contract — what every build must emit

An agent package is not a worker with capabilities. It is a method document. Three layers, and conflating them is the single most expensive mistake this project has made:

"Can this agent read the web?" is a category error. The runtime reads the web. The only question a package can answer is what method does it carry, and what must the machine be able to do for that method to run.

package-contract.json is the machine-readable list of artifacts every build emits, and scripts/verify-generated-package.sh <folder> is what enforces it. A build that omits a required artifact fails; it does not ship. Four of those artifacts carry the routing contract:

contracts/intake.schema.json     what a requester must hand over before work starts
contracts/output.schema.json     what the requester ends up holding
contracts/output.example.json    one real instance, validated by a JSON Schema
                                 validator at publish time — never by a model
.agentlas/brief.json             the compiled resume, schemaVersion agentlas.brief/1

Direction lives in the filename because nothing else ever marked it, and a schema whose direction must be guessed cannot be matched against a request.

Two rules bind every enum a build writes. Both were paid for in production:

1. Any enum reachable from matching must carry an escape member ("other", "unknown"). Matching one stated requirement against a 23-word closed list took a three-candidate inventory to zero on eight probes out of eight. A publisher whose real case is not on the list must still be findable.
2. Sentences stay sentences. No field that holds an author's sentence may be split into terms for matching. Shredding refusal sentences into the bare words tests and ci cut a correct agent's score to a quarter and pushed it from rank 2 to rank 24 — on a query that was literally its own job.

Vendor and MCP names live in exactly one place, host[].preferred, and that field is display-only. Roughly 99.9% of machines have no MCP servers installed, so a package wired to its author's own Slack, Notion or Jira has to stay usable by everyone else: the matcher reads host[].capability ("open the page in a real browser and read what a user would see") and every requirement states withoutIt, what the method still does on a machine that lacks the facility.

agentlas.brief/1 is written from either side — side: "offer" is the package's resume, side: "need" is the requester's work order. The same form, so the two can be compared without a translation step. Its schema is schemas/agentlas-brief.schema.json, and it is compiled, never hand-written: the upload path writes it from the files the package already ships.

provenance is the part that keeps the rest honest. absent is a legal value that scores zero, so a gap stays a gap. Filling gaps with something plausible is how capabilities came to equal snake_case(agent.md ## Responsibilities) in 130 of 130 packages — a field that was always full and never once informative.

The reference shape is Web_master: it ships input and output contracts as real JSON Schema, a domain catalogue its rules are checked against, and verification scripts that run. Everything above is what a build has to emit to be readable the way that package already is.

Deliberately absent: there is no field for what an agent is good at, and none for its permissions. Quality cannot be read off a package that has never run, and permissions are granted by the host after the fact — an employer hands you a computer once you are hired, so neither says anything about whether this method fits the work.

#Hub and Agent Cloud are different scopes

Agentlas maps agent work to operating-system-like responsibilities without forcing your work into one model provider:

_{Figure 1. Request shaping, four builders, generated package contracts, memory curation, skill lifecycle, runtime adapters, and sync boundaries.}

Agents generated from vague, single-sentence prompts fail under real-world edge cases. Hephaestus v1.1.0 positions task specification as a first-class OS service through the Briefing Interview Engine:

The current v1.2.47 release carries the resolved Work Brief through host-owned Network 2.0 selection, exact release pinning, and server-first tool discovery.

• Quantitative Ambiguity Gates: The compilation scheduler evaluates prompt clarity across four key vectors (Goal, Constraints, Scope, Context). The build process is strictly gated until the ambiguity score passes a numeric threshold (ambiguity score $\le 0.2$, with per-dimension safety floors). Clear prompts bypass the interview loop entirely via a budget system that caps questions for trivial tasks.
• Lens-Driven System Analysis: Clarifying questions are dynamically sourced from a structured lens table (Scope, Intent, Challenge, System Architecture) focusing on critical routing indicators: anti-scope bounds (what the agent must NOT do), verifiable acceptance criteria, and exit conditions.
• The Work Brief: Resolved details are frozen into .agentlas/work-brief.json—recording the validated goal, concrete constraints, an assumption ledger with source tags, and the metadata ambiguity score.
• Contextual In-Flight Briefs: The CLI tool cards migrate automatically maps brief details directly to triggers and anti-triggers on the agent's routing card. Running route --brief propagates this brief to all Stormbreaker execution packets, ensuring constraints and exit conditions govern parallel subprocesses across the entire lifecycle.
• Enhanced Routing Discrimination: Prevents same-topic/different-intent collision (e.g., a security agent intercepting a deployment prompt) via double-sided gating: interview-validated anti-triggers on the routing card, and low-confidence LLM re-ranking escalation inside the router.

#Manual LLM Adapter Install

Use this only when your current LLM cannot run setup for you. It installs the shared Hephaestus runner and command adapters for supported LLM tools.

xcode-select --install   # Command line tools (skip if already installed)
git --version            # Confirm git is available
curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | bash

This installs the neutral runner at ~/.agentlas/runtime/current/bin/hephaestus and registers the command adapters for Claude Code, Codex, Gemini CLI, Antigravity, Cursor, OpenCode, OpenClaw, Hermes, and compatible local/API hosts. The installer verifies each runtime surface after registration.

Desktop startup and every /hep-* command start the same digest-verified, rate-limited update check in the background. The current command never waits for network or installation work. A successful update atomically moves ~/.agentlas/runtime/current and reconciles every already-installed host adapter; the next command or reloaded session uses the new release. Releases v1.1.63 through v1.1.68 briefly installed a separate six-hour OS scheduler. Current installs remove that retired scheduler automatically.

Offline or air-gapped install: set HEPHAESTUS_SOURCE_DIR=/path/to/checkout before running the installer to skip the GitHub release download and verified checksum step entirely and install straight from a local Agentlas-OS checkout instead, e.g. HEPHAESTUS_SOURCE_DIR=$(pwd) bash scripts/install-all-runtimes.sh. Use it when you already have the source on disk (a git clone or an already-extracted release) and want a fully local install.

#Optional Global Router

hephaestus global install

This appends a managed marker block to ~/.codex/AGENTS.md, ~/.claude/CLAUDE.md, and ~/.gemini/GEMINI.md. It is an optional host adapter, not the owner of an Agentlas One session or a Desktop Work project. For substantial work, Network is one explicit federated source scope (local + cloud + hub): the host model selects exact releases from the returned menu and validates them. It never routes by keyword, silently substitutes a different agent, or treats Cloud, Hub, Local, and skills as semantic fallback tiers. The command is idempotent and keeps a timestamped backup before editing.

The installed router prompt asks the host to report results by the workers that did the task rather than narrating the routing step — it is a conciseness convention, not a secrecy one, and it says so. It carries an explicit status-line contract for English and Korean sessions:

Global router command reference:

The independent Agentlas Terminal owns the agentlas shell command. The Core installer intentionally leaves that command untouched and removes only the exact legacy Core alias it created in older releases.

#Per-Runtime Plugin Drivers

claude plugin marketplace add https://github.com/agentlas-ai/Agentlas-OS --sparse .claude-plugin claude/plugins
claude plugin install hephaestus@agentlas-core-engine

codex plugin marketplace add agentlas-ai/Agentlas-OS --ref v1.2.47
codex plugin add hephaestus@agentlas-core-engine

Just talk: After installation, speak in plain language within native Agentlas interfaces to auto-route tasks. In external LLM tools, use the explicit commands listed below. When you don't know what agents exist, start with /agentlas search. To connect Telegram, use /agentlas connect.

One word to remember: everything starts with agentlas — /agentlas in an LLM host, agentlas in a shell.

Inside native Agentlas environments, Hephaestus operates commandless. External LLM tools use a deliberately small visible command set. System-level utilities like Stormbreaker, research loadouts, and configuration tables attach automatically from context:

/hep-orch sets which model runs the orchestrator and which runs the workers, so a fan-out of mechanical work does not bill frontier runs. The split only puts two models to work on Claude Code, which is the one host that spawns a real subagent and takes a model per subagent. Codex, Gemini/Antigravity, Cursor, and OpenCode have no subagent of their own: one model plays every role in sequence there, the allocation receipt is still written, and the ceiling still bounds what that model may request — but no second, cheaper model appears.

Every row also answers to its original /hep-* name — /agentlas network and /hep-network are the same command. Nothing was renamed away, so existing scripts, notes, and muscle memory keep working. Current Codex uses explicit plugin skills $hephaestus-build, $hephaestus-network, $hephaestus-cloud, $hephaestus-upload, $hephaestus-storm, and $hephaestus-graph; other MCP surfaces can be requested in plain language. Custom /prompts:* commands were removed from Codex 0.117+.

#Meta-Agent Factory — Process Creation

A unified compilation factory using four builders. Every generated package registers its global command (.agentlas/global-commands.json) and ships verification scripts—the user never has to infer how to run the compiled package:

Briefing Interview Gate: Builders initiate the process using the briefing interview gate : conducting lens-driven questions, evaluating the ambiguity threshold, searching primary sources, and outputting the work brief.

#Network 2.0 — The Scheduler

_{Figure 2. A2A scheduling: explicit host commands, model-selected exact releases, local memory, and federated Agentlas Network discovery.}

• Typed Job Analysis: The active host LLM turns the request into a redacted WorkOrder with explicit roles, skills, tools, artifacts, authority, cardinality, and handoffs. Core does not infer staffing intent from a substring list.
• Exact Source Federation: local, cloud, and hub are exact scopes; network is their sealed union. Each source returns a bounded, content-only menu, and Core records unavailable sources instead of silently widening scope.
• Host-Owned Task Forces: The host LLM reads the qualification evidence and authors the exact Selection. Core never chooses a deterministic winner or performs a hidden Router Agent re-rank; it validates governance, privacy, identity, cardinality, and graph integrity.
• Pinned Execution: After validation, Core fetches only the selected immutable releases from their original source sessions and verifies release, package, and content digests before distinct planner, worker, synthesis, and verifier invocations run.
• Evidence-Scored Evaluation: Retrieval coverage, host selection, immutable preparation, real child invocations, and final verification are scored as separate claims. A benchmark result never replaces the host staffing decision or turns usage history into routing authority.

#Execute a prepared goal from an external host

An explicitly selected host plugin or executable can run the newest ready plan bound to a Workforce goal through the provider-neutral adapter contract:

./bin/hephaestus workforce execute \
  --project . \
  --goal-id <host-task-id> \
  --adapter-argv-json '["/absolute/path/to/host-adapter"]'

The adapter reads one versioned JSON request from standard input and writes one JSON response to standard output for inventory observation and each required orchestrator, planner, worker, synthesis, and verifier invocation. Core retains the exact preparation pins, verifies and snapshots output artifacts locally, and returns an execution receipt only after the existing receipt validator accepts the complete run. The adapter owns its provider authentication and native runtime configuration as an independently installed plugin; do not put credentials in the argv JSON. The complete v1 request, response, artifact, and failure contract is documented in agentlas_cloud/workforce/host_executor.py.

Tool inventory distinguishes native host enforcement (host-native) from a host-owned tool dispatcher (host-broker). A bound tool requires its invocation receipt to use that same enforcement path; neither label grants authority to a package that did not select the host permission policy.

#Stormbreaker — Disciplined Execution

Stormbreaker is the execution gating subsystem of the Agent OS. It ensures that agents do not report success or terminate until all outcomes have been verified by deterministic checks:

Kernel Gating Envelope:
[Scope Lock] -> [Decomposition] -> [Parallel Work Packets] -> [Verify Contracts] -> [Bounded Repair] -> [Final Gate]

A local run journal makes long executions resumable after interruption. Execution packets carry the Work Brief so that anti-scope rules and exit criteria govern all parallel subprocesses. Stormbreaker reports explicit completion states (verified / unverified / blocked) to prevent autonomous completion theater.

#Ontology Runtime — The Knowledge Filesystem

For knowledge-intensive operations, bin/ontology acts as the semantic filesystem, converting unstructured local files into an agent-readable database stack:

Ingested Files -> [Parser Adapter] -> [CJK trigram/bigram tokenization] 
  -> [FTS5 + SQLite Storage] -> [Reciprocal Rank Fusion Ranking] -> [GraphRAG Search]

Features first-party Korean document parsing (HWPX and legacy HWP5) with zero GPL dependencies. Fully local and SQLite-backed; confidential and private chunks are isolated, preventing them from reaching external cloud hooks.

The current release contract ships and verifies the dependency-free potion-multilingual-128M-int8 Model2Vec asset as the primary semantic adapter. Its pure-Python Unigram runtime returns a normalized 256-dimensional semantic vector. Runtime queries never download a model or call a hosted embedding API. Hash-96 mode is an explicitly reported degraded fallback when the verified local asset is missing or rejected, not an alternative silent default.

The current self-updater installs the complete one-touch runtime payload, including Career Graph, templates, and the verified model under the versioned models/model2vec/potion-multilingual-128M-int8 directory. It checks that payload before and after switching ~/.agentlas/runtime/current, then repairs merge-safe memory hooks for detected hosts without replacing unrelated user configuration.

Agent experience recall is a governed path, not an unrestricted nearest-vector search:

exact agent + allowed scope + active status + unexpired + not superseded
  -> lexical rank + local cosine rank
  -> reciprocal-rank fusion + bounded salience prior
  -> all relevant memories when they fit, otherwise budgeted top-k

Experience recall scores a deterministic newest-first window of at most 5,000 governance-eligible rows before token-budget selection. When more rows are eligible, the response is explicitly partial with a truncated scan receipt; older evidence outside the bounded window may require a narrower query or projection rebuild. Each Hub agent has a rebuildable private projection at ~/.agentlas/networking/hub-agents/<normalized-slug>/memory/experience.sqlite. The runtime may infer only same-agent, same-scope similar_to edges from local cosine similarity; supersedes and contradicts require an explicit curator decision.

bin/ontology ingest ./corpus --scope internal
bin/ontology --db .agentlas/ontology-runtime.sqlite query "Project Helios Memory Curator" --agent verifier
bin/ontology --db ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite experience query "What did we learn?" --agent hub:<slug>
bin/ontology memory candidates

Plain Claude Code and Codex sessions receive bounded recall through SessionStart and UserPromptSubmit additional context. Antigravity uses a PreInvocation ephemeral message, OpenCode uses an experimental local plugin, and Grok refreshes a workspace-scoped cache because its passive hooks do not inject stdout. These hooks supplement live AGENTS.md/CLAUDE.md policy rather than copying it.

#Governed Memory — Curated Promotion

• Local Project Memory: Project documents remain in the local .agentlas/ontology-runtime.sqlite; borrowed-agent experience remains in its exact per-agent projection. The two stores share one query engine without collapsing their scope or ownership boundaries.
• Governance Before Ranking: Exact agent, allowed privacy scope, active status, expiry, and structural supersession are enforced before lexical/cosine ranking. Secret redaction and capsule bounds are applied again before host delivery.
• Workspace Personalization: Manages summaries, playbooks, plugin locks, and receipts for borrowed Cloud/Hub agents without storing raw prompts, credential values, or private files.
• Curator Gating: Skills and durable memory modifications remain candidates until a local curator confirms evidence, rollback coverage, and security policy approval. Automatic experience relations are limited to similar_to.

#A2A Boundary — Inter-Agent Isolation

Standardized CLI commands allow safe inter-agent coordination:

agentlas-cloud ao a2a import ./agent-card.json .
agentlas-cloud ao a2a export . --agent local/10-builder
agentlas-cloud route "run the release check" --caller local/orchestrator .

Import acts as a proposal (restricting automatic invocation), export redacts private paths and logic, and invocations are caller-gated before routing is resolved.

Hephaestus packages agents into a standard directory layout that any workspace runtime can parse, install, verify, and run. The important part is not just agent.md; it is the operating contract around it:

├── AGENTS.md                              # Canonical operating loop and source-of-truth map
├── agent.md / agents/                     # Single worker, HQ/orchestrator, or team roles
│   ├── 10-single-agent-builder/
│   ├── 20-multi-agent-team-builder/
│   ├── 30-agentlas-packager/
│   └── 40-session-agent-builder/
├── .agentlas/                             # Agentlas OS system directory
│   ├── sitemap.json                       # Product graph: modes, runtime adapters, memory, release checks
│   ├── mode-map.json                      # Single-agent / team / packager classification contract
│   ├── routing-card.json                  # Triggers, anti-triggers, capabilities, risk, routing readiness
│   ├── agent-card.json                    # A2A-facing identity and capability card
│   ├── company-blueprint.json             # Team/company topology for multi-agent packages
│   ├── global-commands.json               # Runtime command aliases and install surfaces
│   ├── memory-map.json                    # Memory roots, write owners, trust labels, exclusions
│   ├── memory-tickets.jsonl               # Candidate memory events before durable promotion
│   ├── project-soul-memory.md             # Project-level operating memory
│   ├── curator-decisions.jsonl            # Memory Curator promotion/rejection decisions
│   ├── vault-references.json              # Secret/credential references without raw values
│   ├── validation-ledger.jsonl            # Verification and release evidence
│   ├── field-test-report.json             # Field test results for package readiness
│   ├── skill-registry.json                # Reusable skill inventory and lifecycle metadata
│   ├── skill-trials.jsonl                 # Skill trial evidence before promotion
│   └── agent-ontology/                    # Local code/agent map for capabilities, artifacts, scopes, edges
├── skills/                                # Canonical reusable skills
├── modes/                                 # Mode contracts for build/package behavior
├── schemas/                               # JSON schemas for cards, memory maps, sitemap, evals, manifests
├── templates/                             # Package, memory, interview, eval, ontology, and contract templates
├── ontology/ + bin/ontology               # Local-first parser/search/GraphRAG runtime
├── agentlas_cloud/                        # Hub/Cloud bundle, routing, update, and runtime APIs
├── .claude/ codex/ .gemini/ .agents/      # Thin runtime adapters over the same core
├── claude/ codex/ gemini/ antigravity/    # Plugin/extension/workflow distributions
├── cursor/ hermes/ openclaw/              # Additional runtime shims and skill mirrors
│   ├── source-of-truth.md
│   ├── chain-map.md
│   ├── memory-architecture.md
│   ├── ontology-runtime.md
│   ├── hephaestus-network-2.0.md
│   └── builder-interview-research-gate.md
└── scripts/                               # Verification, installer, sync, release, and public-safety gates
    ├── verify-package.sh
    ├── verify-ontology-runtime.sh
    ├── verify-routing-cards.sh
    ├── sync-adapters.sh
    └── public_safety_check.sh

That package shape is why an Agentlas agent is more than an LLM-written role prompt. It carries routing, memory, sitemap, code/agent ontology, permissions, runtime adapters, verification ledgers, and release gates together.

#Dependency-aware project context

Hephaestus keeps the project map local. The explicit context refresh writer creates a content-addressed snapshot; passive reads then hand each concrete task only the goals, constraints, definitions, backlinks, interfaces, and related files it structurally depends on.

Passive MCP context reads remain write-free, but they recompute the same bounded file-list fingerprint before returning indexed data. If code, verification, CI, or version-contract inputs changed—or the freshness scan cannot complete—the read returns context_map_stale or context_freshness_incomplete with a refresh=true retry instead of returning old symbols as status=ok.

The v3 manifest retains the Code Map v2 compatibility projection and carries an agentlas.verification-map.v2 graph. Search-only lexical backlinks are kept separate from completion-gating dependency edges. Blocking edges come from resolved imports, explicit package commands, CI workflows, and version scopes; generated releases, embedded runtimes, and declared mirrors are not rescanned as canonical source. Every safe project file is inventoried by role, so docs, config, and prior-snapshot deletion tombstones are valid change inputs.

context impact returns source review obligations separately from test/CI and release obligations. context verify passively reuses the same fresh snapshot, and --verified records an actually executed test path or exact command/CI ID. Putting a test in --reviewed or --waived never masquerades as execution. Local and CI are alternatives, not duplicate requirements. Version contracts remain a separate release responsibility, and a missing test reference blocks the CI channel that owns it until the workflow is fixed or explicitly waived. Local test files and fixtures may remain Git-ignored and excluded from public runtime archives; the project-local map still fingerprints and links them so local execution is a real selectable channel rather than invisible state.

hephaestus context refresh --project .
hephaestus context refs resolveHubEntityKind --project .
hephaestus context slice --project . --task "fix entity kind routing" \
  --target src/package-kind.ts --render
hephaestus context impact --project . --changed src/package-kind.ts
hephaestus context verify --project . --changed src/package-kind.ts \
  --reviewed src/register/route.ts \
  --verified tests/test-package-kind.ts

Claude and Codex receive the task slice from their local hook and get a reverse-reference warning immediately before edit tools. Desktop, Terminal, Stormbreaker, and Workforce call the same Core implementation. Network/Cloud search and bundle fetches remain redacted and never receive local source paths or Context Map contents.