@sporhq/spor 0.21.0 → 0.22.0

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "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.21.0",
+  "version": "0.22.0",
   "author": {
     "name": "losthammer"
   }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "spor",
-  "version": "0.21.0",
+  "version": "0.22.0",
   "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.",
   "author": {
     "name": "Spor",

package/API.md

@@ -69,6 +69,21 @@ neighbor → neighbor); `render_lens` lineage lenses trace why a node exists,
 and `render_lens` with no `lens_id` returns the lens catalog (the discovery
 step before rendering).
 
+**Per-viewer language register** (task-spor-viewer-register-adaptation): when
+the authenticated viewer's person node carries a free-text `register:` field
+(GRAPH.md "person" — role + preferred language style), the server renders it
+on two channels so the host's model adapts how it explains graph content to
+that user. (1) The initialize `instructions` gain a trailing **`AUDIENCE`**
+section quoting the field; (2) the conversational read tools — `query_graph`,
+`get_node`, `explore_graph`, `show_queue` — prepend one line to their TEXT
+content: `Audience note — how to communicate with this user: <register>`.
+Both channels because host support for instructions is uneven. The preamble
+is presentation-only: `structuredContent` is never touched, `isError` results
+are exempt, and content is never filtered or reordered by it. The field is
+capped at 500 chars on render; agent-scoped identities (dispatch tokens) get
+neither channel — the register describes the human reader. Absent the field,
+both channels are byte-identical to before.
+
 ### `query_graph`
 
 The compiler over the wire. Input:

package/GRAPH.md

@@ -640,6 +640,8 @@ email: losthammer@gmail.com
 github: losthammer
 roles: [reviewer, maintainer]
 queue_mute: [some-noisy-project, task-noisy-job@2026-07-01]
+register: Non-technical founder. Plain everyday language, no graph jargon;
+  use node titles, never raw ids. Analogies over precision.
 date: 2026-06-10
 edges:
   - {type: stewards, to: norm-cc-registry-is-contract}
@@ -653,6 +655,14 @@ edges:
   (issue-cc-identity-email-mutable-primary-key). The token's `{name, email}`
   attribution is read from the bound node, never from a caller parameter
   (dec-viewer-token-binding, dec-cc-attribution-from-token).
+- **`register` is the language-register field** (free-text folded scalar): the
+  reader's role and preferred language style. Viewer-facing surfaces (the
+  server's MCP instructions block and the conversational read tools' `Audience
+  note` preamble) render it verbatim so the model adapts how it talks about
+  graph content to this person — a non-technical user gets plain language
+  instead of node-type jargon (task-spor-viewer-register-adaptation).
+  Presentation only: it never changes what is returned. Settable from chat by
+  updating your own person node.
 - **`stewards` edges are the routing key.** A `person → node` `stewards` edge
   declares ownership of an area, spec, or norm. When a question can't be
   answered from the graph and is filed (`ask_question` / `POST /v1/questions`),

package/lib/seed/schema-person.md

@@ -2,7 +2,7 @@
 id: schema-person
 type: schema
 kind: node-schema
-schema_version: 2026.06.23.1
+schema_version: 2026.07.14.1
 title: Seed schema for person nodes
 summary: Node schema for the person type — a member of the org, with a mutable display name plus the identity anchor for $viewer binding and Tier-2 question routing. Seed-pack default; a graph-resident schema node for this type overrides it.
 date: 2026-06-10
@@ -41,6 +41,25 @@ node may reach a resolving/done state. Declarative data only — absent it, a
 person holds no roles and the field has no effect, so this register is purely
 additive (existing person nodes are unchanged).
 
+`register` (2026.07.14.1) is the person node's language-register field (folded
+scalar, free-text prose): how to communicate with this user — their role and
+preferred language style, e.g. `register: Non-technical founder. Plain
+everyday language, no graph jargon; use node titles, never raw ids.` Consumers
+that render graph content *to* this person (the server's MCP instructions
+block and conversational tool-result preambles; API.md §2) surface it verbatim
+so the model adapts its language to the reader
+(task-spor-viewer-register-adaptation). Free text on purpose — the model
+follows prose directly, so no enum→instruction translation table exists to
+drift. When setting it on a user's behalf, don't transcribe a vague
+preference ("keep it simple") — interview briefly, compose 2–4 directive
+sentences a model can act on (vocabulary level, node titles vs raw ids,
+analogies vs precision, detail depth), and confirm the draft with the user
+before writing. Per-viewer presentation only, read via the same `$viewer` binding as
+`queue_mute`; it never changes what content is returned, only how the
+assistant is told to talk about it. Declarative data only — absent it, nothing
+is injected and the field has no effect, so this register is purely additive
+(existing person nodes are unchanged).
+
 `github` (2026.06.21.1) is the person node's GitHub-handle register (flat inline
 scalar): `github: octocat`. It is the login→person key the Spor server's GitHub
 review reflection maps by: when a GitHub review or merge is reflected into the
@@ -77,6 +96,10 @@ register is purely additive (existing person nodes are unchanged).
       "kind": "inline-list",
       "description": "role-list register consumed by policy quorum gates"
     },
