@passioncode-ai/passioncode 0.2.45 → 0.2.47

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

@@ -42,7 +42,9 @@ operator gives in Fabric (Agents & access): callee `fabric`, capability `board.r
 
 The responder runs inside the service process, started after the instance lock like every other piece of state
 (SKILL.md, Step 3). [`sample_service.py`](../scripts/sample_service.py) does it behind `serve --board-project <uuid>`,
-off by default:
+off by default (register it with the same `--board-project`, so its manifest lists the take-back tool below; a serve
+whose board mode differs from the registered manifest at its start logs `service.manifest.mismatch` and leaves the
+manifest as it is):
 
 ```python
 import fabric_board as fbd, fabric_hub as fhb
@@ -53,12 +55,13 @@ responder = fbd.Responder(
     handler=render, admit=gate, observe=look_on_disk, emit=log.append, service="example-agent")
 board = threading.Thread(target=responder.run, args=(stop_event, 5.0), daemon=True)  # SIGTERM: set stop_event
 board.start()
-# ... at stop, after stop_event is set: wait for it to leave its board session (a clean leave forgets its slot
-# records, FAA-155), bounded inside the kit's hard exit, as scripts/sample_service.py does
+# ... at stop, after stop_event is set: wait for it to leave its board session (a clean leave forgets the slot
+# records it confirmed, FAA-155), bounded inside the kit's hard exit, as scripts/sample_service.py does
 board.join(timeout)
 ```
 
-Node: `new Responder({...same names in camelCase})`, then `responder.run({ signal, drain })`. A service that lists
+Node: `new Responder({...same names in camelCase})`, then `const running = responder.run({ signal, drain })`; at stop,
+abort the signal and `await running`, bounded inside the hard exit (the run leaves its board session before it settles). A service that lists
 `fabric-project-comms/0.1` in its well-known `protocols` (DEC-0067: only once its hosts are pinned at or after it)
 declares that it answers board requests; the probe checks that declaration.
 
@@ -144,6 +147,28 @@ answers `not_available` or `capacity_exceeded`, which do not say whether the rep
 in line and the next tick asks again, and a restart asks with the same old fence. A request leaves the resume queue only
 once it has resumed: when the `com.complete` that sends a known outcome loses its answer, the next tick sends the same
 key again in the same session (FAA-86). `shutdown()` drains, then leaves the session (its DELETE releases the slot).
+An idle responder waits 3 s at most for that DELETE (`IDLE_LEAVE_SECONDS`), so an idle stop ends within the org's 5 s
+(LC-01, FAA-173); one with work waits up to the session's 15 s client timeout. A board call already in flight when the
+stop comes (a poll against a slow hub) runs first; when the service's bounded join ends before the DELETE is sent, the
+slot lapses on the board's clock as before. The slot records are forgotten only after
+a DELETE Fabric answered with a 2xx (a 404, the session already gone, keeps them: a move made before it ended is read at the next `com.status`), also when a session is dropped on a live board (FAA-163): an unanswered one keeps
+them, and the slot lapses in 60 s.
+
+**One capability at a time (FAA-163).** At connect (and every reconnect) the responder starts with no slot. Each
+capability's enroll or replace is settled on its own: a refusal of that capability (`capacity_exceeded`,
+`invalid_arguments`, any code that is not about the board session) leaves it `retry`, asked again alone after 15 s,
+30 s, doubling to 15 minutes, with one `board.slot.refused` event (warning; said again if it is refused again after
+the slot was held); its accepted work waits `lapsed` and goes back
+by a transfer once the slot is held. The capabilities after it are recovered as before. A refusal of the board session
+(`unreachable`, `session-ended`, `not_available`, `not_authorized` and the other codes in `SESSION_CODES`) leaves the
+rest `retry` too, says no `board.slot.refused`, and goes to the responder's fault, which says it by code:
+`board.access.needed` for `not_authorized`, `authority_changed` and `credential` (the session is left),
+`board.blocked` for a defect (`no-epoch`, `schema-unsupported`, `checkpoint`, `receipt-shape`,
+`idempotency_conflict`), and `board.down` for the rest: `unreachable` keeps the session while a held slot's lease runs
+(so a lost enroll of one capability is asked again at its next retry), `not_available` keeps it except at connect or recovery with no slot held,
+and `session-ended`, `not-running` and the other hub codes drop it (as a fault during connect or recovery does) and
+reconnect. A slot whose lease lapsed (`lease_expired`) holds
+no lease for that decision.
 
 ## When the operator holds work (DEC-0079)
 
@@ -178,9 +203,16 @@ held and not transferred). The responder keeps that move instead of undoing it:
   {project, generation, moved?, asking?}}`). The record is written when a receipt's generation changes and before an
   enroll or a replace that can change it; a live holder's renew (about every 20 s) cannot, and writes nothing. At a
   clean leave (the service stopped; the session's DELETE released its slots) the record of a slot with no request left
-  in the checkpoint and not moved is forgotten (a moved slot's record stays, so a clean stop never undoes a move): the slot is free, and whoever takes it next is no move. A file without the record
-  reads as before; a kit before 0.53.0 reads the file, ignores the record and drops it at its first checkpoint write. So a service stopped cleanly with no request left in its checkpoint, rolled back to 0.52 and up again starts as on a first
-  start. After a crash the record stays: if 0.52 then ran, enrolled the slot and
+  in the checkpoint and not moved is forgotten when this session confirmed its generation (held it, paused under the
+  operator's hold included, or read it unmoved in `com.status`) and no fenced call has put in doubt since: the slot is
+  free, and whoever takes it next is no move. An unconfirmed record stays, since the slot may have moved while the
+  service was down, and a move this session saw keeps its record, so a clean stop never undoes it. A paused or
+  retrying slot reads `com.status` before each new ask. A move made after the slot's last renew or check and before
+  the stop, with no call since, is not seen at the leave: its record is forgotten, and the next start reads the slot
+  as free and may enroll it once the other holder lets it go (FAA-187). A file without the record
+  reads as before; a kit before 0.53.0 reads the file, ignores the record and drops it at its first checkpoint write. So a service stopped cleanly with no request left in its checkpoint, its DELETE answered 2xx and every slot confirmed
+  in that session, rolled back to 0.52 and up again starts as on a first start. Otherwise (a 404, the idle wait running
+  out, a slot this session never confirmed, one left retrying before `com.status` answered for it included) its records stay, and the case is the crash case below. After a crash the record stays: if 0.52 then ran, enrolled the slot and
   wrote nothing to the checkpoint, the next 0.53 start reads that enroll as a move; bring it back with the service's take-back action (below).
 - An enroll or a replace is written into that record with its key before it is sent (`asking`). When its answer is
   lost, the next connect (or the next enroll) sends the same call again under the same key; the board answers the
@@ -205,8 +237,8 @@ held and not transferred). The responder keeps that move instead of undoing it:
   holder, or the estate owner, reconciles it now). No `com.claim`, `com.renew`, `com.complete`, `com.enroll` or
   `com.responder_replace` is sent for that capability again: not at recovery after a restart, and not when the new
   holder's lease lapses, nor when com.status later names no generation for the slot (a recorded move stays until
-  take-back). Accepted requests stay held on the board, unanswered, until the slot is taken back (CT-175
-  will hand them to the new holder). One `board.slot.moved` event (warn, notify) says so, once, also across restarts
+  take-back). Accepted requests stay `accepted` on the board, unanswered, until the slot is taken back (CT-175
+  will hand them to the new holder). One `board.slot.moved` event (warning, notify) says so, once, also across restarts
   (the record keeps `moved`).
 - A responder that never held the slot (a first start: no record, or a record of another Project), or whose record
   equals the current generation, behaves as before: it enrolls, recovers and replaces its own lapsed work. A recorded or
