@passioncode-ai/fabric-agent-adapter 0.77.0 → 0.79.1

package/CHANGELOG.md

@@ -1,5 +1,212 @@
 # Changelog
 
+## 0.79.1 (2026-11-12)
+
+0.79.0 was tagged and never published: its release run (43176165810) failed two jobs, so `release` and `publish` were
+skipped. 0.79.1 is 0.79.0 with these fixes, and is the release that ships it. Kit modules change: `fabric-peer-owner.mjs`,
+`fabric_supervisors` and `fabric-supervisors.mjs`, `fabric_board_session`, `fabric_board_slots` and their Node twins.
+
+### Fixed
+
+- **A checked connection to `localhost` reaches a listener on 127.0.0.1 under Node 18** (the `floors` job). Node 18
+  connects to the first address only, and `localhost` resolves to `::1` first on Linux, so `checkedSocket` (and every
+  loopback read made through it: `wellKnownOf`, the key set, the OpenRouter connector) found nothing where Python and
+  Node 20 and later try every address. It now passes `autoSelectFamily: true`. Reproduced on Node 22 with
+  `--no-network-family-autoselection`: the test fails without the change and passes with it.
+- **The Windows job runs what passes there** (the `windows` job). 0.79.0 ran the whole of
+  `test_fabric_session_dispatch.py` on Windows for the first time (FAA-236): the parsing, `gate-id` and damaged-folder
+  tests pass, and twelve `Hooks` tests fail (the dispatch record's holder and `/clear` across processes). The job runs
+  the whole file again: the twelve were ten tests of the POSIX `/clear` take-over, which `dispatch_holder` turns off on
+  Windows by design (now skipped there with the reason), one file read with the code page (now UTF-8), and one real
+  defect: when `os.fdopen` raised, the descriptor stayed open, Windows refused to remove the empty record, and the
+  run was told it was nested and never did its request. The descriptor is closed first (FAA-302).
+- **`foreign-user` no longer drops a lost call's record** (the 0.79.0 seam reading): 0.79.0's new board code
+  (FAA-252) reached two places that keep a lost call's state and read it as a refusal. The reply probe
+  (`_replied_before`, `repliedBefore`) and a lost enroll's asking record (`_replay`, `replay`) now stay, as for
+  `unreachable`, so a reply is never sent twice. Both twins, a test in each.
+- **A loopback origin with no port, or `:80`, is read on a checked connection** in both twins: Node's `new URL`
+  drops the default port and read `http://127.0.0.1:80` unchecked; Python read a portless origin unchecked.
+- `references/delegation.md` says what a restricted socket table does to a loopback key set and the way round.
+
+### Changed
+
+- 0.79.0's FAA-293 line is narrower than it read: the inode check closes the race between two copies starting at once.
+  A folder swapped under a copy already running is not caught yet (FAA-303).
+
+### Upgrading
+
+- `fabric_delegation` (and `fabric-delegation.mjs`) imports `fabric_peer_owner` since 0.79.0: update with
+  `fabric_kit.py install`, which brings it along, never a hand copy of the one file.
+
+## 0.79.0 (2026-11-12)
+
+The first release of the backlog sweep of 2026-11-12 (plan and inventory of the 134 open rows:
+`docs/evidence/specs/2026-11-12-backlog-waves-plan.md`). The contract pin stays `18f8d487`. Kit modules change:
+`fabric_lock`, `fabric_base`, `fabric_delegation`, `fabric_descriptor`, `fabric_supervisors`, `fabric_board_link`,
+`fabric_board_slots`, `fabric_board_session`, `fabric_openrouter`, the facade `fabric_service`, their Node twins, and
+`fabric-secrets.mjs`. The dashboard kit moves to 1.1.6.
+
+### Added
+
+- **creating and adapting: an organization's catalogue first** (the project board's request `2718ece8`). One neutral
+  line at step 0 of creating-fabric-agents and before scaffolding in adapting-projects-to-fabric: a private catalogue
+  of agent templates with an architect is asked first for the template, version, variant and known traps; the skill
+  runs after it. Scenario `ask-the-organization-catalogue-first` in both skills.
+
+### Changed
+
+- **working-with-fabric reads against Fabric v0.3.19.** The session-start preamble, the README and SKILL.md say both
+  cases: before Fabric 0.3.17 a dispatched run declines a request no session can take and the asker resends; from
+  0.3.17 the session's own Project is granted `board.respond` at `com.enroll` (CO-506) (FAA-221). The exit contract's
+  decline names the refusal's reason, takes over an `in_progress` request an earlier run left, and reads board ids
+  from the dispatch line first; the Observatory packet's board refs are the fallback (FAA-215, FAA-295).
+  `references/on-demand-session.md` and `board.md` name the Fabric releases as they are (FAA-246, FAA-216), and a
+  helper a run starts itself uses the runner's bypass flag with the task's limits set at launch (FAA-274).
+- **"When nobody answers"** runs only on a machine whose trust is `mine` (ADR-0176), and the asker cancels its own
+  request after adapting (FAA-220). One phrase for a never-held slot, and a gate question is moot once its request is
+  answered or taken (FAA-222, FAA-248).
+- **creating-fabric-agents: completion lines for an agent that answers people**, one per checklist item (a file and a
+  test, or `NOT_RUN`), the first reply measured from the person's message (FAA-180).
+- **One rule for a secret in a child's environment**: the agent's own process may hold its key from its supervisor or
+  a vault runner; a child it starts never gets it (FAA-281).
+- **Operator channel through the estate's gateway**: where the estate runs a messaging gateway the operator chose, the
+  channel sends through it; a polling token has one poller across machines (`poller-elsewhere`); the contract's
+  own-bot form (DEC-0034) is unchanged (FAA-282).
+- **README quick start picks a free port**; `where-agents-run.md` adds one computer with a personal and an
+  organization account and a member's virtual machine (DEC-0154) (FAA-283).
+- **The dashboard link gate is agent-side**, and a generated project pins a negative fixture in its own test (FAA-129).
+- **The shipped-file check follows npm** (`test/validate.py`): a `files` entry with a glob, one naming nothing, or no
+  `files` at all is a finding; README and LICENSE are read because npm ships them regardless; a line with no scheme
+  says so. Tests pin `__pycache__`, the wiring into `validate_repo`, and the kit's `older` and `modified` verdicts
+  without release tags (FAA-212).
+
+### Fixed
+
+- **The instance lock never holds a file that is no longer at its path** (FAA-293, a board finding of 2026-11-10).
+  After `flock` (Python) or the `O_EXLOCK` open (Node on macOS), and again after the pid is written, `acquire`
+  compares the locked inode with the file at the path; on a mismatch it re-opens up to
+  `InstanceLock.INODE_RETRIES` (3) times, then fails with an error naming the path. A data import that swapped the
+  data folder no longer lets two copies start.
+- **The dashboard kit's resize observers write in the next frame** (dashboard kit 1.1.6, a board finding of
+  2026-11-12): the nav's observer laid the bar out inside its callback and the chrome's wrote `--fd-chrome-h` and
+  `--fd-chrome-top` there, so WebKit raised "ResizeObserver loop completed with undelivered notifications" at 390 px.
+  Both schedule their work with `requestAnimationFrame` (cancelling the previous frame), the nav refits only when its
+  width changed, the chrome writes a property only when its value changed; a WebKit test pins that no callback writes.
+- **Another OS account's listener is never read as ours**: the delegation verifier reads a loopback key set only from
+  this account's listener (FAA-255); the OpenRouter connector stops at once on a loopback base URL another account
+  holds, without trying the fallback model (FAA-257); a board session maps a hub port another account holds to
+  `foreign-user`, never `unreachable` (FAA-252); Python's `well_known_of` and `job_well_known_of` tell down from
+  `foreign-user` as Node's `wellKnownOf` does, and an origin spelled `localhost`, another 127/8 address or `[::1]` is
+  read on a checked connection (FAA-259, FAA-257); a hub pid another account's process holds is "not verified",
+  never running (FAA-254).
+- **The reserved capability `project.work`** is refused by both kits in `surfaces.mcp.capabilities`, as an action's
+  tool and by the board responder (DEC-0140 PR-1) (FAA-244).
+- The provider entry's URI check uses the RFC 3986 class the descriptor check uses: a byte-order mark, a zero-width
+  space, a non-ASCII path and an IDN host are refused (FAA-127).
+- The dispatch record survives a hooks folder damaged by hand: `RecursionError` reads as unreadable, a `dispatch`
+  file is a folder that cannot be written, prune ages a record by its own `lstat` (FAA-208).
+- `test/validate.py` reads board rows cell by cell as the workspace aggregator does: code spans and escaped pipes
+  (FAA-214). The Node credential detector and the dashboard kit's button append values in place, linear like the
+  Python twin (FAA-245). The source check's linear-time tests measure a ratio, not the wall clock (FAA-209).
+- The board kit sends the operator to Fabric's Settings → Agent access (FAA-223); `vendor_vectors.mjs` names the
+  command that works, the contract's `tsx` at the pin (FAA-242).
+- Step 6's `fabric_task_create` example carries the required `origin` (FAA-154).
+- A dispatched Claude Code run that sees only `fabric_whoami` is named as Fabric's CO-563 (fixed in the Fabric release
+  after v0.3.19) and says so in its exit report instead of claiming the board was read (FAA-296).
+- `fabric_session.py --help` and the README list `gate-id`, and the Windows job runs the dispatch tests (FAA-236).
+- `provider-entry.md` and the provider writer's message name Fabric v0.3.16 for CO-479 (FAA-216).
+
+### Upgrading
+
+- A service that vendors the kit updates its copies with `fabric_kit.py install` (the changed modules are named
+  above); a dashboard that vendors the dashboard kit takes 1.1.6. `launchd_install` takes injected readers
+  (`fetch_well_known=`, `fetch_job_well_known=`) as Node's `launchdInstall` takes `fetchWellKnown`.
+
+## 0.78.0 (2026-11-12)
+
+The contract pin stays `18f8d487`. Kit modules change: a new `fabric_tailnet` and `fabric-tailnet.mjs` (layer L0); `fabric_supervisors` and `fabric-supervisors.mjs`, and the facades
+`fabric_service` and `fabric-service.mjs` (new exports `launchd_domain` / `launchdDomain`, `SYSTEM_DAEMONS`,
+`jobWellKnownOf`, `ForeignUserAnswer`); the probe `check_service.py` (`lifecycle.one-copy`); guidance in building-fabric-services and
+working-with-fabric.
+
+### Added
+
+- **A LaunchDaemon for a headless Mac** (FAA-278, with FAA-228): the launchd helpers in both kits work in launchd's system
+  domain, for a Mac that a FileVault restart (`fdesetup authrestart`) leaves with no GUI login, where a `gui/<uid>` job
+  never starts. A plist in `/Library/LaunchDaemons` (the folder's case ignored) or `domain="system"` /
+  `domain: 'system'` is a LaunchDaemon, macOS only; `launchd_plist(..., user_name=)` / `launchdPlist({userName})` writes
+  its `UserName`, which a system install requires; `launchd_domain` / `launchdDomain` names the domain.
+  `launchd_loaded`, `launchd_pid` and `launchd_override` read the system domain without root. `launchd_install` and
+  `launchd_uninstall` there need root, refuse before writing anything otherwise and name the command to run as root,
+  refuse `purge` (the data is the `UserName`'s), and accept the installed service's token-free answer only on a
+  connection launchd's own job accepted (its pid from `launchctl print system/<label>`, running as the `UserName`'s uid)
+  or, under a restricted socket
+  table, on a port that pid listens on (`lsof -p`, a weaker vouch, CT-261). A `gui/<uid>` bootstrap that fails for lack
+  of a GUI session (error 125, an SSH install) now says to remove that LaunchAgent and use the system domain. The probe's
+  `lifecycle.one-copy` asks launchd in the domain the descriptor's plist names. A LaunchDaemon's label is the machine's:
+  an install refuses, before writing anything, a label another plist holds, a plist at its path of another label or
+  another `UserName`, a `UserName` that is not a short name, is root or is no account of the Mac, and an origin other
+  than `http://127.0.0.1:<port>`; one refused after its bootstrap leaves the job loaded and names the `bootout`. An
+  uninstall refuses a label another plist holds before its `bootout`. The root installer's read of its own job's token-free answer, proved by the job's pid, its uid and a bind on
+  exactly `127.0.0.1`, departs from the pinned HA-2 (and the contract's later RT-3); the contract owner accepted it in
+  principle as DEC-0161, proposed (FAA-288). `references/lifecycle.md`
+  *The system domain* says which steps run as the `UserName` and which as root, and what a host must not do (FAA-287);
+  one scenario eval.
+
+- **A kit module for an agent behind `tailscale serve`: `fabric_tailnet`** (FAA-297, a board request of 2026-11-11).
+  `fabric_tailnet.py` and `fabric-tailnet.mjs` (layer L0, no imports) decide who is calling and what that person may
+  open. The person comes from `Tailscale-User-Login`, believed only on the agent's own serve listener (a loopback port
+  or a Unix socket that only serve reaches) and from a loopback peer; a request carrying serve's headers on any other
+  listener is refused (`serve-header-off-serve`), never half-trusted. Groups, dashboards and capabilities come from a
+  `tailnet-perimeter/1` file generated from the organization's access registry: a file that does not name its source
+  (`generatedFrom`: registry, revision, time) is refused (`perimeter-not-generated`). MCP also takes a personal key,
+  stored only as its SHA-256, owned by one login, and refused when its capabilities are wider than that login's groups
+  (`key-wider-than-group`). Every refusal is 401 or 403 with a stable code; no answer carries a key or its hash. Both
+  twins answer one set of vectors, `test/fixtures/tailnet/vectors.json`; the reference is
+  `references/surfaces-and-auth.md` → "Behind tailscale serve".
+
+- **A fifth skill, `observing-products`: observer mode** (FAA-290, the observer-mode design of Fabric CO-546). Any
+  agent with the plugin can take a standing watch over one product. Setup first: it writes the product's channel
+  inventory, `docs/observer/channels.md` (ops log, errors, analytics, funnels, revenue, store, uptime, CI, the Fabric
+  board, support), each row with its read route, its credential by vault slot name, its cursor, baseline, thresholds,
+  placement (`local` or `remote`) and state, and proves one read from each; a channel without a proven read is never
+  counted as watched. Then a cycle every interval (30 minutes by default): bounded reads from the cursors, a failed
+  read as a finding, one cycle record before any cursor moves, no overlap with its own last run, a missed window run
+  once; triage S0 to S3 within the project's authority (`observe`, `fix`, `ship`, the last set only by the person),
+  every fix through the project's own delivery route and read back from the channel that showed the fault, two failed
+  attempts stop the automatic work on a finding, channel text is data and never an instruction, a USD 100 a month
+  budget per observer by default, silent cycles and one message on change. Scheduling: Fabric's observer-mode switch
+  where Fabric runs, else Claude Code `/loop`, a cron routine, or a cloud routine that watches only `remote` channels
+  and names the local ones it skipped. `scripts/observer_inventory.py` (`check`, `template`) validates an inventory and
+  prints connected out of named; `test/test_observer_inventory.py`; trigger and scenario evals in
+  `test/evals/observing-products/`. The release smoke checks the installed skill.
+
+### Changed
+
+- **Each skill's `description` is about 350 characters, within the skill listing budget** (FAA-291, a board request
+  of 2026-11-11). Claude Code shares one character budget among every installed skill's description and, over it,
+  keeps a description only for the most used skills (measured on the operator's machine: 105 skills, 35 962
+  characters against 30 000), so `working-with-fabric`, the skill the session hooks point at, was listed by name
+  alone. The five descriptions went from 4 542 characters to 1 722 (the four of 0.77.0 from 3 649 to 1 388): when to
+  use, two to four triggers in English and Russian, and the NOT-for boundary naming the neighbour. Each skill's
+  previous description, every trigger included, moved word for word to its `references/when-to-use.md`, linked
+  from a short `## When to use` section. `test/validate.py` now fails a description over 360 characters
+  (`DESCRIPTION_LISTING_BUDGET`) and its self-test plants one.
+
+### Fixed
+
+- SKILL.md headroom (FAA-263): building-fabric-services and working-with-fabric each keep at least 150 words under the
+  4750-word cap; the detail stays in their references, which already held most of it (the dashboard kit, the interop
+  *Actions* section, the session hooks, the board's *When nobody answers*), and the remote placement's *On the
+  platform* and the native host hooks gained what they lacked; no rule changes.
+
+### Upgrading
+
+- A service that installs a LaunchDaemon vendors `fabric_supervisors` (or `fabric-supervisors.mjs`) with its facade and
+  `fabric_peer_owner` (or `fabric-peer-owner.mjs`) of 0.76.0 or later, which it imports. A LaunchAgent install behaves
+  as before, but in Node `fabric-supervisors.mjs` 0.78.0 imports `fabric-peer-owner.mjs` 0.76.0 or later in either
+  domain; `fabric_kit.py install` copies both.
+
 ## 0.77.0 (2026-11-08)
 
 The contract pin stays `18f8d487`. Kit modules change: `fabric_events` and `fabric-events.mjs`, `fabric_peer_owner`

package/README.md

@@ -8,7 +8,7 @@
 
 **Fabric Agent Adapter** makes any agent Fabric-compatible. Fabric is PassionCode.ai's
 product, the CEO AI agent: you talk to Fabric, and it chooses, binds and runs the agents that
-do the work. This adapter is how an agent becomes one Fabric can bind: four Agent Skills,
+do the work. This adapter is how an agent becomes one Fabric can bind: five Agent Skills,
 Python and Node reference kits and a live conformance probe for the
 [Fabric Agent Contract](https://github.com/passioncode-ai/fabric-agent-contract). It also works
 on its own: the skills, kits and probe need no Fabric install.
@@ -18,13 +18,15 @@ on its own: the skills, kits and probe need no Fabric install.
 [![license](https://img.shields.io/badge/license-AGPL--3.0%20or%20commercial-blue.svg)](LICENSE)
 
 The skills are `adapting-projects-to-fabric`, `creating-fabric-agents`,
-`building-fabric-services` and `working-with-fabric`.
+`building-fabric-services`, `working-with-fabric` and `observing-products`.
 
 `working-with-fabric` is for the other side: a coding agent (Claude Code, Codex, Kimi Code, Kilo, Hermes) opened in
 a terminal that works in a project through Fabric. It finds Fabric (`hub.json`, its `pid`), has the machine's
 lifecycle broker start it when it is down, registers `fabric-mcp` once with no secret, calls `fabric_whoami`
 first, reads the project board (`com.status`, `com.list`, `com.read_ack` only what was read), answers what waits on its
-Project in the same turn with its state (the result later; a request a responder should take stays queued), and asks other
+Project in the same turn with its state (the result later; a request its Project's service should take stays queued; before Fabric 0.3.17 a run Fabric starts
+declines a request no session can take and the asker resends, and from 0.3.17 the session's own Project is granted
+`board.respond` at `com.enroll`, CO-506), and asks other
 Projects only through `com.submit`, asks who is working on what and claims its task before it starts
 (`fabric_work_list`, `fabric_work_claim`, Fabric v0.3.5 and later), links tasks to backlog rows instead of copying them, and
 releases at the end (`fabric_work_release`). `scripts/fabric_session.py status` prints where Fabric stands and one
@@ -40,7 +42,7 @@ uses Fabric (one line pointing at `fabric_whoami` in a folder with no sign of it
 is down it adds one line (skip `fabric_whoami`, start Fabric through the broker if the task needs it), and only in a
 project that uses Fabric; in a session Fabric started on a board request (`FABRIC_DISPATCH_WORKFLOW` set) it prints the
 exit contract instead, on the condition that the session's own prompt starts with the dispatch line naming the same
-three, and UserPromptSubmit, which sees that line, confirms the run or says it is none (FAA-201); Stop records each turn's facts (HEAD, files changed, lines added and removed, never content)
+three (a `/clear` while another session holds the dispatch is told it is nested, FAA-208), and UserPromptSubmit, which sees that line, confirms the run or says it is none (FAA-201); Stop records each turn's facts (HEAD, files changed, lines added and removed, never content)
 and the board's unread count, and, once the running Fabric takes them (unless `FABRIC_SESSION_NO_REPOSITORIES=1`), the other repositories the turn touched (it then
 reads the last 512 KB of the session transcript (message text and tool output included, which can hold a secret the session displayed; read in memory only), uses only tool names and path arguments, and sends host/owner/name, never a
 local path or text); UserPromptSubmit adds one line only when that count rose, and each reminder Fabric gave on a turn once (a turn `watch-mail` delivered prints there instead); SessionEnd releases what the
@@ -49,7 +51,8 @@ line naming the retro (FAA-206; Fabric's `retro-after-work`, since Fabric 0.3.16
 advertises `session-hooks/1`; Stop and SessionEnd always prune their own stale spool folders. All are silent in a session Fabric launched (except the retro line after a release of finished work and, in one started on a board request, the exit contract and the prompt hook's verdict on its dispatch line, but no unread line or reminder), never block the session, read no Fabric token (an `origin` URL's embedded credential is dropped in memory, never
 kept or sent) and always
 exit 0 once `python3` starts (on Windows, Claude Code runs hooks in Git Bash, or PowerShell without it, where `python3`
-must name Python 3.9 or later; FAA-183). `fabric_session.py watch-mail` waits for board mail under a background watcher, and `install-host-hooks
+must name Python 3.9 or later; FAA-183). `fabric_session.py watch-mail` waits for board mail under a background watcher, `gate-id <request>` prints the
+`commandId` of a request's gate question (the one a dispatched run uses), and `install-host-hooks
 --host codex|kimi|hermes|opencode|openclaw|pi` installs each host's native context bridge (dry run unless `--apply`).
 Codex receives structured SessionStart JSON; Hermes, OpenCode, OpenClaw and Pi use native plugin APIs.
 See the [native host matrix](plugins/fabric-agent-adapter/skills/working-with-fabric/references/native-host-hooks.md)
@@ -58,6 +61,18 @@ for activation, reload and verification limits. The
 they need from Fabric; the [board reference](plugins/fabric-agent-adapter/skills/working-with-fabric/references/project-board.md)
 is the board-first workflow.
 
+`observing-products` puts an agent on a standing watch over one product (observer mode). It first writes the
+product's channel inventory, `docs/observer/channels.md`: every channel the product reports through (operations log,
+errors, analytics, funnels, revenue, store, uptime, CI, the Fabric board, support), each with its read route, its
+credential by vault slot name, its baseline and a proven read. Then every interval (30 minutes by default) it reads
+each channel from its cursor, triages what changed (S0 to S3) and fixes it through the project's own delivery route,
+within the authority the project sets (`observe`, `fix`, `ship`). `scripts/observer_inventory.py check` validates the
+inventory and prints connected out of named:
+
+```bash
+python3 plugins/fabric-agent-adapter/skills/observing-products/scripts/observer_inventory.py template --project example-app
+```
+
 `building-fabric-services` makes an agent a long-lived local service with a dashboard
 that is always alive, runs as one copy, keeps its state through a reinstall and appears
 in Fabric Dashboards by itself: the `fabric-service/0.1` extension. It also makes an **online** agent
@@ -174,6 +189,7 @@ npx skills add passioncode-ai/fabric-agent-adapter --skill adapting-projects-to-
 npx skills add passioncode-ai/fabric-agent-adapter --skill creating-fabric-agents
 npx skills add passioncode-ai/fabric-agent-adapter --skill building-fabric-services
 npx skills add passioncode-ai/fabric-agent-adapter --skill working-with-fabric
+npx skills add passioncode-ai/fabric-agent-adapter --skill observing-products
 ```
 
 ### Configure
@@ -191,18 +207,20 @@ With Python 3.9+ and the Claude Code CLI, in a throwaway directory and a tempora
 ```bash
 KIT=plugins/fabric-agent-adapter/skills/building-fabric-services/scripts   # or ~/.agents/skills/building-fabric-services/scripts
 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"
+# A free loopback port, so the sample never collides with a service already running here.
+PORT=$(python3 -c 'import socket;s=socket.socket();s.bind(("127.0.0.1",0));print(s.getsockname()[1])')
+python3 "$KIT/sample_service.py" serve --port "$PORT" --data-dir "$DATA" &
+python3 "$KIT/sample_service.py" register --port "$PORT" --data-dir "$DATA" --services-dir "$SERVICES"
 # 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.
 # On macOS 27.2 run these with Apple's /usr/bin/python3: an ad-hoc-signed Python, such as Homebrew's, sees no other
 # process's sockets (FAA-272).
 python3 "$KIT/check_service.py" sample --services-dir "$SERVICES" && \
-python3 - "$DATA/service.token" "$WORK/mcp.json" <<'EOF'
+python3 - "$DATA/service.token" "$WORK/mcp.json" "$PORT" <<'EOF'
 import json, os, sys
 token = open(sys.argv[1]).read().strip()
 with os.fdopen(os.open(sys.argv[2], os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o600), "w") as f:
-    json.dump({"mcpServers": {"sample": {"type": "http", "url": "http://127.0.0.1:47190/mcp",
+    json.dump({"mcpServers": {"sample": {"type": "http", "url": "http://127.0.0.1:%s/mcp" % sys.argv[3],
                "headers": {"Authorization": "Bearer " + token}}}}, f)
 EOF
 (cd "$WORK" && claude -p "Call the tool mcp__sample__sample_echo with text 'ping' and reply with only the text it returns." \
@@ -211,12 +229,14 @@ EOF
 kill %1
 ```
 
-Verified 2026-11-07 from the published npm package 0.76.0 (`npm pack` into a throwaway folder, `KIT`
+Verified 2026-11-08 from the published npm package 0.77.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.76.0-quick-start.md)). The probe prints one line per rule
+([record](docs/evidence/runs/2026-11-08-0.77.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.
+The free-port line (FAA-283) was run again on 2026-11-12 from this repository's kit with Claude Code 2.1.299 and
+Apple's `/usr/bin/python3`: a port the system chose, 44 rules, 0 FAIL, `listener.owner` PASS, and `ping`.
 `FABRIC_REAL_CLIENT=1 python3 -m unittest discover -s test -p test_real_client.py` repeats the connection check
 (every sample tool listed, no model call) in the test suite.
 

package/SECURITY.md

@@ -25,7 +25,13 @@ bounded and non-publishing until explicit scoped grants exist in a project bindi
 - The service kits create the service token (0600) and the instance lock in the
   service's own data directory, and write supervisor files only when an installer calls
   them: a launchd plist in `~/Library/LaunchAgents` (macOS), a systemd user unit (Linux) or
-  a per-user Scheduled Task (Windows), plus one descriptor in the services directory. The
+  a per-user Scheduled Task (Windows), plus one descriptor in the services directory. A LaunchDaemon in
+  `/Library/LaunchDaemons` (FAA-278) is written only by an installer running as root, which the kits never become:
+  without root they refuse before writing and name the command, and refuse a plist without `UserName` (except one written
+  there with an explicit `domain="gui"`, not refused yet, FAA-286 item 21); the job runs as the account its `UserName`
+  names. The installer accepts the job's answer only on a connection launchd's own job accepted
+  (its pid from `launchctl print system/<label>`) or, where the socket table is restricted, on a port that pid listens
+  on (`lsof -p`, the weaker vouch below, CT-261). The
   token is readable by any process of the same user; the protocol defends against web pages
   and mistakes, not against hostile local code.
 - The kits' connectors (`fabric_http`, `fabric_openrouter` and their Node twins) reach the
@@ -36,7 +42,12 @@ bounded and non-publishing until explicit scoped grants exist in a project bindi
   `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:
+  another account's, root's, SYSTEM's or an untellable listener; the one exception is a LaunchDaemon's installer
+  (root, FAA-278), which sends a token-free well-known GET only on a connection the pid launchd names for its job
+  accepted while it runs as the plist's `UserName` and listens on exactly `127.0.0.1` (`lsof -p`), or, under a
+  restricted table, to a port that pid listens on there (the weaker vouch below): a departure from the pinned HA-2 and
+  the contract's later RT-3, accepted in principle by the contract owner as DEC-0161 (proposed; the restricted-table vouch
+  included) and kept as a departure until the next repin (FAA-288). 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
@@ -45,7 +56,10 @@ bounded and non-publishing until explicit scoped grants exist in a project bindi
   short-lived child of its own interpreter listening on a random `127.0.0.1` port; when the
   table is restricted (macOS 27.2, FAA-267) the launchd installers also run `/usr/sbin/lsof
   -nP -a -p <pid> -i4TCP -sTCP:LISTEN -Fn` on their own job's pid. That vouch shows the job listens on the port, not that it accepted
-  the connection (a more specific bind by root over a wildcard job would pass; contract CT-261). A token-free loopback door is not yet protected against
+  the connection (a more specific bind by root over a wildcard job would pass; contract CT-261). A LaunchDaemon's root
+  installer runs that `lsof` and `ps -o uid=` on its job's pid before it accepts an answer, and reads, never changes, every other
+  plist in `/Library/LaunchDaemons` (to find another holder of its label, `plutil -convert xml1` for a binary one in
+  Node), `launchctl print system/<label>` and the `UserName`'s uid (`pwd`, or `id -u` in 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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@passioncode-ai/fabric-agent-adapter",
-  "version": "0.77.0",
+  "version": "0.79.1",
   "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

@@ -2,8 +2,8 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "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.77.0",
+  "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; and put an agent on a standing watch over a product (observer mode).",
+  "version": "0.79.1",
   "author": {
     "name": "PassionCode.ai",
     "url": "https://passioncode.ai/"

package/plugins/fabric-agent-adapter/hooks/hooks.json

@@ -1,5 +1,5 @@
 {
-  "description": "Two silent-unless-relevant hook sets. The dashboard-kit notice: one line at session start or /clear in a repository that owns a Fabric service whose dashboard has no kit or an older one (fabric-dashboard/0.1, DEC-0036), phrased as an upgrade the agent may make itself. The Fabric session hooks (working-with-fabric, COM-04, FAA-12a): at session start or /clear, the preamble when Claude Code has the MCP server `fabric` and Fabric runs (fabric_whoami, then the project board through com.status and com.list, claim and release); when Fabric is down, one line, only in a project that uses Fabric (a Fabric contract file, a project-bound registration or a service descriptor naming the repository); nothing on compact or resume; each turn's facts (HEAD, files changed, lines added and removed, never content), the board's unread count, and, once the running Fabric's fabric_session_observe takes them (unless FABRIC_SESSION_NO_REPOSITORIES=1), the other repositories the turn touched (the last 512 KB of the session transcript, message text and tool output included (a secret the session displayed can be there; read in memory only), is then read and only the current turn's tool names and path arguments are used; host/owner/name leave the machine, never a local path or text) and the session's end through Fabric, only when the running Fabric advertises session-hooks/1; at each prompt one line only when the unread count rose, then each nudge a turn's answer carried, once (watch-mail prints those of turns it delivered). The session hooks are all silent in a session Fabric launched but the exit contract and the prompt hook's verdict on it and the retro line below; the dashboard-kit notice is silent only in a session started on a board request. Every hook reads no Fabric token (a credential embedded in an origin URL is read by git config and dropped in memory, never spooled or sent), prints at most one block, always exits 0 once python3 starts (on Windows it must name Python in Git Bash, FAA-183), and hands any Fabric call to a detached worker with a 10 s deadline. In a session Fabric started on a board request (FABRIC_DISPATCH_WORKFLOW), session start prints the exit contract instead of the preamble on the condition that the session's own prompt starts with the dispatch line naming the same three, launched or not, and the prompt hook, which sees that line, confirms the run or says it is none, launched or not, with no unread line or nudge, and the dashboard-kit notice says nothing (FAA-201). After a call to Fabric's fabric_work_release or fabric_task_release that releases a claim as done, PostToolUse adds one line naming the retro (FAA-206); after any other call, or a release Fabric's answer refuses (released: false, already-released) or that released nothing, nothing.",
+  "description": "Two silent-unless-relevant hook sets. The dashboard-kit notice: one line at session start or /clear in a repository that owns a Fabric service whose dashboard has no kit or an older one (fabric-dashboard/0.1, DEC-0036), phrased as an upgrade the agent may make itself. The Fabric session hooks (working-with-fabric, COM-04, FAA-12a): at session start or /clear, the preamble when Claude Code has the MCP server `fabric` and Fabric runs (fabric_whoami, then the project board through com.status and com.list, claim and release); when Fabric is down, one line, only in a project that uses Fabric (a Fabric contract file, a project-bound registration or a service descriptor naming the repository); nothing on compact or resume; each turn's facts (HEAD, files changed, lines added and removed, never content), the board's unread count, and, once the running Fabric's fabric_session_observe takes them (unless FABRIC_SESSION_NO_REPOSITORIES=1), the other repositories the turn touched (the last 512 KB of the session transcript, message text and tool output included (a secret the session displayed can be there; read in memory only), is then read and only the current turn's tool names and path arguments are used; host/owner/name leave the machine, never a local path or text) and the session's end through Fabric, only when the running Fabric advertises session-hooks/1; at each prompt one line only when the unread count rose, then each nudge a turn's answer carried, once (watch-mail prints those of turns it delivered). The session hooks are all silent in a session Fabric launched but the exit contract and the prompt hook's verdict on it and the retro line below; the dashboard-kit notice is silent only in a session started on a board request. Every hook reads no Fabric token (a credential embedded in an origin URL is read by git config and dropped in memory, never spooled or sent), prints at most one block, always exits 0 once python3 starts (on Windows it must name Python in Git Bash, FAA-183), and hands any Fabric call to a detached worker with a 10 s deadline. In a session Fabric started on a board request (FABRIC_DISPATCH_WORKFLOW), session start prints the exit contract instead of the preamble on the condition that the session's own prompt starts with the dispatch line naming the same three, launched or not (a /clear while another session holds the dispatch is told it is nested, FAA-208), and the prompt hook, which sees that line, confirms the run or says it is none, launched or not, with no unread line or nudge, and the dashboard-kit notice says nothing (FAA-201). After a call to Fabric's fabric_work_release or fabric_task_release that releases a claim as done, PostToolUse adds one line naming the retro (FAA-206); after any other call, or a release Fabric's answer refuses (released: false, already-released) or that released nothing, nothing.",
   "hooks": {
     "SessionStart": [
       {

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

@@ -1,11 +1,15 @@
 ---
 name: adapting-projects-to-fabric
-description: Use when adapting an existing agent, MCP server, A2A peer, HTTP service, or terminal CLI to the Fabric Agent Contract (choosing MCP/A2A/local-runner, scaffolding a provider bundle, or checking Fabric compatibility); also for «подключить проект к Fabric» or «сделать агента совместимым с Fabric». NOT for building the Fabric host/orchestrator, configuring an MCP client, a brand-new agent (creating-fabric-agents), running an agent as a local or online Fabric service with a dashboard (building-fabric-services), or a coding session working through Fabric, its board or claims, «подключись к Fabric» (working-with-fabric).
+description: >-
+  Use when adapting an existing agent, MCP server, A2A peer, HTTP service or CLI to the Fabric Agent Contract:
+  profile, provider bundle, compatibility check. Triggers: "adapt this to Fabric", «подключить проект к Fabric».
+  NOT for a new agent (creating-fabric-agents), a service (building-fabric-services) or a session
+  (working-with-fabric).
 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.77.0"
+  version: "0.79.1"
   contract-version: "0.1.0"
   contract-commit: "18f8d48762edc5bfb1433657cbfe1c16196df1a6"
 ---
@@ -16,6 +20,10 @@ Turn an existing stable interface into a proposed Fabric provider bundle, then p
 only the compatibility gates for which receipts exist. The Fabric Agent Contract is
 normative; this skill is an authoring workflow pinned to one immutable revision.
 
+## When to use
+
+The description above stays short for the skill listing budget; the whole reach, every trigger included, is in [references/when-to-use.md](references/when-to-use.md).
+
 ## Boundary
 
 Use this skill to adapt or assess a provider project. Do not use it to:
@@ -92,6 +100,7 @@ is unavailable, continue only through local structure and mark exact schema vali
 
 ### 3. Scaffold the provider bundle
 
+If your organization keeps a private catalogue of agent templates with an architect, ask it first: it names the template, version, variant and known traps; this skill runs after it.
 Before scaffolding, ask the [agents database](references/agents-database.md) for an audit of the project
 (`agents-db.audit`) and carry its `optimize` proposals into the completion report.
 Load [provider bundle](references/provider-bundle.md) before creating or mapping files.
@@ -282,9 +291,10 @@ host's `open` and `fallback=never`. Never `open <url>`, `open -a Safari`, `xdg-o
 `not_installed` host; an installed host that failed to open is reported, never replaced by HTTP.
 Links carry no token or login code.
 
-The agent's `AGENTS.md` carries this as its dashboard rule block, and its checks run the adapter's link gate
-(`scripts/check_dashboard_link.py` from this skill's own directory; it is not copied into the project) on every
-completion and notification action before delivery:
+The agent's `AGENTS.md` carries this as its dashboard rule block; the agent runs the adapter's link gate
+(`scripts/check_dashboard_link.py` from this skill's own directory, an agent-side gate never copied into the project or
+run by its CI) on every completion and notification action before delivery, and the project's own test pins the
+negative fixture:
 [dashboard links](references/dashboard-links.md) has the block, the gate's input and the remote case.
 Headless agents need no dashboard.
 

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

@@ -125,11 +125,43 @@ its acceptance does not authorize or deliver it. Enforce grants/dedup/expiry in
 the transport. Unknown or failed host status produces no executable local action.
 A separately labelled copyable link for diagnosis is not an open action.
 
-Add this check to the generated project's dashboard completion/notification
-renderer before delivery. A raw-HTTP primary action with an available host is the
-negative fixture; a valid native action is the positive one. Keep diagnostics
-separate. This gate checks structured actions, not arbitrary prose: a CLI invocation
-or instructions alone do not prove all final answers from every agent are filtered.
+The gate is **agent-side**: the agent runs it from this skill's directory before it
+delivers an action. It is never copied into the generated project and never run by
+that project's CI: the adapter's versioned plugin folder has no stable path there, so
+its result in a project's pipeline would always be NOT_RUN. A raw-HTTP primary action
+with an available host is the gate's negative fixture; a valid native action is the
+positive one. Keep diagnostics separate. This gate checks structured actions, not
+arbitrary prose: a CLI invocation or instructions alone do not prove all final answers
+from every agent are filtered.
+
+The generated project pins the same negative fixture in its own test suite, without
+calling the gate: a test that renders its completion and notification output with an
+available host and fails when a raw loopback `http_url` or a legacy `open?service=`
+link appears in it. The snippet is self-contained; `render` stands for the project's
+own renderer:
+
+```python
+import re
+import unittest
+
+RAW_LOOPBACK = re.compile(r"https?://(?:127\.0\.0\.1|localhost|\[::1\])")
+LEGACY = "fabric-dashboards://open?service="
+RESOLVED = {"service": "example-agent.default",
+            "open_link": "fabric-dashboards://service/example-agent.default?path=%2Fdashboard",
+            "http_url": "http://127.0.0.1:47195/dashboard"}
+
+
+def render(resolved, host_state):  # replace with the project's completion/notification renderer
+    raise NotImplementedError
+
+
+class RenderedDashboardLinks(unittest.TestCase):
+    def test_rendered_output_has_no_raw_loopback_or_legacy_link(self):
+        out = render(RESOLVED, host_state="available")
+        self.assertIn(RESOLVED["open_link"], out)
+        self.assertIsNone(RAW_LOOPBACK.search(out), out)
+        self.assertNotIn(LEGACY, out)
+```
 
 ## Degradation
 

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

@@ -25,6 +25,16 @@ unless addressed (`/command@ThisBot`, a reply to its own message or a press of i
 bare `/command` in a group is not addressed), and a channel nobody receives on is `degraded`
 (`receiver-missing`). Say so in the proposal when the operator means to bind a shared group.
 
+Where the estate runs a messaging gateway service the operator chose for sending (one service every
+agent sends through, holding its own grants and allowlist), the channel sends through that gateway
+and does not call the messenger itself; the agent's own bot above is the contract's form (DEC-0034,
+OC-11) and the form used where no such gateway runs. A bot token read by polling (Telegram
+`getUpdates`) has exactly one poller across every machine: a second poller on the same token gets
+`409 Conflict` and the two take each other's updates. Check placement before polling: the instance
+on the machine the estate's placement record names for the agent polls, an instance on any other
+machine does not poll and reports `degraded` with the reason (`poller-elsewhere`), and a test starts a
+second instance placed elsewhere and sees it stay off the token.
+
 Record the answer (`accepted`, `declined` or `later`) in the agent's state and in its conformance
 report, and do not ask again; an agent that serves `surfaces.operatorChannel` also shows it as
 `proposal` in its status document. Creating the bot and putting its token into the secret store
@@ -57,9 +67,9 @@ For a PassionCode.ai repository, the agent's repository follows the organization
   and a `CLAUDE.md` whose first line is `@AGENTS.md`.
 
 Whoever owns the repository, an agent with a page gets the dashboard rule block in its `AGENTS.md`
-(pages open only in Fabric Dashboards; the block is in `references/dashboard-links.md`), and its
-checks run the adapter's link gate (`scripts/check_dashboard_link.py` from the skill's own directory, not a copy in
-the project).
+(pages open only in Fabric Dashboards; the block is in `references/dashboard-links.md`); the agent runs the
+adapter's link gate (`scripts/check_dashboard_link.py` from the skill's own directory, agent-side, never a copy in the
+project or a step of its CI), and the project's own test pins the gate's negative fixture (the same reference).
 
 org-index `scripts/check_format.py` reports 0 findings for it before it is called done. An agent
 someone builds for themselves is not a PassionCode.ai repository: its licence is its owner's

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/references/provider-entry.md

@@ -64,9 +64,9 @@ It refuses, with one sentence that never quotes a value:
 - a manifest whose name follows a backslash (`C:\Agents\example\fabric-agent.json`). The reader,
   `validate_provider_entry`, accepts it since DEC-0145 (`MANIFEST_PATTERN`, the schema's), but a reader that has not
   re-pinned to DEC-0145 refuses the entry, Fabric's registry among them (CT-192), so the writer does not emit it until
-  the oldest Fabric release in use reads it (the release after v0.3.15, CO-479). Write the path with `/` before the name. A manifest under the home folder
+  the oldest Fabric release in use reads it (Fabric v0.3.16, which shipped CO-479). Write the path with `/` before the name. A manifest under the home folder
   (`~/Agents/example/fabric-agent.json`) is read by every Fabric release; one with a drive letter
-  (`C:/Agents/example/fabric-agent.json`) only by Fabric after v0.3.15, whose registry took the repin (CO-479): v0.3.15
+  (`C:/Agents/example/fabric-agent.json`) only by Fabric v0.3.16 and later, whose registry took the repin (CO-479): v0.3.15
   and earlier read only a manifest under `~/` or `/`, so not `~\` either.
 
 `validate` also checks that the file is named `<id>.json` (FAC-SEM-014, slug half): the stem is what follows the last

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/references/when-to-use.md

@@ -0,0 +1,5 @@
+# When to use adapting-projects-to-fabric
+
+The skill's full trigger description, kept here so the front matter's `description` stays within the client's skill listing budget (about 350 characters a skill). Read it when choosing between this skill and a neighbour.
+
+Use when adapting an existing agent, MCP server, A2A peer, HTTP service, or terminal CLI to the Fabric Agent Contract (choosing MCP/A2A/local-runner, scaffolding a provider bundle, or checking Fabric compatibility); also for «подключить проект к Fabric» or «сделать агента совместимым с Fabric». NOT for building the Fabric host/orchestrator, configuring an MCP client, a brand-new agent (creating-fabric-agents), running an agent as a local or online Fabric service with a dashboard (building-fabric-services), or a coding session working through Fabric, its board or claims, «подключись к Fabric» (working-with-fabric).