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

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.
@@ -66,8 +66,10 @@ 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 an agent, checked as one. `ctx.delegation["chain"]` lists a
-node with `partner` by its `org:` id. `chain_depth(act)` /
+`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.
 
@@ -76,19 +78,19 @@ grant, FAC-SEM-124) is the issuer's, not the kit's.
 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.
 
@@ -120,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.

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

@@ -1,7 +1,8 @@
-# The estate record — what the operator's machines are, signed by their passkey (DEC-0055)
+# The estate record: what the operator's machines are, signed by their passkey (DEC-0055)
 
 Fabric Agent Contract DEC-0055, `docs/specification/estate-record.md`, schema `schemas/estate-record.schema.json`,
-rules `FAC-SEM-072…076`, with contexts (DEC-0082, `docs/specification/contexts.md`, `FAC-SEM-110`, `FAC-SEM-111`).
+rules `FAC-SEM-072…076`, with contexts (DEC-0082, `docs/specification/contexts.md`, `FAC-SEM-110`, `FAC-SEM-111`) and a
+partner's scoped publisher key (DEC-0090, `docs/specification/partner-channel.md`, `FAC-SEM-122`).
 One revision of one person's estate lists:
 - the passkeys that sign it;
 - the machines, with their device keys and a certificate of each machine's hub key;
@@ -78,13 +79,13 @@ gate = fd.delegation_gate(audience=..., jwks=keys, issuer=..., effects=..., esta
                           estate_revocations=lambda: delta_entries)
 ```
 
-- **The token's fault** — no such certification, another key under that `kid`, a `kid` on two machines, a revoked hub
-  key or machine — is `unauthenticated` (for an approval, `approval-invalid`) with detail `kid-not-certified`.
+- **The token's fault** (no such certification, another key under that `kid`, a `kid` on two machines, a revoked hub
+  key or machine) is `unauthenticated` (for an approval, `approval-invalid`) with detail `kid-not-certified`.
 - **The trust source's fault** is `issuer-unavailable`: `estate-unreadable` (a source that throws or answers nothing
   readable, a revision without a number or digest, a window of zero or over 30 days, dates read strictly, `machines` or
   `revocations` not arrays), `estate-outside-window`, `estate-rolled-back` (lower than the applied revision) and
   `estate-forked` (the applied number with another digest). A caller cannot cure these by minting again.
-- An unreadable clock — not a finite number of seconds a `Date` can hold — is refused `unknown-state` `no-clock`
+- An unreadable clock (not a finite number of seconds a `Date` can hold) is refused `unknown-state` `no-clock`
   before row 1, in every verifier.
 - Only an absent `estate` skips the check. In the Node kit `null` is an unreadable source; in Python, where `None` is
   the absent value, pass a function returning `None` for a source that has nothing.
@@ -117,6 +118,10 @@ of `[A-Za-z0-9][A-Za-z0-9_-]{0,127}`. Absent is `personal`; `null` is not absent
   names the keys that are a partner's (`kid`, `partner: org:<id>`, `contexts`); a placement under such a key is in one
   of the organization contexts listed, never `personal` or another organization. A key is scoped once, and only a key
   `publisherKeys` pins. A key no scope names keeps DEC-0051's meaning, trusted in any context.
+- **Update a copied kit before a revision carries `publisherScopes`.** A service runs the copy of the kit it was built
+  with; a copy older than 0.39.0 does not read `publisherScopes`, so it trusts a partner's key in every context and
+  finds no rule broken. A service that applies the estate record updates its copy of `fabric_estate.py` /
+  `fabric-estate.mjs` to 0.39.0 or later first.
 
 Every rule is total on hostile JSON, as the contract's are: an `instancePath` names an item by its index as written (a
 non-object before it does not shift it), and a value whose own `toString` member is data is shown as its JSON. Both kits

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/events-and-notifications.md

@@ -13,7 +13,7 @@ The feed is a view: never copy rows into a second store that can drift from the
 
 ## Reading a feed (FAC-SEM-036)
 
