@passioncode-ai/fabric-agent-adapter 0.21.0 → 0.23.0

package/CHANGELOG.md

@@ -1,5 +1,117 @@
 # Changelog
 
+## 0.23.0 - 2026-10-13
+
+The contract pin moves from `b291bf0` (DEC-0055) to contract `main` `fe55fc6`, and both kits follow every rule in that
+range that touches what they already do (FAA-32; the contract's hand-over of 2026-10-12, its CT-18 row). `b291bf0`
+joins the supported revisions. What the range adds beyond that is its own row: FAA-33…37.
+
+### Changed
+
+- **The supervisor marker comes as an argument too** (DEC-0057, CT-01, P4-01): `supervisor_marker` /
+  `supervisorMarker` read `FABRIC_SERVICE_SUPERVISOR=<manager>` and `--fabric-supervisor <manager>` /
+  `--fabric-supervisor=<manager>` (after the executable, before `--`; a bare flag consumes no `--…` token), with `node`
+  among the managers. Markers that disagree — the two forms, the argument twice, a bare or empty argument beside the
+  variable — exit 75 at once, before the lock, naming both. `supervised()` and `supervised_by_launchd()` take the
+  marker; `hold_single_instance` / `holdSingleInstance` take `env` and `argv`. A holder whose pid cannot be read is
+  named unknown (`FAC-SEM-078`).
+- **Writers:** `task_xml` / `taskXml` write `--fabric-supervisor task-scheduler` in the task's `Arguments`, before any
+  `--` (a task's action carries no environment, so a Task Scheduler copy now waits like one under launchd);
+  `systemd_unit` / `systemdUnit` set the variable unconditionally; every writer refuses a marker in the program
+  arguments. `add_supervisor_argument(parser)` lets a service's argparse accept the flag; the sample service uses it.
+- **DL-HUBKEY** (DEC-0060): `hub_key_certified` / `hubKeyCertified(record, kid, x, at, applied, extra)` answer the
+  contract's verdict — `{certified, machine, revision}` or `{certified: false, fault, detail}` — instead of a boolean.
+  A revision outside its window, unreadable, lower than the applied one or forking it is the trust source's fault
+  (`issuer-unavailable`: `estate-outside-window`, `estate-unreadable`, `estate-rolled-back`, `estate-forked`); a `kid`
+  on two machines, a missing `x` and a numeric `kid` never certify; revocation refs compare exactly. The verifiers
+  take `estate_applied` / `estateApplied` and `estate_revocations` / `estateRevocations`; in the Node kit only an
+  absent `estate` skips the check (`null` is an unreadable source). Every verifier refuses a clock that is not a number
+  of seconds `unknown-state` `no-clock` before row 1.
+- **The estate record** (DEC-0063, DEC-0066): `verify_estate_record` / `verifyEstateRecord` admit `issuedAt` up to 60 s
+  ahead (`CLOCK_SKEW_SECONDS`); the signing passkey must be under a `sign.<domain>` RP (`wrong-rp`) and its origins
+  within it (`wrong-origin`); the record's rules add `FAC-SEM-092`.
+- **The Windows token-file reader** (DEC-0057, `FAC-SEM-079`): `windows_token_acl_problem` /
+  `windowsTokenAclProblem` decide over the file's flags, owner and ACEs `{type, sid, mask}`: an object or callback ACE
+  is refused, an allow with an empty mask and every deny grant nothing, SIDs compare case-insensitively, anything
+  unreadable is refused. The Python kit reads the ACEs from SDDL (`acl_from_sddl`), the Node kit through .NET's raw
+  descriptor with the mask read unsigned. `windows_acl` / `windowsAcl` now answer ACEs; `token_acl_problem` /
+  `tokenAclProblem` are replaced by `token_file_problem` / `tokenFileProblem`.
+- **The descriptor** (DEC-0057 item 5): `label` and `plist` are refused beside `systemd` and `task-scheduler`; a
+  `localPath` starting `//` or `/\` is a share and refused.
+
+### Evidence
+
+- Vendored from the contract at `fe55fc6` and re-answered by its own functions (`test/fixtures/contract/vendor_vectors.mjs`):
+  `hub-key-vectors.json` (51 cases, 14 verifier answers; the hub seeds dropped), `supervisor-vectors.json` (22 marker
+  cases, 11 `FAC-SEM-078` records), `windows-token-vectors.json` (30 cases), `descriptor-negatives.json` (DEC-0057's
+  seven); `estate-vectors.json` regenerated (49 verify cases). Both kits answer every case as the contract does.
+- The kits' own starts against a held lock — by hand, the node, a task, an unknown holder, three conflicts — are
+  recorded and read by a port of `lockOutcomeRules` that itself reads the contract's 11 records as it does.
+- The sample service, started with `--fabric-supervisor=node`, serves a well-known document, usage report and events
+  page valid under the `fe55fc6` schemas; the descriptors the kit writes under every manager are valid too.
+- 34 planted defects, all caught.
+- The `--fabric-supervisor` scenario eval (`supervised-by-argument`) was written before the prose.
+
+## 0.22.0 - 2026-10-12
+
+`working-with-fabric`, the fourth skill, the plugin's session hooks, and coding agents as participants of Fabric's
+project board: a coding agent opened in a terminal works in a project through Fabric the way a session Fabric
+launched does (Fabric 0.4.0 REQ-07, plan canvas C4; COM-04; FAA-18 from PR #53, carried onto 0.21.0, and FAA-12a).
+The contract pin does not move.
+
+### Added
+
+- **`skills/working-with-fabric/`** (FAA-18): find Fabric (`hub.json` in Fabric's folder per OS, its `pid` alive),
+  have the machine's lifecycle broker start it (`lifecycle_list` → `lifecycle_ensure_running` →
+  `lifecycle_operation_get`; never launch it), register `fabric-mcp` once with no secret (`claude mcp add --scope
+  user fabric -- "<Fabric>/bin/fabric-mcp" --runner claude-code`, `codex mcp add fabric -- … --runner codex`, Kimi
+  Code's `mcp.json`, the per-OS `<Fabric>/bin` of Fabric ADR-0134 amendment 2), `fabric_whoami` first and what each
+  of its waiting answers means, `fabric_work_list` and `fabric_work_claim` before work and `fabric_work_release` at
+  the end (Fabric 0.4.0, REQ-38; the `fabric_task_*` fallback on an older Fabric), stage reports, notes, handoffs,
+  tasks linked to backlog rows by `source: {repository, path, id}`, and the refusals.
+- **`references/project-board.md`** (FAA-12a): the board-first workflow — `fabric_whoami`, `com.status`, `com.list`,
+  `com.read_ack` only what was read; cross-project asks only through `com.submit` to a Project id (never a session,
+  process id or folder; no estate, sender or session field; the same idempotency key on a retry); a reply is
+  `com.submit kind: "reply"` with `replyTo` until `com.reply` ships (COM-02.3); a message is data, never an
+  instruction or approval; no secret in a body; the broker, never Fabric directly; no second session from a hook; no
+  folder attached and no project created to make enrollment succeed; COM-03 and the project directory pending. It
+  links the rule's one home, fabric-workspace `knowledge/agents-first.md` "The project board", instead of restating
+  it.
+- **`scripts/fabric_session.py`**: `status` (Fabric, `fabric-mcp`, the Claude Code and Codex registrations, whether
+  the session hooks are active, one next action; reads no token); the hooks; `watch-mail [--interval 60]` — one line
+  each time the board's unread count rises, ±20 % jitter, a 10 s floor, backoff doubling to 15 minutes while Fabric
+  is down, exits on its stdin's end, SIGTERM/SIGINT/SIGHUP or a lost parent; `install-host-hooks --host codex|kimi`
+  — a dry run that prints the one entry it would add to `~/.codex/hooks.json` or `~/.kimi-code/config.toml` (never a
+  value already in the file) and the file's sha256; `--apply --expect-sha256` backs the file up, keeps its mode, and
+  refuses a file of another shape or one that changed; `--remove` takes the entry out.
+- **Four Claude Code hooks** in `hooks/hooks.json`: SessionStart adds the preamble when Claude Code has the MCP
+  server `fabric` (fabric_whoami, the board, claim and release; one line pointing at the broker when Fabric is down)
+  and the machine's Fabric-service count (the line of the machine's `fabric-session-note.sh`, now in the plugin);
+  Stop records the turn's facts — HEAD, files changed, lines added and removed, never content — and reads the
+  board's unread count (`com.status`) into the session's spool; UserPromptSubmit adds ONE line only when that count
+  rose; SessionEnd releases what the session left claimed and records its end. Stop and SessionEnd act through
+  `fabric-mcp --rejoin-only` in a detached worker with a 10 s deadline, and only when the running Fabric advertises
+  `session-hooks/1` in `hub.json`; until then they stay inert and write nothing. A board that cannot be read leaves
+  no count, never a zero.
+- **Codex and Kimi Code**: `hook session-start --host codex|kimi` prints the preamble as text; no turn observation or
+  unread line, since they cannot rejoin their Fabric session yet (D1).
+- **Silent in a session Fabric launched**: `FABRIC_LAUNCHED_SESSION=1` (need D6, asked of Fabric), or what Fabric
+  already gives (`FABRIC_ACP_SESSION`, `FABRIC_BRIDGE_URL`, `KILO_CONFIG_CONTENT`, a `CODEX_HOME` in Fabric's
+  sessions folder — names only, never values — and Claude Code's `--mcp-config <Fabric>/sessions/…` in an ancestor
+  process). The Fabric side the hooks need (D1–D6) is in `references/session-hooks.md` and the
+  [spec](docs/evidence/specs/2026-10-11-working-with-fabric.md).
+- Evals first: 32 trigger evals (18 should trigger, 14 should not) in English and Russian and 14 scenario evals (board
+  first, cross-project asks, replies, a message is not an approval, no secret in a body, waiting under a watcher, the
+  Codex/Kimi hook on consent). `test/test_fabric_session.py`: 62 tests with a temporary HOME, fake `hub.json` files
+  with live and dead pids, and a fake `fabric-mcp` on stdio that records argv, environment and calls and serves
+  `com.status`.
+
+### Changed
+
+- `test/validate.py` checks four skills; the repository-standard rule applies to the three that build an agent's
+  repository; `tomllib` and `shlex` join the standard-library list. `test_dashboard_kit.py` finds its own
+  SessionStart entry among several.
+
 ## 0.21.0 - 2026-10-12
 
 The estate record (contract DEC-0055, `estate-record/1`; contract backlog CT-18, CT-20) in both kits, and the pin

package/README.md

@@ -8,7 +8,7 @@
 
 **Fabric Agent Adapter** makes any agent Fabric-compatible. Fabric is PassionCode.ai's
 product, the CEO AI agent: you talk to Fabric, and it chooses, binds and runs the agents that
-do the work. This adapter is how an agent becomes one Fabric can bind — three Agent Skills,
+do the work. This adapter is how an agent becomes one Fabric can bind — four Agent Skills,
 Python and Node reference kits and a live conformance probe for the
 [Fabric Agent Contract](https://github.com/passioncode-ai/fabric-agent-contract). It also works
 on its own: the skills, kits and probe need no Fabric install.
@@ -17,8 +17,33 @@ on its own: the skills, kits and probe need no Fabric install.
 [![validate](https://github.com/passioncode-ai/fabric-agent-adapter/actions/workflows/validate.yml/badge.svg)](https://github.com/passioncode-ai/fabric-agent-adapter/actions/workflows/validate.yml)
 [![license](https://img.shields.io/badge/license-AGPL--3.0%20or%20commercial-blue.svg)](LICENSE)
 
-The skills are `adapting-projects-to-fabric`, `creating-fabric-agents` and
-`building-fabric-services`.
+The skills are `adapting-projects-to-fabric`, `creating-fabric-agents`,
+`building-fabric-services` and `working-with-fabric`.
+
+`working-with-fabric` is for the other side: a coding agent (Claude Code, Codex, Kimi Code, Kilo, Hermes) opened in
+a terminal that works in a project through Fabric. It finds Fabric (`hub.json`, its `pid`), has the machine's
+lifecycle broker start it when it is down, registers `fabric-mcp` once with no secret, calls `fabric_whoami`
+first, reads the project board (`com.status`, `com.list`, `com.read_ack` only what was read) and asks other
+Projects only through `com.submit`, asks who is working on what and claims its task before it starts
+(`fabric_work_list`, `fabric_work_claim`, Fabric 0.4.0), links tasks to backlog rows instead of copying them, and
+releases at the end (`fabric_work_release`). `scripts/fabric_session.py status` prints where Fabric stands and one
+next action:
+
+```bash
+python3 plugins/fabric-agent-adapter/skills/working-with-fabric/scripts/fabric_session.py status
+```
+
+In Claude Code the plugin adds four session hooks: SessionStart puts that preamble into the session when the MCP
+server `fabric` is registered (one line pointing at the broker when Fabric is down), with the machine's
+Fabric-service count; Stop records each turn's facts (HEAD, files changed, lines added and removed — never content)
+and the board's unread count; UserPromptSubmit adds one line only when that count rose; SessionEnd releases what the
+session left claimed. Stop, UserPromptSubmit and SessionEnd act only when the running Fabric advertises
+`session-hooks/1`. All are silent in a session Fabric launched, never block the session, read no token and always
+exit 0. `fabric_session.py watch-mail` waits for board mail under a background watcher, and `install-host-hooks
+--host codex|kimi` adds the session-start preamble to Codex or Kimi Code (a dry run unless `--apply`). The
+[hooks reference](plugins/fabric-agent-adapter/skills/working-with-fabric/references/session-hooks.md) lists what
+they need from Fabric; the [board reference](plugins/fabric-agent-adapter/skills/working-with-fabric/references/project-board.md)
+is the board-first workflow.
 
 `building-fabric-services` makes an agent a long-lived local service with a dashboard
 that is always alive, runs as one copy, keeps its state through a reinstall and appears
@@ -40,12 +65,12 @@ box, sticky chrome at most 120 px — with seven WCAG AA themes (light and dark)
 `fabric_appearance` cookie. `scripts/dashboard_kit.py install|status` copies and checks it,
 `scripts/check_dashboard_layout.mjs` measures a rendered page in WebKit at 360, 480, 768 and 1280 px
 (Playwright; `NOT_RUN` without it), and the probe's `dashboard.declared` checks the declaration. The
-plugin's one hook (SessionStart) prints a single line in a repository whose dashboard has no kit or an
+plugin's dashboard-kit hook (SessionStart) prints a single line in a repository whose dashboard has no kit or an
 older one, and nothing anywhere else; the [kit reference](plugins/fabric-agent-adapter/skills/building-fabric-services/references/dashboard-kit.md)
 has the upgrade steps, taken only with the operator's go-ahead.
 
 Dashboard handoffs use the host-generated `open_link` as the primary action. The
-three skills carry the same [consumer procedure](plugins/fabric-agent-adapter/skills/building-fabric-services/references/dashboard-links.md)
+three builder skills carry the same [consumer procedure](plugins/fabric-agent-adapter/skills/building-fabric-services/references/dashboard-links.md)
 and a portable `scripts/check_dashboard_link.py` gate for generated renderers.
 It rejects primary HTTP when the host is available, failed-host browser fallback,
 and local links addressed to another device. A skill install alone does not filter
@@ -98,6 +123,7 @@ Generic Agent Skills clients:
 npx skills add passioncode-ai/fabric-agent-adapter --skill adapting-projects-to-fabric
 npx skills add passioncode-ai/fabric-agent-adapter --skill creating-fabric-agents
 npx skills add passioncode-ai/fabric-agent-adapter --skill building-fabric-services
+npx skills add passioncode-ai/fabric-agent-adapter --skill working-with-fabric
 ```
 
 ### Configure
@@ -178,6 +204,12 @@ Or, for an agent that does not exist yet:
 Create a new fabric-compatible agent for <capability>; its consumer is <who calls it>.
 ```
 
+Or, in a coding agent opened in a project folder:
+
+```text
+Work on backlog row FAA-18 through Fabric: check who is working here, claim it, and release it when done.
+```
+
 Or run the deterministic helper directly:
 
 ```bash
@@ -203,7 +235,7 @@ Scaffolding is non-destructive by default. It writes only the paths declared in
 The default pin for new bundles is [`fabric-contract.lock.json`](fabric-contract.lock.json):
 
 - version: `0.1.0`
-- commit: `b291bf09e0a9f9fd3c16cf540832cd021203b7d1`
+- commit: `fe55fc67cba1a9e34a736da7d148d4fe2a8fbfa0`
 
 Every other mention of the default contract revision — this section, the skills' metadata, the
 skill card, `adapt_project.py` — must equal it; `python3 test/validate.py` fails a tree

package/package.json

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

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

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

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

@@ -1,5 +1,5 @@
 {
-  "description": "One line at session start in a repository whose Fabric dashboard has no dashboard kit or an older one (fabric-dashboard/0.1, DEC-0036). Silent everywhere else; reads only, never writes, always exits 0.",
+  "description": "Two silent-unless-relevant hook sets. The dashboard-kit notice: one line at session start in a repository whose Fabric dashboard has no kit or an older one (fabric-dashboard/0.1, DEC-0036). The Fabric session hooks (working-with-fabric, COM-04, FAA-12a): at session start the preamble when Claude Code has the MCP server `fabric` (fabric_whoami, then the project board through com.status and com.list, claim and release), and the machine's Fabric-service count; each turn's facts (HEAD, files changed, lines added and removed, never content), the board's unread count and the session's end through Fabric, only when the running Fabric advertises session-hooks/1; at each prompt one line only when the unread count rose. All silent in a session Fabric launched. Every hook reads no token, prints at most one block, always exits 0, and hands any Fabric call to a detached worker with a 10 s deadline.",
   "hooks": {
     "SessionStart": [
       {
@@ -11,6 +11,48 @@
             "timeout": 5
           }
         ]
+      },
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 -S \"${CLAUDE_PLUGIN_ROOT}/skills/working-with-fabric/scripts/fabric_session.py\" hook session-start",
+            "timeout": 5
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 -S \"${CLAUDE_PLUGIN_ROOT}/skills/working-with-fabric/scripts/fabric_session.py\" hook stop",
+            "timeout": 5
+          }
+        ]
+      }
+    ],
+    "SessionEnd": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 -S \"${CLAUDE_PLUGIN_ROOT}/skills/working-with-fabric/scripts/fabric_session.py\" hook session-end",
+            "timeout": 5
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 -S \"${CLAUDE_PLUGIN_ROOT}/skills/working-with-fabric/scripts/fabric_session.py\" hook user-prompt-submit",
+            "timeout": 5
+          }
+        ]
       }
     ]
   }

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

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

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