@@ -216,18 +248,28 @@ held and not transferred). The responder keeps that move instead of undoing it:
   records its own generation. Only a replay the board refuses, or one that ran for the first time (`repeated: false`)
   after the slot had moved past the record, reads as a move: the safe side; a slot such a replay took is left to lapse
   unused. A generation written `2.0` is `2`.
-- Only the operator brings the slot back: `take_back(capability)` (`takeBack`) forgets the record; never edit the
+- Only the operator brings the slot back: `take_back(capability)` (`takeBack`) forgets the record, and wins over a move
+  being read at the same time: the move is written under the responder's lock (Node: on the fence queue, after any fenced
+  call in flight) and only while the record is unchanged (FAA-158). Never edit the
   checkpoint's `slots` record by hand to undo a move. In the same board
   session the next tick enrolls once the other session lets the slot go (a live holder is waited for) and takes the work
-  left `lapsed` back with a transfer. A restart or reconnect before that, with accepted work held for the slot, takes it
+  left `lapsed` back with a transfer. A restart or reconnect before that, with accepted work waiting for the slot, takes it
   back at once by `com.responder_replace`, as a restart did before 0.53.0: the operator asked for the slot back, so the
   other session is replaced. In recovery, a refusal that leaves no slot held reconnects; one that leaves some held keeps
