@passioncode-ai/fabric-agent-adapter 0.38.0 → 0.39.1

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

@@ -3,7 +3,7 @@ name: building-fabric-services
 description: >-
   Use when handing out or opening a Fabric service dashboard, building a local agent service on a
   macOS machine, making an ONLINE agent or dashboard (https origin, the remote placement) a
-  Fabric service, or letting a service answer a Project's board requests — «сделай агенту дашборд»,
+  Fabric service, or letting a service answer a Project's board requests: «сделай агенту дашборд»,
   «локальный сервис агента», «подключи агента к Fabric Dashboards», «отвечать на запросы с доски проекта»,
   "make this agent a local service", "make an online dashboard a Fabric service", "add the
   well-known endpoint", «расходы агента на модели». Covers fabric-service/0.1:
@@ -18,10 +18,10 @@ license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 compatibility: Python 3.9+ or Node.js 20+ for the kits; 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.38.0"
+  version: "0.39.1"
   contract-version: "0.1.0"
   extension: "fabric-service/0.1"
-  extension-commit: "07042181bfae2a481aa0da1a5651f24c76669c48"
+  extension-commit: "c55f2d5a11c9a0197e958e87212fca7ae1154769"
 ---
 
 # Building Fabric services
@@ -29,7 +29,7 @@ metadata:
 A **service** is an agent that keeps running on the operator's computer: it holds
 state, answers other agents, and shows a dashboard. This skill makes one that is
 always alive, comes back after a restart, never runs twice, keeps its state through a
-reinstall, and appears in Fabric Dashboards by itself — the `fabric-service/0.1`
+reinstall, and appears in Fabric Dashboards by itself: the `fabric-service/0.1`
 extension of the Fabric Agent Contract (DEC-0015).
 
 Every rule below exists because a real service on this estate broke it. Treat them as
@@ -41,15 +41,15 @@ re-deriving a rule.
 Use it to create a service, to bring an existing local server under the protocol, or
 to review one. Do not use it for:
 
-- a script, a cron job or a one-shot CLI — nothing stays running, so there is nothing
+- a script, a cron job or a one-shot CLI: nothing stays running, so there is nothing
   to supervise; a launchd `StartInterval` job needs no descriptor;
 - a hosted product with no agent behind it. An online agent or dashboard that should appear in