-A client of `GET /fabric/v1/events` — or of any token-protected route — sends the token in the
+A client of `GET /fabric/v1/events` (or of any token-protected route) sends the token in the
 header the descriptor's `auth.header` names, in the form `auth.scheme` names: the raw token for
 `none`, `Bearer <token>` for `Bearer`. Never assume `Authorization: Bearer`: a client that did
 was refused on every poll and silently dropped every notify event. `token_header(auth, token)` /
@@ -27,7 +27,7 @@ in the URL.
 - `level`: `info` (routine), `notice` (the operator may want to look), `warning`
   (something is degrading), `error` (something failed and needs action).
 - `text`: one sentence, in the operator's language, with the object named and the
-  number stated — "The Q3 report draft is ready for your approval (12 sections, 3
+  number stated: "The Q3 report draft is ready for your approval (12 sections, 3
   languages)." Never a machine id, never a stack trace.
 - `subject`: what it is about (`{type: "report", id: "q3", label: "Q3 report"}`), so a host
   can group.
@@ -42,11 +42,11 @@ lands on what matters:
 
 | The operator… | Event | `notify` |
 |---|---|---|
-| must decide or act — a choice, an approval, a key to enter | kind says it: `job.awaiting_choice`, `plan.awaiting_approval`, `human_step.opened`; level `notice` | `true` |
-| lost work — a job failed after its retries, a key expired | level `error`; kind `*.failed`, `*.expired` | `true` |
-| will lose work soon — a degraded source that blocks orders | level `warning`, `service.degraded`, **once when it starts** | `true` |
+| must decide or act: a choice, an approval, a key to enter | kind says it: `job.awaiting_choice`, `plan.awaiting_approval`, `human_step.opened`; level `notice` | `true` |
+| lost work: a job failed after its retries, a key expired | level `error`; kind `*.failed`, `*.expired` | `true` |
+| will lose work soon: a degraded source that blocks orders | level `warning`, `service.degraded`, **once when it starts** | `true` |
 | asked to be told when a long job finishes | `job.delivered`, level `notice` | `true` only if that person asked; a host may still keep it in Activity |
-| only needs the record — progress, retries, recoveries, syncs | `job.started`, `service.recovered`, `*.cleared`, level `info` or `notice` | `false` |
+| only needs the record: progress, retries, recoveries, syncs | `job.started`, `service.recovered`, `*.cleared`, level `info` or `notice` | `false` |
 
 - **One episode, one request.** Notify on the transition, never on each poll: a source that
   flaps between degraded and healthy sends `service.degraded` with `notify: true` once, and later

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

@@ -4,14 +4,14 @@ Normative source: the Fabric Agent Contract's `docs/specification/interop.md` (D
 at the commit this plugin pins. This page says how the kit implements it; where the two
 differ, the contract is right.
 
-A service that other agents — and Fabric — call does five things. Each has one helper in
+A service that other agents (and Fabric) call does five things. Each has one helper in
 `scripts/fabric_interop.py` (Python) and `scripts/fabric-interop.mjs` (Node).
 
 | Rule | What the service does | Helper |
 |---|---|---|
-| C3.1 capability = tool | serves each `mcp` capability of its manifest as the MCP tool of the same name, with the manifest's input schema unchanged, its output schema unchanged — or, for a job, wrapped as `oneOf[result envelope, job handle]` — and annotations from the effect | `tool_for_capability` / `toolForCapability`, `job_tool_output_schema`, `expected_annotations` |
+| C3.1 capability = tool | serves each `mcp` capability of its manifest as the MCP tool of the same name, with the manifest's input schema unchanged, its output schema unchanged (or, for a job, wrapped as `oneOf[result envelope, job handle]`) and annotations from the effect | `tool_for_capability` / `toolForCapability`, `job_tool_output_schema`, `expected_annotations` |
 | C3.2 long work = job | a capability whose work can outlive one request declares `"job": true` in its interop block, returns `{"job": {"id", "status": "working"}}`, and serves `fabric.job.get` and `fabric.job.cancel` | `JobStore`, `McpToolServer` (Python), `unknown_job_result` |
