@passioncode-ai/fabric-agent-adapter 0.57.0 → 0.59.0

package/plugins/fabric-agent-adapter/skills/creating-fabric-agents/SKILL.md

@@ -5,7 +5,7 @@ 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. Ships in one plugin with adapting-projects-to-fabric, whose scripts it reuses.
 metadata:
   author: PassionCode.ai
-  version: "0.57.0"
+  version: "0.59.0"
   contract-version: "0.1.0"
   contract-commit: "3830a3353923e20f826d466610e1c479f120bec0"
 ---
@@ -57,6 +57,9 @@ No file is created until every row has an answer. An answer of "later" fails the
 | **Which profile?** | `mcp` when Fabric owns planning and retries and the capability has a schema; `a2a` when the provider owns its task lifecycle end to end; `local-runner` when it is a terminal agent Fabric drives. When unsure, the sibling skill's profile-selection reference is the decision record |
 | **What effects?** | declare anything money-, deletion-, or publication-adjacent now; the host's floor and grants are designed against these declarations, and one discovered late invalidates the admission |
 | **Where does it run, for whom?** | this machine, the person's cloud or an organization's, and in which contexts (`personal`, `org:<id>`): one instance per context, its secrets, spend and journal never crossing into another. Record which capabilities need the person's machine and what they answer when it is off (references/where-agents-run.md) |
+| **Does it run around the clock?** | the uptime category, decided now: **A** when a capability must answer while the owner's machine is off or asleep (a schedule, a chat, callers outside the machine): the agent gets a cloud host from its first release, Heroku unless a reason names another (the person's or an organization's cloud, or PassionCode's for a paid agent), built as an online service (building-fabric-services, the remote placement) and started from the cloud Fabric-server template once that template's repository exists; **B** when nothing needs it then: a local service only, no cloud, reading an A agent's data through that agent's MCP or API. The README names the category (references/where-agents-run.md) |
+| **Whose data does it keep?** | the kind of its data, named in the README: **U** when it keeps data of people outside the owner's team (messages, support requests, reviews, customers' answers), which never enters the source, a copy of it or its tests: the source holds the schema and synthetic fixtures, and a copy starts with an empty store of its own; **O** when it keeps none (a tool or service for other agents, the owner's reports, runs and media). In doubt, U. Either way the data lives in `<agent>-data` (a kit service: the kit's folders; on a cloud host: a durable store), apart from the source, from the first commit (references/source-and-instance.md) |
+| **Who holds the copyright?** | the holder the agent's `LICENSE` names: a new private agent (built for its owner or for a client) gets a `LICENSE` naming that holder in its first commit, all rights reserved unless the owner gives other terms; a public product keeps its own licence (a PassionCode.ai repository: the organization's, step 2) |
 | **Which models?** | per lane (planning, replies, volume work, media): a primary, a fallback of another vendor, an open-vendor model where it reads what users send, the input kinds each reads, declared as classes in the profile (references/models-and-providers.md) |
 | **Who pays?** | one key per agent and context with its own ceiling, from the estate's key manager, read from the environment; checked before every call; a personal key never pays for an organization |
 | **How does it learn?** | decisions recorded with reasons, one trace per turn, every failure a planted fixture first, history replayed, learnings proposed and never self-approved (references/orchestration-and-learning.md) |
@@ -73,8 +76,10 @@ failures, a retro), distil it before writing code:
    failures and dead ends).
 3. **Convert every trap into a planted eval fixture.** The new agent is not done until
    it has been watched rejecting the exact defects its predecessors were burned by:
-   knowledge transfers as a check, not as prose.
-4. Record the pack in the new project as `docs/knowledge-pack.md` with its sources, so
+   knowledge transfers as a check, not as prose. A fixture carries the defect on neutral
+   ids, never the predecessor's owner, paths or accounts.
+4. Record the pack in the new project as `docs/knowledge-pack.md` with its sources (a public URL or commit, else a
+   neutral name, the private address kept in the instance), so
    the provenance of every borrowed decision survives the person who borrowed it.
 
 Skipping this step because there is no prior art is legal; skipping it because reading