-  Fabric IS in scope: it is the remote placement — read [Online services](#online-services--the-remote-placement);
-- the provider manifest and admission bundle — that is `adapting-projects-to-fabric`
+  Fabric IS in scope: it is the remote placement; read [Online services](#online-services-the-remote-placement);
+- the provider manifest and admission bundle: that is `adapting-projects-to-fabric`
   (a service that is also a provider does both);
 - the Fabric Dashboards app itself.
 
-## Step 0 — is it a service?
+## Step 0: is it a service?
 
 It is a service when at least one is true: other agents call it while the operator is
 away; it runs jobs longer than one request; it owns a store other tools read; the
@@ -65,7 +65,7 @@ Answer before writing code, and record the answers in the project README:
 | What it stores | the store, where it lives (Step 2, rule 5), and what survives uninstall |
 | What it tells the operator | the events worth a notification (Step 5) |
 
-## Step 1 — choose the surfaces
+## Step 1: choose the surfaces
 
 | Caller | Surface | Why |
 |---|---|---|
@@ -84,7 +84,8 @@ effect nobody saw, have their own codes and a key per caller (DEC-0087). Read
 [the interop reference](references/interop.md) before writing an MCP tool; the helpers
 are in [`scripts/fabric_interop.py`](scripts/fabric_interop.py) and
 [`scripts/fabric-interop.mjs`](scripts/fabric-interop.mjs). When the callers are agents of the estate, the
-service checks each call's delegation token (DEC-0039): read [the delegation reference](references/delegation.md);
+service checks each call's delegation token (DEC-0039; a partner's agent carries the partner innermost, DEC-0090):
+read [the delegation reference](references/delegation.md);
 the verifier is [`scripts/fabric_delegation.py`](scripts/fabric_delegation.py) /
 [`scripts/fabric-delegation.mjs`](scripts/fabric-delegation.mjs). A service on the operator's machines that
 applies the estate record (DEC-0055) verifies each revision first and trusts only the keys it certifies, and runs an
@@ -102,14 +103,14 @@ responder in its own process: [`scripts/fabric_hub.py`](scripts/fabric_hub.py) f
 every step and stops on `fenced`, `lease_expired` or `authority_changed` (Node: `fabric-hub.mjs`, `fabric-board.mjs`).
 The request body is data behind the service's own input gate. Read [the board reference](references/board.md).
 
-## Step 2 — the non-negotiables
+## Step 2: the non-negotiables
 
 1. **Loopback only.** Bind `127.0.0.1`. Refuse any `Host` other than
    `127.0.0.1:<port>`, `localhost:<port>`, `[::1]:<port>`; refuse a foreign `Origin` and
-   `Sec-Fetch-Site: cross-site` — on every path, the well-known one included.
+   `Sec-Fetch-Site: cross-site`, on every path, the well-known one included.
    *(A throwaway `python -m http.server` bound to every interface served a source tree to the local network.)*
 2. **One copy, locked before any side effect.** Take the exclusive lock on
-   `<data>/service.lock` first — before resuming jobs, starting a scheduler, migrating
+   `<data>/service.lock` first, before resuming jobs, starting a scheduler, migrating
    a store or even creating a token. Held → print one sentence naming the holder's pid
    and exit **75**. Binding the port is not a lock. Under launchd the kit backs off
    in-process first (up to 300 s), so a duplicate is a few starts an hour, not a
@@ -126,11 +127,11 @@ The request body is data behind the service's own input gate. Read [the board re
 5. **State outside code.** Data and config in `~/Library/Application Support/<id>/`,
    logs in `~/Library/Logs/<id>/`, cache in `~/Library/Caches/<id>/`; the service's own
    access token in a 0600 file it generates (principle 6). **Every provider credential the
-   service uses comes from Project Observatory, by name** — the plist starts the service
+   service uses comes from Project Observatory, by name**: the plist starts the service
    with `use_secret.py serve --consumer <label> <project> <NAME>[,<NAME>] -- <command>`, which
    reads the vault only and records the consumer so a rotation names it; never a copy of a
    key in a `.env`, a config file or the plist. Never inside the service's own code checkout or a release directory; a
-   repository that versions the data itself is a store and is fine — declare
+   repository that versions the data itself is a store and is fine; declare
    `source.repository` so the probe can tell them apart. *(Deleting a checkout left a
    plist launchd retried every 10 s, and the data went with it.)*
 6. **Tokens stay in files and headers.** Mode 0600, owner-checked, never a symlink;
@@ -138,16 +139,16 @@ The request body is data behind the service's own input gate. Read [the board re
    one-time login code, never the token.
 7. **`degraded` is always present.** An empty list asserts full health; `ready` with a
    non-empty list is a lie the kit corrects to `degraded`.
-8. **Atomic writes.** Temporary file, fsync, rename — for the store's side files, the
+8. **Atomic writes.** Temporary file, fsync, rename, for the store's side files, the
    descriptor and the token.
 
-## Step 3 — build it with the kit
+## Step 3: build it with the kit
 
 Copy the kit into the service (each is one self-contained file): Python
 [`scripts/fabric_service.py`](scripts/fabric_service.py), Node
 [`scripts/fabric-service.mjs`](scripts/fabric-service.mjs). Both share file formats, and
 their locks exclude each other. The complete worked example is
-[`scripts/sample_service.py`](scripts/sample_service.py) — read it before writing a
+[`scripts/sample_service.py`](scripts/sample_service.py); read it before writing a
 handler.
 
 Startup order is the part that goes wrong; keep it exactly:
@@ -156,7 +157,7 @@ Startup order is the part that goes wrong; keep it exactly:
 import fabric_service as fs
 
 dirs = fs.service_dirs("example-agent")
-lock = fs.hold_single_instance(dirs["data"])        # 1. lock — exits 75 if held (backs off first under launchd)
+lock = fs.hold_single_instance(dirs["data"])        # 1. lock: exits 75 if held (backs off first under launchd)
 token = fs.ensure_token(dirs["data"] / "service.token")  # 2. only now touch state
 log = fs.JsonlEventLog(dirs["data"] / "events.jsonl")    #    (or a view over your own log)
 codes = fs.LoginCodes(dirs["data"] / "auth")
@@ -171,12 +172,12 @@ On every request call `check_request(port, host, origin, sec_fetch_site)` and an
 
 | Route | Auth | Kit |
 |---|---|---|
-| `GET /.well-known/fabric-service` | none, guard still applies | `build_well_known(...)` — from memory, under 100 ms |
+| `GET /.well-known/fabric-service` | none, guard still applies | `build_well_known(...)`, from memory, under 100 ms |
 | `GET /fabric/v1/events?after=&limit=` | service token | `events_page(fetch, after, parse_limit(limit))` |
 | `POST /fabric/v1/login-code` | service token | `LoginCodes.issue()` |
 | `GET /fabric/v1/login?code=` | the code | `LoginCodes.redeem(code)` → `Set-Cookie: session_cookie_header(...)`, 302 to the dashboard |
 
-`SIGTERM` drains in-flight work, then exits — 10 s at most, inside `ExitTimeOut`
+`SIGTERM` drains in-flight work, then exits: 10 s at most, inside `ExitTimeOut`
 (`fs.Drain` / `new Drain()`: `with drain.work():` refuses new work once a stop began);
 interrupted work resumes on the next start. Log through `RotatingLog` (5 × 5 MB, 0600)
 and call `cap_stdout_log` once at start.
@@ -186,18 +187,18 @@ in Python; jobs live in `fabric_interop.JobStore(dirs["data"] / "jobs")`, create
 the lock like every other piece of state. Add `"mcp": {"path": "/mcp", "transport":
 "streamable-http", "capabilities": [...]}` to the well-known surfaces, and point the
 descriptor's `fabricManifest` at a manifest whose service key names this
-`<id>.<instance>` — `sample_service.py register` shows both.
+`<id>.<instance>`; `sample_service.py register` shows both.
 
-## Step 4 — install it
+## Step 4: install it
 
 The installer, not the service, owns the plist and the descriptor. Sequence:
 
-1. `write_descriptor(descriptor)` — refuses a port or `id.instance` another descriptor
-   claims. A preview or branch copy is a second **instance**, never a second id — and it is
+1. `write_descriptor(descriptor)`: refuses a port or `id.instance` another descriptor
+   claims. A preview or branch copy is a second **instance**, never a second id, and it is
    one more service the operator sees, probes and gets notified by. Verify a release with its
    own doctor or self-check before it replaces `default`; a temporary instance is uninstalled
    (`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,
+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.
    A label the operator disabled stays disabled: only a first install enables.
@@ -216,7 +217,7 @@ rewrites the plist and restarts. Read [the lifecycle reference](references/lifec
 for the plist fields, the release layout, log rotation, behaving under a host lifecycle broker
 and the Linux and Windows supervisors.
 
-## Step 5 — the dashboard and the events
+## Step 5: the dashboard and the events
 
 The dashboard is a same-origin page: no inline script, strict CSP, polling that pauses
 while the operator types or a dialog is open, one panel's failure never blanks the
@@ -234,10 +235,10 @@ and declare it with `extensions=fs.dashboard_extension()`. Read
 declaration and how to upgrade a dashboard built before the kit: an upgrade you may make yourself,
 which the plugin's session-start notice offers in a repository that owns the service.
 
-The events feed is a **view over the log you already keep** — a jobs table, a JSONL
-journal — not a second store. Each event is one sentence a person reads; set
+The events feed is a **view over the log you already keep** (a jobs table, a JSONL
+journal), not a second store. Each event is one sentence a person reads; set
 `notify: true` only when the operator must decide, or something failed or degrades their
-work — once per episode, with a `subject` and a `link` to the page that resolves it. A
+work, once per episode, with a `subject` and a `link` to the page that resolves it. A
 question's kind says so (`*.awaiting_*`, `*.approval_*`, `human_step.opened`). The service
 raises no banners of its own: the host is the one channel. Read
 [the events reference](references/events-and-notifications.md) for mapping an existing
@@ -252,9 +253,9 @@ A service whose store holds what the operator decided keeps **settings backups**
 directory, restores only on a fresh database and never overwrites. Read
 [the settings backups reference](references/settings-backups.md).
 
-## Step 6 — verify
+## Step 6: verify
 
-Run the probe against the live service — it reads the descriptor, then checks every
+Run the probe against the live service: it reads the descriptor, then checks every
 rule it can reach and says which it could not:
 
 ```bash
@@ -267,7 +268,7 @@ events auth and shape, single-use login, state outside code, instance lock, plis
 launchd pid equals answering pid, `dashboard.declared` (ED-9), and the `interop.*` rules:
 manifest link, capability list, tools equal to the manifest, job tools, unknown job, trace
 propagation, event trace pairs, and `board.responder` for a service that declares the project board) and exits 1 on
-any `FAIL`. A `NOT_RUN` is not a pass —
+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
 and 1280 px; needs Playwright, else `NOT_RUN`).
