@passioncode-ai/fabric-agent-adapter 0.58.0 → 0.60.0

package/plugins/fabric-agent-adapter/skills/creating-fabric-agents/references/where-agents-run.md

@@ -16,6 +16,7 @@ The normative rules are the Fabric Agent Contract's, at the commit this plugin p
 - [Connecting a machine or a cloud to the estate](#connecting-a-machine-or-a-cloud-to-the-estate)
 - [Sharing an agent into an organization](#sharing-an-agent-into-an-organization)
 - [Running while the laptop is closed](#running-while-the-laptop-is-closed)
+- [Uptime: A or B](#uptime-a-or-b)
 - [Selling an agent](#selling-an-agent)
 - [The checklist](#the-checklist)
 
@@ -85,13 +86,33 @@ checked, and removes the instance from the next revision.
 ## Running while the laptop is closed
 
 A cloud agent keeps working with the laptop closed only if everything it needs is in the cloud: its worker, its
-secrets, its data, and a hub that can admit calls. The local Fabric hub is not a cloud hub. Design for it:
+secrets, its data, and, for the calls Fabric admits, a hub that can admit them. The local Fabric hub is not a cloud hub. Design for it:
 
 - Declare what each capability needs and where it is; a capability that needs the person's machine reports
   `pending` or `unavailable` instead of pretending, and queues within a deadline or declines.
 - Never charge for work it cannot deliver on the promised terms.
 - A test that passed on fixtures says nothing about uptime; measure the installed agent in its cloud.
 
+## Uptime: A or B
+
+Every new agent is given an uptime category on its first day, and the README names it:
+
+- **A, around the clock.** A capability must answer while the owner's machine is off or asleep: a schedule, a chat,
+  callers outside the machine. A cloud host is required from the first release; Heroku is the default, another host
+  only when a reason names it: an instance in the person's PassionCode cloud or an organization's cloud runs there
+  (the places above), and a paid agent stays in PassionCode's cloud (selling an agent, below). On a host with no
+  Fabric hub it answers what reaches its own origin (its schedule, its chat, its API); a call Fabric admits needs a
+  cloud hub, as running while the laptop is closed says. The agent is an online service (building-fabric-services, the remote placement), often
+  alongside its local instance, and starts from the cloud Fabric-server template once that template's repository
+  exists. Its data lives where the cloud reaches it, in a durable store (a database, an object store, the private
+  `<agent>-data` repository), never the host's own folder, which a platform such as Heroku does not keep across a
+  restart.
+- **B, local only.** Nothing needs it while the machine sleeps: a local service and no cloud. It reads an A agent's
+  data through that agent's MCP or API, never from its store.
+
+A B agent that gains a capability that must answer around the clock becomes A for that capability; record the change
+and move only that capability to the cloud.
+
 ## Selling an agent
 
 - **A paid agent** runs in PassionCode's cloud inside its developer's organization (`org:<developer>`); each customer
@@ -108,6 +129,7 @@ secrets, its data, and a hub that can admit calls. The local Fabric hub is not a
 - Where does each instance run, and in which context? Write it in the knowledge pack.
 - Does any state, secret, log line or cache key cross contexts? It must not.
 - Which capabilities need the person's machine, and what do they answer when it is off?
+- Which uptime category is it, A (a cloud host from the first release) or B (local only)? The README names it.
 - Who pays for each call (which grant, which key)? The person's personal key never pays for an organization.
 - If it joins machines or applies the estate record: tokens from stdin or a 0600 file only, revisions verified with
   their parent.

package/plugins/fabric-agent-adapter/skills/working-with-fabric/SKILL.md

@@ -18,7 +18,7 @@ compatibility: >-
   this plugin; Codex/Kimi use command hooks; Hermes/OpenCode/OpenClaw/Pi use native context plugins after opt-in.
 metadata:
   author: PassionCode.ai
-  version: "0.58.0"
+  version: "0.60.0"
 ---
 
 # Working with Fabric
@@ -283,15 +283,15 @@ build or test in flight is not a stall. Note each restart (what stopped, when, a
 
 ## Step 6: tasks link to backlog rows, never copy them
 
-A backlog row in a repository stays the status source. File the Fabric task that runs it with the row's address:
+A repository's backlog row stays the status source. File the Fabric task that runs it with the row's address:
 
 ```json
 {"title": "…", "source": {"repository": "passioncode-ai/fabric-agent-adapter", "path": "docs/backlog.md", "id": "FAA-18"}}
 ```
 
-through `fabric_task_create` (or `fabric_work_claim`, which files one when none exists). Do not paste the row's
-text or status into the task; edit the row in its repository under that repository's rules. A row that does not
-resolve (a repository the project does not hold) is refused, naming the part that failed.
+through `fabric_task_create` (or `fabric_work_claim`, which files one when none exists); read its answer as Step 4
+item 2 says. Your single live claim links the row (Fabric 0.3.14): file an unrelated row after your release, never linked
+by hand, or say it is linked. Do not paste the row's text or status into the task; edit it in its repository.
 
 ## Step 7: at the end
 

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

@@ -61,12 +61,12 @@ reply or progress note): the target replied, not that the work was done. Read th
 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. An `accepted`
 request can also wait unanswered for its responder's operator: since adapter 0.53.0 a responder whose slot was moved
-to another session leaves its accepted work `accepted` and unanswered until the slot is taken back (until Fabric
-hands it over, CT-175), which is not the operator's hold below; tell
+to another session leaves its accepted work `accepted` and unanswered until the slot is taken back, or, once Fabric offers the operator's move,
+moved back to it (a responder from adapter 0.60.0 finds that; an older one comes back only by take-back), or until Fabric hands it over (CT-175), which is not the operator's hold below; tell
 the person, and cancel it if it is past what they can wait. 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.
+a new key while it is open; follow "When nobody answers" below. A queued or claimed 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. An accepted one is kept past its deadline (C4) and never expires: follow "When nobody answers".
 `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.
 
@@ -100,6 +100,20 @@ A request to a Project whose owner is not working now would wait for nobody. Aft
    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.
+   An `active` responder does not prove your request is being worked. A slot moved to another session (the operator's move,
+   contract DEC-0140 PR-2, once Fabric offers it, or another session's replacement) keeps the requests the old holder had accepted: they stay `accepted` with the old holder's
+   attempt, which nobody works until the new holder takes them over by a transfer or the old service gets the slot back
+   (its take-back, or a move back to a responder from adapter 0.60.0), while Fabric's thread view shows the
+   new holder as "Answers it" and its "requests no agent answers now" leaves them out (FAA-172). The board shows a
+   requester no attempt or generation (`com.get` gives the request's `state`, `effect` and `revision`, never its attempt), so you cannot tell
+   this from slow work: when your request has stayed `accepted` with no progress note or reply past what the work
+   should take, ask on its thread (`com.reply`) whether it is being worked. If nobody answers, cancel it first: while
+   its `effect` is still `not_started`, `com.cancel` moves it to `cancelled` (nothing has happened yet). Only when the
+   cancel's receipt shows the request `cancelled`, submit it again and read the new request from this step (an active
+   responder is step 2; step 3 only when nobody is live and it stays queued and unclaimed); an
+   accepted request never expires, and the old service would carry it out by a transfer once it gets the slot back, so
+   it is never adapted while still accepted. `outcome_unknown` means the work began meanwhile: tell the person and
+   change nothing.
 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:
@@ -114,8 +128,8 @@ A request to a Project whose owner is not working now would wait for nobody. Aft
    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.
+   your own request: a queued one 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

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

@@ -58,7 +58,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.58.0"
+VERSION = "0.60.0"
 
 
 HOSTS = {"claude": "Claude Code", "codex": "Codex", "kimi": "Kimi Code",