@passioncode-ai/fabric-agent-adapter 0.73.0 → 0.75.0

package/CHANGELOG.md

@@ -1,5 +1,177 @@
 # Changelog
 
+## 0.75.0 (2026-11-07)
+
+Guidance only: no kit module, probe rule or hook changes; the contract pin stays `18f8d487`.
+
+### Added
+
+- **The Fabric communication agent template** (FAA-262, the operator's decision of 2026-11-07):
+  `creating-fabric-agents/references/communication-agent-template.md`, a prompt a coding agent builds a channel agent
+  from (support, sales and leads, community, inbox, store reviews, an internal assistant). It carries the inbound
+  pipeline as one estate measured it on 56 real questions and 19 written batches: a code prefilter, a triage at low
+  thinking that answers only a batch with no ask, one call that analyses, plans and drafts (with the injection check
+  and the product-only scope), the actions, a final pass only when an action returned new facts or an injection is
+  suspected, then the pre-send gates with a checker of another vendor. It also carries the business patterns, the
+  knowledge and data connections (the handoff queue's «a person answered» signal, the account state and version facts
+  as tools of every turn, retrieval over the whole conversation), leads handed to a sales agent of their own that owns
+  the CRM, the learning loop, the model lanes, the Fabric integration and the acceptance with 18 adversarial batches, and maps its sections to the parts of an organization agent template one file can carry (fabric-workspace
+  `knowledge/system/templates.md`, S2; S2's operating rules A1 to A12 apply by reference until the folder, FAA-265). `SKILL.md` links it beside `agents-that-answer-people.md`.
+- A scenario eval (`a-channel-agent-starts-from-the-communication-template`) and a trigger query for it (measured with a
+  real client: creating-fabric-agents 28 of 31, the new query routed right;
+  [record](docs/evidence/evals/2026-11-07-trigger-run.md)), and `test/test_communication_template_prose.py`,
+  which pins the template phrases that scenario grades and checks every event kind it names against the kit's writer.
+
+### Changed
+
+- `references/models-and-providers.md`: a new agent's model key gets USD 100 a month unless the operator names a higher
+  one, and the agent's own stop sits a little under the key's limit (the operator's decision of 2026-11-07).
+  It also names the template's open-vendor rule (every route of a lane reading people's words, fallbacks included) as
+  narrower than DEC-0083, and excepts a channel agent's batch triage from the volume row.
+- The template is linked from the creating-fabric-agents grill row «Does it answer people?» (the row «Who pays?» names
+  the USD 100 default), `agents-that-answer-people.md` and `practices.md`, and named in building-fabric-services
+  `SKILL.md` and the support-agent recipe's README, which now says how the recipe serves the template: the plan's draft carries `[KB:<id>]`
+  markers and the agent runs `check_reply` on it; the checker of another vendor stays the agent's own.
+
+- `agents-that-answer-people.md` A1: every inbound message belongs to one turn; a burst the template batches is one
+  turn listing its message ids (it said every message is a turn). The support-agent recipe's README names what goes in
+  `check_reply`'s `given`: the ids placed in the prompt, never the plan's own list, with tool results as entries of their own.
+- The operator channel's first step (`operator-channel-and-repository.md`, in adapting-projects-to-fabric and
+  creating-fabric-agents) says an agent that answers people on Telegram gives the operator channel a bot of its own,
+  and its example slot is now `EXAMPLE_AGENT_OPERATOR_BOT_TOKEN`.
+- The support-agent recipe's `channel-agent.example.json` final text reads as the standard's final reply (6.6: «we
+  could not confirm this»), not as an answer.
+- `docs/backlog.md`: FAA-263 (SKILL.md word headroom), FAA-264 (the readings' follow-ups that block nothing) and
+  FAA-265 (organization agent templates as folders, W0-Q8).
+- building-fabric-services `references/usage.md`: the every-limit example calls `usage_report` over the ledger's
+  receipts, since the Python `ledger.report` takes no `budgets` (it showed a call that raised `TypeError` since 0.19.0);
+  `test/test_usage_reference_snippet.py` runs it.
+
+### Upgrading
+
+- An answering agent that adopts the template moves every route that reads people's text to an open-vendor model,
+  fallbacks included (template rule 6); one that does not adopt it keeps what DEC-0083 asks. Its monthly stop uses the
+  kit's OpenRouter client with `window="month"` (the default window is a day).
+- Adopting the template starts a new series for `nobodyDropped.turns` (batched turns) and the outcome shares
+  (`customer_silent` up, `no_reply_owed` down); say so in the owner's report, never inside `support.quality_daily`.
+- A declaration copied from the 0.74.0 support-agent example replaces its `texts.final`, which claimed an answer.
+- An agent whose operator channel shares its answering bot moves the operator channel to a bot of its own (a new token
+  slot and link code), and binds the operator's id on the answering bot by its own link code (CA-8).
+
+## 0.74.0 (2026-11-07)
+
+The contract pin moves to `18f8d487` (`v0.1.0+2026-11-07.1`) from `eac1a594` (`v0.1.0+2026-11-06.1`); between them
+only DEC-0154 (several OS accounts on one computer). `eac1a594` stays in `SUPPORTED_CONTRACT_COMMITS`, so bundles
+issued under it stay valid; a new scaffold writes `18f8d487`.
+
+### Added
+
+- **The listener's owner before a credential** (FAA-226, the contract's DEC-0154 HA-2). Loopback is one per computer,
+  not one per OS account, so every kit client that sends a credential to `http://127.0.0.1:<port>` first tells the
+  owner of the server end of its own connection from the computer's socket table, and sends nothing to another OS
+  account's process, root's, SYSTEM's, or one whose owner cannot be told (`foreign-user`):
+  - a new layer-L0 module, `fabric_peer_owner` / `fabric-peer-owner.mjs`. The Python file is Project Observatory's
+    `peer_owner.py` 1.1.0, vendored by commit (`f86f0622`, the same licence), with `Owner` and `Row` as NamedTuples so
+    the module loads by its path and `Optional[X]` in its signatures for the Python 3.9 floor; it reads macOS through `sysctl net.inet.tcp.pcblist_n` (calibrated on a connected pair
+    of its own, else `netstat -anv`), Linux through `/proc/net/tcp` and `/proc/net/tcp6`, Windows through
+    `GetExtendedTcpTable` and the owner's SID. The Node twin reads `netstat -anv` and `ps` on macOS, the same `/proc`
+    files on Linux, `netstat -ano`, `whoami /user` and a PowerShell `GetOwnerSid` (SIDs, never names) on Windows; `checkedSocket` and `CheckedAgent` check a connection
+    before a byte is written. Both twins answer the same questions over `test/fixtures/peer-owner/peer-owner-cases.json`.
+  - `check_service.py`: a new rule for a local placement, `listener.owner`, the first that reads the port, from the server end of a connection
+    of the probe's own on which nothing is sent: `PASS` for this OS account's process,
+    `FAIL` `foreign-user` (then no rule reads the port and no token is sent), `NOT_RUN` when nothing listens. Every
+    local request goes on a checked connection.
+  - the hub client (`fabric_hub.post_mcp`, `postMcp`): `HubError` code `foreign-user`, retryable, before the bearer; the
+    live pid in `hub.json` stays a precondition and is never the proof. The Node client keeps a checked connection
+    alive (closed after 2 s idle), so a busy session reads the socket table once per connection.
+  - `fabric_http` / `fabric-http.mjs` for a plain `http://` loopback URL: `HttpError` kind `foreign-user`, never
+    retried; the Node twin sends such a request through `node:http` on a checked connection instead of `fetch`.
+  - `check_dashboard_layout.mjs` before it asks a local service for a login code (a copy of that file alone, without
+    the kit beside it, sends nothing to an origin that is not `https://`).
+  - the launchd installers' poll: a listener of another account is never a successful install; the error names
+    `foreign-user`.
+
+### Upgrading
+
+- `check_service.py` prints one more line for a local service (`listener.owner`), and a local service whose port is
+  held by another OS account's or root's process, or by one whose owner cannot be told (a sandbox without `sysctl` or
+  `netstat`, a socket launchd holds for a socket-activated job), now fails (exit 1) where 0.73.0 read its answer.
+  When the port's rules cannot be read (that FAIL, or a well-known document that gives no answer), one `port.rules`
+  `NOT_RUN` line names them, where 0.73.0 left them out of the report.
+  A socket-activated job's listening socket belongs to whoever created it: a systemd user unit's to this account, a
+  system unit's and launchd's to root (pid 1), so such a service binds its own listener or runs as a user unit.
+- `fetch_well_known` (re-exported by `fabric_service`) answers `None` for a listener of another account, and
+  `launchd_install` / `launchdInstall` now raises, naming `foreign-user`, where 0.73.0 returned success when another
+  account's copy of the service answered on the port.
+- The Node `fabric-http.mjs` sends a plain `http://` loopback request through `node:http` on a checked connection, not
+  `fetch`: a caller or test that stubs the global `fetch` for a loopback URL is no longer reached (pass `transport`).
+- On a computer with more than one counted OS account a loopback caller with no token is not T0 until the door checks
+  its peer's account (the pinned HA-3 and DL-25; the kit's own peer check is FAA-227): pass `tier="T0"` to `gate` or
+  `server.handle` there only for a caller the descriptor token authenticated (`references/delegation.md`).
+- Services that vendored 0.73.0 kit files keep sending to loopback unchecked until their copies are refreshed
+  (`fabric_kit.py status` names them `older`). `fabric-supervisors.mjs` exports `wellKnownOf` and `ForeignUserAnswer`
+  (new names), and `fabric_peer_owner` reports its version as `1.1.0+kit.1`.
+- `fabric_http`, `fabric-http.mjs` and the hub client refuse a loopback listener of root or a service account too (a
+  rootful container proxy in front of a local model gateway, for one): use a rootless runtime or a forwarder of your own
+  account. The Python `fabric_http` no longer sends a loopback URL through a proxy from the environment (`http_proxy`).
+- `fabric_peer_owner` is now imported by `check_service.py`, `fabric_hub`, `fabric_http`, `fabric_supervisors` and the
+  Node `fabric-hub.mjs`, `fabric-supervisors.mjs` and `fabric-http.mjs` (which imported no kit module before): a project
+  that refreshes vendored copies file by file takes each module's `kit.json` closure, or the import fails.
+- A socket table over 4 MiB cannot be read (about 6,800 TCP sockets for the Python reader on macOS, 617 bytes each in
+  `pcblist_n`; about 19,000 for `netstat -anv`, the Node reader there; about 28,000 in Linux's `/proc/net/tcp`), so every loopback send fails closed as `foreign-user` on such a host.
+- On Linux the server end of an accepted connection is told by its own row (the uid of the process that accepted it),
+  and of one not accept()ed yet, which `/proc` prints with uid 0 and inode 0, by the listener row on its local address
+  (state 0A; the exact address, else the wildcard), as Observatory's `peer_owner.py` 1.2.0 reads it; the contract's
+  CT-254 is settling HA-2's Linux row (FAA-258). A client row with inode 0 (a closed client) reads `unknown`. Several
+  listening rows of one owner (SO_REUSEPORT workers, an IPv4 and an IPv6 socket of one process) read as that owner;
+  rows of two owners stay `unknown`.
+- A `/proc` read that sockets came and went under can print a row twice or skip one (Linux resumes it by position):
+  rows equal in every field count once, and a `/proc` question that finds no row or several reads the table once
+  more before it answers `unknown`. Without it a busy Linux host refused its own service now and then.
+- The Python module imports `ctypes` only where it reads with it, so a CPython built without libffi still imports
+  every kit module; the owner check then reads `netstat` on macOS and fails closed on Windows.
+- A client running as root or SYSTEM reads root's or SYSTEM's listener as its own account's (launchd's pid 1 stays
+  `system`): the vendored module put the system rule first, which would have refused a root container's own sidecar.
+- The hub client and `fabric_http` refuse a loopback listener whose owner cannot be told (a socket table the process
+  cannot read): nothing is sent. Fail closed, as HA-2 asks.
+- A copy of `check_dashboard_layout.mjs` alone refuses a `--service` whose origin is not `https://`; run it from the
+  kit's folder. Which way a request goes follows its origin, not the descriptor's `placement`: a descriptor that says
+  `remote` with an `http://` origin is asked through the checked transport too.
+- A service's own `<tool> mcp-register` now establishes that the listener is this OS account's before it writes the
+  token (`references/surfaces-and-auth.md`: `fabric_peer_owner.server_end` on a connection it opens and sends nothing
+  on, as `listener.owner` does; `foreign-user` writes nothing). The kit ships no `mcp-register` helper: one written for
+  0.73.0 or earlier writes the token unchecked until its author adds the check.
+- Every new checked loopback connection from the Node twin starts processes: on macOS `netstat -anv` and `ps` (about
+  20 to 35 ms), on Windows `netstat -ano` twice and one PowerShell `GetOwnerSid` (5 s cap each, not yet measured,
+  FAA-256). The hub client keeps its checked connection alive; `fabric-http.mjs` does not, so each loopback request
+  pays it.
+- The Python `fetch_well_known` answers `None` both when nothing listens and for a `foreign-user` listener; a status
+  command that must report `foreign-user` (the order `down`, `foreign-user`, `foreign`, then `status`) asks
+  `fabric_peer_owner.server_end` itself, or uses the Node `wellKnownOf`, which answers `ForeignUserAnswer` (FAA-259).
+- The Python `launchd_install` polls through the module's `_read_well_known`, no longer through `fetch_well_known`:
+  a test that faked the poll by patching `fabric_supervisors.fetch_well_known` now makes real connections and times out
+  (the Node `launchdInstall` still takes an injected `fetchWellKnown`; FAA-259 gives Python the same).
+
+### Changed
+
+- `references/protocol.md` gains "The listener's owner (DEC-0154 HA-2)"; `references/board.md`, `references/lifecycle.md`,
+  `references/kit-modules.md` and `SKILL.md` name the check. `references/surfaces-and-auth.md` gives `mcp-register` the
+  check, `references/interop.md`'s real-client gate waits for `listener.owner` PASS, and the README's MCP quick start
+  writes the client config only after the probe passes.
+- The test fake hub keeps HTTP/1.1 connections with no Nagle delay, as a Node server does by default (whether Fabric's
+  own hub keeps idle connections past the Node client's 2 s is FAA-256).
+- `dashboard-links.md` (all three copies) opens a raw loopback address in a browser only after the listener is this OS
+  account's (the pinned PL-3); the link gate enforcing it is FAA-251. `connectors.md` names the loopback owner check
+  and the kind `foreign-user`; the skill card's Network row names the socket table the kit now reads; `SKILL.md` and
+  `references/lifecycle.md` read a service's identity only from this account's listener, with a scenario eval for a
+  port another account holds; `references/delegation.md` says when a token-free loopback caller is T0 (HA-3);
+  `SECURITY.md` names the socket-table reads and the programs the kit now starts. Owed, each its own row: FAA-251 (the
+  link gate), FAA-252 (a running board session's reason), FAA-253 (the systemd and Task Scheduler installers' poll),
+  FAA-254 (working-with-fabric's "Fabric is up"), FAA-255 (the delegation key set read over loopback), FAA-256 (the Node
+  check's cost on Windows), FAA-257 (the OpenRouter connector reports a refused loopback gateway as no answer), FAA-258 (re-pinning
+  to CT-254 once it is tagged and reconciling with Observatory's `peer_owner.py` 1.2.0), FAA-259 (the Python
+  `fetch_well_known` telling `foreign-user` from `down`), FAA-260 (the readings' smaller follow-ups).
+
 ## 0.73.0 (2026-11-07)
 
 ### Added

package/README.md

@@ -70,7 +70,9 @@ installed into a service with `scripts/fabric_kit.py install` and checked with `
 the dates API); connectors for outbound HTTP and OpenRouter (`fabric_http`, `fabric_openrouter`: one deadline, safe
 retries, the agent's own key, a spend ceiling before every attempt, usage receipts, a fallback model;
 [connectors](plugins/fabric-agent-adapter/skills/building-fabric-services/references/connectors.md)); the draft-and-check step of a support agent as a
-[recipe](plugins/fabric-agent-adapter/skills/building-fabric-services/recipes/support-agent/README.md);
+[recipe](plugins/fabric-agent-adapter/skills/building-fabric-services/recipes/support-agent/README.md)
+(the whole agent starts from creating-fabric-agents'
+[communication agent template](plugins/fabric-agent-adapter/skills/creating-fabric-agents/references/communication-agent-template.md));
 a complete `scripts/sample_service.py`; and `scripts/check_service.py`, a live probe. A service that answers
 requests other Projects post to its Project on Fabric's project board uses the board responder
 (`scripts/fabric_hub.py` and `scripts/fabric_board.py`, Node `fabric-hub.mjs` and `fabric-board.mjs`): the
@@ -188,8 +190,9 @@ KIT=plugins/fabric-agent-adapter/skills/building-fabric-services/scripts   # or
 DATA=$(mktemp -d); SERVICES=$(mktemp -d); WORK=$(mktemp -d)
 python3 "$KIT/sample_service.py" serve --port 47190 --data-dir "$DATA" &
 python3 "$KIT/sample_service.py" register --port 47190 --data-dir "$DATA" --services-dir "$SERVICES"
-python3 "$KIT/check_service.py" sample --services-dir "$SERVICES"   # exit 0: no FAIL
-# Register the service for one client run; the token goes in a header, never in argv.
+# The probe exits 0 (no FAIL); only then is the service registered for one client run (listener.owner proves the port
+# is this account's, and the client cannot check it). The token goes in a header, never in argv.
+python3 "$KIT/check_service.py" sample --services-dir "$SERVICES" && \
 python3 - "$DATA/service.token" "$WORK/mcp.json" <<'EOF'
 import json, os, sys
 token = open(sys.argv[1]).read().strip()
@@ -203,9 +206,10 @@ EOF
 kill %1
 ```
 
-Verified 2026-10-01 from the published npm package 0.5.4 (`npx` into a throwaway hub, `KIT`
-pointing at the installed skill) with Claude Code 2.1.286: the probe reported 27 rules, 0 FAIL;
-the CLI connected to the sample over streamable HTTP, called `sample.echo` and printed `ping`. The probe prints one line per rule
+Verified 2026-11-07 from the published npm package 0.74.0 (`npm pack` into a throwaway folder, `KIT`
+pointing at its skill) with Claude Code 2.1.299: the probe reported 44 rules, 0 FAIL, `listener.owner` PASS;
+the CLI connected to the sample over streamable HTTP, called `sample.echo` and printed `ping`
+([record](docs/evidence/runs/2026-11-07-0.74.0-quick-start.md)). The probe prints one line per rule
 (`PASS`, `FAIL` or `NOT_RUN` with its evidence) and exits 1 on any `FAIL`; run it against your
 own service by its id once its installer has written the descriptor.
 `FABRIC_REAL_CLIENT=1 python3 -m unittest discover -s test -p test_real_client.py` repeats the connection check
@@ -301,7 +305,7 @@ Scaffolding is non-destructive by default. It writes only the paths declared in
 The default pin for new bundles is [`fabric-contract.lock.json`](fabric-contract.lock.json):
 
 - version: `0.1.0`
-- commit: `eac1a594aa131851f079da8bb7b2149e1951f35f`
+- commit: `18f8d48762edc5bfb1433657cbfe1c16196df1a6`
 
 Every other mention of the default contract revision (this section, the skills' metadata, the
 skill card, `adapt_project.py`) must equal it; `python3 test/validate.py` fails a tree

package/SECURITY.md

@@ -32,6 +32,23 @@ bounded and non-publishing until explicit scoped grants exist in a project bindi
   external APIs the service's author configures, such as OpenRouter, with keys the service
   reads by name at run time; the kit itself calls no outside host on its own. A board
   responder talks only to Fabric's hub on loopback.
+- Before `check_service.py`, the hub client, `fabric_http` (a plain `http://` loopback URL),
+  `check_dashboard_layout.mjs` (a local login code) and the launchd installers' poll send
+  anything to `127.0.0.1:<port>`, they read the computer's socket table to tell which OS
+  account owns the listener (DEC-0154 HA-2, `fabric_peer_owner`), and send nothing to
+  another account's, root's, SYSTEM's or an untellable listener. They read, never change:
+  macOS `sysctl net.inet.tcp.pcblist_n` in the process, or the programs `/usr/sbin/netstat
+  -anv -p tcp` and `/bin/ps -o uid= -p <pid>` (the Node twin always); Linux
+  `/proc/net/tcp` and `/proc/net/tcp6`; Windows `GetExtendedTcpTable` and the process
+  token (Python), or `netstat -ano`, `whoami /user` and one PowerShell `GetOwnerSid` query
+  per new connection (Node). A token-free loopback door is not yet protected against
+  another account's process (HA-3, FAA-227). An MCP client (Claude Code, Codex) sends the
+  token it was registered with on every later connection without this check (the contract's
+  residue "a coding agent's bearer"): when the port may have changed hands, rotate the token
+  and re-run `mcp-register` (one written as `references/surfaces-and-auth.md` says checks the
+  listener first; the kit ships none). On Linux `/proc` names a socket's creator and
+  no pid, so a listening socket root created and handed to another account (systemd
+  socket activation with `User=`) reads as root's: a client running as root sends to it.
 - The working-with-fabric PostToolUse hook (FAA-206) reads only the release call Claude Code gives it on stdin (the
   tool's name, its input, which can carry the agent's note, and Fabric's answer), in memory: it writes, logs and sends
   nothing and prints one fixed line or nothing.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@passioncode-ai/fabric-agent-adapter",
-  "version": "0.73.0",
+  "version": "0.75.0",
   "description": "Create Fabric-compatible agents, run them as always-alive local services with dashboards (fabric-service/0.1), and adapt existing projects to the Fabric Agent Contract. This package is the installer CLI.",
   "scripts": {
     "test": "python3 test/validate.py && python3 -m unittest discover -s test -q && node --test 'test/*.test.mjs'"

package/plugins/fabric-agent-adapter/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "fabric-agent-adapter",
   "displayName": "Fabric Agent Adapter",
   "description": "Create new Fabric-compatible agents, build them as always-alive local services with dashboards (fabric-service/0.1), and adapt existing projects to the Fabric Agent Contract through evidence-backed MCP, A2A, or local-runner provider bundles; and teach a coding agent to work in a project through Fabric (fabric-mcp, fabric_whoami, claim and release), with Claude Code session hooks.",
-  "version": "0.73.0",
+  "version": "0.75.0",
   "author": {
     "name": "PassionCode.ai",
     "url": "https://passioncode.ai/"

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/SKILL.md

@@ -5,9 +5,9 @@ license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 compatibility: Requires filesystem access and Python 3.9+. Exact schema checks additionally need git, Node.js, pnpm, and the pinned fabric-agent-contract checkout (a public repository). Works without those tools in an explicitly degraded structural-check mode.
 metadata:
   author: PassionCode.ai
-  version: "0.73.0"
+  version: "0.75.0"
   contract-version: "0.1.0"
-  contract-commit: "eac1a594aa131851f079da8bb7b2149e1951f35f"
+  contract-commit: "18f8d48762edc5bfb1433657cbfe1c16196df1a6"
 ---
 
 # Adapting projects to Fabric
@@ -76,7 +76,7 @@ Use exactly:
 
 - contract version `0.1.0`;
 - repository `https://github.com/passioncode-ai/fabric-agent-contract`;
-- commit `eac1a594aa131851f079da8bb7b2149e1951f35f`.
+- commit `18f8d48762edc5bfb1433657cbfe1c16196df1a6`.
 
 This is the default for new bundles. When checking an issued legacy bundle, preserve its
 explicit supported lock and use that exact clean checkout. Never silently upgrade or

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/references/dashboard-links.md

@@ -62,8 +62,12 @@ the fabric-dashboards MCP (`list_services`, never guessed) and hand over the
 `open_link` its `link` tool returns for the page's path; to open it, call the
 host's `open` with `fallback=never`. Never `open <url>`, `open -a Safari`,
 `xdg-open`, `start <url>`, `webbrowser.open` or `shell.openExternal` on this
-agent's pages. A browser only when `host_status` confirms `not_installed`; an
-installed host that failed to open is reported, not replaced by HTTP. Links
+agent's pages. A browser only when `host_status` confirms `not_installed`, and
+a raw `http://127.0.0.1:<port>` address only after the listener on that port is
+this OS account's (DEC-0154 PL-3 and HA-2; the adapter's `building-fabric-services/scripts/fabric_peer_owner.py`: `server_end` of a connection it opens and sends nothing on; `check_service.py <id>.<instance>` prints it as `listener.owner`): a
+`foreign-user` listener is reported, never opened (the link gate below does not
+read the owner yet, FAA-251). An installed host that failed
+to open is reported, not replaced by HTTP. Links
 carry no token or login code. Every completion and notification action passes
 the Fabric Agent Adapter's link gate before delivery: `check_dashboard_link.py`
 in its `building-fabric-services/scripts`, run from that skill's directory;

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/references/operator-channel-and-repository.md

@@ -12,9 +12,10 @@ its stops with buttons: `fabric-operator-channel/0.1` (contract DEC-0034,
 `docs/specification/operator-channel.md`), whose rule OC-11 this follows. Give the operator's four
 steps:
 
-1. create a bot with @BotFather;
+1. create a bot with @BotFather (for an agent that answers people on Telegram, a bot of its own, never
+   the bot that answers people: the contract's channel-agent.md);
 2. put its token into the operator's secret store (Project Observatory where it is installed) under
-   the name the agent reads (for example `EXAMPLE_AGENT_TELEGRAM_BOT_TOKEN`), never into a chat, a
+   the name the agent reads (for example `EXAMPLE_AGENT_OPERATOR_BOT_TOKEN`), never into a chat, a
    file or the bundle;
 3. run the agent's link command;
 4. type the code it shows in the chat with the bot.

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/scripts/adapt_project.py

@@ -22,10 +22,10 @@ import fabric_secrets as _secrets  # noqa: E402 - the contract's credential dete
 
 CONTRACT_VERSION = "0.1.0"
 CONTRACT_REPOSITORY = "https://github.com/passioncode-ai/fabric-agent-contract"
-CONTRACT_COMMIT = "eac1a594aa131851f079da8bb7b2149e1951f35f"
+CONTRACT_COMMIT = "18f8d48762edc5bfb1433657cbfe1c16196df1a6"
 # #region supported-contract-revisions — docs: README.md#contract-pin
 # Only this declaration may name a legacy revision in live files.
-SUPPORTED_CONTRACT_COMMITS = (CONTRACT_COMMIT, "3830a3353923e20f826d466610e1c479f120bec0", "00e050ba7429c0c60261cec871779e0fd6aeeb28", "1197a90dc4b57152cabcc71ad17db7559f35a27f", "e6c4fc16b415eec3190dd34d924d269405359dc9", "a3a66eb0052043847f6556348e37d34ca873a629", "52c7d798b9f4eb784eb4e29e717038a8912c759d", "2f020a696453ae299b123517f14957f6a1354379", "87d384ffce2757081b7ab227e5dad3dddd08328f", "0a4ce773c4b9e6bec40c6387eb3f988af7152c0e", "e742016dc396aa31e5a13a893489e43f15786c69", "bfa9a67aa3c6cb808c093e7d83cd59799f1ee7d0", "c55f2d5a11c9a0197e958e87212fca7ae1154769", "07042181bfae2a481aa0da1a5651f24c76669c48", "d8146cfb0a1c74fc6432284c4356bb0c864b37b5", "82e163665e156a08aa3b92e4711015582c06162c", "1636fa97262f4a26e2086572d540c2ee701e0010", "f00a7685e3861c27f7899c033fb850a145a1708f", "a046f57cf46ea9e3da57ff8ce6a3ed4d26d8774b", "fe55fc67cba1a9e34a736da7d148d4fe2a8fbfa0", "b291bf09e0a9f9fd3c16cf540832cd021203b7d1", "0cacd08b0e95b6abf131eae1206b60792138bc3c", "2eb91c00e852d9c31d804310d38fad91589fcbac", "8e49fbd5fbbf230e32c1969cd24ac3c22422f0a5", "a83bec6b47776af688402c18efec507143061f68", "52da526d7cc1e063d74c5b520dbc03d0ace15246", "78b2da018d2c4bd9ac1bde1dc3b7f1a110a175f5", "623bf61358c339cb10297807b3f024b5d9f1f327", "23f9fda4c05f8a3852246ee98d4f2adf74ed0875", "9091d3d6606b0c4b5591a38c3674356a01fd7f55", "df55c8c54a23251342a7ee57ba95642b7eb39e61", "2ce392291c6668598d12cd38327e24696b5ca15c")
+SUPPORTED_CONTRACT_COMMITS = (CONTRACT_COMMIT, "eac1a594aa131851f079da8bb7b2149e1951f35f", "3830a3353923e20f826d466610e1c479f120bec0", "00e050ba7429c0c60261cec871779e0fd6aeeb28", "1197a90dc4b57152cabcc71ad17db7559f35a27f", "e6c4fc16b415eec3190dd34d924d269405359dc9", "a3a66eb0052043847f6556348e37d34ca873a629", "52c7d798b9f4eb784eb4e29e717038a8912c759d", "2f020a696453ae299b123517f14957f6a1354379", "87d384ffce2757081b7ab227e5dad3dddd08328f", "0a4ce773c4b9e6bec40c6387eb3f988af7152c0e", "e742016dc396aa31e5a13a893489e43f15786c69", "bfa9a67aa3c6cb808c093e7d83cd59799f1ee7d0", "c55f2d5a11c9a0197e958e87212fca7ae1154769", "07042181bfae2a481aa0da1a5651f24c76669c48", "d8146cfb0a1c74fc6432284c4356bb0c864b37b5", "82e163665e156a08aa3b92e4711015582c06162c", "1636fa97262f4a26e2086572d540c2ee701e0010", "f00a7685e3861c27f7899c033fb850a145a1708f", "a046f57cf46ea9e3da57ff8ce6a3ed4d26d8774b", "fe55fc67cba1a9e34a736da7d148d4fe2a8fbfa0", "b291bf09e0a9f9fd3c16cf540832cd021203b7d1", "0cacd08b0e95b6abf131eae1206b60792138bc3c", "2eb91c00e852d9c31d804310d38fad91589fcbac", "8e49fbd5fbbf230e32c1969cd24ac3c22422f0a5", "a83bec6b47776af688402c18efec507143061f68", "52da526d7cc1e063d74c5b520dbc03d0ace15246", "78b2da018d2c4bd9ac1bde1dc3b7f1a110a175f5", "623bf61358c339cb10297807b3f024b5d9f1f327", "23f9fda4c05f8a3852246ee98d4f2adf74ed0875", "9091d3d6606b0c4b5591a38c3674356a01fd7f55", "df55c8c54a23251342a7ee57ba95642b7eb39e61", "2ce392291c6668598d12cd38327e24696b5ca15c")
 # #endregion supported-contract-revisions
 INTEROP_KEY = "https://fabric.passioncode.ai/agent-contract/extensions/interop/0.1"
 MCP_REVISION = "2026-07-28"

package/plugins/fabric-agent-adapter/skills/building-fabric-services/SKILL.md

@@ -14,10 +14,10 @@ license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 compatibility: Python 3.9+ or Node.js 20+ for the kits (Node.js 22+ for a Linux service's instance lock); the probe needs Python 3.9+. launchd steps are macOS-only; Linux services install a systemd user unit and Windows ones a per-user Scheduled Task with the kits' writers. Dashboard handoff optionally uses Fabric Dashboards MCP link/host_status/open; without it, report unresolved host capability. The contract checkout is optional.
 metadata:
   author: PassionCode.ai
-  version: "0.73.0"
+  version: "0.75.0"
   contract-version: "0.1.0"
   extension: "fabric-service/0.1"
-  extension-commit: "eac1a594aa131851f079da8bb7b2149e1951f35f"
+  extension-commit: "18f8d48762edc5bfb1433657cbfe1c16196df1a6"
 ---
 
 # Building Fabric services
@@ -71,7 +71,7 @@ Answer before writing code, and record the answers in the project README:
 
 | Caller | Surface | Why |
 |---|---|---|
-| Another agent on this machine | MCP `2026-07-28`, `streamable-http`, at `/mcp` on the service origin, token in a header | one process serves every session (stdio-per-session once left twenty stray servers) |
+| Another agent on this machine | MCP `2026-07-28`, `streamable-http`, at `/mcp` on the service origin, token in a header | one process serves every session; `mcp-register` checks the listener (HA-2) first |
 | The operator or a script | a CLI: `<tool> service status\|start\|stop\|restart`, `<tool> dashboard` (opens only in Fabric Dashboards, below), `<tool> doctor --json` | every verb delegates to launchd and the well-known document, never to its own process table |
 | A remote agent | A2A `1.0` over HTTPS, or MCP behind an authenticated gateway | loopback reachability is not authorization |
 | An A2A peer on this computer | `surfaces.a2a` names a public Agent Card, served without the token; its interface URLs are loopback (DEC-0122); the kits read it, serving one is FAA-10 | the card carries no credential, process member or required Fabric extension |
@@ -168,8 +168,8 @@ handler.
 Calling out: [the connectors reference](references/connectors.md) (`fabric_http` with one
 deadline, safe retries and a size cap; `fabric_openrouter` with the agent's own key, a
 spend ceiling before every attempt, receipts and a fallback). The draft-and-check step of a
-support agent on the kit: [`recipes/support-agent/`](recipes/support-agent/README.md); what the whole agent carries is
-creating-fabric-agents' `references/agents-that-answer-people.md`.
+support agent on the kit: [`recipes/support-agent/`](recipes/support-agent/README.md); the whole agent starts from
+creating-fabric-agents' `references/communication-agent-template.md` (parts: `agents-that-answer-people.md`).
 
 Startup order is the part that goes wrong; keep it exactly:
 
@@ -220,7 +220,7 @@ The installer, not the service, owns the plist and the descriptor. Sequence:
    (`launchd_uninstall`, `remove_descriptor`) as soon as its check is done, not left running.
 2. `launchd_plist(...)` then `launchd_install(...)`: writes and lints the plist,
    `bootout` and waits for the unload, `bootstrap` with retries on the transient I/O
-   error, then polls the well-known document until it answers with **this** identity.
+   error, then polls the well-known document until **this** identity answers on this OS account's listener (HA-2).
    A label the operator disabled stays disabled: only a first install enables.
 3. Uninstall: `launchd_uninstall` (waits for the unload, removes the plist, resets the
    override; `purge=True` removes data only when the operator asks), `remove_descriptor`.
@@ -292,14 +292,14 @@ directory, restores only on a fresh database and never overwrites. Read
 
 ## Step 6: verify
 
-Run the probe against the live service: it reads the descriptor, then checks every
-rule it can reach and says which it could not:
+Run the probe against the live service; it checks every rule it can reach and names
+those it could not:
 
 ```bash
 python3 <skill-dir>/scripts/check_service.py <id>[.<instance>]
 ```
 
-It reports `PASS`, `FAIL` or `NOT_RUN` per rule (descriptor, port claim, `descriptor.source-repository`,
+It reports `PASS`, `FAIL` or `NOT_RUN` per rule (descriptor, port claim, `descriptor.source-repository`, `listener.owner` (HA-2), `port.rules`,
 `well-known.connections`, well-known
 shape, identity, latency, Host/Origin/cross-site guards, loopback bind, token file,
 events auth and shape, single-use login, state outside code, instance lock, plist,
@@ -409,28 +409,27 @@ this estate needs.
 - **A desktop app with no supervisor** (DEC-0069): its descriptor says `manager: "person"` with `lifecycle.app`, no
   origin, `installedBy {by: "person", role, tool}`, `source.repository` (the lifecycle reference, *An app's own
   descriptor and the node*).
-- **No Python:** use the Node kit; run the probe from any machine that has Python and
-  can reach the port, or mark the probe `NOT_RUN` with the reason.
+- **No Python:** use the Node kit; run the probe where Python reaches the port, or mark it `NOT_RUN`
+  with the reason.
 - **Neither kit fits the framework:** implement the four routes and the lock by hand
   against [the protocol reference](references/protocol.md); the probe is the judge.
 - **No contract checkout:** the protocol reference is pinned to the extension commit
   in this skill's metadata; do not reconstruct fields from memory.
-- **Fabric Dashboards not installed:** nothing changes; the service is complete
-  without a host; the descriptor waits for one.
+- **Fabric Dashboards not installed:** nothing changes; the descriptor waits for a host.
 
 ## Gotchas
 
 - `lsof` shows `*:<port>` or `0.0.0.0` → the bind is wrong even if the Host check works.
-- A health probe that only checks HTTP 200 accepts any program on the port: compare
-  `service.id` and `service.instance`.
+- HTTP 200 alone accepts any program on the port: compare `service.id` and `service.instance`, read only from
+  this OS account's listener. On `listener.owner` FAIL (`foreign-user`) send that port nothing.
 - `launchctl bootstrap` right after `bootout` fails with I/O error 5: wait for the unload, then retry.
 - Under launchd `PATH` is bare. Pin the interpreter by absolute path; set `PATH`
   explicitly in the plist; never copy the whole shell environment into it.
 - A plist pointing at a worktree or checkout breaks when it moves: point it at a release.
 - `http.server.HTTPServer` resolves its FQDN between `bind()` and `listen()`: with a slow
   resolver (a macOS CI runner, a Mac offline) the port is bound but silent. Use `fs.LoopbackHTTPServer`.
-- `logging.basicConfig` called twice: the second is a no-op, the server's log file
-  stays empty. Configure logging once, in the entry point.
+- `logging.basicConfig` called twice: the second is a no-op and the log stays empty. Configure logging once, in
+  the entry point.
 - Hand-made `.plist.bak` files in `~/Library/LaunchAgents` are never cleaned up; keep
   backups elsewhere.
 

package/plugins/fabric-agent-adapter/skills/building-fabric-services/recipes/support-agent/README.md

@@ -1,7 +1,19 @@
 # Recipe: the draft-and-check step of a support agent
 
 A service answers one inbound question from its own knowledge file, or hands it to a person. It is a step of an
-agent that answers people, not that agent: see the paragraph after the table. Built only on the service
+agent that answers people, not that agent: see the paragraph after the table. Under the creating-fabric-agents
+template (`communication-agent-template.md`) the plan-and-draft call writes the draft, not this recipe's `answer()`:
+the draft carries a `[KB:<id>]` marker for each knowledge id the plan used, and the agent runs `check_reply(draft,
+question, prompt_ids, max_chars=..., sources=...)` on it for the code checks. `prompt_ids` are the ids of the items
+placed in the plan's prompt, never the plan's own list (an id the plan names outside them is held as a suspected
+injection); each tool result of the turn enters both under an id of its own, with its system-of-record fields only, never one
+a customer wrote (`tool.order`; the citation takes letters,
+digits, dot, dash and underscore, no colon; knowledge ids too, so map one that does not). Every template turn that went through the plan runs
+`check_reply` on its final text, except an off-topic plan, a plan whose only actions are ask_clarification or handoff,
+and a triage reply: the route decides, never the draft's markers. The final pass keeps the markers. A handle
+(`@name`) is not one of `check_reply`'s claims: it is the agent's own gate. Repair of a plan draft, and the
+checker of another vendor, stay the agent's own (agents-that-answer-people.md): the recipe's `repair=` reruns only its
+own `answer()` draft, and it has no checker. Built only on the service
 kit: `fabric_openrouter` for the model, `fabric_usage` for receipts, `fabric_paths` for private, atomic state.
 Tests: `test/test_support_agent_recipe.py` (a fake model; no network, no key).
 
@@ -130,7 +142,7 @@ FAC-SEM-162 to 165 (rule `channel-agent.declaration`).
 | `stateDir` | the decisions (`decisions.jsonl`), the handoff outbox (`handoffs.jsonl`) and the usage ledger (`usage.jsonl`) |
 | `model`, `fallback` | two models of different vendors; a lane that reads what customers write runs on an open-vendor model (DEC-0083) |
 | `keyEnv` | the environment variable that holds the agent's own OpenRouter key; never a value in the file |
-| `ceilingUsd`, `window` | the spend ceiling per UTC `day` or `month` |
+| `ceilingUsd`, `window` | the spend ceiling per UTC `day` or `month` (`month` under the communication agent template, under the key's monthly limit) |
 | `prices` or `catalog` | USD per token per model. The example's prices are placeholders, not OpenRouter's: take them from `GET https://openrouter.ai/api/v1/models` (a saved catalog file named in `catalog` is read with `prices_from_catalog`). A model without a price is never called |
 | `maxTokens`, `maxChars` | the output budget per call and the reply's length limit |
 

package/plugins/fabric-agent-adapter/skills/building-fabric-services/recipes/support-agent/channel-agent.example.json

@@ -59,7 +59,7 @@
                 "en": "Thank you, we are looking into it and will answer here."
               },
               "final": {
-                "en": "Here is the answer to your question. Write again if anything is still unclear."
+                "en": "We could not confirm this. Please write to the support address on our site."
               }
             }
           }

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/board.md

@@ -35,7 +35,10 @@ operator gives in Fabric (Agents & access): callee `fabric`, capability `board.r
    binding credential, shown once, goes into `credential_file` (0600, atomic) and never into the answer, a log or argv.
    Keep the file in the service's data directory or the operator's vault.
 3. Each connection joins with `fabric.board.join {projectId}` (`join_board` / `joinBoard`). It re-reads `hub.json`,
-   checks the pid it names is alive, and only then sends the credential. A missing grant is `HubError` code
+   checks the pid it names is alive, tells the owner of the door's listener from the socket table (DEC-0154 HA-2:
+   another OS account's process, or one whose owner cannot be told, is `HubError` code `foreign-user`, retryable, with
+   nothing sent), and only then sends the credential (a session already running maps that refusal, as any transport
+   failure, to `board.down` with reason `unreachable` until FAA-252). A missing grant is `HubError` code
    `not_authorized` whose `data.ask` holds the arguments to ask with.
 
 ## Wiring it into the service

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/connectors.md

@@ -37,6 +37,7 @@ const answer = await request('GET', 'https://api.example/v1/items', { headers, d
 | The body is read to one byte past `max_bytes`; over it is an error | 8 MiB | a runaway answer never fills memory |
 | Redirects are answered, never followed | | a redirect must not carry the `Authorization` header to another host |
 | Plain `http://` is refused unless the host is loopback or `insecure=True`; credentials in a URL are refused | | a token never crosses a network in clear, nor sits in a URL |
+| Plain `http://` to a loopback host goes on a connection whose server end is this OS account's process, told from the socket table before a byte is sent and never through a proxy from the environment (`fabric_peer_owner`); another account's listener, root's, or one whose owner cannot be told is kind `foreign-user`, nothing sent, never retried. The Node twin sends such a request through `node:http` on a checked connection, not `fetch` | | DEC-0154 HA-2: loopback is one per computer, not one per OS account |
 | Header names must be tokens; a value with a line break or NUL is refused | | header injection |
 | A JSON body is written as `JSON.stringify` writes it: a lone surrogate escaped, NaN and Infinity refused | | both twins send the same bytes |
 | Whatever the transport throws is a connection error, in both languages; a timeout is a timeout | | |
@@ -44,7 +45,7 @@ const answer = await request('GET', 'https://api.example/v1/items', { headers, d
 | `Response.json()` reads as `JSON.parse` does: a byte order mark skipped, `NaN` and `Infinity` refused | | |
 
 Every answer comes back as a `Response`, whatever its status; `HttpError` means no usable answer came, with `kind`
-`connection`, `timeout`, `too-large` or `refused`, the status when there was one, and the URL redacted to scheme,
+`connection`, `timeout`, `too-large`, `refused` or `foreign-user`, the status when there was one, and the URL redacted to scheme,
 host, port and path (`redact_url`); a URL that is not http or https keeps only its scheme (`htps:<redacted>`, and `ssh:<redacted>`
 for `ssh://h:99999/r` too), and an http, https, ws, wss or ftp URL that does not parse (Node reads it with `new URL`;
 Python reads its own special-scheme form and prints what it finds, never the user information), or a value with no

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/dashboard-links.md

@@ -62,8 +62,12 @@ the fabric-dashboards MCP (`list_services`, never guessed) and hand over the
 `open_link` its `link` tool returns for the page's path; to open it, call the
 host's `open` with `fallback=never`. Never `open <url>`, `open -a Safari`,
 `xdg-open`, `start <url>`, `webbrowser.open` or `shell.openExternal` on this
-agent's pages. A browser only when `host_status` confirms `not_installed`; an
-installed host that failed to open is reported, not replaced by HTTP. Links
+agent's pages. A browser only when `host_status` confirms `not_installed`, and
+a raw `http://127.0.0.1:<port>` address only after the listener on that port is
+this OS account's (DEC-0154 PL-3 and HA-2; the adapter's `building-fabric-services/scripts/fabric_peer_owner.py`: `server_end` of a connection it opens and sends nothing on; `check_service.py <id>.<instance>` prints it as `listener.owner`): a
+`foreign-user` listener is reported, never opened (the link gate below does not
+read the owner yet, FAA-251). An installed host that failed
+to open is reported, not replaced by HTTP. Links
 carry no token or login code. Every completion and notification action passes
 the Fabric Agent Adapter's link gate before delivery: `check_dashboard_link.py`
 in its `building-fabric-services/scripts`, run from that skill's directory;

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/delegation.md

@@ -52,7 +52,9 @@ service's own local floor (the descriptor token, the Host guard) has authenticat
 the same owner; **T2** everyone else, and any call relayed onto loopback from off the machine (a tunnel, a proxy, the
 hub forwarding a T2 caller). DL-26: a T0 or T1 caller is never required to present a token; pass the tier,
 `gate(tool, headers, tier="T0")` or `server.handle(message, headers, tier="T0")`, and the call passes with no
-delegation. A token such a caller presents is still verified and refused when invalid. A T2 caller takes the whole
+delegation. On a computer with more than one counted OS account, a loopback caller with no token is T0 only after the
+door checks the peer's account (the pinned DEC-0154 HA-3 and DL-25; the kit's own peer check is FAA-227), so pass
+`tier="T0"` there only for a caller the descriptor token authenticated. A token such a caller presents is still verified and refused when invalid. A T2 caller takes the whole
 profile. Money limits and human gates bind at every tier.
 
 **The family and the agent network** (DEC-0130, wording settled by DEC-0137). The operator's family is every agent

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/interop.md

@@ -77,7 +77,9 @@ untraced work carries no trace pair.
 **Check with a real client**, never only an SDK: `FABRIC_REAL_CLIENT=1 python3 -m unittest
 test.test_real_client` in the adapter repository, or by hand: a throwaway directory, a
 temporary `--mcp-config` (mode 600, the token in a header) and `--strict-mcp-config`, so
-the operator's own configuration is not touched:
+the operator's own configuration is not touched. Write that config only after `check_service.py <id>` reads
+`listener.owner` PASS: the client cannot tell the port's owner, so the side that hands it the token does (DEC-0154
+HA-2):
 
 ```bash
 claude -p "Reply with the single word OK." --strict-mcp-config --mcp-config "$TMP/mcp.json" \

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/kit-modules.md

@@ -59,6 +59,7 @@ A module imports only modules listed before it in `kit.json`, so the kit has no
 | L0 | `fabric_time` | strict RFC 3339, UTC days, formatting, day windows, the clock ([dates](#dates-and-times)) |
 | L0 | `fabric_identifiers` | identifier equality by normal form (DEC-0076) |
 | L0 | `fabric_secrets` | the contract's one credential detector (DEC-0044) |
+| L0 | `fabric_peer_owner` | which OS account owns each end of a loopback connection, from the computer's socket table (DEC-0154 HA-2, FAA-226): `listener`, `server_end`, `peer`, `CheckedHTTPConnection`; the Python file is Project Observatory's `peer_owner.py` 1.1.0 vendored from commit `f86f0622` with the readings its header names (`1.1.0+kit.1`), the Node twin reads netstat, `/proc` and the owner SID where Python reads `sysctl`, `/proc` and `GetExtendedTcpTable` |
 | L1 | `fabric_crypto` | Ed25519 signing (a Montgomery ladder that does not branch on the key) and verification, P-256 verification, base64url, sha256 |
 | L1 | `fabric_base` | the protocol name, `ServiceError`, small shared helpers |
 | L1 | `fabric_platform` | Windows: named pipes, owner-only files (DEC-0032) |

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/lifecycle.md

@@ -48,10 +48,12 @@ refuses a port another instance declares), the service's directories, and comman
 carry a credential. Only `doctor` and `update` are commands a host may run.
 
 **Started is not ready.** Readiness is the well-known document, `GET /.well-known/fabric-service`: answered without
-authentication, from memory, in under 100 ms, with `service.id` and `service.instance` equal to the descriptor's.
+authentication, from memory, in under 100 ms, with `service.id` and `service.instance` equal to the descriptor's,
+on a listener of this OS account (DEC-0154 HA-2: another account's listener is `foreign-user` whatever it answers).
 `status` is `starting`, `ready`, `degraded` or `stopping`; `degraded` is always present, and an empty list asserts
 full health. A process that cannot serve does not answer, and a host derives `down`. An install or upgrade polls
-that document until `service.id` matches (at most 40 s) before it calls the service started.
+that document until `service.id` matches (at most 40 s) before it calls the service started (the launchd installers;
+systemd and Task Scheduler do not poll yet, FAA-253).
 
 | Id | Rule | Here | Kit (Python / Node) |
 |---|---|---|---|
@@ -87,11 +89,15 @@ that document until `service.id` matches (at most 40 s) before it calls the serv
 1. Build or unpack the release into `~/.local/share/<id>/releases/<version>-<sha12>/`
    (a venv or `node_modules` inside it). Never edit a release after it is written.
 2. `write_descriptor` (port and id claims are checked here, and a new descriptor without `source.repository` is
-   refused; a rewrite of an installed one warns, FAA-198).
+   refused; a rewrite of an installed one warns, FAA-198). "Port claim" here is the kit's older sense, a port no other
+   descriptor declares; the pinned contract's HA-1 claim file per OS account, and a port free on the whole computer,
+   are not written or checked yet (FAA-225, after the contract's CT-228).
 3. `launchd_install` (Node: `await launchdInstall(...)`, the same steps): write + `plutil -lint`, read `launchctl print-disabled gui/<uid>`,
    `enable` **only when no override is recorded** (a first install), `bootout` and wait
    until `launchctl print gui/<uid>/<label>` fails, `bootstrap` with up to five retries,
-   then poll the well-known document until it answers with this `id.instance`.
+   then poll the well-known document until it answers with this `id.instance` on a listener of this OS account
+   (DEC-0154 HA-2: another account's listener, or one whose owner cannot be told, is `foreign-user` and never a
+   successful install; the error names it).
 4. Upgrade = new release, rewrite the plist with the new path, `launchd_install`
    again, then `prune_releases(releases_dir, current=<new release>)`: the running release
    and the one before it stay for rollback, older ones go (LC-11, LC-15).