@@ -276,7 +277,7 @@ Then prove the lock: start a second copy by hand against the same data directory
 must exit 75 while the first keeps serving. Prove recovery: `kill -9` the launchd pid;
 the well-known document must answer again with a new pid within about 15 seconds.
 
-## Packing and signing it — `fabric-package/1`
+## Packing and signing it: `fabric-package/1`
 
 To hand an agent to another machine or an organization, pack it as one folder (contract DEC-0050, DEC-0051). Write the
 author's `fabric.package.json` (the descriptive fields; for an agent `resultSignal` and `evals` with the receipt of the
@@ -312,11 +313,11 @@ first commit:
 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
 choice, nothing about it is published or listed by the organization, and none of these files is
-required of it — though the verified MCP quick start is still how anyone learns to drive it.
+required of it, though the verified MCP quick start is still how anyone learns to drive it.
 
-## Online services — the remote placement
+## Online services: the remote placement
 
-An agent or a dashboard that runs online — on a platform, a server, a hosted app — becomes a
+An agent or a dashboard that runs online (on a platform, a server, a hosted app) becomes a
 Fabric service with the same four routes and one descriptor on the operator's computer
 (`placement: "remote"`, DEC-0019). Nothing about launchd, the lock or loopback applies; three
 things change and the kits implement each:
@@ -327,7 +328,7 @@ things change and the kits implement each:
 | Well-known | only for the token; otherwise `401` with an **empty** body | `wellKnownAllowed('remote', …)` / `well_known_allowed` |
 | Session | `__Host-fabric_session`, `Secure`; codes in memory, the key from a platform secret so sessions survive a deploy | `remoteSessionCookieHeader`, `new LoginCodes(null, 120, { store: new MemoryCodeStore(), key })` |
 
-1. **Serve the four routes** in the app that already exists — not beside it. The complete worked
+1. **Serve the four routes** in the app that already exists, not beside it. The complete worked
    example is [`scripts/sample-remote-service.mjs`](scripts/sample-remote-service.mjs): it runs
    with its own TLS or behind a platform router.
 2. **Secrets live on the platform:** the service token and the session key (32 bytes) are
@@ -335,7 +336,7 @@ things change and the kits implement each:
    remote service needs is issued and kept in Project Observatory, pushed to the platform, and
    the movement recorded with `vault.py moved --at <provider>`, so the platform's copy is
    known rather than invisible.