-  the session and serves them. The kit gives it no route of its own (the reference service has none yet,
-  FAA-157): a service built on the kit declares it as an operator action, a button with its tool ([Every button has a
-  tool](../SKILL.md), `fabric-actions/0.1`) with gate `relayed` (the operator's decision), never `none`, so no other
-  agent can call it on its own; on a server that reads mandates (`agent_id`) it also names its effect class, for example
-  `change-policy` (DEC-0125); until Fabric's hub forwards decisions (CT-125) the operator reaches it through the
-  service's page or its elicitation, and names it in its docs; otherwise a moved slot stays moved. A move back to this service's own session is not
+  the session and serves them. The kit gives it no route of its own. The reference service (`sample_service.py`) offers
+  it on its dashboard (FAA-157): a moved slot shows a Take back button that posts `POST /api/board/take-back` from the
+  operator's signed-in session with the `X-Fabric-Request` header; the service token alone is refused. Since 0.56.0 the
+  button has its tool, `board.take-back` with `{capability}`, declared under `extensions/actions/0.1` with gate
+  `relayed` and target `capability`, and a capability of the manifest like every tool the well-known lists
+  (`interop.well-known-capabilities`): an agent whose MCP client sets `_meta` calls it over `/mcp` with the operator's
+  decision in `_meta.decision` (a call without one is `operator-decision-required`); Claude Code and Codex send
+  arguments only, so until CT-125 they hand the operator the page as Fabric Dashboards' `open_link`. Either door records
+  the take-back as a `board.slot.returned` event (info, the capability as its subject) whose sentence says the route in
+  words and whose `data` holds `by`, `via` and the `caller` (none when the feed refuses the caller), never the decision's words; a repeat after a lost answer is answered `{capability, moved: false}`. A service built on the kit declares it as an operator action, a button with its tool ([Every button has a
+  tool](../SKILL.md), `fabric-actions/0.1`) with gate `relayed` (the operator's decision), never `none`, so a call
+  without the operator's relayed decision is refused; on a server that reads mandates (`agent_id`) it also names its effect class, for example
+  `change-policy` (DEC-0125); the operator reaches it through an agent that relays their decision in `_meta`, the
+  service's page or its elicitation (Claude Code and Codex, which cannot set `_meta`, wait for CT-125's forwarding), and the service names it in its docs; otherwise a moved slot stays moved. A move back to this service's own session is not
   detected yet: the receiving side and the hand-over of accepted requests (contract CT-175) wait for Fabric's session
   surface.
 
@@ -251,11 +293,19 @@ raises `directory-invalid` rather than answering; an unlisted Project may still
 
 ## 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=…, subject=…, data=…)` (`JsonlEventLog.append` fits: every level is one
+of its `info`, `notice`, `warning`, `error`; `subject` is `{type, id}`, the notice's request, else its capability, else
+its episode (such as a block's cause), else the Project; in Python it goes only to an `emit` whose signature names a `subject`
+parameter with no value bound, as `JsonlEventLog.append` does, and any other `emit`, one with only `**kwargs`, one with
+a subject bound by `functools.partial` (which then stands) or one whose signature cannot be read, is called once, without
+one, as before 0.56.0; the Node responder always passes it in its options, which an `emit` that does not read it ignores) 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.slot.moved`, `board.access.needed`, `board.blocked`,
-`board.down`, each notifying episode said once.
+`board.reconcile.needed`, `board.slot.contested`, `board.slot.moved`, `board.slot.refused`, `board.access.needed`, `board.blocked`,
+`board.down`, each notifying episode said once, and `board.outcome.invalid` (warning) when a handler's outcome fails
+its checks and is not sent. The operator's hold (below) adds `board.held`, `board.slot.held`,
+`board.slot.released` and `board.request.waiting`. The reference service adds `board.slot.returned` at a take-back.
 
 `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

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