@@ -21,10 +21,10 @@ import fabric_secrets as _secrets  # noqa: E402 - the contract's credential dete
 
 CONTRACT_VERSION = "0.1.0"
 CONTRACT_REPOSITORY = "https://github.com/passioncode-ai/fabric-agent-contract"
-CONTRACT_COMMIT = "b291bf09e0a9f9fd3c16cf540832cd021203b7d1"
+CONTRACT_COMMIT = "fe55fc67cba1a9e34a736da7d148d4fe2a8fbfa0"
 # #region supported-contract-revisions — docs: README.md#contract-pin
 # Only this declaration may name a legacy revision in live files.
-SUPPORTED_CONTRACT_COMMITS = (CONTRACT_COMMIT, "0cacd08b0e95b6abf131eae1206b60792138bc3c", "2eb91c00e852d9c31d804310d38fad91589fcbac", "8e49fbd5fbbf230e32c1969cd24ac3c22422f0a5", "a83bec6b47776af688402c18efec507143061f68", "52da526d7cc1e063d74c5b520dbc03d0ace15246", "78b2da018d2c4bd9ac1bde1dc3b7f1a110a175f5", "623bf61358c339cb10297807b3f024b5d9f1f327", "23f9fda4c05f8a3852246ee98d4f2adf74ed0875", "9091d3d6606b0c4b5591a38c3674356a01fd7f55", "df55c8c54a23251342a7ee57ba95642b7eb39e61", "2ce392291c6668598d12cd38327e24696b5ca15c")
+SUPPORTED_CONTRACT_COMMITS = (CONTRACT_COMMIT, "b291bf09e0a9f9fd3c16cf540832cd021203b7d1", "0cacd08b0e95b6abf131eae1206b60792138bc3c", "2eb91c00e852d9c31d804310d38fad91589fcbac", "8e49fbd5fbbf230e32c1969cd24ac3c22422f0a5", "a83bec6b47776af688402c18efec507143061f68", "52da526d7cc1e063d74c5b520dbc03d0ace15246", "78b2da018d2c4bd9ac1bde1dc3b7f1a110a175f5", "623bf61358c339cb10297807b3f024b5d9f1f327", "23f9fda4c05f8a3852246ee98d4f2adf74ed0875", "9091d3d6606b0c4b5591a38c3674356a01fd7f55", "df55c8c54a23251342a7ee57ba95642b7eb39e61", "2ce392291c6668598d12cd38327e24696b5ca15c")
 # #endregion supported-contract-revisions
 INTEROP_KEY = "https://fabric.passioncode.ai/agent-contract/extensions/interop/0.1"
 MCP_REVISION = "2026-07-28"

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