-3. **Register it on the operator's computer** — the installer side, run there:
+3. **Register it on the operator's computer**, the installer side, run there:
    `registerRemote({ id, name, origin, token })` / `register_remote(...)` writes the token file
    (0600) and the descriptor; pass the token from a file or stdin, never in argv. Public names
    only in public artifacts: a private service is registered by a local descriptor and nowhere
@@ -349,7 +350,7 @@ behaviour a host shows, rotation, a multi-process platform, and what a host will
 
 ## Migrating an existing service
 
-Read [the migration reference](references/migrating-a-service.md) — the order of
+Read [the migration reference](references/migrating-a-service.md): the order of
 changes that keeps the service answering throughout, and what each existing service on
 this estate needs.
 
@@ -366,14 +367,14 @@ this estate needs.
   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
+- **Fabric Dashboards not installed:** nothing changes; the service is complete
   without a host; the descriptor waits for one.
 
 ## 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` — two services here once defaulted to ports
+  `service.id` and `service.instance`: two services here once defaulted to ports
   another service already held.
 - `launchctl bootstrap` right after `bootout` fails with I/O error 5 until the unload
   finishes; wait, then retry.
@@ -396,7 +397,7 @@ the probe table verbatim with every `NOT_RUN` explained; the lock and kill-9 res
 with pids; and the one next command. Never call a service conformant while the probe
 reports a `FAIL`.
 
-## Dashboard handoff — also for consumers
+## Dashboard handoff: also for consumers
 
 When handing a registered service dashboard to a person, or writing the generated
 agent's completion/notification instructions, read and apply

package/plugins/fabric-agent-adapter/skills/building-fabric-services/assets/dashboard-kit/demo.html

@@ -65,7 +65,7 @@
           <tbody>
             <tr><td class="fd-mono">job-7f3a91</td><td>example.summarize</td><td><span class="fd-chip fd-s-info"><span class="fd-dot"></span>Running</span></td><td><time>2026-10-11 17:02</time></td><td class="fd-num">12 480</td><td class="fd-num">$0.031</td><td class="fd-mono">4bf92f3577b34da6a3ce929d0e0e4736</td></tr>
             <tr><td class="fd-mono">job-7f3a90</td><td>example.translate</td><td><span class="fd-chip fd-s-ok"><span class="fd-dot"></span>Done</span></td><td><time>2026-10-11 16:40</time></td><td class="fd-num">8 002</td><td class="fd-num">$0.019</td><td class="fd-mono">00f067aa0ba902b74bf92f3577b34da6</td></tr>
-            <tr><td class="fd-mono">job-7f3a8f</td><td>example.review</td><td><span class="fd-chip fd-s-warn"><span class="fd-dot"></span>Needs you</span></td><td><time>2026-10-11 15:12</time></td><td class="fd-num">2 210</td><td class="fd-num">—</td><td class="fd-mono">a3ce929d0e0e47364bf92f3577b34da6</td></tr>
+            <tr><td class="fd-mono">job-7f3a8f</td><td>example.review</td><td><span class="fd-chip fd-s-warn"><span class="fd-dot"></span>Needs you</span></td><td><time>2026-10-11 15:12</time></td><td class="fd-num">2 210</td><td class="fd-num">none</td><td class="fd-mono">a3ce929d0e0e47364bf92f3577b34da6</td></tr>
           </tbody>
         </table>
       </div>

package/plugins/fabric-agent-adapter/skills/building-fabric-services/assets/dashboard-kit/fabric-button.js

@@ -1,4 +1,4 @@
-/* fabric-dashboard-kit@1.1.0 · Fabric's button (Fabric Agent Contract DEC-0040, FB-1…FB-8, FL-1…FL-6)
+/* fabric-dashboard-kit@1.1.1 · Fabric's button (Fabric Agent Contract DEC-0040, FB-1…FB-8, FL-1…FL-6)
    Load it same-origin, after fabric-dashboard.css, with the service it opens Fabric on:
      <script src="fabric-button.js" defer data-service="example-agent.default" data-service-name="Example Agent"
              data-project="project-a" data-project-name="Project A"></script>
@@ -10,7 +10,7 @@
 (function (root) {
   'use strict';
 
-  var VERSION = '1.1.0';
+  var VERSION = '1.1.1';
   var COOKIE = 'fabric_button';
   var GET_FABRIC = 'https://passioncode.ai/fabric';
   var ABSENT_AFTER_MS = 1500;
@@ -212,7 +212,7 @@
       return a;
     });
     var note = el(doc, 'p', { 'class': 'fd-fabric-button-note', role: 'note' });
-    note.appendChild(doc.createTextNode('Fabric is not installed — get it at '));
+    note.appendChild(doc.createTextNode('Fabric is not installed. Get it at '));
     note.appendChild(el(doc, 'a', { href: GET_FABRIC, target: '_blank', rel: 'noopener', 'class': 'fd-fabric-button-get' }, 'passioncode.ai/fabric'));
     note.hidden = !absent;
     menu.appendChild(note);

package/plugins/fabric-agent-adapter/skills/building-fabric-services/assets/dashboard-kit/fabric-dashboard.css

@@ -1,4 +1,4 @@
-/* fabric-dashboard-kit@1.1.0 · fabric-dashboard/0.1 (Fabric Agent Contract DEC-0036)
+/* fabric-dashboard-kit@1.1.1 · fabric-dashboard/0.1 (Fabric Agent Contract DEC-0036)
    A Fabric service dashboard shown inside a host pane: usable from 360 CSS px up, navigation always
    reachable, wide content in its own scroll box, one vertical scroller, appearance from the host.
    Copy this file next to fabric-dashboard.js; do not edit it in place. Put the page's own rules in

package/plugins/fabric-agent-adapter/skills/building-fabric-services/assets/dashboard-kit/fabric-dashboard.js

@@ -1,4 +1,4 @@
-/* fabric-dashboard-kit@1.1.0 · fabric-dashboard/0.1 (Fabric Agent Contract DEC-0036)
+/* fabric-dashboard-kit@1.1.1 · fabric-dashboard/0.1 (Fabric Agent Contract DEC-0036)
    Load it same-origin with <script src="fabric-dashboard.js" defer></script>: no inline script, no
    eval, nothing from a CDN. It applies the host's appearance (ED-6, ED-8), folds navigation that
    does not fit into a More menu (ED-3), makes wide boxes keyboard-reachable (ED-4) and keeps
@@ -8,7 +8,7 @@
   'use strict';
 
   var KIT = 'fabric-dashboard-kit';
-  var VERSION = '1.1.0';
+  var VERSION = '1.1.1';
   /* fabric-dashboard-kit:theme-ids:begin */
   var THEMES = ['graphite', 'fabric', 'paper', 'forest', 'ocean', 'ember', 'contrast'];
 /* fabric-dashboard-kit:theme-ids:end */

