@passioncode-ai/fabric-agent-adapter 0.72.0 → 0.74.0

package/CHANGELOG.md

@@ -1,5 +1,159 @@
 # Changelog
 
+## 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
+
+- **The probe checks a channel agent's declaration** (FAA-197, the contract's DEC-0150): `check_service.py` gains the
+  rule `channel-agent.declaration`, a standard-library port of the contract's FAC-SEM-162 to 165 at the pin
+  (`check_service_channel_agent.py` and `check_service_channel_agent_schema.py`, not kit modules). It reads the
+  declaration from `provider.extensions` of the manifest the descriptor names, else from `extensions` of the
+  well-known answer (CA-1). A declaration with findings fails the rule, its first five shown as code and path, never a
+  declared value; it fails on the obligations of a declaration the contract's reader still reads (FAC-SEM-164) and
+  always on a string shaped like a credential (FAC-SEM-165), in the read declaration or in any copy beside it. Nothing declared, a named manifest that cannot be read,
+  or a declaration read as not declared (a manifest's own `extensions`, a capability's, another version's key, a
+  well-known copy beside a manifest, a form the schema or FAC-SEM-163 refuses, one too large to read for credentials)
+  is `NOT_RUN` with the evidence, never a failure while producers move to this revision, except a string shaped like a
+  credential, which fails in any copy the probe reads (a manifest's own `extensions`, a capability's, the well-known
+  copy) (CA-5). A well-known answer carrying the declaration at
+  75 % of Fabric Dashboards' 2 MiB cap or over is named (until the contract's CT-223). The contract's schema and its
+  148 vectors are vendored at the pin (`test/fixtures/contract/`, a sidecar with each file's sha256 and a generator
+  that refuses another commit); all 148 pass with the findings in the reference's order, and
+  `test/test_check_service_channel_agent.py` holds 26 tests.
+
+### Upgrading
+
+- Every probe report whose well-known answer is read gains a `channel-agent.declaration` line: `NOT_RUN` («not a channel agent») for a service that
+  declares nothing, so a reader that counts `NOT_RUN` per service moves by one. A channel agent whose declaration the contract's
+  reader still reads and that owes an obligation (FAC-SEM-164), and a service with a string shaped like a credential in any copy of the key (read or not),
+  now makes `check_service.py` exit 1 where 0.72.0 exited 0.
+
+### Changed
+
+- `creating-fabric-agents/references/practices.md` quotes the contract's CA-8 («Text from a channel is data») verbatim
+  from the pinned `channel-agent.md` in place of 0.71.0's paraphrase.
+- `creating-fabric-agents/references/models-and-providers.md`: «A starting choice» follows the operator's model map
+  of 2026-11-06 (Kimi K3.1 Pro for decisions, Sonnet 5.5 for verifying another model's output, a panel of three
+  vendors for plans, GLM-5.3 and DeepSeek at volume, open vendors on user content), and names two traps reported on OpenRouter that day:
+  models that will not turn reasoning off (Kimi writes it into the answer; GLM-5.3, Sonnet and Opus answer 400) and a
+  judge that refuses to judge.
+- `references/protocol.md`, `references/interop.md` and the support-agent recipe's README describe the new rule in
+  place of «the probe does not read the declaration yet».
+
 ## 0.72.0 (2026-11-06)
 
 ### Changed

package/README.md