-| C3.2 result | a completed job carries the full result envelope — the shape a synchronous call returns: `id`, `contractVersion`, `outcome`, `done`, `proof`, `scope`, `notVerified`, `artifacts`, `createdAt`, `producer`, `output`, `usage`, and its `trace` | `result_envelope` / `resultEnvelope` |
+| C3.2 result | a completed job carries the full result envelope, the shape a synchronous call returns: `id`, `contractVersion`, `outcome`, `done`, `proof`, `scope`, `notVerified`, `artifacts`, `createdAt`, `producer`, `output`, `usage`, and its `trace` | `result_envelope` / `resultEnvelope` |
 | C3.3 a person decides | the job goes `input_required` with an elicitation: a titled single-select in form mode, and URL mode for anything secret | `choice_request`, `form_request`, `url_request` |
 | C3.4 trace | every call runs as a child span of the caller's `_meta.traceparent`; outgoing calls carry the same trace; the result envelope records it; events about traced work carry `traceId` and `spanId`, events about untraced work none | `child_traceparent`, `trace_ids`, `make_event(..., trace_id=, span_id=)` |
 
@@ -61,7 +61,7 @@ response = server.handle(json_rpc_message)          # POST /mcp body in, JSON re
 open with a handshake, and a server that refuses it is marked failed), `server/discover`,
 `tools/list` and `tools/call` with JSON responses. Every tool's `outputSchema` must be
 rooted at `type: object` (DEC-0018): `add_tool` refuses any other root, because a client may
-drop the whole tool list over one bad schema — an SDK-level test will not show it, so check
+drop the whole tool list over one bad schema; an SDK-level test will not show it, so check
 with the real client (below). A service already on an MCP SDK keeps
 the SDK and uses only the helpers. The Node kit has the helpers and the same job file
 format, without the dispatcher. `scripts/sample_service.py` is the worked example:
@@ -73,7 +73,7 @@ DEC-0017 amended by DEC-0018), so its `structuredContent` always conforms; an ev
 untraced work carries no trace pair.
 
 **Check with a real client**, never only an SDK: `FABRIC_REAL_CLIENT=1 python3 -m unittest
-test.test_real_client` in the adapter repository, or by hand — a throwaway directory, a
+test.test_real_client` in the adapter repository, or by hand: a throwaway directory, a
 temporary `--mcp-config` (mode 600, the token in a header) and `--strict-mcp-config`, so
 the operator's own configuration is not touched:
 
@@ -105,7 +105,9 @@ As a provider:
   `limit_holds=False`, a `limit-reached` job once `approval_granted=True`, and an `outcome-unknown` job never.
 - **Usage you did not measure is `null`, never 0,** but only toward a caller whose request `_meta.protocols` names
   `fabric-interop/0.2`: pass `request_meta` to `result_envelope` (`usage_toward`). Toward any other caller the kit
-  writes the measured lower bound, as before.
+  writes the measured lower bound, as before. Either way, record that call's usage receipt with
+  `tokens_measured=False` / `tokensMeasured: false` and the tokens you have, so your own usage report counts it in
+  `unmeasuredCalls` and does not show the lower bound as complete (DEC-0091, [usage](usage.md)).
 
 As a caller: send `request_meta(traceparent)` as your `_meta` (it names `fabric-interop/0.1` and `0.2`), act on every
 `fabric.job.get` answer as `job_caller_action(answer, now)` says, and resend only under

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

@@ -1,4 +1,4 @@
-# Lifecycle — supervisor, install, release layout, state
+# Lifecycle: supervisor, install, release layout, state
 
 **This page is the rule** for anyone who builds, installs or runs a `fabric-service/0.1` service with this
 skill. Everything you must follow is stated here or in the public Fabric Agent Contract's
@@ -56,17 +56,17 @@ that document until `service.id` matches (at most 40 s) before it calls the serv
 | Id | Rule | Here | Kit (Python / Node) |
 |---|---|---|---|
 | LC-01 | **Quit reaches exit within a deadline.** Every trigger (`SIGTERM`, `SIGINT`, logout, the app's own quit) ends the process: within 5 s idle, within 10 s with work in flight, then a hard exit. Nothing starts after quit begins | [Shutdown](#shutdown) | `Drain` / `Drain` |
-| LC-02 | **Every child has an owner, a deadline and a process group.** No subprocess without a timeout; on timeout or the parent's exit the whole group goes; no orphan survives. Locks and shared resources are released in `finally` | your own code | — |
+| LC-02 | **Every child has an owner, a deadline and a process group.** No subprocess without a timeout; on timeout or the parent's exit the whole group goes; no orphan survives. Locks and shared resources are released in `finally` | your own code | none |
 | LC-03 | **A job is bounded and exclusive.** One copy holds `service.lock`; a scheduled job has a watchdog shorter than its interval, shares its lock with every manual entry point, bounds every network call and records each run's outcome. Long work is journalled before it starts | [One copy under a supervisor](#one-copy-under-a-supervisor) | `hold_single_instance` / `holdSingleInstance` |
-| LC-04 | **Credentials are silent after setup.** No background prompt; a credential read that is denied or absent is cached and backs off until a person acts | [Directories](#directories) (secret files 0600) | — |
-| LC-05 | **Identity is stable across updates.** The supervisor runs a stable executable inside a release directory, never an interpreter by a versioned package-manager path; signed builds are pinned by team and identifier | [launchd plist](#launchd-plist-generate-it-with-launchd_plist-or-launchdplist-both-kits-write-the-same-bytes) | — |
+| LC-04 | **Credentials are silent after setup.** No background prompt; a credential read that is denied or absent is cached and backs off until a person acts | [Directories](#directories) (secret files 0600) | none |
+| LC-05 | **Identity is stable across updates.** The supervisor runs a stable executable inside a release directory, never an interpreter by a versioned package-manager path; signed builds are pinned by team and identifier | [launchd plist](#launchd-plist-generate-it-with-launchd_plist-or-launchdplist-both-kits-write-the-same-bytes) | none |
 | LC-09 | **The footprint is declared.** The service's `AGENTS.md` names every resident process, its supervisor label, unit or task and its port, who starts each and who stops it | the descriptor and the supervisor file | `write_descriptor`, `launchd_plist`, `systemd_unit` / `systemdUnit`, `task_xml` / `taskXml` |
 | LC-11 | **An update is a lifecycle event.** An upgrade writes a new immutable release and restarts through the supervisor; the previous release is kept for rollback, older ones are pruned | [Install, upgrade, uninstall](#install-upgrade-uninstall) | `prune_releases` / `pruneReleases` |
 | LC-12 | **Every file is bounded.** Logs rotate by size (5 × 5 MB), mode 0600, never in `/tmp`; temporary leftovers are swept at start | [Logs](#logs) | `RotatingLog`, `cap_stdout_log` / `RotatingLog`, `capStdoutLog` |
 | LC-14 | **The operator's intent wins; uninstall is symmetric.** No install or upgrade re-enables what the operator turned off; uninstall removes what install added (supervisor file, override, descriptor), and data goes only on an explicit purge | [Install, upgrade, uninstall](#install-upgrade-uninstall), [Linux and Windows](#linux-and-windows) | `launchd_install` / `launchdInstall`, `launchd_uninstall` / `launchdUninstall`; `systemd_install` / `systemdInstall`, `task_install` / `taskInstall` and their uninstalls |
 | LC-15 | **Builds clean up after themselves.** At most the current release and the one before it remain; the prune runs inside the installer, not later | [Install, upgrade, uninstall](#install-upgrade-uninstall) | `prune_releases` / `pruneReleases` |
 | LC-21 | **A secret never travels in a command line.** Keys reach the process through its environment, a 0600 file or a vault, never argv; a supervisor file carries no secret | [launchd plist](#launchd-plist-generate-it-with-launchd_plist-or-launchdplist-both-kits-write-the-same-bytes), [Linux and Windows](#linux-and-windows) | the supervisor-file writers refuse a secret-shaped value |
-| LC-22 | **Work survives a restart.** Work started but not finished is journalled on disk, without secrets, before it starts; the restarted service takes it back or cleans it up | [Shutdown](#shutdown) | — (the service's own journal) |
+| LC-22 | **Work survives a restart.** Work started but not finished is journalled on disk, without secrets, before it starts; the restarted service takes it back or cleans it up | [Shutdown](#shutdown) | none (the service's own journal) |
 
 ## launchd plist (generate it with `launchd_plist` or `launchdPlist`; both kits write the same bytes)
 
@@ -78,8 +78,8 @@ that document until `service.id` matches (at most 40 s) before it calls the serv
 | `KeepAlive` | `true` | `{SuccessfulExit:false}` leaves a cleanly exited service down |
 | `ThrottleInterval` | `10` | bounds a crash loop |
 | `ExitTimeOut` | above the drain and its hard exit (15 s default; `Drain` ends by 10 s) | SIGKILL arrives after it, so it must never come first |
-| `ProcessType` | `Standard` — never `Background`, and no `Nice` > 0 or `LowPriorityIO` | a host probes the service and agents call it while the Mac is busy; a background job is starved for tens of seconds under load and every host reports an outage that never happened (the probe's `lifecycle.priority` rule fails it) |
-| `EnvironmentVariables` | `PATH` set explicitly; `*_FILE` paths to secrets; `FABRIC_SERVICE_SUPERVISOR=launchd` | never a secret value — the plist is world-readable in backups; the supervisor marker is how the lock knows to back off (the probe's `lifecycle.supervisor-marker` rule fails a plist without it: a copy that finds the lock held would exit 75 at once into a respawn every `ThrottleInterval`) |
+| `ProcessType` | `Standard`, never `Background`, and no `Nice` > 0 or `LowPriorityIO` | a host probes the service and agents call it while the Mac is busy; a background job is starved for tens of seconds under load and every host reports an outage that never happened (the probe's `lifecycle.priority` rule fails it) |
+| `EnvironmentVariables` | `PATH` set explicitly; `*_FILE` paths to secrets; `FABRIC_SERVICE_SUPERVISOR=launchd` | never a secret value: the plist is world-readable in backups; the supervisor marker is how the lock knows to back off (the probe's `lifecycle.supervisor-marker` rule fails a plist without it: a copy that finds the lock held would exit 75 at once into a respawn every `ThrottleInterval`) |
 | `StandardOutPath`/`StandardErrorPath` | `~/Library/Logs/<id>/service.log` | one place the host tails |
 
 ## Install, upgrade, uninstall
@@ -103,13 +103,13 @@ that document until `service.id` matches (at most 40 s) before it calls the serv
 rewrites the plist, so the new release is what starts once they turn it back on, and
 answers `{"disabled": true, ...}` instead of the well-known document. `force_enable=True`
 is for an operator who asked for the service to be switched on. The service never
-implements these verbs itself — its CLI calls launchctl the same way.
+implements these verbs itself; its CLI calls launchctl the same way.
 
 **Uninstall is symmetric.** `launchd_uninstall` boots the job out and **waits** until
 launchd reports it gone (it raises, removing nothing, if the job is still loaded at the
 timeout), removes the plist, and resets the override to `enabled`. launchctl has no verb
 that deletes an override, and a leftover `disabled` would make a later fresh install stay
-off. Tests use a throwaway label or a fake `launchctl` first on `PATH` — never the
+off. Tests use a throwaway label or a fake `launchctl` first on `PATH`, never the
 operator's real jobs.
 
 ## One copy under a supervisor
@@ -118,7 +118,7 @@ Started by hand, a copy that finds `service.lock` held prints one sentence namin
 holder (or saying the holder is unknown, when its pid cannot be read) and exits 75 at once.
 Under launchd that exit is a respawn every `ThrottleInterval` (10 s), forever, and under
 systemd one every `RestartSec`. So a copy its supervisor started, and that says so with the
-**supervisor marker**, backs off in-process — 0.5 s doubling to 30 s, 300 s in all — takes over
+**supervisor marker**, backs off in-process (0.5 s doubling to 30 s, 300 s in all), takes over
 if the holder leaves, and exits 75 only when the wait runs out: a few starts an hour instead of
 360. It touches nothing while it waits. Two installs sharing one data directory are still the
 defect to remove; the back-off only stops the loop from costing the machine.
@@ -136,8 +136,8 @@ never infers supervision from its parent process.
   `supervised` (with the manager), `manual` or `conflict`. Only an empty variable counts as no
   marker; a bare `--fabric-supervisor` (followed by nothing, by `--` or by another `--…` flag,
   none of which it consumes) names no manager.
-- Markers that disagree — the variable and the argument with different values, the argument
-  twice, or a bare or empty argument beside the variable — exit 75 at once, before the lock and
+- Markers that disagree (the variable and the argument with different values, the argument
+  twice, or a bare or empty argument beside the variable) exit 75 at once, before the lock and
   whether or not it is held, naming both markers.
 - A service's own argument parser accepts the flag in both spellings and ignores it: in Python,
   `add_supervisor_argument(parser)` (argparse otherwise exits 2 on an unknown flag); the sample
@@ -152,8 +152,8 @@ never infers supervision from its parent process.
 `"lifecycle": {"manager": "person", "app": "<the installed bundle or executable>"}`, `installedBy {by: "person", role,
 tool}` and no `origin`: it says the app is installed, never that it runs. The installer writes it; where there is none
 (a macOS app dragged into Applications), the app writes it on a start when `app_descriptor_action` /
-`appDescriptorAction` answers `write` — no descriptor yet, another version in `installedBy.tool`, or another path than
-`lifecycle.app` — and never from an App Translocation path. Its live origin and process id go in its own liveness file,
+`appDescriptorAction` answers `write` (no descriptor yet, another version in `installedBy.tool`, or another path than
+`lifecycle.app`), and never from an App Translocation path. Its live origin and process id go in its own liveness file,
 rewritten on every start and removed on quit; a caller that sends anything reads that file and checks the process.
 `write_descriptor` claims no port for it, and a reader that finds `lifecycle.app` gone treats the descriptor as stale.
 
@@ -179,8 +179,8 @@ anything the operator would miss belongs in data.
 
 ## Logs
 
-One structured log (JSON lines) rotated by size — `RotatingLog(dirs["logs"] / "service.jsonl")`,
-5 × 5 MB by default, files 0600 in a 0700 directory — plus the launchd stdout file, which
+One structured log (JSON lines) rotated by size (`RotatingLog(dirs["logs"] / "service.jsonl")`,
+5 × 5 MB by default, files 0600 in a 0700 directory), plus the launchd stdout file, which
 `cap_stdout_log` copies to `.1` and truncates at start once it passes 5 MB (launchd holds it
 open for append, so it is truncated in place, never renamed). Configure logging once, in the
 entry point. Never log a token, a cookie, a login code or a request body that may carry one.
@@ -189,7 +189,7 @@ entry point. Never log a token, a cookie, a login code or a request body that ma
 
 On `SIGTERM`: stop accepting new work, append a `service.stopping` event, drain
 in-flight work, persist what was interrupted so the next start resumes it, release the
-lock, exit 0 — within 10 s with work in flight (LC-01). `Drain` does the timing:
+lock, exit 0, within 10 s with work in flight (LC-01). `Drain` does the timing:
 
 ```python
 drain = fs.Drain()                       # drain 8 s, hard exit 2 s later (EXIT_HARD_STOP, 70)