package/plugins/fabric-agent-adapter/skills/building-fabric-services/assets/dashboard-kit/kit.json

@@ -1,6 +1,6 @@
 {
   "name": "fabric-dashboard-kit",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "profile": "fabric-dashboard/0.1",
   "decision": "DEC-0036",
   "declarationKey": "https://fabric.passioncode.ai/agent-contract/extensions/dashboard/0.1",
@@ -15,9 +15,9 @@
     "contrast"
   ],
   "files": {
-    "fabric-dashboard.css": "498571903fac6dfd2d6645283da2f703fa945f410f2fafa269a8c9c322735c3b",
-    "fabric-dashboard.js": "100f55d940d4ed60aa8511cee4c65219c93114eb7d7a66639b0e4e4d7aa05f22",
-    "fabric-button.js": "4f1e100936ae65af5539594681e66092ae1834a4952da547a67d0558c9fadbbe",
+    "fabric-dashboard.css": "a8847c8e2f386572318842ec1d1613fcb29e4aec060e033c060d8dba6b7c6f02",
+    "fabric-dashboard.js": "d0fc41144a6bd413383bd53bbfa6e01a29547c7ec9c01a3927d69fb36cd71a7d",
+    "fabric-button.js": "f5599fabfeadfb5c69d30f7ea500846521a166470078a736291c7753014bc25c",
     "themes.json": "511839f1a1a83eb37fadfd132791474497d5c28c5091700b9aa31ad076e359b5"
   },
   "history": {
@@ -29,6 +29,11 @@
       "fabric-dashboard.css": "498571903fac6dfd2d6645283da2f703fa945f410f2fafa269a8c9c322735c3b",
       "fabric-dashboard.js": "100f55d940d4ed60aa8511cee4c65219c93114eb7d7a66639b0e4e4d7aa05f22",
       "fabric-button.js": "4f1e100936ae65af5539594681e66092ae1834a4952da547a67d0558c9fadbbe"
+    },
+    "1.1.1": {
+      "fabric-dashboard.css": "a8847c8e2f386572318842ec1d1613fcb29e4aec060e033c060d8dba6b7c6f02",
+      "fabric-dashboard.js": "d0fc41144a6bd413383bd53bbfa6e01a29547c7ec9c01a3927d69fb36cd71a7d",
+      "fabric-button.js": "f5599fabfeadfb5c69d30f7ea500846521a166470078a736291c7753014bc25c"
     }
   }
 }

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

@@ -63,12 +63,12 @@ One tick every 15 s ± 5 s (`step()` answers the wait):
 
 | Step | Board call | Checkpoint written first |
 |---|---|---|
