@sporhq/spor 0.9.0 → 0.10.0

package/.claude-plugin/plugin.json

@@ -2,6 +2,6 @@
   "name": "spor",
   "displayName": "Spor Context Compiler",
   "description": "Maintains a typed, versioned knowledge graph and compiles compact briefings from it: session-start injection, per-prompt relevance digests, capture at discovery, end-of-session distillation, decision queue.",
-  "version": "0.9.0",
+  "version": "0.10.0",
   "author": { "name": "losthammer" }
 }

package/API.md

@@ -117,12 +117,21 @@ changes the description without a deploy.
 ### `add_edge`
 
 Micro-mutation. Input `{ "id": "<node>", "type": "<edge type>",
-"to": "<target>" }` — accepts canonical, alias, and inverse forms; inverse
-forms are flipped onto the target before writing. No revision echo is needed.
-Output `{ "status": "updated|skipped", "id": <node actually modified>,
-"revision", "warnings" }` (`skipped` = edge already present — the call is
-idempotent). Both nodes must exist. The tool description carries the same
-registry-generated vocabulary as `put_node`.
+"to": "<target>", "attrs"?: { "<k>": "<v>" } }` — accepts canonical, alias, and
+inverse forms; inverse forms are flipped onto the target before writing. No
+revision echo is needed. Output `{ "status": "updated|skipped",
+"id": <node actually modified>, "revision", "warnings" }` (`skipped` = edge
+already present — the call is idempotent). Both nodes must exist. The tool
+description carries the same registry-generated vocabulary as `put_node`.
+
+The optional `attrs` carries trailing flat edge attributes — the per-assignment
+`profile:` override on an `assigned → agent` edge is the motivating case. Values
+round-trip only simple `[A-Za-z0-9_-]` tokens (the frontmatter edge grammar);
+richer values need `put_node`, and `type`/`to` are reserved. With `attrs`, a
+duplicate `(type, to)` becomes an **upsert**: same attributes → still `skipped`;
+different attributes → the edge's attribute set is replaced (not merged) in
+place. Omitting `attrs` never touches an existing edge's attributes, so a bare
+`add_edge` is unchanged.
 
 ### `set_status`
 
@@ -301,9 +310,9 @@ endpoint is the REST twin of a core call:
 | `GET /v1/me` | `spor whoami`/`status`, onboarding | identity echo for the bearer token → `{person, name, email, bound, is_admin}`. `bound:false` means the token authenticates but maps to **no person node** (legacy/OAuth, or minted before the node existed), so routed questions and the personal queue will be empty — the client warns on it (the silent identity-degradation signal). `is_admin` reflects the `stewards→root` edge that gates the token-admin surface |
 | `GET /v1/briefing/{project}` | session-start | read the `brief-<project>` node → `{found, version, body, project_brief?, graph_status}`. The slug resolves through project-node aliases (GRAPH.md "Project identity nodes") before lookup. A BARE repo slug also rides up to its home-project grouping: the grouping's `brief-<grouping>` node returns alongside as `project_brief` (the product context spanning sibling repos), matching the shared up-resolution (dec-spor-queue-slug-resolves-to-grouping); passing the repo NODE id (`repo-<slug>`) is the escape hatch that returns only the repo brief, no `project_brief`. Optional `?fp=root:<sha>,remote:<host/path>,...` carries the repo's fingerprints: the server learns them onto the owning project node, and an unknown slug with a known fingerprint files an alias proposal in the queue |
 | `POST /v1/digest` `{query, root?, project?, min_sim?}` | prompt-context, /spor:brief | digest-mode compile → `{found, text}`; `found: false` is a successful empty result. `root` is the structural-walk twin of `query` (the two are mutually exclusive; `root` wins, an unknown id is `422`). Optional `project` is the session slug: the server scopes the compile to it — the same-project relevance boost, the grouping union, and the `always_on` norm `applies_to_*` ride-along — resolving the slug through project-node aliases/groupings inside compile (dec-spor-queue-slug-resolves-to-grouping), exactly as `/v1/queue` does. A bad slug is `422`; **omitting `project` runs the digest project-blind (byte-identical to before)**, so older clients that send only `{query}` are unaffected |
-| `GET /v1/nodes/{id}` | /spor:brief | `get_node` semantics; when a live inbound resolves/answers edge contradicts a still-open status the response carries `resolution`, and open gardener findings about the node ride along as `open_findings` |
+| `GET /v1/nodes/{id}` | /spor:brief | `get_node` semantics; a live inbound resolves/answers edge rides along as `resolution` (carrying the resolver's `summary`/`title` and a `lagging` flag — set when it contradicts a still-open status, clear when the node is already terminal, e.g. an answered question pointing at its answer), and open gardener findings about the node ride along as `open_findings` |
 | `POST /v1/nodes` | drain-outbox, mechanical writers | `put_node` semantics, batch: `{nodes: [...], if_exists: "skip"}` (entries may be raw strings or `{node, if_exists, revision}`) → `{results: [...]}`, 207 when any entry failed |
-| `POST /v1/nodes/{id}/edges` `{type, to}` | scripts, mechanical writers | `add_edge` semantics (§1): normalize/flip, dedupe, append — no revision echo |
+| `POST /v1/nodes/{id}/edges` `{type, to, attrs?}` | scripts, mechanical writers | `add_edge` semantics (§1): normalize/flip, dedupe, append — no revision echo. Optional `attrs` adds trailing flat edge attributes (e.g. a per-assignment `profile:` override); re-adding the same edge with different attrs upserts the set |
 | `POST /v1/nodes/{id}/status` `{status}` | scripts, mechanical writers | `set_status` semantics (§1): one-scalar update through the `transitions()` gate. Setting a work node to an in-progress status also CLAIMS it (same lease as `/claim` below) |
 | `POST /v1/nodes/{id}/claim` `{session?}` | `claim`/`set_status` MCP tools, `spor dispatch` | take the heartbeat-renewed lease (dec-cc-task-claim-lease): writes the durable `assigned` edge once, attributes to `$viewer` from the token (never an argument), and creates the ephemeral lease → `{ok, status, lease: {node_id, by, expires, expires_at, session, claimed_at}, edge}`. A live lease held by ANOTHER person is `409 conflict` naming the holder + expiry (re-claiming your OWN live claim just renews it). `session` scopes the heartbeat (omit to leave it person-scoped, so any of the claimer's sessions may renew — what `spor dispatch` does at the PRE-launch claim, since `claude --bg` self-allocates the run session only at launch; dispatch then renews with the real session once it has read it from `claude agents --json`, dec-spor-dispatch-bg-session-late-bind) |
 | `POST /v1/nodes/{id}/renew` `{session?}` | post-tool heartbeat, `renew` MCP tool, `spor dispatch` | bump the live lease's expiry only — no commit; the heartbeat that keeps a claim from lapsing. A lapsed/stolen lease is `409` (names the current holder). Person-scoped: any of the claimer's sessions may renew; a `session` binds the lease to that run (`spor dispatch` uses this to bind the captured `claude --bg` session post-launch) |

package/GRAPH.md

@@ -58,7 +58,10 @@ Rules:
   omit them.
 - Edges may point at ids that don't exist yet; the compiler skips them. Don't
   delete an edge just because the target is missing — it marks a node worth
-  creating.
+  creating. An edge may also carry extra flat attributes after `to:` —
+  `- {type: assigned, to: agent-X, profile: profile-Y}` — preserved on the edge
+  object (the per-assignment profile override; see "The agent orchestration
+  layer"). Plain `{type, to}` edges are unchanged.
 - `commits` is an optional inline list of repo-qualified git shas
   (`commits: [wf@1a2b3c4d, ...]`, kebab-case repo slug + 7–40 hex) linking
   the node to the code commits that implement it (task-cc-commit-linking).
@@ -95,6 +98,8 @@ Rules:
 | question   | `question-` | a routed ask the graph could not answer (queueable; status `open`/`answered`, gated) |
 | person     | `person-` | a member of the org — the identity anchor for `$viewer` binding and Tier-2 question routing (team mode; see "People, routing, and onboarding") |
 | agent      | `agent-`  | a person-owned automation principal — a dispatched session's durable identity, owned by a person via an `owned-by` edge; its writes attribute "agent on behalf of person" (see "Agents") |
+| profile    | `profile-`| a reusable runtime+capability bundle an agent runs under: `harness`, `model`, `skills`/`plugins`/`mcp`. Its runtime fields ARE the dispatch satisfiability spec; `capturable: false` (see "The agent orchestration layer") |
+| routine    | `routine-`| owner-scoped trigger→action automation (`owned-by` a person): declarative `when → do` rules over graph events that dispatch only the owner's agents, AND-ed with org policy; `capturable: false` (see "The agent orchestration layer") |
 | capture-pending | `cap-` | raw captured text that fit no schema; filed by the server for later triage (QUEUE.md §2.3); born status-less, closed only as `merged` (content now in proper node(s)) or `rejected` (no durable fact) — a `transitions()` gate rejects other statuses at write time |
 | finding    | `find-`   | a gardener observation about another node, filed as a queue item (QUEUE.md §6) |
 | repo       | `repo-`   | durable git-repo identity: slug aliases + repo fingerprints; heals renames at read time (below) |
@@ -606,6 +611,112 @@ edges:
   mirroring `person`, `repo`, and `workflow-run`. (So the distiller's emit
   vocabulary deliberately omits `agent`/`owned-by`.)
 
+## The agent orchestration layer
+
+The layer ABOVE agent identity (dec-spor-agent-orchestration-layer): how work is
+routed to agents, and how per-person automation fires on graph events. The node
+model is `person ──owns──▶ agent ──uses-profile──▶ profile`, with owner-scoped
+`routine` nodes driving automation. It composes with — never bypasses — the org
+policy layer. The schemas ship in the seed pack; the dispatch matcher, the
+routine engine, and the remote fleet scheduler are deferred
+(task-spor-dispatch-capabilities-satisfiability).
+
+### profile — the reusable runtime+capability bundle
+
+A `profile` node (prefix `profile-`) is "the HOW" an agent dispatches under,
+factored out of the agent node so a toolset is reusable across agents and people.
+
+```markdown
+---
+id: profile-docs-writer
+type: profile
+title: Docs-writer profile
+summary: Claude-code on Opus with the writing + spor skills and the spor MCP server.
+harness: claude-code
+model: opus
+skills: [writing, brief]
+plugins: [spor]
+mcp: [spor]
+status: active
+date: 2026-06-18
+---
+```
+
+- `harness:` (`claude-code` | `codex` | `opencode` | …) selects the launcher
+  (dec-cc-portable-core-adapters: claude-code → `claude --bg`, others → their
+  CLIs); `model:` → the harness `--model`; `skills`/`plugins` are preloaded;
+  `mcp` is merged into the strict `--mcp-config` dispatch writes, so the agent's
+  toolset is exactly the profile plus the agent-spor server, nothing ambient
+  (dec-spor-session-identity-active-record).
+- **The runtime fields ARE the satisfiability spec** — there is no separate
+  requirements block (dec-spor-machine-profile-satisfiability). A machine
+  declares ATOMIC capabilities in a machine-local `dispatch.capabilities` map
+  (built like `dispatch.repos`, never committed), and `satisfies(machine,
+  profile)` checks `profile.harness ∈ machine.harnesses ∧ profile.mcp ⊆
+  machine.reachable_mcp ∧ profile.skills ⊆ machine.skills ∧ profile.plugins ⊆
+  machine.plugins ∧ profile ∉ machine.deny`. No satisfying machine → dispatch
+  fails soft and LOUD, leaves the assignment intact, NEVER substitutes a
+  different profile. Forward-compatible with the deferred remote fleet scheduler
+  (each agent publishes its capabilities; same vocabulary).
+- **Reusable + both-scoped, with override.** Profiles are PERSONAL and
+  ORG-PUBLISHED (a curated, vetted toolset), with personal override. Org-published
+  profiles are where this meets policy: a policy can require that work of a risk
+  class go to an agent whose profile is org-approved (curated-toolset-as-governance).
+- `status:` is declarative (`active` default); `capturable: false` (created
+  deliberately, never distilled).
+
+### routine — owner-scoped trigger→action automation
+
+A `routine` node (prefix `routine-`), `owned-by` a person, holds declarative
+`when → do` rules. Triggers are graph events (a status change — e.g. to a
+resolving state, or to `done` — or an edge like `reviewed-by`/
+`changes-requested-by`) with `where:` filters; actions are the bounded verb set
+`create-node` / `assign` (to a SPECIFIC agent, optionally with a `profile:`
+override) / `dispatch` / `set-status` / `reassign` / `escalate`. Because the
+regex frontmatter parser is flat, an instance carries its `rules` as a fenced
+` ```json ` block in its BODY, parsed by the deferred routine engine.
+
+Two invariants (dec-spor-agent-orchestration-layer): (1) **only the owner's
+agents are ever dispatched** — the `person → routine → agent` RFC 8693 act-chain
+is the audit trail; (2) **personal routines accelerate, org policy gates — they
+AND, never bypass** — agent-on-behalf-of-X counts as X for the self-approval ban
+and the definition-of-done quorum, so an owner's reviewer-agent cannot
+auto-approve their implementer-agent's work past the org bar. Per
+dec-spor-orchestration-routine-requires-threads (thread 1) the bounded
+declarative register ships FIRST; attached sandboxed code is a later
+schema-gated escape hatch. The routine ENGINE and its vetting (dry-run, mandatory
+retry budget, self-approval-floor activation review, fire-time org-policy gate —
+thread 2) are deferred, so this seed schema is declarative and UNGATED;
+`capturable: false`.
+
+### Routing is explicit assignment; the profile cascade
+
+Routing is EXPLICIT `assigned` to a SPECIFIC target, not an eligibility match:
+`assigned → person` is human work (the default human pool); `assigned → agent-X`
+makes the task a dispatch candidate (X's profile says how and what it may touch).
+An agent-targeted `assigned` edge may carry an optional `profile:` attribute —
+the durable per-assignment override (`{type: assigned, to: agent-X, profile:
+profile-Y}`, thread 3). Profile precedence, explicit wins: `--profile` dispatch
+flag > assignment-edge `profile:` attribute > the agent's default `uses-profile`
+edge.
+
+### The `requires:` risk-class register
+
+`requires:` is a flat list on a WORK node naming the risk/permission classes the
+work may touch (`requires: [shell, prod-creds]`). It is a **registry-declared
+extensible enum** — a `type: schema` node with `kind: register` and `register:
+requires` (seed: `schema-requires`), so an org grows the vocabulary by editing a
+schema node, never a code change. The kernel exposes it as a partition
+(`graph.registry.requiresClasses()`); it stays policy-free. The register is
+**DISTINCT from machine-satisfiability**: satisfiability asks "can this box LAUNCH
+the profile"; `requires:` asks "what may this work touch", validated against the
+assigned profile (a task's `requires:` must be ⊆ the profile's granted classes,
+else warn/refuse) and gated by org policy via the same governs-traversal the
+definition-of-done quorum uses (dec-spor-orchestration-routine-requires-threads
+thread 4). The seed set is small — `shell`, `prod-creds`, `browser`, `network`,
+`human`, `filesystem-write`, `paid-api`. `human` is unsatisfiable by any agent:
+assign that work to a person.
+
 ## Edge types and traversal weights
 
 | edge             | weight | meaning                                          |
@@ -618,7 +729,7 @@ edges:
 | `resolves`       | 0.9    | this node fixes/closes the target                |
 | `blocks`         | 0.7    | target cannot proceed until this node does       |
 | `answers`        | 0.7    | this node answers that question (inverse `answered-by`); pulls the answer through the asker's next compile |
-| `assigned`       | 0.5    | work is assigned to this person                  |
+| `assigned`       | 0.5    | work is assigned to this person OR agent (the explicit-routing edge; an agent target may carry a `profile:` per-assignment override) |
 | `reviewed-by`    | 0.5    | this person reviewed and approved the node — counts toward a policy quorum |
 | `changes-requested-by` | 0.5 | this person reviewed the node and requested changes — not an approval |
 | `relates-to`     | 0.5    | weak association                                 |
@@ -626,6 +737,7 @@ edges:
 | `stewards`       | 0.4    | this person stewards an area/spec/norm — the Tier-2 question-routing key |
 | `grouped-under`  | 0.3    | this repo's home project grouping (inverse `groups`); structural membership, not work dependency |
 | `owned-by`       | 0.3    | this agent is owned by that person (inverse `owns`); structural identity binding, not work dependency |
+| `uses-profile`   | 0.3    | this agent's default profile (the runtime+capability bundle it dispatches under); structural config binding, overridable per assignment/dispatch |
 | `routed-to`      | 0.3    | a question routed to this person for answering   |
 | `review-requested` | 0.3  | a review of this node is requested of this person (pending) — surfaces in their queue |
 | `compiled-for`   | —      | briefing → its task/query (provenance only)      |

package/QUEUE.md

@@ -142,6 +142,15 @@ is the default and graph-resident schema nodes override/extend it. The
 `schema` node type itself is recognized natively by the core — no
 schema-for-schemas regress.
 
+Beyond `node-schema`/`edge-schema`, a schema node may carry a non-type `kind`:
+`policy` (the org-defined policy layer, §below), `queue-policy` (the ranking
+override singleton), and `register` — a registry-declared extensible **enum**
+the kernel exposes as a partition (`graph.registry.register(name)` /
+`requiresClasses()`) instead of a hardcoded table. The seed `requires` register
+(`schema-requires`, the work-node risk/permission axis) is the first; an org
+grows the vocabulary by writing a resident `kind: register` schema with the same
+`register:` name (graph beats seed, higher CalVer wins — like every other kind).
+
 Resolution is **graph beats seed wholesale, regardless of version**: a
 resident override replaces the seed entry for that type entirely, so a seed
 behavior change (a new `transitions()` gate, a default, a prefix) does *not*

package/bin/spor.js

@@ -2088,21 +2088,39 @@ async function compileBriefing(cfg, { nodeId, query, full, project }) {
 async function topQueueItem(cfg, slug) {
   const LIMIT = 25;
   let items = [];
+  // --from-queue dispatches an AGENT to do work, and questions are human
+  // decisions — not agent-dispatchable (the standing model: agent-actionable
+  // work is a task, not a question; dec-spor-questions-human-not-agent-dispatch).
+  // Exclude them AT THE RANKER (the issue's preferred fix,
+  // issue-spor-dispatch-from-queue-dispatches-questions): excludeTypes/
+  // exclude_type is a hard scope filter applied BEFORE the limit, so the page is
+  // a full LIMIT of actionable candidates rather than LIMIT-minus-questions —
+  // the in-flight skip below then has the whole page to advance through (a page
+  // crowded by top-ranked questions could otherwise starve it). Questions stay
+  // queueable for the HUMAN queue (`spor next`). Sibling of
+  // issue-spor-routed-questions-ignore-wake.
   if (cfg.mode() === "remote") {
-    const q = slug ? `?project=${encodeURIComponent(slug)}&limit=${LIMIT}` : `?limit=${LIMIT}`;
+    const base = `limit=${LIMIT}&exclude_type=question`;
+    const q = slug ? `?project=${encodeURIComponent(slug)}&${base}` : `?${base}`;
     const r = await remote.get(cfg, `/v1/queue${q}`, { timeoutMs: 6000 });
     items = r.ok && r.json ? r.json.items || [] : [];
   } else {
     try {
       const g = require(path.join(ROOT, "lib", "graph.js")).loadGraph(cfg.nodesDir());
       const { rankQueue } = require(path.join(ROOT, "lib", "queue.js"));
-      const r = rankQueue(g, slug ? { project: slug, limit: LIMIT } : { limit: LIMIT });
+      const opts = { limit: LIMIT, excludeTypes: ["question"] };
+      const r = rankQueue(g, slug ? { project: slug, ...opts } : opts);
       items = r.items || [];
     } catch {
       items = [];
     }
   }
   if (!items.length) return null;
+  // Defense-in-depth: drop any question the ranker left in (an older server that
+  // predates / ignores exclude_type), so a question is never dispatched even
+  // against a stale backend. Primary exclusion is at the ranker above.
+  items = items.filter((it) => it.type !== "question");
+  if (!items.length) return null;
   // Skip items already in flight on this machine; advance to the first free one.
   const { items: free, hidden } = annotateInFlight(items, dispatchedAgents(), true);
   if (hidden && free.length) {

package/lib/kernel/graph.js

@@ -90,15 +90,20 @@ const DEFAULT_MIN_SIM = 0.08;
 // Supports simple
 // key: value, YAML folded multi-line values (indented continuations),
 // pin:/exclude:/queue_mute:/commits:/slugs:/fingerprints:/roles:/tags:/
-// applies_to_tags:/applies_to_repos:/applies_to_projects: inline lists,
-// and "- {type: X, to: Y}" edges. commits entries are repo-qualified shas
+// applies_to_tags:/applies_to_repos:/applies_to_projects:/skills:/plugins:/
+// mcp:/requires: inline lists, and "- {type: X, to: Y}" edges (which may carry
+// extra flat attributes — "- {type: assigned, to: agent-X, profile: profile-Y}"
+// — preserved on the edge object). commits entries are repo-qualified shas
 // ("repo@sha", task-cc-commit-linking); slugs/fingerprints are the project
 // node's alias and repo-evidence registers (task-cc-project-identity-nodes);
 // roles is the person node's role-list register the org-defined policy layer's
 // quorum gate counts qualified approvals against (task-cc-policy-layer); tags is
 // the repo node's free-form label register, and applies_to_* are a norm's
 // repo/tag-scope selectors matched against it (task-cc-norm-ride-along-repo-tag-
-// scope) — flat strings, not objects, by parser design.
+// scope); skills/plugins/mcp are the orchestration-layer profile node's
+// runtime+capability bundle and requires is a work node's risk-class list (the
+// registry-declared `requires` register, dec-spor-orchestration-routine-
+// requires-threads) — all flat strings, not objects, by parser design.
 function parseFrontmatter(raw, file) {
   const m = raw.match(/^---\n([\s\S]*?)\n---\n?([\s\S]*)$/);
   if (!m) throw new Error(`no frontmatter in ${file}`);
@@ -106,7 +111,7 @@ function parseFrontmatter(raw, file) {
   const node = { edges: [], pin: [], exclude: [], body: body.trim(), file };
   let lastKey = null; // for YAML folded scalars (indented continuation lines)
   for (const line of fm.split("\n")) {
-    const list = line.match(/^(pin|exclude|queue_mute|commits|slugs|fingerprints|roles|tags|applies_to_tags|applies_to_repos|applies_to_projects):\s*\[([^\]]*)\]/);
+    const list = line.match(/^(pin|exclude|queue_mute|commits|slugs|fingerprints|roles|tags|applies_to_tags|applies_to_repos|applies_to_projects|skills|plugins|mcp|requires):\s*\[([^\]]*)\]/);
     if (list) { node[list[1]] = list[2].split(",").map((s) => s.trim()).filter(Boolean); lastKey = null; continue; }
     const kv = line.match(/^(\w[\w-]*):\s*(.*)$/);
     if (kv) {
@@ -114,8 +119,18 @@ function parseFrontmatter(raw, file) {
       else lastKey = null;
       continue;
     }
-    const edge = line.match(/-\s*\{type:\s*([\w-]+),\s*to:\s*([\w-]+)\}/);
-    if (edge) { node.edges.push({ type: edge[1], to: edge[2] }); continue; }
+    // Edges are "- {type: X, to: Y}" and may carry trailing flat attributes
+    // ("- {type: assigned, to: agent-X, profile: profile-Y}", the per-assignment
+    // profile override, dec-spor-orchestration-routine-requires-threads thread 3).
+    // The first two captures stay type/to (byte-identical for the no-attribute
+    // form); any "key: value" pairs after `to:` are folded onto the edge object.
+    const edge = line.match(/-\s*\{type:\s*([\w-]+),\s*to:\s*([\w-]+)((?:\s*,\s*[\w-]+:\s*[\w-]+)*)\}/);
+    if (edge) {
+      const e = { type: edge[1], to: edge[2] };
+      if (edge[3]) for (const a of edge[3].matchAll(/,\s*([\w-]+):\s*([\w-]+)/g)) e[a[1]] = a[2];
+      node.edges.push(e);
+      continue;
+    }
     const cont = line.match(/^\s+(\S.*)$/);
     if (cont && lastKey) node[lastKey] += ` ${cont[1].trim()}`;
   }
@@ -1166,7 +1181,10 @@ function validateGraphFiles(files, seedSchemas = []) {
     for (const line of m[1].split("\n")) {
       const kv = line.match(/^(\w[\w-]*):\s*(.*)$/);
       if (kv && kv[1] !== "edges") node[kv[1]] = kv[2].replace(/^["']|["']$/g, "");
-      const edge = line.match(/-\s*\{type:\s*([\w-]+),\s*to:\s*([\w-]+)\}/);
+      // Match the build parser: tolerate trailing flat edge attributes
+      // (e.g. profile: on a profile-bearing assigned edge); validate only needs
+      // type/to, so the extra attributes are matched and discarded here.
+      const edge = line.match(/-\s*\{type:\s*([\w-]+),\s*to:\s*([\w-]+)(?:\s*,\s*[\w-]+:\s*[\w-]+)*\}/);
       if (edge) node.edges.push({ type: edge[1], to: edge[2] });
     }
     for (const field of ["id", "type", "title", "summary"]) {

package/lib/kernel/queue.js

@@ -886,4 +886,4 @@ function rankQueue(graph, opts = {}) {
   return r;
 }
 
-module.exports = { rankQueue, warmQueueIndex, PRIORITY_BUMP, DEFAULT_LIMIT };
+module.exports = { rankQueue, warmQueueIndex, wakeTime, PRIORITY_BUMP, DEFAULT_LIMIT };

package/lib/kernel/registry.js

@@ -113,7 +113,7 @@ function applyUpgrades(node, schema) {
 
 const FENCE_RE = /^```(\w+)?[ \t]*\n([\s\S]*?)^```[ \t]*$/gm;
 const EXPORT_RE = /export\s+(?:async\s+)?(?:function|const|let)\s+([A-Za-z_$][\w$]*)/g;
-const KINDS = new Set(["node-schema", "edge-schema", "queue-policy", "policy"]);
+const KINDS = new Set(["node-schema", "edge-schema", "queue-policy", "policy", "register"]);
 
 // Takes an already-parsed graph node (frontmatter fields + body) and extracts
 // the registry entry. Never throws on bad data; returns { ok, errors, schema }.
@@ -127,7 +127,7 @@ function parseSchemaNode(node) {
   const id = node.id ?? "?";
 
   if (!KINDS.has(node.kind)) {
-    errors.push(`kind '${node.kind}' must be node-schema, edge-schema, or queue-policy`);
+    errors.push(`kind '${node.kind}' must be one of: node-schema, edge-schema, queue-policy, policy, register`);
   }
   if (!parseCalVer(node.schema_version)) {
     errors.push(`schema_version '${node.schema_version}' is not CalVer YYYY.MM.DD.MICRO`);
@@ -221,6 +221,26 @@ function parseSchemaNode(node) {
           }
         }
       }
+    } else if (node.kind === "register") {
+      // A registry-declared extensible enum — a named vocabulary the kernel
+      // exposes as a partition (graph.registry.register(name)) instead of
+      // owning a hardcoded table (dec-spor-orchestration-routine-requires-
+      // threads thread 4: `requires:` is the first such register, the
+      // risk/permission axis). Keyed by the register NAME (payload.register),
+      // so a graph-resident register schema overrides/extends the seed one
+      // wholesale — an org grows the enum by editing a schema node, no code
+      // change. `classes` is the enum: an array of { id, description } objects;
+      // readers (the dispatch matcher, the policy layer) read the ids off the
+      // partition. The kernel only DECLARES the vocabulary here — validating a
+      // node's `requires:` against it, and policy gating, are downstream.
+      key = payload.register;
+      if (typeof key !== "string" || !key) errors.push(`register payload missing register name`);
+      if (payload.classes != null) {
+        if (!Array.isArray(payload.classes) ||
+            payload.classes.some((c) => !c || typeof c !== "object" || typeof c.id !== "string" || !c.id)) {
+          errors.push(`register classes must be an array of { id, description } objects`);
+        }
+      }
     } else if (node.kind === "edge-schema") {
       key = payload.edge_type;
       if (typeof key !== "string" || !key) errors.push(`edge-schema payload missing edge_type`);
@@ -288,6 +308,12 @@ class Registry {
     this.policySchemas = new Map(); // id -> policy schema (+ .source); the
                                     // org-defined policy layer (kind: policy),
                                     // NOT a singleton — selected by scope.
+    this.registers = new Map();     // name -> register schema (+ .source); the
+                                    // registry-declared extensible enums (kind:
+                                    // register), e.g. `requires` (the risk axis,
+                                    // dec-spor-orchestration-routine-requires-
+                                    // threads). Keyed by register name; graph
+                                    // beats seed, higher CalVer wins.
     // key -> { graphId, graphVersion, seedVersion } when a graph-resident
     // schema wins over a STRICTLY NEWER seed entry for the same type — the
     // silent-shadow case (issue-cc-schema-override-seed-shadow). Surfaced as
@@ -340,6 +366,16 @@ class Registry {
       this.policySchemas.set(schema.key, entry);
       return true;
     }
+    if (schema.kind === "register") {
+      // Keyed by register name. Same precedence as the rest (graph beats seed,
+      // higher version wins within a source); distinct register names coexist.
+      const existing = this.registers.get(schema.key);
+      const winner = Registry._prefer(existing, entry);
+      this._noteShadow(schema.key, winner, winner === entry ? existing : entry);
+      if (winner !== entry) return false;
+      this.registers.set(schema.key, entry);
+      return true;
+    }
     const map = schema.kind === "edge-schema" ? this.edgeSchemas : this.nodeSchemas;
     const existing = map.get(schema.key);
     const winner = Registry._prefer(existing, entry);
@@ -420,6 +456,34 @@ class Registry {
     return !this.nonResolvingStatuses().has((status || "").toLowerCase());
   }
 
+  // ---- registry-declared enums (kind: register) ----
+
+  // The full payload of a named register (its `classes` array and any other
+  // declared fields), or null when no schema declares it. The orchestration
+  // layer's `requires:` risk-class register is the first
+  // (dec-spor-orchestration-routine-requires-threads thread 4): a node's
+  // `requires:` lists risk/permission classes the work touches; the dispatch
+  // matcher and the org policy layer read the legal vocabulary off this
+  // partition rather than a hardcoded table (the registry is the contract).
+  register(name) {
+    const s = this.registers.get(name);
+    return s ? s.payload : null;
+  }
+
+  // The class ids of a named register, in declaration order ([] if undeclared).
+  registerClasses(name) {
+    const s = this.registers.get(name);
+    const classes = s && Array.isArray(s.payload.classes) ? s.payload.classes : [];
+    return classes.map((c) => c.id);
+  }
+
+  // The `requires:` risk-class vocabulary as a Set, the convenience the matcher
+  // and policy gate read. Empty when no `requires` register is declared (a
+  // graph with neither the register nor any `requires:` fields is unaffected).
+  requiresClasses() {
+    return new Set(this.registerClasses("requires"));
+  }
+
   // ---- the org-defined policy layer (task-cc-policy-layer) ----
 
   // governs-traversal selection (dec-spor-policy-layer-activate): which policy

package/lib/kernel/resolution.js

@@ -7,10 +7,14 @@
 // twice (issue-cc-status-lags-resolution-edges), so read surfaces and the
 // queue derive actionability from edges, not status:
 //
-//   resolutionMap(graph)  -> { targetId: { by, edge, date } } for every live
-//                            node retired by a live resolver. `answers` only
-//                            retires question nodes; `resolves` retires any
-//                            target. Superseded or rejected/abandoned
+//   resolutionMap(graph)  -> { targetId: { by, edge, date, summary, title } }
+//                            for every live node retired by a live resolver.
+//                            `summary`/`title` are the RESOLVER's, so a read
+//                            surface can show WHAT resolved/answered the target,
+//                            not just that something did
+//                            (task-spor-getnode-surface-resolution-on-terminal).
+//                            `answers` only retires question nodes; `resolves`
+//                            retires any target. Superseded or rejected/abandoned
 //                            resolvers don't count — a withdrawn fix resolves
 //                            nothing.
 //   resolutionOf(graph, id)      -> that entry, or null.
@@ -51,7 +55,7 @@ function resolutionMap(graph) {
       const target = graph.nodes[e.to];
       if (!target || out[e.to]) continue;
       if (e.type === "answers" && target.type !== "question") continue;
-      out[e.to] = { by: r.id, edge: e.type, date: r.date ?? null };
+      out[e.to] = { by: r.id, edge: e.type, date: r.date ?? null, summary: r.summary ?? null, title: r.title ?? null };
     }
   }
   return out;

package/lib/seed/schema-edge-assigned.md

@@ -2,23 +2,45 @@
 id: schema-edge-assigned
 type: schema
 kind: edge-schema
-schema_version: 2026.06.10.1
+schema_version: 2026.06.18.1
 title: Seed schema for assigned edges
-summary: Edge schema for the assigned type — work is assigned to a person; the traversal key for per-person views and queues. Seed-pack default; a graph-resident schema node for this edge type overrides it.
-date: 2026-06-10
+summary: Edge schema for the assigned type — work is assigned to a person OR an agent; the traversal key for per-person views and queues, and the orchestration layer's explicit-routing edge. An agent-targeted edge may carry an optional profile: attribute (the per-assignment profile override). Seed-pack default; a graph-resident schema node for this edge type overrides it.
+date: 2026-06-18
 ---
 
-Seed schema for the `assigned` edge type (work node → person), shipped
+Seed schema for the `assigned` edge type (work node → person OR agent), shipped
 with the plugin as a registry default (QUEUE.md §2). Per-person views
 ("what am I blocking") traverse it from the `$viewer` binding; per-person
 queues filter on it — the queue's `assignee` parameter
 (`GET /v1/queue?assignee=<person>`), unioned with the person's `stewards`
 edges (task-cc-queue-assignee-filtering).
 
+**Routing is explicit assignment, not eligibility**
+(dec-spor-agent-orchestration-layer). The target distinguishes who does the work:
+
+- `assigned → person` — human work. Unassigned + person-assigned = today's human
+  pool, unchanged.
+- `assigned → agent-X` — an agent does it (X's profile says how and what it can
+  touch). Only agent-assigned tasks are dispatch candidates. Use this for work an
+  agent must NOT do — e.g. an irreversible real-world action — by assigning it to
+  the person instead.
+
+An agent-targeted edge may carry an optional **`profile:` attribute** — the
+durable, graph-recorded per-assignment profile override
+(dec-spor-orchestration-routine-requires-threads thread 3): `{type: assigned, to:
+agent-X, profile: profile-Y}` reads "when this task goes to this agent, run it
+under this profile." It is the natural, auditable home for the override; cascade
+precedence is `--profile` dispatch flag > this assignment-edge attribute > the
+agent's default `uses-profile` (schema-edge-uses-profile). The attribute is flat
+edge data the regex frontmatter parser preserves; the dispatch matcher reads it
+(task-spor-dispatch-capabilities-satisfiability). An assignment with no `profile:`
+falls through to the agent's default, so existing `assigned` edges are unchanged
+(backward-readable, no upgrade chain). Weight is unchanged at 0.5.
+
 ```json
 {
   "edge_type": "assigned",
-  "description": "work assigned to this person",
+  "description": "work assigned to this person or agent — the explicit-routing edge; an agent target may carry a profile: per-assignment override",
   "weight": 0.5
 }
 ```

package/lib/seed/schema-edge-uses-profile.md

@@ -0,0 +1,38 @@
+---
+id: schema-edge-uses-profile
+type: schema
+kind: edge-schema
+schema_version: 2026.06.18.1
+title: Seed schema for uses-profile edges
+summary: Edge schema for the uses-profile type — an agent → its DEFAULT profile (the runtime+capability bundle it dispatches under), overridable per assignment or per dispatch. A low-weight structural config binding like owned-by, not a work dependency. Seed-pack default; a graph-resident schema node for this edge type overrides it.
+date: 2026-06-18
+---
+
+Seed schema for the `uses-profile` edge type (agent → profile), shipped with the
+plugin as a registry default (QUEUE.md §2). Written from a `type: agent` node
+(schema-agent) to the `profile-` node (schema-profile) it dispatches under by
+default — "the WHO points at the HOW" (dec-spor-agent-orchestration-layer).
+
+The default is overridable without rewriting this edge: per assignment via the
+`assigned → agent` edge's `profile:` attribute (schema-edge-assigned), or per
+dispatch via `--profile`. Cascade precedence, explicit wins: `--profile` flag >
+assignment-edge attribute > this default `uses-profile`
+(dec-spor-orchestration-routine-requires-threads thread 3) — the same shape as
+`dispatch.agent` vs `--as`.
+
+A low structural weight (0.3), mirroring `owned-by` and `grouped-under`: an
+agent's default profile is durable configuration, not work flow — the profile
+rarely needs to be pulled into a work neighborhood, and a low weight keeps
+runtime config from polluting task briefings. `capturable: false`: the binding
+is created deliberately alongside the agent/profile (by `spor agent` config),
+never drafted from a capture — mirroring the identity/config-node family it joins
+(`owned-by`).
+
+```json
+{
+  "edge_type": "uses-profile",
+  "description": "this agent's default profile — the runtime+capability bundle it dispatches under (overridable per assignment or dispatch)",
+  "weight": 0.3,
+  "capturable": false
+}
+```

package/lib/seed/schema-profile.md

@@ -0,0 +1,74 @@
+---
+id: schema-profile
+type: schema
+kind: node-schema
+schema_version: 2026.06.18.1
+title: Seed schema for profile nodes
+summary: Node schema for the profile type — a reusable runtime+capability bundle (harness, model, skills, plugins, mcp) an agent runs under. The runtime fields ARE the dispatch satisfiability spec the machine-capabilities matcher reads; there is no separate requirements block. Personal AND org-published with personal override. Seed-pack default; a graph-resident schema node for this type overrides it.
+date: 2026-06-18
+---
+
+Seed schema for the `profile` node type (ontology in GRAPH.md), shipped with the
+plugin as a registry default (QUEUE.md §2). A `type: schema` node in the graph
+with `kind: node-schema` and the same `node_type` overrides this entry.
+
+A profile is the orchestration layer's runtime+capability bundle — "the HOW" —
+that an `agent` (schema-agent, "the WHO") dispatches under
+(dec-spor-agent-orchestration-layer). Factoring it out of the agent node makes
+the toolset reusable across agents and people, and gives dispatch one structured
+declaration to parameterize a launch from.
+
+Instances carry, beyond the standard fields (`id`, `type`, `title`, `summary`,
+`date`), the runtime register — all flat values the regex frontmatter parser
+already supports:
+
+- `harness:` — the launcher/adapter the work runs under (`claude-code` |
+  `codex` | `opencode` | …), operationalizing dec-cc-portable-core-adapters
+  (claude-code → `claude --bg`, codex/opencode → their CLIs). A flat scalar.
+- `model:` — the model id passed to the harness (`--model`). A flat scalar.
+- `skills:` / `plugins:` / `mcp:` — inline lists of the skills, plugins, and MCP
+  servers the harness preloads; `mcp` is merged into the strict `--mcp-config`
+  dispatch writes so the agent's toolset is exactly the profile plus the
+  agent-spor server, nothing ambient (dec-spor-session-identity-active-record).
+
+**These runtime fields ARE the satisfiability spec** — there is no separate
+requirements block (dec-spor-machine-profile-satisfiability, FORK A). A machine
+declares ATOMIC capabilities in a machine-local `dispatch.capabilities` map, and
+`satisfies(machine, profile)` is `profile.harness ∈ machine.harnesses ∧
+profile.mcp ⊆ machine.reachable_mcp ∧ profile.skills ⊆ machine.skills ∧
+profile.plugins ⊆ machine.plugins ∧ profile ∉ machine.deny`. The matcher and the
+machine-local map are the deferred build this schema unblocks
+(task-spor-dispatch-capabilities-satisfiability); the same atomic vocabulary is
+forward-compatible with the deferred remote fleet scheduler (each agent publishes
+its capabilities to the server). This schema only fixes the profile's field
+contract that match reads.
+
+**Reusable + both-scoped, with override.** Profiles are PERSONAL (you author
+your own) AND ORG-PUBLISHED (the org curates a vetted toolset, e.g.
+`profile-docs-writer`), with personal override. Org-published profiles are where
+this meets policy — the org policy layer (dec-spor-policy-layer-activate) can
+require that work of a given risk class be assigned to an agent whose profile is
+org-approved (curated-toolset-as-governance). That gating lives in policy nodes,
+not in this schema. An agent references its DEFAULT profile with a `uses-profile`
+edge (schema-edge-uses-profile), overridable per assignment (the `assigned →
+agent` edge's `profile:` attribute, schema-edge-assigned) or per dispatch
+(`--profile`); cascade precedence is `--profile` flag > assignment-edge attribute
+> agent's default.
+
+`status:` is declarative (`active` by default; any other status, or none, reads
+as before) — not gated by a `transitions()` enum, so the type stays
+backward-readable. `capturable: false`: a profile is created deliberately (by a
+person curating a toolset, or an org publishing one), never drafted from a
+capture or distilled from a transcript — mirroring `agent`, `person`, `repo`,
+and `workflow-run`. Graphs without profile nodes behave exactly as before.
+
+```json
+{
+  "node_type": "profile",
+  "description": "a reusable runtime+capability bundle an agent runs under — harness, model, skills, plugins, mcp; its runtime fields are the dispatch satisfiability spec",
+  "prefix": [
+    "profile-"
+  ],
+  "capturable": false
+}
+```

package/lib/seed/schema-requires.md

@@ -0,0 +1,58 @@
+---
+id: schema-requires
+type: schema
+kind: register
+schema_version: 2026.06.18.1
+title: Seed schema for the requires risk-class register
+summary: Registry-declared extensible enum (kind register) for the `requires:` risk/permission axis — the classes of capability a piece of work may touch (shell, prod-creds, browser, network, human, filesystem-write, paid-api). DISTINCT from machine-satisfiability: this is what the WORK needs, validated against the assigned profile and gated by org policy. The kernel exposes the vocabulary as a partition (graph.registry.requiresClasses()); reading/gating is downstream. Seed default; a graph-resident register schema for this name overrides/extends it.
+date: 2026-06-18
+---
+
+Seed schema for the `requires` register (ontology in GRAPH.md), shipped with the
+plugin as a registry default (QUEUE.md §2). It declares a named, extensible
+vocabulary — not a node or edge type. A `type: schema` node in the graph with
+`kind: register` and `register: requires` overrides/extends this entry, so an org
+grows the enum by editing a schema node, never by a code change (the registry is
+the contract).
+
+`requires:` is the risk/permission axis (dec-spor-orchestration-routine-requires-
+threads thread 4): a flat list on a work node (`requires: [shell, prod-creds]`)
+naming the classes of capability the work may touch. It is **DISTINCT from
+machine-satisfiability** — that asks "can this box LAUNCH the assigned profile"
+(harness/mcp/skills present, derived from the profile's runtime fields, decides
+dispatch; dec-spor-machine-profile-satisfiability). `requires:` asks "what is this
+work allowed to touch", validated against the assigned agent's profile (a task's
+`requires:` must be ⊆ the profile's granted classes, else warn/refuse —
+under-equipped or over-privileged) and gated by org policy.
+
+The kernel stays policy-free: it only DECLARES the vocabulary and exposes it as a
+partition (`graph.registry.requiresClasses()` / `register("requires")`), the same
+way the resolving-status partition is read off the registry rather than a
+hardcoded table. The org policy layer reads it via the same governs-traversal the
+definition-of-done quorum gate uses (dec-spor-definition-of-done-org-policy):
+the nearest governing policy node decides which classes need which approvals and
+which agents may hold them. Validating a node's `requires:` against the register,
+the profile match, and the policy gate are the deferred build this unblocks
+(task-spor-dispatch-capabilities-satisfiability); this schema only fixes the
+vocabulary.
+
+`human` is special: it is unsatisfiable by ANY agent — work that needs a human
+(an irreversible real-world action, e.g. delegating Namecheap NS to Cloudflare)
+is assigned to a person, not an agent. The seed set is deliberately small;
+org-extend it with a resident register schema.
+
+```json
+{
+  "register": "requires",
+  "description": "the risk/permission classes a piece of work may touch — validated against the assigned profile and gated by org policy; DISTINCT from machine-satisfiability",
+  "classes": [
+    { "id": "shell", "description": "runs arbitrary shell commands on the host" },
+    { "id": "prod-creds", "description": "uses production credentials or secrets" },
+    { "id": "browser", "description": "drives a real web browser / does web automation" },
+    { "id": "network", "description": "makes outbound network calls beyond the Spor server" },
+    { "id": "human", "description": "needs a human — unsatisfiable by any agent; assign to a person" },
+    { "id": "filesystem-write", "description": "writes to the filesystem outside a scratch/worktree sandbox" },
+    { "id": "paid-api", "description": "calls a metered/paid external API" }
+  ]
+}
+```

package/lib/seed/schema-routine.md

@@ -0,0 +1,91 @@
+---
+id: schema-routine
+type: schema
+kind: node-schema
+schema_version: 2026.06.18.1
+title: Seed schema for routine nodes
+summary: Node schema for the routine type — owner-scoped (owned-by a person) trigger→action automation: declarative when→do rules over graph events that dispatch ONLY the owner's agents, AND-ed with org policy. Declarative register first; attached sandboxed code is a later schema-gated escape hatch. Seed-pack default; a graph-resident schema node for this type overrides it.
+date: 2026-06-18
+---
+
+Seed schema for the `routine` node type (ontology in GRAPH.md), shipped with the
+plugin as a registry default (QUEUE.md §2). A `type: schema` node in the graph
+with `kind: node-schema` and the same `node_type` overrides this entry.
+
+A routine is the orchestration layer's per-person automation
+(dec-spor-agent-orchestration-layer): a node `owned-by` a person
+(schema-edge-owned-by) holding `when → do` rules that fire on graph events. The
+sonnet-implements → opus-reviews → approve/send-back/escalate loop and the "a
+task touching docs reaches done → dispatch the docs-profile agent" handoff are
+routines.
+
+**Two invariants** (from the parent decision):
+
+1. **Only the owner's agents are ever dispatched.** Enforced by the trigger
+   locus — locally your machine runs only your routines for your agents;
+   remotely the server fires a person's routine only for that person's work and
+   can only mint tokens for agents they own. The `person → routine → agent` RFC
+   8693 act-chain is the audit trail (dec-cc-attribution-from-token,
+   dec-cc-workflow-credential-issuance).
+2. **Personal routines accelerate; org policy gates — they AND, never bypass.**
+   Agent-on-behalf-of-X counts as X for the self-approval ban and the
+   definition-of-done quorum (dec-spor-definition-of-done-org-policy), so an
+   owner's reviewer-agent CANNOT auto-approve their implementer-agent's work past
+   the org review bar. A routine gets work pre-vetted and clean; independent
+   approvals still require other people.
+
+**Declarative register first** (dec-spor-orchestration-routine-requires-threads
+thread 1). A routine instance carries its rules as a fenced ```json `rules` block
+in its BODY (the regex frontmatter parser is flat, so structured rules live in
+the body, exactly as a schema's payload does; the deferred routine ENGINE parses
+and runs them). The bounded vocabulary:
+
+- **Triggers (`when`)** are graph events — a status change (e.g. to a resolving
+  state, or to `done`), or an edge appearing (e.g. `reviewed-by` /
+  `changes-requested-by`) — with `where:` filters (type, project, requires,
+  assignee, …).
+- **Actions (`do`)** are the bounded verb set: `create-node`, `assign` (to a
+  SPECIFIC agent, optionally with a `profile:` override), `dispatch`,
+  `set-status`, `reassign`, `escalate` (to the owner). Arbitrary attached
+  sandboxed code is the LATER schema-gated escape hatch, gated like lens/schema
+  code (dec-lens-custom-wasm-timing) — NOT this schema.
+
+Shape of an instance body (documented for the engine; not parsed by the kernel —
+shown as `jsonc` so the seed parser does not mistake it for this schema's own
+payload, which is the first ```json block below):
+
+```jsonc
+{
+  "rules": [
+    {
+      "when": { "event": "status-change", "to": "resolving", "where": { "type": "task", "project": "spor" } },
+      "do": [ { "action": "dispatch", "to": "agent-x", "profile": "profile-y" } ]
+    }
+  ]
+}
+```
+
+This schema fixes the routine's IDENTITY and its declarative vocabulary only. The
+routine ENGINE and its vetting machinery — dry-run, the mandatory retry budget,
+self-approval-floor activation review (a routine that auto-dispatches against
+shared state is `proposed` until a different identity activates it), and the
+fire-time org-policy gate (thread 2) — ride on the engine, deferred. So this
+seed schema is declarative and UNGATED: `status:` is plain data
+(backward-readable), no `transitions()` enum ships here; the activation gate is
+added (with a `schema_version` bump) when the engine lands.
+
+`capturable: false`: a routine is authored deliberately by its owner, never
+drafted from a capture or distilled from a transcript — mirroring `agent`,
+`profile`, `person`, and `workflow-run`. Graphs without routine nodes behave
+exactly as before.
+
+```json
+{
+  "node_type": "routine",
+  "description": "owner-scoped trigger→action automation owned by a person — declarative when→do rules dispatching only the owner's agents, AND-ed with org policy",
+  "prefix": [
+    "routine-"
+  ],
+  "capturable": false
+}
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sporhq/spor",
-  "version": "0.9.0",
+  "version": "0.10.0",
   "description": "Spor — a shared memory substrate for teams and agents. Decisions, their reasons, and the traces they leave. Knowledge-graph context compiler: session-start briefings, per-prompt digests, capture at discovery, end-of-session distillation, decision queue.",
   "license": "Apache-2.0",
   "author": "Anthony Allen",

package/skills/spor/references/authoring-schemas.md

@@ -19,6 +19,15 @@ Frontmatter: `id: schema-<type>` (or `schema-edge-<type>`), `type: schema`,
 body holds prose, then a fenced **JSON payload**, then optional fenced **JS
 functions**.
 
+(Two more kinds exist for non-type schemas. `kind: policy` is the org-defined
+policy layer — see GRAPH.md. `kind: register` declares a named, extensible
+**enum** the kernel exposes as a partition rather than a hardcoded table: a
+payload `{ "register": "<name>", "classes": [{ "id": …, "description": … }] }`,
+keyed by register name (graph beats seed, higher CalVer wins). The seed
+`requires` register — the work-node risk/permission axis — is the first; read it
+with `graph.registry.requiresClasses()`. Grow it by writing a resident `kind:
+register` schema with the same `register:` name.)
+
 ### Node schema — JSON payload keys
 
 ```json

package/skills/spor/references/concepts.md

@@ -24,6 +24,8 @@ the decision queue (QUEUE.md §4).
 | question | `question-` | a routed ask the graph couldn't answer | queueable; status `open`/`answered`; joins the queue until answered |
 | person | `person-` | an org member | anchor for `$viewer` binding and question routing |
 | agent | `agent-` | a person-owned automation principal | a dispatched session's durable identity; owned by a person via `owned-by`; `capturable: false`; carries forward-compat `spiffe:`/`pubkey:` |
+| profile | `profile-` | a reusable runtime+capability bundle an agent runs under | `harness`/`model`/`skills`/`plugins`/`mcp`; these runtime fields ARE the dispatch satisfiability spec; `capturable: false` |
+| routine | `routine-` | owner-scoped trigger→action automation | `owned-by` a person; declarative `when → do` rules over graph events; dispatches only the owner's agents, AND-ed with org policy; `capturable: false` |
 | capture-pending | `cap-` | raw captured text that fit no schema | born status-less; closes only as `merged` or `rejected` |
 | finding | `find-` | a gardener observation (stale anchor, cold work) | filed as a queue item |
 | repo | `repo-` | a durable git-repo identity | carries `slugs:` aliases + `fingerprints:`; heals renames at read time; optional `tags:` are the match key for a norm's `applies_to_tags` |
@@ -51,12 +53,13 @@ are same-direction synonyms renamed at write time.
 | performs | 0.8 | this run is an execution of the target workflow | — |
 | blocks | 0.7 | the target can't proceed until this does | inverse `blocked-by` |
 | answers | 0.7 | this answers the target question | inverse `answered-by` |
-| assigned | 0.5 | work assigned to this person | — |
+| assigned | 0.5 | work assigned to this person OR agent (explicit routing; an agent target may carry a `profile:` per-assignment override) | — |
 | relates-to | 0.5 | weak association | alias `related-to` |
 | mentions | 0.5 | weakest association | — |
 | stewards | 0.4 | this person stewards the target area/spec/norm | question-routing key |
 | grouped-under | 0.3 | this repo's home project grouping (structural) | inverse `groups` |
 | owned-by | 0.3 | this agent is owned by that person (structural identity) | inverse `owns` |
+| uses-profile | 0.3 | this agent's default profile (runtime+capability bundle); structural config, overridable per assignment/dispatch | — |
 | routed-to | 0.3 | this question is routed to that person | — |
 | compiled-for | — | briefing → the task/query it was compiled for | provenance only |
 | shaped-by | — | briefing → the corrections that shaped it | provenance only |