@@ -16,10 +16,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.21.0"
+  version: "0.23.0"
   contract-version: "0.1.0"
   extension: "fabric-service/0.1"
-  extension-commit: "b291bf09e0a9f9fd3c16cf540832cd021203b7d1"
+  extension-commit: "fe55fc67cba1a9e34a736da7d148d4fe2a8fbfa0"
 ---
 
 # Building Fabric services

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

@@ -95,16 +95,19 @@ itself (`isSmallOrderKey`), because Node before 26 lets OpenSSL accept a signatu
 
 ## Keys the estate record certifies
 
-A verifier that also reads the estate's record (DEC-0055, [the estate record reference](estate-record.md)) trusts a
-`kid` only while a current revision certifies it for a machine and does not revoke it (DL-14). Pass the current
-verified revision as `estate=` / `{ estate }`, as a value or as a function returning it, to `delegation_gate`,
+A verifier that also reads the estate's record (DEC-0055, DEC-0060, [the estate record reference](estate-record.md))
+trusts a `kid` only while the revision it reads certifies it (DL-14, row 4a, right after the signature). Pass the
+current verified revision as `estate=` / `{ estate }`, as a value or as a function returning it, with
+`estate_applied` / `estateApplied` and `estate_revocations` / `estateRevocations`, to `delegation_gate`,
 `verify_delegation` or `verify_approval`.