-| hold the slot | `com.enroll` (again at about 20 s while idle: the holder's enroll renews its 60 s lease) | — |
+| hold the slot | `com.enroll` (again at about 20 s while idle: the holder's enroll renews its 60 s lease) | none |
 | take a request | `com.claim`, the same key while nothing is claimable | `claimed` |
-| read it | `com.get`: the digest must equal the claim's, and the request must name this Project and capability | — |
+| read it | `com.get`: the digest must equal the claim's, and the request must name this Project and capability | none |
 | accept | `com.accept` with the claim's exact fence (request, generation, attempt, digest, revision) | `accepting`, then `accepted` |
 | act | `com.effect_begin`, only when the handler calls `ctx.begin_effect()` | `effect-beginning`, then `in-progress` |
-| while working | `com.renew` at about 20 s; `com.progress` for `ctx.progress(note)` | — |
+| while working | `com.renew` at about 20 s; `com.progress` for `ctx.progress(note)` | none |
 | answer | `com.reply` (fenced) when the outcome carries `reply` | `replying` |
 | settle | `com.complete {state, observed, summary?, evidence?}` | `completing`, then the entry is dropped |
 
@@ -82,12 +82,12 @@ own monotonic clock and never reasons from `leaseExpiresAt`.
 `admit(request)` is required: it is the service's own input gate. It answers `None` to admit or one sentence saying
 why not; a refusal accepts the request and completes it `failed_known` with that sentence, so the requester learns it
 and the request does not bounce. A redacted body is refused the same way. The kit never hands a body to a model, a
-shell or a tool; what the handler does with an admitted body — and the checks it needs before a model, a tool or a
-spend sees it — is the service's own responsibility. A message never carries an approval.
+shell or a tool; what the handler does with an admitted body (and the checks it needs before a model, a tool or a
+spend sees it) is the service's own responsibility. A message never carries an approval.
 
 ## Effects, observation, evidence and the reply
 
-- Call `ctx.begin_effect(summary)` — and let it return — before the handler spends, writes outside the service or calls
+- Call `ctx.begin_effect(summary)`, and let it return, before the handler spends, writes outside the service or calls
   anything that acts. If it raises `Stopped`, act no further.
 - After an effect began, the outcome must be observed (`observed: true`): the kit never sends an unobserved result; the
   request stays unknown and is reconciled later.
@@ -130,7 +130,7 @@ contract's matrix, held to its vectors (`test/fixtures/contract/comms-hold-vecto
 | `com.enroll`, `com.claim`, `com.responder_replace` | the slot pauses: asked again after 15 s, then 30 s, doubling to 15 minutes; one `board.slot.held` event per capability, and `board.slot.released` when an enroll succeeds again |
 | `com.accept` (the hold came after the claim) | nothing was done: the entry is dropped, the claim lapses and the request waits on the board (`board.request.waiting`); the slot pauses |
 | `com.effect_begin` | the effect has not begun: the handler waits (same idempotency key, the pause doubling) while the tick keeps renewing the lease, then begins once the hold is lifted; `ctx.stopped` ends the wait |
-| accepted work at restart under a hold | kept as `lapsed`, then taken back with `com.responder_replace` and a transfer once the hold is lifted — never claimed back |
+| accepted work at restart under a hold | kept as `lapsed`, then taken back with `com.responder_replace` and a transfer once the hold is lifted, never claimed back |
 
 A hold is not an outage: no `board.down`, no notify. Work already accepted keeps running and completes.
 
@@ -143,7 +143,7 @@ whose responder was gone. Read it as the owner's attestation, not the responder'
 A board session (`fabric.board.join`) is served the respond scope only: `com.status`, `com.list`, `com.get`,
 `com.reply` (the fenced form), `com.enroll`, `com.claim`, `com.renew`, `com.accept`, `com.progress`,
 `com.effect_begin`, `com.complete`, `com.reconcile`, `com.responder_replace`. `BoardSession.call` refuses anything else
-locally (`not-in-scope`) — never `com.submit`, `com.cancel`, `com.read_ack` or `com.directory`.
+locally (`not-in-scope`): never `com.submit`, `com.cancel`, `com.read_ack` or `com.directory`.
 
 The idempotency epoch comes from `com.status`. A Fabric built before its board-session fix tells a board session none:
 the kit fails closed (`no-epoch`, `board.blocked`) instead of guessing one.
@@ -152,13 +152,13 @@ the kit fails closed (`no-epoch`, `board.blocked`) instead of guessing one.
 
 The directory belongs to a Project session (a coding agent's, or a launched one). Before looking a Project up in a
 `com.directory` page, `find_project(page, project_id, capability=None)` / `findProject` checks the page: closed shapes
-(no count, holder or generation) and FAC-SEM-107 — each Project once, each capability once per Project. Project ids and
+(no count, holder or generation) and FAC-SEM-107: each Project once, each capability once per Project. Project ids and
 capability names compare **exactly as written** (DEC-0077; they are not URIs, so not by normal form). A page that fails
 raises `directory-invalid` rather than answering; an unlisted Project may still be addressed by an id already held.
 
 ## Events, the probe and the live smoke
 
-Events go to `emit(kind, level, text, notify=…, data=…)` — `JsonlEventLog.append` fits — with `data {schema, value}`
+Events go to `emit(kind, level, text, notify=…, data=…)` (`JsonlEventLog.append` fits) with `data {schema, value}`
 checked by FAC-SEM-101 (no credential in data): `board.request.completed`, `board.request.refused`,
 `board.request.skipped`, `board.request.reconciled`, `board.request.held`, `board.attempt.lost`,
 `board.reconcile.needed`, `board.slot.contested`, `board.access.needed`, `board.blocked`, `board.down`, each
@@ -167,10 +167,10 @@ notifying episode said once.
 `check_service.py <id> [--board-kit <the service's fabric_board.py or fabric-board.mjs>]` rule **board.responder**:
 `NOT_RUN` when the well-known `protocols` names no `fabric-project-comms` revision; `FAIL` for a revision this kit does
 not read or a fixture conversation that goes wrong; `PASS` when the kit's `self_check()` / `selfCheck()` passes (the
-whole conversation, a fenced accept, a session without an epoch — no Fabric touched).
+whole conversation, a fenced accept, a session without an epoch; no Fabric touched).
 
 The live smoke runs only against a disposable Fabric (built app and its own stack), never an operator's estate: Fabric's
-COM-03 packet (`docs/evidence/plans/2026-10-04-project-communications.md`) has the exact commands — register
+COM-03 packet (`docs/evidence/plans/2026-10-04-project-communications.md`) has the exact commands: register
 `fabric-mcp` for Claude Code and Codex, the operator allows `session.enroll` and `board.respond`
 (`board:<example-agent project>/<capability>`), Claude submits a request, the responder enrolls, claims, accepts and
 completes, then is killed mid-claim and replaced. Without that Fabric, report it `NOT_RUN`.

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

@@ -1,4 +1,4 @@
-# The dashboard kit — `fabric-dashboard/0.1`
+# The dashboard kit: `fabric-dashboard/0.1`
 
 Fabric Dashboards shows a service's page in a pane beside its sidebar and the agent console, and the
 operator drags the console wider whenever they need it. The page never knows how much room it will
@@ -97,12 +97,12 @@ service. Load it after the stylesheet, with ids only:
   scroll. The mark and the word *Fabric*, the mark alone below 480 px; the accessible name is always *Open Fabric*;
   `--ink` on `--panel` with an `--edge` boundary, the pairs the themes are measured on.
 - **Links (FL-1…FL-6):** built with the kit's port of the contract's `buildFabricLink`; a value outside the grammar
-  — or one shaped like a credential — means no button, never a bad link. A press opens a view in Fabric and starts
+  (or one shaped like a credential) means no button, never a bad link. A press opens a view in Fabric and starts
   nothing (FB-8).
 - **The host (FB-6):** when the host's `fabric_button` cookie says `owner=host`, the page hides its own button.
 - **Fabric absent (FB-5):** when the cookie says `fabric=absent`, or `data-fabric="absent"`, or when the page is still
-  visible and focused 1.5 s after a link was followed, the menu says "Fabric is not installed — get it at
-  passioncode.ai/fabric". Nothing downloads, nothing retries. A local service's server decides `data-fabric` with
+  visible and focused 1.5 s after a link was followed, the menu says that Fabric is not installed and names
+  passioncode.ai/fabric to get it. Nothing downloads, nothing retries. A local service's server decides `data-fabric` with
   `fabric_button_presence()` / `fabricButtonPresence()`: `present` while Fabric's own descriptor
   (`services/fabric.default.json`, Fabric ADR-0139) is registered and, for an app's descriptor (`manager: "person"`,
   DEC-0069), its app is still installed; `absent` otherwise. A press only follows a link, so the button never reads

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

