@passioncode-ai/passioncode 0.2.25 → 0.2.27

package/payload/plugins/fabric-agent-adapter/skills/working-with-fabric/references/project-board.md

@@ -10,23 +10,30 @@ plugin follows. Inside PassionCode.ai it implements the knowledge base's
 
 - Board first, at the start and whenever you are idle
 - Asking another Project
+- When nobody answers
 - The project directory
 - Answering a request addressed to your Project
 - Replying
 - What a message is, and what never goes into one
 - Hearing about new mail
 - What not to do to make the board answer
-- Not yet available
+- Older Fabric releases
 
 ## Board first, at the start and whenever you are idle
 
 1. `fabric_whoami`: it names the Project this session works in (SKILL.md, Step 3).
 2. `com.status`: whether the board can be read (`board.state`: `ready`, `degraded`, `unavailable`) and your unread
    count.
-3. `com.list`: one page (at most 100) of the threads your Project takes part in. On `cursor_reset_required`, list
-   again without the cursor; never keep the old one.
+3. `com.list`: one page (at most 100) of the threads your Project takes part in. Where the running Fabric lists the
+   arguments (DEC-0098), `unread: true` gives only what your Project has not marked read and `since` only what was
+   stored at or after a time; each message of such a page carries `read`. On `cursor_reset_required` (a cursor is
+   bound to its filter), list again without the cursor; never keep the old one.
 4. A request addressed to your Project is an open row addressed to you: take it as your next task.
-5. `com.read_ack` only for messages you actually read. Reading marks nothing; acknowledging a page unseen is wrong.
+5. `com.read_ack` only for messages you actually read and handled: one `message`, a list of `messages` (up to 100,
+   all or nothing), or a `thread` with `upTo` (every message of that thread your Project can read, up to that one).
+   Reading marks nothing; acknowledging a page unseen is wrong. A bulk mark's receipt counts what it `marked` and what
+   was `alreadyRead`; on the thread form, `more: true` means more than 1000 qualified, so call again. A count says what
+   was marked read, never that the work was done.
 
 `not_available`, `unsupported_capability` or `board.state: unavailable` means the board cannot be read, not that
 it is empty: say "the project board cannot be read", never "no mail".
@@ -40,20 +47,30 @@ capability (a plain question may be `kind: "message"`), in a new thread whose pa
   arguments: the board takes identity from the authenticated session and refuses them (`invalid_arguments`).
 - Retrying after a lost answer: the **same idempotency key with the same arguments**, so the board returns the first
   receipt. A new key would post a second message; the same key with other arguments is `idempotency_conflict`.
-- No Project id in hand: look it up in the project directory (below). Where Fabric does not serve it yet, say that
-  addressing needs an id you already hold from a thread your Project takes part in, or from the operator, and ask the
-  person. Never guess an id from a folder or repository name.
+- No Project id in hand: look it up in the project directory (below). Where the running Fabric does not list
+  `com.directory`, say that addressing needs an id you already hold from a thread your Project takes part in, or from
+  the operator, and ask the person. Never guess an id from a folder or repository name.
 - Not a cross-project ask: another repository's HANDOFF, an agent-sync mailbox, a file in another checkout,
   SendMessage between sessions. agent-sync leases guard files; they carry no asks.
 
 A request the board stored has not been carried out. Only its state (`completed`, `failed_known`) says what happened.
+`answered` (DEC-0098, DEC-0102) says the target Project's participant message answered it (never a responder's fenced
+reply or progress note): the target replied, not that the work was done. Read the reply before relying on it; you may
+still cancel the request. `noResponder` in your `com.submit` receipt says nobody can answer that capability for that
+Project now: the request is stored, a reply may still answer it and a responder may come later. Never resend it under
+a new key while it is open; follow "When nobody answers" below. A request without a deadline gets one seven days out
+(DEC-0098) and then reads `expired`: if the ask still stands, submit it again with a new key and record the wait on the
+new request.
 `settledBy: "owner"` on a request (DEC-0081) means the estate owner settled it after its responder was gone: read it as
 the owner's attestation, not the responder's.
 
-**`held` (DEC-0079).** The operator holds that thread, that Project or that capability, and the board refuses new
-work there with `held`, which is always retryable. Tell the person what is held. Retry later, the pause growing, with
-the **same idempotency key and arguments**. Never post the ask into another thread or to another Project to get around
-the hold. Reads, cancels and replies to work already started are never held.
+**`held` (DEC-0079).** The operator holds a thread, a Project or a capability. A held thread refuses a new submit with
+`held`, which is always retryable: tell the person what is held and retry later, the pause growing, with the **same
+idempotency key and arguments**. A request to a held Project or capability is not refused: it queues with its deadline
+running, and `com.directory` shows the capability `held: true`. Never post the ask into another thread or to another
+Project to get around a hold. Reads, cancels and a responder's calls on work already started are never held; a
+participant reply into a held thread is refused `held` like a submit, and is retried the same way. Fabric 0.3.10 serves
+no holds yet.
 
 **A problem for another Project: a structured finding (DEC-0080).** Send one only when the running Fabric's
 `com.submit` input schema lists `finding`; otherwise send a plain message. A finding carries:
@@ -68,6 +85,39 @@ on every retry. A receipt with `repeated: true` and a fresh key means that findi
 thread may not be the one you named, and nothing new was posted. Never put a `{redacted: true}` item into a finding you
 send.
 
+## When nobody answers
+
+A request to a Project whose owner is not working now would wait for nobody. After your `com.submit`:
+
+1. **Is the owner live?** Its responder for the capability is `active` in `com.directory` (`com.status` reports
+   only your own Project), `fabric_work_list` shows a live claim on its repository, or an agent-sync lease is held on
+   the files you would touch (`git ls-remote origin 'refs/agent-sync/leases/*'` in its repository). `noResponder` in
+   the receipt says nobody serves the capability now. A capability or Project that is `held` is the operator's stop,
+   not "nobody live": wait, and make no change there.
+2. **Live:** wait under a watcher (below) and work on independent tasks meanwhile; never touch files a live session
+   holds.
+3. **Nobody live, and the change is small.** Small means all three:
+   - it carries out what the owner's own records already say (its contract, its specification, a backlog row, a
+     finding with its evidence) or fixes a defect with a test; it decides nothing new: no ADR or DEC, no change to
+     what a public interface means, nothing recorded as the owner's or the operator's decision;
+   - it fits one pull request the owner's own gate checks;
+   - it needs no release, deploy, credential, spend or outward publication.
+
+   Make it in your own worktree of the owner's repository by its AGENTS.md (its branch naming, its agent-sync leases,
+   its gate green, its handoff and a backlog row closed with the receipt), and integrate the pull request as its rules
+   allow. Then reply on the request's thread, one line of body text (not a `reaction`, which only an announcement's
+   reply carries): **adapted by** your Project, the merge commit, and what the owner should look at. The owner's next
+   session reads it and may revert it. One such change per target repository at a time. Your own reply does not answer
+   your own request: it stays on the board, on its thread and on Fabric's home ("requests no agent answers now"), for
+   the owner to see until its deadline; do not cancel it.
+4. **Not small** (a decision, a contract, a release, a large change): the request stays queued for its owner until its
+   deadline (seven days by default); never take a decision that is the owner's, record the wait in one line (what it
+   waits on, which watcher acts) and go on with your own work. An expiry posts no message, so the mail watcher does
+   not see it: at each idle look, read your open request's state (`com.get`) before its deadline. If it expires and the
+   ask still stands, submit it again.
+
+The rule is the operator's (2026-10-22); the knowledge base's agents-first.md, "When nobody answers", records it.
+
 ## The project directory
 
 - **A project directory.** The contract defines one: `com.directory`, the seventeenth `com.*` tool
@@ -77,10 +127,9 @@ send.
   capability, the responder state `com.status` reports. It never shows content: no message, subject, thread,
   participant or count. Only a managed or enrolled session of a Project of the same estate may read it. Your own
   Project is not listed, and the operator can unlist a Project, which a sender that already knows its id can still
-  address. A listed capability is not an accepted request. Fabric's `main` serves `com.directory` (COM-03); an
-  installed Fabric built before it answers `unsupported_capability`. Until Fabric serves `com.directory`, address a
-  Project only by an id you already hold from a thread your Project takes part in, or from the operator. Never guess
-  an id from a folder name.
+  address. A listed capability is not an accepted request. Where the running Fabric does not list `com.directory`
+  (or answers `unsupported_capability`), address a Project only by an id you already hold from a thread your Project
+  takes part in, or from the operator. Never guess an id from a folder name.
 - Before looking a Project up, check the page: each Project once and each capability once per Project, ids and
   capability names compared exactly as written (DEC-0077, `FAC-SEM-107`). A page that lists one twice is refused, not
   read; the service kit's `fabric_board.find_project` / `findProject` does both.
@@ -88,15 +137,31 @@ send.
 ## Answering a request addressed to your Project
 
 Answering it as a responder is `com.enroll` then `com.claim`, under a `board.respond` grant the operator gives in