-- An uncertified `kid` is refused `unauthenticated` (`approval-invalid` for an approval), with detail
+- An uncertified `kid` is the token's fault: `unauthenticated` (`approval-invalid` for an approval), detail
   `kid-not-certified`.
-- An unreadable record is refused `issuer-unavailable`, with detail `estate-unreadable`.
+- A revision that cannot be read, is outside its window, is lower than the applied one or forks it is the trust
+  source's fault: `issuer-unavailable`, detail `estate-unreadable`, `estate-outside-window`, `estate-rolled-back` or
+  `estate-forked`.
 - Without `estate`, nothing changes.
-- Pass only a revision `verify_estate_record` accepted, and the highest one the machine has applied. The rule trusts
-  what it is given, so an unverified or older revision would certify a key the current one revoked.
+- Every verifier refuses a clock that is not a number of seconds `unknown-state` `no-clock` before row 1: a NaN clock
+  would make every time row false and pass an expired token.
 
 ## What the kit does not do
 

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

@@ -43,12 +43,16 @@ It checks, in the order of the ER table:
    parent, and no revocation dropped.
 5. **The signer.** The signing passkey must be among the trusted ones and not revoked by the parent. A revision may
    revoke its own signer: that is rotation.
-6. **The assertion.**
+6. **The assertion.** The passkey is a signing credential (DEC-0063): an RP ID that is not a dedicated signing RP,
+   `sign.<domain>` in lower case, is `wrong-rp` before the assertion is read, and an origin outside the RP ID is not
+   pinned, so a ceremony that ran there is `wrong-origin`.
    - Client data: type, challenge, origin, no cross-origin use.
    - The RP ID hash, and the user-presence and user-verification flags.
    - The signature: ES256 or EdDSA, under a key validated first (a valid P-256 point; an Ed25519 key of full order).