@@ -1,4 +1,4 @@
-# Dashboard links — producer and consumer rule
+# Dashboard links: producer and consumer rule
 
 Read when an agent creates a dashboard, implements `<tool> dashboard`, or hands
 an existing Fabric service dashboard to a person. This also applies to generated

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

@@ -4,10 +4,10 @@ The dashboard is where the operator decides; it must stay truthful when parts of
 service are not.
 
 1. **Same origin, static assets.** HTML shell plus hashed `app.js`/`app.css` from a
-   whitelist; no inline script; a strict CSP. Nothing from a CDN — the page must work
+   whitelist; no inline script; a strict CSP. Nothing from a CDN: the page must work
    offline on a plane.
 2. **State first, then detail.** The top of every page answers "is it working, and
-   does it need me?" — the same `status`, `degraded` and attention tiles the
+   does it need me?": the same `status`, `degraded` and attention tiles the
    well-known document publishes, so the page and Fabric Dashboards never disagree.
 3. **Calm refresh.** Poll the page's own API every 5 s while visible, back off when
    hidden, and pause while a field is focused, a form has unsaved input or a dialog is
@@ -16,7 +16,7 @@ service are not.
 4. **Partial failure stays partial.** Load panels independently (`Promise.allSettled`);
    a failed panel shows its own one-sentence error and a retry, and the rest render.
 5. **Every error is a sentence and an action.** "Store listing push failed: App Store
-   Connect rejected the key. Settings → Keys" — never a status code, a stack trace or a
+   Connect rejected the key. Settings → Keys", never a status code, a stack trace or a
    blank area. Show when data was last fresh.
 6. **Server down is a state, not a crash.** When the API stops answering, keep the
    last data greyed with "Service not answering since 17:02", and recover by itself
@@ -30,4 +30,4 @@ service are not.
 9. **Links into the page are stable.** Event `link`s point at hash routes that survive
    a reload (`/dashboard#/approvals/77`) so a notification opens the exact item.
 10. **No second browser tab required.** With Fabric Dashboards installed, the page is
-    shown inside it; do not open windows or tabs on your own — use in-page dialogs.
+    shown inside it; do not open windows or tabs on your own; use in-page dialogs.

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

@@ -1,4 +1,4 @@
-# Delegation — checking who acts for whom (DEC-0039)
+# Delegation: checking who acts for whom (DEC-0039)
 
 A service that other agents of the estate call checks each call offline with the kit's verifier: the estate hub
 signs a delegation token naming the person (`sub`), the actor chain (`act`), this service (`aud`), the
@@ -22,7 +22,7 @@ contract's own verifier does.
 ## Declaring it
 
 In the well-known document: `surfaces.mcp.auth: "delegation"` (only delegation tokens) and