@@ -45,7 +45,12 @@ const answer = await request('GET', 'https://api.example/v1/items', { headers, d
 
 Every answer comes back as a `Response`, whatever its status; `HttpError` means no usable answer came, with `kind`
 `connection`, `timeout`, `too-large` or `refused`, the status when there was one, and the URL redacted to scheme,
-host, port and path (`redact_url`). An error never carries a request header or body.
+host, port and path (`redact_url`); a URL that is not http or https keeps only its scheme (`htps:<redacted>`), and
+one that does not parse as a URL is `<unparseable url>`. The path is not redacted (Node writes it as `new URL`
+normalises it, Python as given), so a key never belongs in it. Python's `check_url` refuses a host
+with a backslash, space, control character (C0, DEL or C1) or `%`, a URL with a space or ASCII control character before its
+first `#` (the default transport sends a URL up to there, as Node's does; a transport you pass receives the URL as given), or a character outside ASCII in its path or query (ASCII whitespace at its ends is trimmed, as urllib and `new URL` trim it; a Unicode space ending the part before the first `#` is refused, where Node keeps it percent-encoded), a bracketed host that is not an IPv6 address with no zone, and a port that is not
+ASCII digits, all as kind `refused` before sending; it checks a host's shape, not its name. `redact_url` on Python reads a host holding `%` as `<unparseable url>`; Node writes it decoded. An error never carries a request header or body.
 
 ## fabric_openrouter
 
@@ -77,6 +82,7 @@ const answer = await client.chat(messages, { model, fallback, maxTokens: 800 });
 | The fallback | required, of another vendor (the part before `/` differs) |
 | Content | text only: a string, null, or parts that are all `{"type": "text"}`; an image, audio or file part is refused (`config`), because what it is billed cannot be bounded from its bytes |
 | What the ceiling does not cover | the `provider` routing param can send a call to a provider priced above the catalog; two `Client` objects sharing one ledger each hold only their own calls in flight, so give an agent one client per key |
+| The base URL | `base_url` (`baseUrl`), by default `https://openrouter.ai/api/v1`: checked by `check_url` when the client is built; ASCII whitespace and trailing `/` at its ends are trimmed (Node also trims every C0 control at the ends and removes a tab or line break anywhere, as `new URL` reads them); a base that is not a string is refused as `check_url` refuses it (`HttpError` kind `refused`, both twins); a query or a fragment is refused (kind `config`, both twins, before `check_url`). Python also refuses a space, a control or a non-ASCII character in the path (`check_url`'s `HttpError` kind `refused`); Node sends it percent-encoded, as `new URL` writes it (FAA-187 (18)) |
 | Attribution | off unless an `attribution` setting is given (FAC-SEM-098, `fabric_usage.attribution_headers`) |
 | Request body | `model`, `messages`, `max_tokens`, `usage: {include: true}` and your params (temperature, reasoning, response_format, tools); `stream`, `model`, `messages`, `max_tokens` and `usage` as params are refused |
 

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

@@ -124,6 +124,15 @@ page as Fabric Dashboards' `open_link`; both kits carry the same sentence. The g
 `JwksCache` holds the estate's key set at most 10 minutes and, on a `kid` it does not hold, re-reads at most once
 a minute (DL-15), and waits 10 s after a failed read before trying again; after 10 minutes without a successful read it answers nothing, and the verifier says
 `issuer-unavailable`. It reads https, http on loopback only, or a file; a URL with credentials is refused. The
+Python kit also refuses, https included, a URL holding a space or ASCII control character before its first `#` (it
+reads the URL up to there, as Node does), or a character outside ASCII in its path or query (urllib would send it
+and every read fail; a trailing ASCII space or line break is trimmed as urllib reads it; a Unicode space ending the
+part before the first `#` is refused, as `check_url` refuses it, because Node keeps it percent-encoded (urllib would
+trim it and read the keys when it ends the URL); a leading space is refused as not a URL), a host holding `%`, a backslash, a Unicode space or a control character (urllib
+would decode or dial it as another host), a bracketed host that is no IPv6 address, a port that is not ASCII digits or is above
+65535, no host, and an empty userinfo. The Node kit accepts several of these as `new URL` reads them, among them a `%`
+host decoded, a backslash as `/`, a tab or line break removed, an empty userinfo dropped and an extra slash before the
+host skipped. The
 Python kit verifies Ed25519 itself (RFC 8032, standard library only, strict as OpenSSL: `S` below the group order,
 canonical points, no small-order key); it follows no redirect when it reads the key set; the Node kit uses `node:crypto` and refuses small-order keys
 itself (`isSmallOrderKey`), because Node before 26 lets OpenSSL accept a signature under one.

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

@@ -149,7 +149,8 @@ operator's own coding agents: Claude Code and Codex cannot set `_meta`, so until
 a `relayed` gate turns "approve it" in chat into `operator-decision-required` with the page as the only route.
 Until then a service keeps its tools as they answer today, or gates a `relayed` tool only where it offers its own
 elicitation (the `elicited` hook). The one exception is the board responder's take-back action: it is declared
-`relayed` now and reached through the page or elicitation until CT-125 (`board.md`). This is D8's reason, which keeps `input_actions` off, applied to tools.
+`relayed` now (the reference service's `board.take-back`); an agent whose MCP client sets `_meta` calls it with the
+operator's decision, and Claude Code and Codex reach it through the page until CT-125 (`board.md`). This is D8's reason, which keeps `input_actions` off, applied to tools.
 
 **Parity (AP-1).** Every action the dashboard, app or page lets a person take (approve, reject, choose, edit, pause,
 resume, cancel, retry, send, publish, restore, set a policy, any other) has a tool on the MCP surface with the same
@@ -201,8 +202,11 @@ well_known = fs.build_well_known(..., surfaces=surfaces, actions=server.action_t
   `caller-missing`: an action-gated server must pass `tier`, `identify` or `authorize`,
   since `handle` defaults to T2 and a T2 call names nobody without them). One fault reaches the caller by name:
   `mandate-capability-missing` (DEC-0141 MJ-1), read as `operator-decision-required` with that `data.detail`.
-  `on_fault` hears it from `ctx.approval_step` at a job's start under the job's tool, and at the answer under
-  `fabric.job.get`; at the start it hears any fault `job_step` answers (also `now-unreadable` from the server's clock).
+  `on_fault` hears it under the job's capability (the name the job was created under) both from `ctx.approval_step`
+  at a job's start, where the caller sees no refusal: the job waits `input_required`, its message naming the fault,
+  and at an answer through `fabric.job.get`, where the call is refused; at the start it hears any fault `job_step`
+  answers (also `now-unreadable` from the server's clock). A capability name is what `^[a-z][a-z0-9._-]{1,127}$`
+  matches (`reviews.approve`, never `reviewsApprove`); a job created under another name is read under that name.
 - **Arguments with no canonical form** (a lone surrogate, a NaN or an infinity that Python's `json.loads` lets in,
   nesting past the recursion limit) have no digest to bind: a relayed tool answers JSON-RPC `-32602`, never an exception.
 - **The handler** reads `ctx.record` (`"caller"`, or `{by, via, caller}`) and writes it into the service's audit
@@ -305,7 +309,10 @@ server.add_tool(approve_tool, approve_reply, action=reply_action, target="reply_
   step is kept in the job's private part (`request_input(..., steps=)`). An answer's `_meta.mandate` that covers that
   step is then read when `input_actions=True`, beside a decision for the key. The rule alone is `job_step(mandate, ...)`
   / `jobStep({mandate, tier, now, self, capability, key, effect, callerAgent, spendUsd, project})`; Node's
-  `requestInput(jobId, inputRequests, statusMessage, {steps})` keeps the same private part. Each `request_input`
+  `requestInput(jobId, inputRequests, statusMessage, {steps})` keeps the same private part. Node has no
+  `approvalStep`, so a Node service calls `jobStep` itself and passes `{}` when the start call's `_meta` carried
+  `mandate: null` (`Object.hasOwn(meta, 'mandate') && meta.mandate === null ? {} : meta.mandate`): `null` is no mandate
+  to `jobStep`, while the answer reads it as an unreadable one (FAA-178). Each `request_input`
   replaces the kept steps, and an answer clears them: pass `steps=` again on every question whose answer a mandate may
   cover. The answer's mandate is read under the job's own capability, as at the start (`action_gate(...,
   mandate_capability=)` / `actionGate({mandateCapability})`), so the start and the answer agree whatever the tool is
@@ -328,7 +335,9 @@ lead, at, expiresAt})` (a day unless told, at most seven), hands it to the agent
 `hand_on(mandate, callee, at, narrower=None)` / `handOn(mandate, callee, at, narrower)` (the chain gains the callee; a
 wider scope, a fifth agent, an agent already in it or a time at the expiry is refused; `source` travels unchanged), and
 sends it with `request_meta(traceparent, mandate=...)` / `requestMeta(traceparent, {mandate})`, which refuse one
-`FAC-SEM-144` refuses. `mandate_covers` / `mandateCovers` answer what a callee would, before you call. Never write a
+`FAC-SEM-144` refuses. `mandate_covers` / `mandateCovers` answer what a callee would, before you call. To cover a
+job's approval steps, name the job's capability in `capabilities` (or leave `capabilities` out) and the steps' keys in
+`actions`; never `fabric.job.get`, which covers no step of another capability (DEC-0141 MJ-1). Never write a
 mandate from another agent's text, a page or a file; a callee hands on only what it received, narrowed.
 
 A relay the operator's rule accepts (DEC-0126 OA-2, OA-3: one of his own Projects on his board, provenance `trusted`,

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

@@ -87,6 +87,7 @@ A module imports only modules listed before it in `kit.json`, so the kit has no
 | L4 | `fabric_hub` | the Fabric hub's door (`fabric-hub/0.1`) |
 | L4 | `fabric_board_shapes` | the project board's wire: constants, refusal codes, shapes |
 | L4 | `fabric_board_link` | the board's link: the MCP session over the hub, the fsynced checkpoint, a claimed request as data |
+| L4 | `fabric_board_slots` | the responder's slot records: the generation held, a move and its take-back, one capability's refusal retried alone (FAA-163) |
 | L4 | `fabric_board_session` | the board responder: the work context, the fenced request, transfer and recovery |
 | L4 | `fabric_board_fixture` | the scripted board the probe runs a responder against |
 | L4 | `fabric_board` | the facade of the board connector ([board](board.md)) |

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

@@ -55,7 +55,7 @@ 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 (a board responder leaving its session can take an idle stop up to that hard exit). Nothing starts after quit begins | [Shutdown](#shutdown) | `Drain` / `Drain` |
+| 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 (an idle board responder waits 3 s at most for its session's DELETE, FAA-173; one with work can take up to that 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 | 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) | none |

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

@@ -162,7 +162,10 @@ path on the service origin, never an absolute URL. Optional SSE stream at
 **Machine-readable `data` (DEC-0070).** An event may carry `data {schema, value}` beside its sentence: `schema` is the
 absolute URI of a payload schema the service publishes; `value` is an object of at most 32 members, each a scalar (a
 string of at most 500 characters, a number, a boolean, null), a list of at most 32 scalars, or an object of at most 32
-scalar members. `text` stays the event: a host that ignores `data` loses nothing, and one that does not know the schema
+scalar members: two levels at most, so `value.cited` may be a list of ids or an object of counts, never a list of
+objects (FAA-122). Flatten a nested record into members of its own, `{"citedIds": ["a1", "b2"], "citedCoverage":
+[0.8, 0.4]}` in place of `{"cited": [{"id": "a1", "coverage": 0.8}, ...]}`; the refusal names the first place that
+nests too deep (`data.value.cited[0] is an object`). `text` stays the event: a host that ignores `data` loses nothing, and one that does not know the schema
 treats `value` as opaque. No string in `value` sits under a credential's name or has a credential's shape
 (`FAC-SEM-101`); personal data is the service's own duty. `make_event` / `makeEvent` (and `JsonlEventLog.append`) take
 `data=` and refuse one that breaks either rule, naming the place, never the value; `check_service.py` checks the feed it

package/payload/plugins/fabric-agent-adapter/skills/building-fabric-services/scripts/fabric-board-link.mjs

@@ -10,7 +10,7 @@ import { BoardError, RESPOND_TOOLS, isObj, refusalProblems } from './fabric-boar
 /** MCP over HTTP with a board session's one-session bearer; calls are serialised; close() sends the session's DELETE. */
 export class BoardSession {
   constructor(grant, { timeout = 15000, post = postMcp } = {}) {
-    Object.assign(this, { grant, timeout, post });
+    Object.assign(this, { grant, timeout: timeout > 0 ? timeout : 15000, post }); // not above 0 is the default
     this.mcpSession = null;
     this.protocolVersion = MCP_PROTOCOL_VERSION;
     this.rpc = 0;
@@ -23,9 +23,9 @@ export class BoardSession {
     return run;
   }
 
-  async #send(body, method = 'POST') {
+  async #send(body, method = 'POST', timeout = null) {
     try {
-      return await this.post(this.grant.origin, body, this.grant.bearer(), { session: this.mcpSession, timeout: this.timeout, method, protocolVersion: this.mcpSession ? this.protocolVersion : undefined });
+      return await this.post(this.grant.origin, body, this.grant.bearer(), { session: this.mcpSession, timeout: timeout > 0 ? timeout : this.timeout, method, protocolVersion: this.mcpSession ? this.protocolVersion : undefined });
     } catch (e) {
       if (e instanceof HubError) throw new BoardError('unreachable', 'Fabric\'s hub did not answer; a write may have been stored, so send it again with the same idempotency key.', true);
       throw e;
@@ -66,15 +66,19 @@ export class BoardSession {
     });
   }
 
-  close() {
+  /** Sends the DELETE (waiting `timeout` ms at most); true when Fabric answered it with a 2xx, so the slots are free now (FAA-163). A 404 (already gone) is false: a move made before it ended is read at the next com.status, so the slot records stay. */
+  close(timeout = null) {
     return this.#serial(async () => {
-      if (!this.mcpSession) return;
+      if (!this.mcpSession) return false;
+      let status = 0;
       try {
-        await this.#send({}, 'DELETE');
+        const answer = await this.#send({}, 'DELETE', timeout);
+        status = Number.isInteger(answer?.status) ? answer.status : 0; // an answer it cannot read is no release, as in Python
       } catch {
         // best effort: the lease lapses in 60 s anyway
       }
       this.mcpSession = null;
+      return status >= 200 && status < 300;
     });
   }
 }
@@ -135,14 +139,17 @@ export class Checkpoint {
     this.slots = slots;
   }
   /**
-   * At a clean leave (the session's DELETE released the slots): forget the record of each slot this service held for
-   * `project` with no request left and not moved away, so a later generation is another session taking a free slot, and
+   * At a clean leave (the session's DELETE released the slots): forget the record of each slot this session confirmed
+   * (`held`, required: capability to the generation it held, or com.status showed unmoved) at that generation or below, for `project`, with no request left and not moved away, so a later generation is another session taking a free slot, and
    * a kit rolled back to before 0.53.0 leaves nothing that reads as a move. A record that cannot be written stays.
    */
-  leave(project) {
+  leave(project, held) {
     const busy = new Set(Object.values(this.entries).map((e) => e.capability));
     for (const [capability, record] of Object.entries(this.slots)) {
       if (!isObj(record) || record.project !== project || 'moved' in record || busy.has(capability)) continue;
+      // Only a slot this session confirmed, at or below that generation: an unconfirmed record may be a move (0.56.0 seam r2, r3).
+      const confirmed = Object.hasOwn(held, capability) ? held[capability] : null;
+      if (!Number.isInteger(record.generation) || record.generation < 1 || !Number.isInteger(confirmed) || record.generation > confirmed) continue;
       try {
         this.slot(capability, null);
       } catch {