-7. **The window.** At most 30 days.
-8. **The record's own rules.** A violation is `rule-violation` with its `codes`.
+7. **The window.** At most 30 days. A revision may be issued up to 60 s ahead of the verifier's clock (DEC-0066,
+   `CLOCK_SKEW_SECONDS`); earlier than that it is `not-yet-valid`.
+8. **The record's own rules.** A violation is `rule-violation` with its `codes`, `FAC-SEM-072…076` and `FAC-SEM-092`
+   (each passkey the record lists is a signing credential, its origins within its RP ID).
 
 Dates are strict RFC 3339: a `T`, an offset, and a day that exists. `:60` and a space are refused. Passkey JWK `x`
 and `y` must be canonical base64url. The Python kit verifies ES256 in pure Python (P-256, strict DER), and the Node
@@ -56,22 +60,35 @@ kit through `node:crypto`.
 
 ## Trusting a delegation key
 
-A delegation verifier that reads the estate record trusts a token's `kid` only while a current revision certifies it
-for a machine and does not revoke it (DL-14, contract CT-20). Give the gate the current verified revision, or a
-function that returns it:
+A delegation verifier that reads the estate record trusts a token's `kid` only while the revision it reads certifies
+it (DL-14, contract DEC-0060): exactly one machine's `hubKey` has that `kid` and the published key's `x`, the clock is
+inside the revision's window (from 60 s before `issuedAt`, DEC-0066, to `validUntil`), and neither the revision nor the
+revocation delta's entries applied since it revoke `hub-key <kid>` or `machine <id>`. It is checked right after the
+signature (DL-13 row 4a). Give the gate the current verified revision, or a function that returns it, the highest
+revision the machine applied, and the delta's revocations:
 
 ```python
-gate = fd.delegation_gate(audience=..., jwks=keys, issuer=..., effects=..., estate=lambda: current)
+gate = fd.delegation_gate(audience=..., jwks=keys, issuer=..., effects=..., estate=lambda: current,
+                          estate_applied={"revision": applied_number, "digest": applied_digest},
+                          estate_revocations=lambda: delta_entries)
 ```
 