@@ -109,8 +114,11 @@ are its seed because a source project's recorded failures count as production.
 repository standard (`knowledge/repository-standard.md`) from its first commit: the licence files,
 the README quick start verified with a real client, `AGENTS.md` and `CLAUDE.md`, as
 [the operator channel and the repository standard](references/operator-channel-and-repository.md)
-lists them. An agent someone builds for themselves is not a PassionCode.ai repository: its licence
-is its owner's choice and none of those files is required of it.
+lists them. An agent someone builds for themselves, or a private agent built for a client, is not a PassionCode.ai repository: its licence
+is its owner's choice and none of those files is required of it, but its first commit carries a `LICENSE` naming
+the copyright holder the grill recorded (all rights reserved unless the owner gives other terms); it covers the
+holder's own files, and the kit files the adapter copies in keep their own licence (AGPL-3.0-only OR
+LicenseRef-PassionCode-Commercial).
 
 **Every credential the agent uses is read by name, never held as a value**, from its first commit:
 the README's Configure section lists key NAMES. With Project Observatory installed, the agent finds
@@ -122,6 +130,15 @@ at start. Either way: no `.env` of its own, no key file beside its data, no valu
 configuration or a commit. A workflow names the keys it needs in its checkpoint (`credentials`),
 never their values.
 
+**The source stays apart from the instance**, from the first commit: instance values (the
+repository address of the owner's account, folders, the owner, accounts, hosts) live in a configuration outside the repository, read through a
+named variable with a neutral default and a committed `*.example`; records, logs and state documents live in the
+instance folder; fixtures use neutral ids. Its data has a home of its own from the same commit, the one the grill recorded: `<agent>-data` (a folder beside the
+checkout, or a private repository of that name; a kit service: the kit's folders; on a cloud host: a durable store), and the README names the data kind (U or O) and the uptime
+category (A or B) from the grill. Load [the source and the instance](references/source-and-instance.md). The
+sibling's `scripts/fabric_source_check.py check <project-root>` finds instance data in the tree without repeating it;
+run it with the owner's list of their own strings, or record that none was given (the owner's own home name, when it is neutral, has one or two letters, or holds a space, `.`, `_`, `-` or `'`, is declared there with `home: <name>` first; a container's, a cloud image's or a CI runner's user that only the image uses, such as `node` or `vscode`, is never declared); the skeleton is done when it exits 0 and the owner has reviewed it (a floor, not a secret scanner; without the sibling or Python 3.9+, record the check as NOT_RUN, as in step 3). Handing the source over stays the owner's act.
+
 ## Step 3: scaffold the provider bundle
 
 Reuse the sibling skill's scaffolder against the new skeleton with the profile chosen at
@@ -163,7 +180,8 @@ reference). An agent that is not a service is announced with a provider entry
 If the agent keeps running on the operator's computer (it answers other agents, runs
 long jobs or shows a dashboard), build it as a service with the sibling skill
 `building-fabric-services`: its instance lock, launchd plist, descriptor, well-known
-document and events feed are part of this step, not a later retrofit. If that skill is
+document and events feed are part of this step, not a later retrofit. An uptime A agent is built with the same
+skill as an online service (its remote placement: the https origin, keys as the platform's secrets). If that skill is
 absent, apply the `fabric-service/0.1` rules from the pinned contract's
 `docs/specification/service.md` by hand and mark its probe `NOT_RUN`.
 
@@ -181,8 +199,11 @@ lets the output decide what counts as success.
 
 Run the sibling skill's `check` (structural, then exact when the contract checkout is
 available) and complete `fabric/FABRIC-CONFORMANCE.md` with dated receipts, exactly as