@@ -208,8 +208,8 @@ A host may run a lifecycle broker: one always-on per-user service that agents as
 stop and restart products, instead of launching or killing them themselves. A product it manages
 has to survive being driven from outside:
 
-- **Quit reaches exit through both doors.** A broker asks the platform's own quit first — on
-  macOS `NSRunningApplication.terminate()`, the path Cmd+Q and the Dock take — and `SIGTERM` a few
+- **Quit reaches exit through both doors.** A broker asks the platform's own quit first (on
+  macOS `NSRunningApplication.terminate()`, the path Cmd+Q and the Dock take) and `SIGTERM` a few
   seconds later. Handle both and exit inside the deadline (LC-01). A desktop app
   that answers `SIGTERM` by closing its window and staying alive is stopped late or not at all.
 - **A background launch stays in the background.** A broker opens the app non-activating
@@ -219,8 +219,8 @@ has to survive being driven from outside:
 - **Identity is the designated requirement.** A broker pins the app by team + bundle id, so an
   update signed by the same team keeps working and anything else is refused (LC-05). Never ship an
   ad-hoc or differently signed build to a machine that pins you.
-- **Starting is not ready.** Expose readiness the broker can probe without a person — the
-  well-known document for a service, a process-level answer for a plain app — and keep it honest
+- **Starting is not ready.** Expose readiness the broker can probe without a person (the
+  well-known document for a service, a process-level answer for a plain app) and keep it honest
   while the app is still starting.
 
 ## Linux and Windows