-- A `kid` the record does not certify is refused like an unknown key: `unauthenticated` (for an approval,
-  `approval-invalid`) with detail `kid-not-certified`. The same holds when the record names another key under that
-  kid, revokes it, or is outside its window.
-- A record that cannot be read certifies nothing: `issuer-unavailable` with detail `estate-unreadable`.
-- **What you pass in.** Pass only a revision that `verify_estate_record` accepted, and the highest revision the
-  machine has applied. The rule trusts the record it is given. A record nobody verified, or an older revision still
-  inside its window, would certify a key the current revision revoked (a rollback).
-- `hub_key_certified(record, kid, x, at)` / `hubKeyCertified(...)` answers the question on its own.
+- **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`
+  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.
+- **What you pass in.** Pass only a revision that `verify_estate_record` accepted and whose number is not lower than
+  the highest the machine applied; a higher one only when you verified its chain from the applied revision.
+- `hub_key_certified(record, kid, x, at, applied, extra_revocations)` /
+  `hubKeyCertified(record, kid, x, at, applied, {extraRevocations})` answers the question on its own:
+  `{certified: true, machine, revision}` or `{certified: false, fault, detail}`. Both kits are held to the contract's
+  `fixtures/vectors/hub-key.json` (`test/fixtures/contract/hub-key-vectors.json`).
 
 ## Checking a record you produce
 

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

@@ -73,12 +73,36 @@ operator's real jobs.
 ## One copy under a supervisor
 
 Started by hand, a copy that finds `service.lock` held prints one sentence naming the
-holder 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 whose plist or unit
-carries `FABRIC_SERVICE_SUPERVISOR=launchd` (or `systemd`) 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.
+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
+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.
+
+The marker (contract DEC-0057, CT-01) is the variable `FABRIC_SERVICE_SUPERVISOR=<manager>` or
+the argument `--fabric-supervisor <manager>` (also `--fabric-supervisor=<manager>`), after the
+executable and before any `--`; `<manager>` is `launchd`, `systemd`, `task-scheduler` or `node`
+(Project Observatory's node, which supervises the services it starts). The writer of the
+supervisor file writes it: `launchd_plist` and `systemd_unit` / `systemdUnit` set the variable,
+always; `task_xml` / `taskXml` put the argument in the task's `Arguments`, because a task's action
+carries no environment. Each writer refuses a marker already in the program arguments. A copy
+never infers supervision from its parent process.
+
+- `supervisor_marker(env, argv)` / `supervisorMarker({env, argv})` reads both forms and answers
+  `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
+  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
+  service adds it to the parser and to each command.
+- The kits are held to the contract's `fixtures/vectors/service-supervisor.json`, and their
+  starts against a held lock are recorded and read as `FAC-SEM-078` reads them
+  (`test/*supervisors*`).
 
 ## Directories
 