-its workflow steps 5–7 prescribe; this skill adds no second verification path on
-purpose. Then record one expectation the report must carry:
+its workflow steps 5–7 prescribe, and run its `fabric_source_check.py check` again (exit 0). Every release of the
+agent runs it too, in Git mode on the checkout and with `--every-file` on the clean copy a transfer would carry (what
+Git would commit, as building-fabric-services' `references/package.md` makes it), as the transfer audit (each exit 0, with the owner's list or
+its absence recorded) until the contract's export (CT-194) replaces it; this skill adds no second verification path
+on purpose. Then record one expectation the report must carry:
 
 > When a Fabric host admits this provider, it enters under a **canary binding** (a
 > checker on its output and a budget cap), regardless of who wrote it. Unsupervised

package/plugins/fabric-agent-adapter/skills/creating-fabric-agents/references/operator-channel-and-repository.md

@@ -63,4 +63,7 @@ the project).
 org-index `scripts/check_format.py` reports 0 findings for it before it is called done. An agent
 someone builds for themselves is not a PassionCode.ai repository: its licence is its owner's
 choice, nothing about it is published or listed by the organization, and none of these files is
-required of it, though the verified MCP quick start is still how anyone learns to drive it.
+required of it, except that an agent built new carries a `LICENSE` naming the copyright holder (all rights reserved
+unless the owner gives other terms), as does a new private agent built for a client; files the adapter copies in (the service kit, the dashboard kit) keep their own
+licence, `AGPL-3.0-only OR LicenseRef-PassionCode-Commercial` ([COMMERCIAL-LICENSE.md](https://github.com/passioncode-ai/fabric-agent-adapter/blob/main/COMMERCIAL-LICENSE.md)).
+The verified MCP quick start is still how anyone learns to drive it.

package/plugins/fabric-agent-adapter/skills/creating-fabric-agents/references/source-and-instance.md

@@ -0,0 +1,179 @@
+# The source and the instance
+
+An agent is two things. Its **source** is what can be handed to someone else: code, skills, prompts, schemas,
+examples, the source documentation. Its **instance** is what belongs to one installation: records, logs, journals,
+keys, the owner's names and paths, accounts, hosts and its configuration. A new agent keeps the two apart from its
+first commit, so that its owner can hand the source over later without rewriting its history. Nothing is handed over
+by itself: handing over, a new remote, a push or a change of visibility stays the owner's act, each time (a personal
+agent stays private until its owner says so about that act).
+
+The format of a source manifest, export and import is the contract's to decide (CT-194). What follows does not depend
+on it.
+
+## Contents
+
+- [The layout](#the-layout)
+- [The data home and its kind](#the-data-home-and-its-kind)
+- [The check](#the-check)
+
+## The layout
+
+| Where | What | In Git |
+|---|---|---|
+| the repository | code, skills, prompts, schemas, the source documentation, fixtures on neutral ids (`example-agent`, `/Users/example`) | yes |
+| `config/<name>.example.json` (or `.env.example`, `*.example.yaml`) | every instance value the agent reads, with a neutral default: the repository address of the owner's account, folders, the owner, account ids, hosts | yes, the example only |
+| the instance folder, outside the repository | the real configuration, records (a database included), logs, journals, state documents | never in the source's repository (a separate private repository of the owner's data belongs to the instance) |
+| the secret store | key values; the source names each key by name only (`EXAMPLE_API_KEY`) | never |
+
+- **The instance folder is the agent's data folder.** An agent that is not a kit service reads it through one named
+  variable (`<AGENT>_DATA_DIR`) that overrides its default. A service built with `building-fabric-services` takes the
+  kit's folders unchanged (the Directories table in its `references/lifecycle.md`, `fabric_paths.service_dirs`): on macOS `~/Library/Application Support/<id>/`,
+  on Linux `${XDG_DATA_HOME:-~/.local/share}/<id>/`, on Windows `%LOCALAPPDATA%\<id>\`. An agent's second context
+  (an organization's) is a sibling instance, `<id>.<instance>`, never a folder inside the personal one
+  (`references/estate-record.md` of that skill).
+- **Ignore the instance in the source**: `.gitignore` names the real configuration (`config/*.json` with
+  `!config/*.example.json`), an instance folder an existing project still keeps inside the checkout, and what running
+  the agent leaves (`__pycache__/`, `*.pyc`), which the check would otherwise report as binary in Git mode.
+- **State documents are instance data.** A handoff, a decision log or a backlog about this codebase is source
+  documentation; a record of what this installation did (runs, conversations, the owner's notes, a journal) lives in
+  the instance folder.
+- **Keys by name.** The README's Configure section lists key names, the agent reads each from its environment or the
+  secret store, and no value is ever written to a file, a fixture, an argument or a commit.
+- **Fixtures on neutral ids.** A test that needs a home folder, an owner or an account uses `example`, `example-agent`,
+  `owner@example.com` or a one-letter home, and a credential-shaped test value says it is synthetic
+  (`sk-test-not-a-key`) or is assembled at run time.
+- **Two names stay in the source until the contract decides (CT-194).** A service's supervisor label is the agent's
+  own name, reverse-DNS on the publisher's domain (`com.example.example-agent`), and `AGENTS.md` names it (LC-09):
+  never the owner's account or name. A provider's `createdBy` names the publisher; until one is chosen it
+  keeps the scaffold's sentinel, and a person's name or account is never written there. The adapter moves both when the
+  contract decides how an instance renames them (FAA-188 part 2).
+
+## The data home and its kind
+
+- **The data has a home of its own from the first commit: `<agent>-data`.** For an agent that is not a kit service it
+  is a folder beside the checkout, never inside it, and `<AGENT>_DATA_DIR` names it (its default is
+  `../<agent>-data`); a kit service keeps the kit's folders above. When the owner keeps the data in Git, it goes to a
+  separate private repository named `<agent>-data`, never to the source's repository. On a cloud host that does not
+  keep its disk across a restart (Heroku and the like, an uptime A agent's default), the data home is a durable store
+  the same variable names (a database, an object store, that private repository); the folder and the kit's folders
+  serve a machine whose disk persists. A copy of the agent starts with an empty home of its own and never connects
+  to the original's.
+- **The README names the kind of the data.** **U**: the agent keeps data of people outside the owner's team
+  (messages, support requests, reviews, customers' answers); it never enters the source, a copy or its tests, and the
+  source holds only the schema and synthetic fixtures (its real-trace corpus and replay samples live in the data
+  home). **O**: it keeps none (a tool or service for other agents, the
+  owner's reports, runs and media); its working data still goes to the data home. When in doubt, the kind is U.
+- **Every release runs the transfer audit.** `fabric_source_check.py check <project-root>` in Git mode, and
+  `check <clean-copy> --every-file` on a clean copy of what Git would commit (`git ls-files --cached --others
+  --exclude-standard`, as building-fabric-services' `references/package.md` makes it; never the checkout itself, whose ignored
+  configuration and dependency folders `--every-file` reads too), each exit 0, with the owner's list or its absence recorded, until the contract's export (CT-194)
+  replaces it.
+
+## The check
+
+`fabric_source_check.py check` reads the files the source would carry (what Git would commit: tracked files and
+untracked ones that are not ignored, as they are in the work tree; a staged copy that differs is not read) and reports each place where the instance shows through, by path, line and kind:
+
+| Kind | Finds |
+|---|---|
+| `home-path` | an absolute path inside a person's home folder (a web route under `/home/` is reported too; a route under `/users/` is not): `/Users/<name>/`, `/home/<name>/`, `C:\Users\<name>\`, Git Bash's `/c/Users/<name>/`, WSL's `/mnt/c/Users/<name>/`, and the dashed (`-Users-<name>-`, `C--Users-<name>-`) and URL-encoded forms a tool makes of one. The name is ASCII, and in the dashed form it ends at the next dash: an owner whose home name holds a space, a dash, a dot, an underscore or an apostrophe (each a dash in the dashed form; a slashed name also ends at a space) declares it with `home: <name>` in the owner's list, which reads it whole in every form, and one whose home name is not ASCII, or holds another character, lists it as a plain string (a typographic apostrophe a keyboard typed, which the folder's name does not hold, is written as `'` in `home:`; a folder whose name holds `’` is listed as a plain string with `’` kept and declared too with `home: <name>` written with `'`, which reads the dashed forms; its URL-encoded `’` is not read; a name outside ASCII of one or two characters cannot be checked) |
+| `secret` | a value shaped like a credential by the contract's detector (DEC-0044), read line by line: a provider key starting a word, a JWT, a bearer token, a long random value assigned to a credential's name (but a whole Ed25519 signature under a JSON `"sig"`, `"signature"` or `"signatures"` member, as `sign` writes it, which is public); or a private key: a PEM, OpenSSH or PGP block, or a JWK's `d` as a JSON member, escaped JSON or a Python dict; a URL with a password of 8 or more characters mixing letters and digits (a password without a digit or without a letter is not read) or a credential in its query, percent-encoded or not, JSON-escaped (`\u0026`, `\/`) or nested in another URL's parameter (two levels deep); a file that is a credential by its name, as `pack` refuses it (`.env`, `*.pem`, `*.key`, `.npmrc` and the rest), or a kit credential file (`*.token`, `board.credential`) |
+| `instance-string` | a string from the owner's list, in a file, in a file's path or in a link's target |
+
+```bash
+python3 <plugin-dir>/skills/adapting-projects-to-fabric/scripts/fabric_source_check.py check <project-root>
+```
+
+- It **never repeats** a value it found: no value, no line holding one, no entry of the owner's list and not the
+  folder it checks reaches its output. A file's path is checked like its text (line `0` of a finding), and printed
+  with an entry of the list as `<line N>`, a home folder's name as `<home>` and each segment holding a
+  credential-shaped value as `<secret>` (two files can then print the same; the segments a found value runs across, an
+  assigned value, a bearer run or a URL, are masked too, while a key, a JWT or a JWK `d` is read up to the `/` that
+  cuts it, so the rest of a cut one can print in the next folder: find the file by the folder the finding names); an instance string is named by its line in the owner's list. The report can go in a commit
+  message, an issue or a chat. A declared home of one or two letters, once found anywhere in the tree, is masked wherever it stands in a printed
+  path, inside a word too (`qzone` prints `<home>one`); found nowhere, it is not masked.
+- It **changes nothing.** Exit `0`: no finding and every file read; `1`: at least one finding (the step is not done);
+  `2`: the check could not run, or a file was not read: an unreadable file, a nested repository, or a binary file the
+  ignore file does not name as source (the summary counts each, and how many files were left out by name). A finding
+  sets `1` even when a file was not read too; the files not read are still listed, so fixing the findings can leave `2`.
+- **What it reads.** A text file of any size is read whole, and the summary counts every text file read; a binary file (a NUL byte in its first 8 KiB) or one that
+  cannot be read is listed by its path as not read, and the summary counts it. A database or another binary of
+  records in the tree is instance data the check cannot read: move it to the instance folder. A binary that is source
+  (an icon, a font) is named in the ignore file. `--every-file` reads every file, those Git ignores included, but `.git`, `__pycache__`, `.DS_Store` and `*.pyc`
+  (litter `pack` refuses): run it
+  on a folder before `pack`, which carries them. A committed symbolic link is checked by the path it names, never followed. When the folder is
+  not in a Git checkout, Git lists nothing in it, or no `git` is found in PATH's absolute folders (with PATH unset, in `/bin` and `/usr/bin`; on Windows, nowhere), every file is read but `.git` and `__pycache__` (uncounted) and the dependency
+  folders (`node_modules`, virtual environments, caches), and the summary says Git was not used and how many dependency folders were not read.
+  Under a locale whose file-system encoding is not UTF-8 (ISO-8859-1, KOI8-R) the check restarts itself in Python's UTF-8
+  mode, so a file name, an argument and a file's text are read in one encoding; a name that is not UTF-8 is matched as its bytes.
+  A file's text is read as UTF-8, so an entry of the owner's list with a letter outside ASCII is found in a UTF-8 file
+  (composed or decomposed, as macOS may store a name), not in one saved as Latin-1 or CP1252.
+  In Git mode a nested repository (a submodule, a vendored checkout) is not read: check a nested repository in its own tree with
+  the same check (a submodule checked out first, `git submodule update --init`), then name its path in the ignore file,
+  with that reason on the line above. That line serves the check of the outer tree only: before `pack`, check the
+  nested repository with `--every-file` in its own tree too, because `pack` carries its files, ignored ones included.
+- **The owner's list** holds the strings only the owner knows are theirs (their name, company, accounts, hosts), one
+  per line, at least three characters; a line starting with `#` is a comment, so list a channel or a hashtag without its `#`, and a `#` after a string is
+  part of that string. An entry matches in any case and inside any word; an invisible format character (a direction mark, a
+  soft hyphen, a joiner) at either end of a string is dropped, spaces between such characters too, and does not count
+  toward the three; one inside it is kept and counts (an emoji's joiner), so a string copied with a soft hyphen in it
+  matches only text that holds one. A line `home: <name>` declares the owner's home
+  name instead (ASCII letters, digits, `.`, `_`, `-`, `'` and spaces, starting with a letter or a digit; a name holding a
+  space, as a Windows profile may, is written whole, `home: Jane Doe`, and everything after the colon is the name, so
+  a note goes on a line of its own (`# laptop`); spaces and tabs may stand around the colon; a line
+  that starts with `home` and a colon and holds anything else is refused, exit 2 (an invisible format character before
+  the name, after it or inside `home` is dropped, one inside the name refuses the line; a NUL anywhere in the list
+  refuses it too); such a line is never a string
+  entry, so list a string like `home: page` by a part of it, `ome: page`): the check then finds that home in every form the table names (it is never neutral, even with one or two
+  letters), and the bare name is not looked for anywhere else, though a declared name of three or more letters and digits is
+  masked wherever a printed path holds it as a word, its parts joined by none or any run of a space, `.`, `_`, `-`, `+`, `'`, their
+  percent-encodings or an escaped apostrophe (`\'`, `\x27`, `\u0027`, `&#39;`, `&#x27;`, `&apos;`), the same separators it is found with in every form; a home that is also your name goes in the list
+  as a plain string too, to be found in text. It is `--instance-strings FILE`, else the file
+  `FABRIC_INSTANCE_STRINGS` names, else `passioncode-fabric/instance-strings.txt` in the user's configuration folder
+  (`$XDG_CONFIG_HOME` when it is absolute, else `~/.config`; `%APPDATA%` on Windows). A list inside the tree is refused, because it would
+  travel with the source. A person who already keeps private terms for org-index's `check_private.py`
+  (`~/.config/passioncode/private-terms.txt`) passes that file with `--instance-strings`; this check matches a term
+  anywhere in a word, and it does not look for e-mail addresses or account ids by their shape.
+- **Leaving paths out.** `.fabric-source-ignore` at the root (globs, one per line, `#` comments) or `--exclude GLOB`
+  leaves out files that hold synthetic values on purpose, such as test vectors. A line is a path from the root, not a
+  `.gitignore` line (a leading `/` changes nothing, a line with no `/` matches at the root only, and a line holding `\`, `//`, an unclosed `[` or a class such as `[[:digit:]]` is refused, as Git reads each
+  otherwise): `*`, `?` and `[...]` stay inside one folder (`?` and `[...]` match one byte, as Git's do, so a letter
+  outside ASCII takes two or more) and `**` as a whole segment crosses
+  folders, so `vectors/*` takes the files in `vectors` and none in its subfolders. A line ending in `/`, or a path
+  with no wildcard, takes that folder and all it holds; only such a line leaves out a nested repository or a
+  submodule (`vendor/sub/`), never a wildcard line without the `/` (`vendor/*`). A wildcard folder line (`vendor/*/`)
+  takes every nested repository it reaches, checked or not, so name each one by its path. In Git mode a nested
+  repository is not read; `--every-file` and a folder outside Git read its files, its `.git` left out. An exception line (`!`) is refused, since what it would
+  bring back would go unread. Name the files, or a folder that holds
+  only synthetic vectors, never a whole source folder (a nested repository checked in its own tree is the one
+  exception), and say why on the line above. The `LICENSE` is the other: its copyright line names the holder, which is
+  authorship and travels with the source, so when the holder is on the owner's list the licence file is named in the ignore
+  file by its own path (`LICENSE`, `LICENSE.md`) with that reason (`# the copyright holder is authorship and travels with the source`); no other file of the
+  owner's is. A file `pack` refuses by its name cannot ship in a package: a public
+  certificate is renamed `*.crt`; a project `.npmrc` that holds no credential may be named in the ignore file, with
+  that reason, for the source check (the line then hides whatever is added to it later, so keep it credential-free),
+  and `pack` still refuses it, so a package is made from a copy without it (its
+  settings then apply only where the owner sets them: `~/.npmrc` reaches every project of the owner, and
+  `package.json`'s `publishConfig` carries publish-time settings such as `registry`, `tag` and `access`). A file
+  holding a credential moves to the instance, never into the ignore file.
+- A neutral home (`example`, `user`, `runner`, a container's, a cloud machine's or a dev container's user such as `node`, `ubuntu` or `vscode`, the fixture id
+  `example-agent`, a
+  one-letter name, a placeholder; the whole set is `NEUTRAL_HOMES` in the script. An owner whose home name is in it, a
+  first name such as `alice` or an `admin` account, or has one or two letters, writes `home: <name>` in the owner's
+  list; a container's, a cloud image's or a CI runner's user that only the image uses, such as `node` or `vscode`, is never declared, since
+  its paths are the image's and stay in the source; the home of the owner's own machine is declared even when its
+  name is an image's user, as `admin` or `ubuntu` on a cloud machine the owner works on; when that name is also the
+  user of an image in the tree, the image's paths are reported, and they are written through a build argument that
+  names the user, `ARG APP_USER=ubuntu`, `USER ${APP_USER}`, `WORKDIR /home/${APP_USER}/app`, so no home path stands
+  in the source; `$HOME` serves only where a shell in the image expands it, a `RUN` line or a script, since a
+  Dockerfile's `WORKDIR` and `COPY` see only `ENV` and `ARG` values) and a value that says it is synthetic (`EXAMPLE`, `not-a-key`, `fake`, `dummy`) are
+  not findings.
+
+The check finds the forms the table names, and only those: a credential in another shape (a bare token with no name
+before it, a provider's key the contract's names do not cover) passes it. It is a floor under the owner's review and a
+secret scanner, never a replacement for either.
+
+The check finds the repository from the folder it checks: a Git location the caller exports (`GIT_DIR`,
+`GIT_INDEX_FILE`, as a hook in a linked worktree has) is not passed to Git. The check reads the tree, not Git history. A value that was committed once is still in the history after the tree is
+clean: handing such a source over needs a fresh history, which is the owner's act, never the agent's (no history
+rewrite, no force-push).

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.57.0"
+  version: "0.59.0"
 ---
 
 # Working with Fabric

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