@@ -230,7 +230,7 @@ Both kits write and install the supervisor file the contract names (DEC-0032, se
 secret: the writers refuse a credential-shaped argument, environment name or value, and any
 control character (a line break would end a unit line early).
 
-**Linux — a systemd user unit.** `systemd_unit(unit, argv, working_directory=…)` /
+**Linux: a systemd user unit.** `systemd_unit(unit, argv, working_directory=…)` /
 `systemdUnit(unit, argv, {workingDirectory})` writes `Restart=always`, `RestartSec=10`,
 `TimeoutStopSec` above the drain (15 s default), `KillMode=mixed`, `WantedBy=default.target`
 and `FABRIC_SERVICE_SUPERVISOR=systemd` (always, whatever the caller passed), quoting every argument (`%` → `%%`, `$` → `$$`).
@@ -247,7 +247,7 @@ descriptor says `"lifecycle": {"manager": "systemd", "unit": "<id>.<instance>.se
 A user unit runs while the person is logged in; one that must run without a session needs
 `loginctl enable-linger <user>`, which is the operator's decision, not the installer's.
 
-**Windows — a per-user Scheduled Task.** `task_xml(task, argv, working_directory=…)` /
+**Windows: a per-user Scheduled Task.** `task_xml(task, argv, working_directory=…)` /
 `taskXml(task, argv, {workingDirectory})` writes a task with a logon trigger for the current
 user, `InteractiveToken` and `LeastPrivilege` (no administrator rights), restart on failure
 every minute, no execution time limit and `MultipleInstancesPolicy` `IgnoreNew`, its settings in the
@@ -269,16 +269,16 @@ starting a second copy. Measured (FAA-38, [report](https://github.com/passioncod
 that still exits 75 stays down until the next logon.
 
 **One copy on each system.** The Python kit takes `flock` (Linux) or a locked byte
-(Windows); the Node kit cannot, so it holds a name instead — an abstract unix socket on Linux,
+(Windows); the Node kit cannot, so it holds a name instead: an abstract unix socket on Linux,
 a named pipe on Windows (`lock_name` / `lockName`), each gone with the process. The Python kit
 holds the same name beside its file lock, so the two kits exclude each other everywhere, and
 `check_service.py` reports the lock held when either is. The probe only looks (`/proc/net/unix`,
 `WaitNamedPipeW`); it never takes the name, so it cannot make a service that is starting fail.
 
 **Token files on Windows.** The privacy of `service.token` is its ACL (service.md *Windows
-token files*): the kits write a protected list — the user, SYSTEM and Administrators, set before the
+token files*): the kits write a protected list: the user, SYSTEM and Administrators, set before the
 token's bytes go in, any entry already there dropped. On read, `windows_token_acl_problem` /
-`windowsTokenAclProblem` decide over what was read — the file's flags, its owner SID and each ACE
+`windowsTokenAclProblem` decide over what was read: the file's flags, its owner SID and each ACE
 as `{type, sid, mask}` (DEC-0057, `FAC-SEM-079`, held to the contract's
 `fixtures/vectors/windows-token.json`): a reparse point, a directory, a real path outside the
 profile, another owner, an allow ACE with a non-zero mask for any other SID, an ACE of another type

package/plugins/fabric-agent-adapter/skills/building-fabric-services/references/migrating-a-service.md

@@ -8,7 +8,7 @@ Order matters: each step leaves the service answering.
 2. **Add the well-known route and the build identity.** Read-only, no risk.
 3. **Add the events view** over the existing log, then the login-code routes. Keep the
    service's old login path until the operator has switched.
-4. **Move the lock to the top of startup** — before the startup hook that resumes jobs.
+4. **Move the lock to the top of startup**, before the startup hook that resumes jobs.
    Test: a second copy exits 75 and the first copy's running jobs are untouched.
 5. **Move state out of the code tree** if it lives there: copy to the OS data
    directory, switch the paths, keep the old tree read-only for one release, then