-`auth.delegation: {issuer, jwks}` — the `iss` you trust (`urn:fabric:estate:<id>`) and where the key set is read.
+`auth.delegation: {issuer, jwks}`: the `iss` you trust (`urn:fabric:estate:<id>`) and where the key set is read.
 The descriptor's token stays the host's: it is never a caller's credential on `/mcp` (DL-12). The probe checks
 the declaration (`auth.delegation-declared`) and that `/mcp` refuses the descriptor token.
 
@@ -34,7 +34,7 @@ keys = fd.JwksCache(well_known["auth"]["delegation"]["jwks"])          # https,
 gate = fd.delegation_gate(audience="example-agent", jwks=keys, issuer=well_known["auth"]["delegation"]["issuer"],  # required
                           effects={"example.write": "draft", "example.publish": "publish"})   # each tool's manifest effect
 server = fi.McpToolServer("example-agent", VERSION, authorize=gate)    # pass the request headers to handle()
-# in a handler: ctx.delegation["principal"], ["caller"], ["chain"] — record the chain with the work
+# in a handler: ctx.delegation["principal"], ["caller"], ["chain"]; record the chain with the work
 ```
 
 ```js
@@ -50,7 +50,7 @@ if (!verdict.ok) return refusalToolResult(verdict);
 DL-25 places each caller in a tier by its origin: **T0** a loopback caller under the owner's account that the
 service's own local floor (the descriptor token, the Host guard) has authenticated; **T1** an enrolled machine of
 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,
+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
 profile. Money limits and human gates bind at every tier.
@@ -63,24 +63,34 @@ job's own capability and effect, and only for the principal and caller that star
 `scope-not-granted`); `on_input` gets the checked delegation on its context. Start jobs with `ctx.start_job()` so the
 job records who started it.
 
+**A partner in the chain** (DEC-0090). A token a partner's agent presents for a customer organization carries the
+partner as the innermost actor: `{partner: "org:<id>"}`, exactly that member, under at least one agent. It counts
+toward the depth limit and ends the chain; outermost, with an `act` beneath, or as `personal` it is
+`malformed-chain`. A node with a `sub` beside `partner` is checked as an agent, yet `ctx.delegation["chain"]` lists it
+by its `org:` id, as the contract's `chainOf` does; the schema refuses such a node, so a correct issuer never mints one
+(raised with the contract, FAA-64). Job ownership and idempotency keys follow `(principal, caller)` and do not include
+the partner (FAA-64). `chain_depth(act)` /
+`chainDepth(act)` answer the contract's depth, infinity for a chain that is not one. Minting a partner's token (its
+grant, FAC-SEM-124) is the issuer's, not the kit's.
+
 ## Approvals
 
 An action with an external effect may need the operator's approval (DL-17, DL-18). The order is fixed: the token,
 then the grant check where there is one, then `verify_approval` / `verifyApproval`, which consumes the approval's
 `jti` last, then the action. Without an approval, answer `approval-required` with
-`action_digest(action)` / `actionDigest(action)` — the SHA-256 of the action's RFC 8785 form (`jcs`) — so the caller
+`action_digest(action)` / `actionDigest(action)` (the SHA-256 of the action's RFC 8785 form, `jcs`) so the caller
 can ask the hub. When the meter denies a grant check, answer `refusal_from_denial(denial)` /
 `refusalFromDenial(denial)`: the meter's code unchanged, its window and level in `error.data` (DL-21 step 6). Keep consumed ids in `FileJtiStore` (0600, survives a restart); `MemoryJtiStore` is for tests
 and `UNSAFE_NO_JTI_STORE` exists only by name. No store at all, or a store file that cannot be read, is
-`unknown-state` — never a pass.
+`unknown-state`, never a pass.
 
 ## What a refusal looks like
 
-DL-19: an MCP tool answers `refusal_tool_result(r)` / `refusalToolResult(r)` — `isError: true` and
+DL-19: an MCP tool answers `refusal_tool_result(r)` / `refusalToolResult(r)`: `isError: true` and
 `structuredContent: {error: {code, message, data: {detail}}}`; an HTTP route answers `refusal_http(r)` /
 `refusalHttp(r)` with the code's status (401 for `unauthenticated`, `token-expired`, `principal-unproven`, with
 `WWW-Authenticate: Bearer error="invalid_token"`; 503 for `issuer-unavailable` and `unknown-state`; 403 for the
-rest). A published key the service cannot use — of small order, for another use, or published twice — is the
+rest). A published key the service cannot use (of small order, for another use, or published twice) is the
 issuer's fault, `issuer-unavailable` (DEC-0045); a gate without a trusted issuer refuses everything as
 `no-trusted-issuer`. `detail` is a short machine word; the token, the approval and the keys never appear in a result or a log.
 
@@ -112,4 +122,4 @@ current verified revision as `estate=` / `{ estate }`, as a value or as a functi
 ## What the kit does not do
 
 It does not mint tokens, check attenuation against a parent (the issuer's rule, DL-5), check a grant or a spend
-window (the meter's, DL-21), or decide which actions need an approval — the service decides that.
+window (the meter's, DL-21), or decide which actions need an approval; the service decides that.