+    "register": {
+      "kind": "scalar",
+      "description": "free-text language register — the reader's role and preferred language style, rendered to the model on viewer-facing surfaces"
+    },
     "github": {
       "kind": "scalar",
       "aliases": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sporhq/spor",
-  "version": "0.21.0",
+  "version": "0.22.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/onboard/SKILL.md

@@ -66,20 +66,43 @@ attribute to you and your queue and question-routing work.
    hand it over; the user then re-runs step 1 with it. Don't paper over it — silent
    identity degradation is exactly the failure this check exists to catch
    (issue-cc-onboarding-email-mismatch-silent-degradation).
-4. **Enable this repo.** `spor enable` writes `.spor.json {enabled: true}` so the
+4. **Ask how assistants should talk to them — the `register` field.** First
+   check `spor get <person-id>` — if the node already carries a `register:`,
+   this step is done (mention it exists and move on; don't re-interview a
+   returning user). Otherwise interview briefly, then **draft the field
+   yourself — never transcribe the user's first answer**. People
+   under-specify this in the moment ("just keep it simple" encodes nothing a
+   model can act on), so extract the substance: what's their role, how
+   technical are they, and what does a useful explanation look like to them —
+   asking for an example of an explanation they liked or hated works well.
+   From that, compose 2–4 directive sentences a model can follow mechanically
+   (vocabulary level, node titles vs raw ids, analogies vs precision, detail
+   depth — e.g. `register: Non-technical founder. Plain everyday language, no
+   graph jargon; use node titles, never raw ids. Analogies over precision.`),
+   read the draft back for approval, and write the approved version to their
+   person node (GRAPH.md "person"): `spor get <person-id> --json` for the
+   revision, add the field, then
+   `spor put-node - --if-exists update --revision <sha>`. The server renders it
+   to every graph-reading assistant (MCP instructions + an Audience note on
+   reads), so a non-technical user gets answers they can actually use — for
+   them this is the highest-value step here
+   (task-spor-viewer-register-adaptation). Presentation only, editable any time
+   by updating their person node; a technical user happy with the default
+   needs no field — skip without ceremony.
+5. **Enable this repo.** `spor enable` writes `.spor.json {enabled: true}` so the
    plugin actually runs here — without a marker every hook no-ops (the opt-in
    default), even in remote mode. Commit the file to share the setting. If the
    inferred project slug is wrong, `spor link <slug>` writes a `.spor` marker.
-5. **(Optional) a dispatch identity**, if the user will run background agents.
+6. **(Optional) a dispatch identity**, if the user will run background agents.
    Two explicit steps: `spor agent create <label>` writes the agent node owned by
    your person, then `spor agent use <agent-id>` makes it **this machine's**
    default — that's what turns on session-start capability auto-publish and the
    liveness heartbeat. Creating does not activate; both are needed. Use the full
    `agent-<slug>` id from `spor agent list`, not the bare label.
-6. **State the data reality correctly.** In remote mode your captures and
+7. **State the data reality correctly.** In remote mode your captures and
    distilled nodes land in the **shared team graph on the server** — visible to
    teammates and attributed to you. It is *not* local-only.
-7. **Hand off to populate the repo:** `/spor:backfill` (mine history, group
+8. **Hand off to populate the repo:** `/spor:backfill` (mine history, group
    repos). Tracker/MCP consent happens there — see step 6 of the local branch,
    which applies equally.
 

package/skills/spor/references/concepts.md

@@ -166,8 +166,9 @@ token — the node reads "agent on behalf of person"). Other
 type-specific fields exist (`wake:` dormancy date; `commits:` linked git shas;
 `pin:`/`exclude:` on corrections; `slugs:`/`fingerprints:`/`tags:` on repo nodes;
 `applies_to_tags:`/`applies_to_repos:`/`applies_to_projects:` ride-along
-selectors on norms; `roles:`/`queue_mute:` on person nodes) — see GRAPH.md for
-the complete list.
+selectors on norms; `roles:`/`queue_mute:`/`register:` on person nodes, `register` being the
+free-text "how to talk to this reader" language-style field viewer-facing
+surfaces render verbatim) — see GRAPH.md for the complete list.
 
 Validate any local node you write: `spor validate` (or
 `node lib/validate.js`), and fix what it flags.

package/skills/triage/SKILL.md

@@ -237,6 +237,17 @@ item(s) to spend it on; don't sweep the whole backlog unprompted. Skip an item
 that's needs-human only because it's someone's assigned work (`assigned →
 person`) — there is no gap to close there.
 
+**Entering this pass, proposing candidates is mandatory — never wait for the
+human to name items** (issue-spor-triage-make-ready-pass-never-triggers: the
+first live run skipped the whole pass because nothing solicited a pick). Pull
+the untriaged and needs-human slices (`spor next --readiness untriaged`,
+`--readiness human`, or the `counts_by_readiness` lead you already have from
+pass 1), present the top ~5 as make-ready candidates — one line each: the item
+and the gap you can already see from its why-line/reasons — and ask which to
+work, recommending the highest-ranked unblockers. Picking stays the human's;
+skipping the proposal is not an option unless both buckets are empty (then say
+so in the outcome).
+
 For each chosen item:
 
 - **Brief it** — `spor brief <id>` (or `query_graph root_id=<id>`) — pulling