@@ -151,7 +175,7 @@ control character (a line break would end a unit line early).
 **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`, quoting every argument (`%` → `%%`, `$` → `$$`).
+and `FABRIC_SERVICE_SUPERVISOR=systemd` (always, whatever the caller passed), quoting every argument (`%` → `%%`, `$` → `$$`).
 `WorkingDirectory=` is written unquoted: systemd reads it as the rest of the line, so quotes would
 become part of the path and the unit would be refused (`systemd-analyze verify` checks it in CI). The
 descriptor says `"lifecycle": {"manager": "systemd", "unit": "<id>.<instance>.service"}`.
@@ -179,9 +203,10 @@ CI job has the real `schtasks` create, read back and delete such a task. The des
 | stop, keep off | `schtasks /End /TN <task>`, then `schtasks /Change /TN <task> /DISABLE` |
 | uninstall | `task_uninstall` / `taskUninstall`: `/End`, then `/Delete /F` |
 
-A task cannot set an environment variable, so a copy Task Scheduler restarts does not back off
-in-process; `IgnoreNew` keeps the scheduler from starting a second copy, and a hand-started copy
-holding the lock makes the scheduled one exit 75 once a minute until it leaves.
+A task cannot set an environment variable, so `task_xml` / `taskXml` write the marker as an
+argument, `--fabric-supervisor task-scheduler`, before any `--`: a copy the Task Scheduler starts
+backs off in-process like one under launchd or systemd. `IgnoreNew` keeps the scheduler from
+starting a second copy.
 
 **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,
@@ -192,7 +217,14 @@ holds the same name beside its file lock, so the two kits exclude each other eve
 
 **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's bytes go in, any entry already there dropped — and refuse
-on read a link, a file outside the profile, another owner, or any other granted SID, naming the
-SID. The Node kit reads the list with Windows PowerShell 5.1 (.NET, no modules) and writes it
-with `icacls`; the path goes through the environment, never a command line.
+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
+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
+than allow or deny (an object or callback ACE), or anything unreadable is refused, naming the SID;
+deny ACEs and an allow with an empty mask grant nothing; SIDs compare case-insensitively. The Python
+kit reads the ACEs from the file's SDDL (`acl_from_sddl`); the Node kit reads them with Windows
+PowerShell 5.1 (.NET's raw descriptor, no modules), converting .NET's signed mask to the unsigned
+one, and writes the list with `icacls`; the path goes through the environment, never a command line.
+An inherit-only ACE applies to children, not to the file, and is not read.

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

@@ -1,11 +1,13 @@
 # fabric-service/0.1 — wire reference
 
-Pinned to `fabric-agent-contract` commit `b291bf09e0a9f9fd3c16cf540832cd021203b7d1`
+Pinned to `fabric-agent-contract` commit `fe55fc67cba1a9e34a736da7d148d4fe2a8fbfa0`
 (`docs/specification/service.md`, DEC-0015; the usage report DEC-0021; Windows and Linux supervision
 DEC-0032 and DEC-0033; the operator channel DEC-0034 and DEC-0035; the embedded dashboard DEC-0036;
 delegation and the operator session's lifetime DEC-0039; the meter's call window DEC-0041; session handoff DEC-0042;
 canonical forms DEC-0043; `degraded[].setup` and `run.mcp.stdio.scope` DEC-0044; delegation sealed and trust tiers
-DEC-0045; runner and model profiles DEC-0046). The contract's schemas are normative;
+DEC-0045; runner and model profiles DEC-0046; the estate record DEC-0055; one copy under any supervisor and its marker,
+the Windows token-file reader DEC-0057; the hub key the estate certifies DEC-0060; signing credentials DEC-0063; the
+estate record's 60 s skew DEC-0066). The contract's schemas are normative;
 this page is the working summary. Extension key:
 `https://fabric.passioncode.ai/agent-contract/extensions/service/0.1`.
 

package/plugins/fabric-agent-adapter/skills/building-fabric-services/scripts/check_service.py

@@ -172,8 +172,11 @@ class Probe:
         self.add("descriptor.valid", "FAIL" if problems else "PASS", "; ".join(problems) or str(self.path))
         if fs.WINDOWS:
             # DEC-0032: on Windows the file's ACL is its privacy.
-            owner, granting = fs.windows_acl(self.path)
-            problem = fs.token_acl_problem(self.path, owner, granting, fs.windows_user_sid())
+            owner, aces = fs.windows_acl(self.path)
+            info = os.lstat(self.path)
+            problem = fs.windows_token_acl_problem({"isRegularFile": stat.S_ISREG(info.st_mode), "isReparsePoint": stat.S_ISLNK(info.st_mode),
+                                                    "realPathInProfile": True, "ownerSid": owner, "aces": aces}, fs.windows_user_sid())
+            problem = problem and problem["message"]
             self.add("descriptor.private", "FAIL" if problem else "PASS", problem or "owner-only ACL")
         else:
             mode = stat.S_IMODE(os.stat(self.path).st_mode)