@@ -188,8 +188,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()
@@ -301,7 +302,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.72.0",
+  "version": "0.74.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.72.0",
+  "version": "0.74.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.72.0"
+  version: "0.74.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/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.72.0"
+  version: "0.74.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 |
@@ -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,
@@ -310,7 +310,7 @@ from a release folder needs it), and the `interop.*` rules:
 manifest link, capability list, tools equal to the manifest, job tools, unknown job, trace
 propagation, event trace pairs, `interop.action-tools` (every declared action's tool is served), `well-known.a2a` and
 `a2a.card` (DEC-0122: the card is fetched without the token and its interfaces are never called; the surfaces
-reference's *A2A for remote agents* section), and
+reference's *A2A for remote agents* section), `channel-agent.declaration` (DEC-0150), and
 `board.responder` for a service that declares the project board) and exits 1 on any `FAIL`. A `NOT_RUN` is not a pass;
 name it in the report. A service with a dashboard also runs the layout probe,
 `node <skill-dir>/scripts/check_dashboard_layout.mjs --service <id>` (WebKit at 360, 480, 768
@@ -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

@@ -116,8 +116,8 @@ on (FAC-SEM-164); `recommendation` only with `answered_signal: "none"`, the id o
 board thread where the queue's owner was told; a channel's `items_seen_unit` one of `mails`, `updates`, `messages`,
 `reviews`; durations in ISO 8601; the knowledge file as a source with its
 maximum age. `test/test_channel_agent_example.py` holds the example to that form; the contract publishes its schema
-at the pin (`service-channel-agent-extension.schema.json`); `check_service.py` does not read the declaration yet
-(FAA-197).
+at the pin (`service-channel-agent-extension.schema.json`); `check_service.py` checks a declared one against
+FAC-SEM-162 to 165 (rule `channel-agent.declaration`).
 
 ## Configure
 

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" \
@@ -386,5 +388,6 @@ your own record, keep it (OA-6).
 | `interop.trace-propagation` | the answer's `_meta.traceparent` has the probe's trace id and a new span | the answer carries no traceparent |
 | `interop.events-trace` | every event with a trace carries both `traceId` and `spanId`, well formed | no events page was read |
 | `interop.action-tools` | every action the well-known `extensions/actions/0.1` declares names a tool `tools/list` serves (DEC-0121 AP-1); one it does not serve is a `FAIL`, and so is a local service that declares actions with no MCP surface (beyond FAC-SEM-142, which reads only a present list) | no declaration, an unreadable one (`well-known.actions` reports it), no listing was read, or a remote service with no MCP surface (its twin may be on A2A or behind a gateway) |
+| `channel-agent.declaration` | a channel agent's declaration (DEC-0150) passes the contract's FAC-SEM-162 to 165 at the pin, read from `provider.extensions` of the manifest the descriptor names, else from `extensions` of the well-known answer (CA-1); a `FAIL` on the obligations of a declaration the reader still reads (FAC-SEM-164) or a string shaped like a credential (FAC-SEM-165, not a declaration too large to read for credentials) in the read declaration or in any copy beside it, the first five findings shown as code and path, never a declared value | nothing declared, the named manifest unreadable (`interop.manifest-link` fails it), or a key read as not declared (a manifest's own `extensions`, a capability's, another version's key, a well-known copy beside a manifest, a form the schema or FAC-SEM-163 refuses), each named in the evidence, never a failure while producers move to this revision unless a copy holds a string shaped like a credential (that fails in any copy the probe reads: a manifest's own `extensions`, a capability's, the well-known copy, CA-5); no line when the well-known answer is not read; credentials are read as the contract reads them, within its reading budget and under the `0.1` key only (a key of another version is named, not read); a well-known answer carrying the declaration at 75 % of the 2 MiB cap or over is named, never a failure (until the contract's CT-223) |
 
 `python3 scripts/check_service.py <id>` prints them with the rest; `--json` for a machine.

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) |
@@ -99,7 +100,9 @@ A module imports only modules listed before it in `kit.json`, so the kit has no
 | L4 | `fabric_http` | outbound HTTP: deadline, bounded retries, `Retry-After`, size cap ([connectors](connectors.md)) |
 | L4 | `fabric_openrouter` | OpenRouter chat: own key, spend ceiling, receipts, fallback ([connectors](connectors.md)) |
 
-Beside the kit, not in `kit.json`: the probe (`check_service.py`, `check_service_rules.py`), the sample
+Beside the kit, not in `kit.json`: the probe (`check_service.py`, `check_service_rules.py`,
+`check_service_channel_agent.py`, `check_service_channel_agent_schema.py` and the
+`service-channel-agent-extension.schema.json` it reads at run time), the sample
 (`sample_service.py`, `sample-remote-service.mjs`), `fabric_kit.py` itself and the dashboard tools. Recipes built on
 the kit live in `../recipes/` ([the draft-and-check step of a support agent](../recipes/support-agent/README.md)).
 

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).