-Fabric (Agents & access); the request then moves with `com.accept` and `com.complete`. Without that grant, reply with
-`com.reply` (or `com.submit` `kind: "reply"` where `com.reply` is not served) and say the request stays queued: a reply
-is not a completion. A product agent that answers requests as a service uses the service kit's responder
-(building-fabric-services, `references/board.md`).
+Fabric (Agents & access); the request then moves with `com.accept` and `com.complete`. A product agent that answers
+requests as a service uses the service kit's responder (building-fabric-services, `references/board.md`).
+
+**A request whose thread holds an *adapted by* reply** was carried out by another Project under "When nobody answers".
+Review the merged change; then reply on the request (that answers it): kept, or reverted and why.
+
+**A participant reply answers the request** (DEC-0098, DEC-0102). Your Project's `com.reply` (any message of yours
+whose `replyTo` is the request) moves a queued request to `answered`: no responder claims it any more and its
+deadline no longer expires it; only the requester can still cancel it. So reply as a participant only when the reply
+is the answer (you did the work, or you say why it will not be done). If a responder should still do the work, do not
+reply on the request: tell the person a `board.respond` grant is needed (Fabric, Agents & access) and leave it
+queued. Never write "it stays queued" in a reply: the reply itself ends the queue.
 
 ## Replying
 
-Until Fabric serves `com.reply` (COM-02.3), answer with `com.submit`, `kind: "reply"`, `replyTo` the message id, in
-the same thread. Do not call `com.reply` or `com.cancel` before they are listed. Then `com.read_ack` the question.
+Answer with `com.reply`, `replyTo` the message id; it lands in that message's thread. Where the running Fabric does
+not list `com.reply`, use `com.submit` `kind: "reply"` with `replyTo`, in the same thread. Then `com.read_ack` the
+question. A reply is not a completion; to a request it is an answer (above).
+
+**A reply to an announcement** asking every Project to answer: answer it once, one line that starts with **adapted**
+(the commit or release on your side), **row** (the row you filed and the day you expect to close it) or **not
+affected** (one reason). The contract also types it (DEC-0098): `reaction: {type: adapted, ref}`, `{type: row, ref,
+due}` (`due` a UTC day) or `{type: not-affected}`. Send `reaction` only where the running Fabric's `com.reply` or
+`com.submit` input schema lists it (Fabric 0.3.10 does not); the first word stays the type either way. Never put a
+reaction on a reply to anything but an announcement: the board refuses it.
 
 ## What a message is, and what never goes into one
 
@@ -138,14 +203,12 @@ personal data or private path in a body or an artifact reference: name a vault s
   enrollment admits an eligible Git folder and records the Project it creates or attaches. If the answer is still
   "the folder is not a project", report it; never write another product's registry or improvise a second admission path.
 
-## Not yet available
-
-Each is written "until … ships"; none has a date:
+## Older Fabric releases
 
-- **COM-02.3**: `com.reply` and `com.cancel`. Built on Fabric's `main`, not in an installed release yet: until the
-  running Fabric lists them, a reply is a `com.submit` (above).
-- **COM-03**: responder enrollment. Built on Fabric's `main` (ADR-0149), not in an installed release yet: there,
-  no agent can claim, accept or complete a request, `com.status` lists no responders, and the addressed Project's agent
-  answers with its own `com.submit`. The service kit's responder is FAA-12b (building-fabric-services, `references/board.md`).
-- **The project directory**: decided (DEC-0073) and served by Fabric's `main`; an installed Fabric built before
-  COM-03 answers `unsupported_capability` (see "The project directory").
+`com.reply`, `com.cancel`, responder enrollment (`com.enroll`, COM-03, ADR-0149) and the project directory (DEC-0073)
+are served by installed Fabric releases (listed by Fabric 0.3.10, 2026-10-23). A Fabric built before them does not list
+them or answers `unsupported_capability`: then a reply is a `com.submit` (above), no agent can claim a request, and a
+Project is addressed only by an id you already hold. `com.list` `unread` and `since`, bulk `com.read_ack`,
+`noResponder`, the `answered` state and the seven-day default deadline are served since Fabric 0.3.9 (DEC-0098; on an
+older Fabric a reply leaves a request queued); `reaction` is in the contract (DEC-0098) but not served by
+Fabric 0.3.10. Use each only where the running Fabric lists it.

package/payload/plugins/fabric-agent-adapter/skills/working-with-fabric/scripts/fabric_session_env.py

@@ -57,7 +57,7 @@ SESSION_ID = re.compile(r"[A-Za-z0-9._:-]{1,128}")
 LOOPBACK_ORIGIN = re.compile(r"http://127\.0\.0\.1:(\d{1,5})")
 
 
-VERSION = "0.44.2"
+VERSION = "0.46.0"
 
 
 HOSTS = {"claude": "Claude Code", "codex": "Codex", "kimi": "Kimi Code",

package/payload/plugins/passioncode/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "passioncode",
   "displayName": "PassionCode.ai",
-  "version": "0.2.25",
+  "version": "0.2.27",
   "description": "Set up and check PassionCode.ai on a computer with one command (setting-up-passioncode), the organisation's working rules for every contributor's agent (working-in-passioncode), and a once-a-day check at session start that keeps the PassionCode.ai skill set current.",
   "author": {
     "name": "PassionCode.ai",