@passioncode-ai/fabric-agent-adapter 0.6.1 → 0.6.3

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # Changelog
 
+## 0.6.3 - 2026-10-04
+
+### Changed
+
+- **Agents and services get every credential from Project Observatory, by name.**
+  `building-fabric-services` principle 5: a service takes its provider credentials from the vault
+  through `use_secret.py serve` (Project Observatory 0.15.0), never from a copy beside the service;
+  a remote service's platform copy is recorded with `vault.py moved`. `creating-fabric-agents`
+  carries the same rule for agents from their first commit: no `.env` of their own, no key file
+  beside their data, no value in code, configuration or a commit, and `use_secret.py run
+  --vault-only` at launch.
+
+## 0.6.2 - 2026-10-03
+
+### Added
+
+- **`building-fabric-services` says how a product behaves under a host lifecycle broker** — the
+  always-on per-user service agents ask to start, stop and restart products
+  (`references/lifecycle.md`, "Being managed by a host lifecycle broker"): quit through both the
+  platform's quit and `SIGTERM`, stay in the background when opened non-activating, keep the
+  designated requirement stable, expose honest readiness. Measured on the first broker that
+  stops apps: a desktop app that closes its window on `SIGTERM` and keeps running, and one that
+  takes focus when launched in the background — both are what this section prevents.
+
 ## 0.6.1 - 2026-10-03
 
 ### Fixed

package/package.json

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

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

@@ -3,7 +3,7 @@
   "name": "fabric-agent-adapter",
   "displayName": "Fabric Agent Adapter",
   "description": "Create new Fabric-compatible agents, build them as always-alive local services with dashboards (fabric-service/0.1), and adapt existing projects to the Fabric Agent Contract through evidence-backed MCP, A2A, or local-runner provider bundles.",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "author": {
     "name": "PassionCode.ai",
     "url": "https://passioncode.ai/"

package/plugins/fabric-agent-adapter/skills/adapting-projects-to-fabric/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.
 metadata:
   author: PassionCode.ai
-  version: "0.6.1"
+  version: "0.6.3"
   contract-version: "0.1.0"
   contract-commit: "2ce392291c6668598d12cd38327e24696b5ca15c"
 ---

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

@@ -15,7 +15,7 @@ license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 compatibility: Python 3.9+ or Node.js 20+ for the kits; the probe needs Python 3.9+. launchd steps are macOS-only (Linux services use lifecycle manager none until a systemd adapter exists). Dashboard handoff optionally uses Fabric Dashboards MCP link/host_status/open; without it, report unresolved host capability. The contract checkout is optional.
 metadata:
   author: PassionCode.ai
-  version: "0.6.1"
+  version: "0.6.3"
   contract-version: "0.1.0"
   extension: "fabric-service/0.1"
   extension-commit: "2ce392291c6668598d12cd38327e24696b5ca15c"
@@ -101,8 +101,12 @@ are in [`scripts/fabric_interop.py`](scripts/fabric_interop.py) and
    digest and the process start time. *(A service ran on stale code after an edit and
    burned budget; nothing showed which build was answering.)*
 5. **State outside code.** Data and config in `~/Library/Application Support/<id>/`,
-   logs in `~/Library/Logs/<id>/`, cache in `~/Library/Caches/<id>/`; secrets in a 0600
-   file. Never inside the service's own code checkout or a release directory; a
+   logs in `~/Library/Logs/<id>/`, cache in `~/Library/Caches/<id>/`; the service's own
+   access token in a 0600 file it generates (principle 6). **Every provider credential the
+   service uses comes from Project Observatory, by name** — the plist starts the service
+   with `use_secret.py serve --consumer <label> <project> <NAME>[,<NAME>] -- <command>`, which
+   reads the vault only and records the consumer so a rotation names it; never a copy of a
+   key in a `.env`, a config file or the plist. Never inside the service's own code checkout or a release directory; a
    repository that versions the data itself is a store and is fine — declare
    `source.repository` so the probe can tell them apart. *(Deleting a checkout left a
    plist launchd retried every 10 s, and the data went with it.)*
@@ -176,7 +180,8 @@ The installer, not the service, owns the plist and the descriptor. Sequence:
 
 Code runs from an immutable release directory; an upgrade writes a new release,
 rewrites the plist and restarts. Read [the lifecycle reference](references/lifecycle.md)
-for the plist fields, the release layout, log rotation and the Linux case.
+for the plist fields, the release layout, log rotation, behaving under a host lifecycle broker
+and the Linux case.
 
 ## Step 5 — the dashboard and the events
 
@@ -253,7 +258,10 @@ things change and the kits implement each:
    example is [`scripts/sample-remote-service.mjs`](scripts/sample-remote-service.mjs): it runs
    with its own TLS or behind a platform router.
 2. **Secrets live on the platform:** the service token and the session key (32 bytes) are
-   platform secrets, never in the repository, a URL or an argument vector.
+   platform secrets, never in the repository, a URL or an argument vector. A provider key the
+   remote service needs is issued and kept in Project Observatory, pushed to the platform, and
+   the movement recorded with `vault.py moved --at <provider>`, so the platform's copy is
+   known rather than invisible.
 3. **Register it on the operator's computer** — the installer side, run there:
    `registerRemote({ id, name, origin, token })` / `register_remote(...)` writes the token file
    (0600) and the descriptor; pass the token from a file or stdin, never in argv. Public names

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

@@ -56,6 +56,27 @@ On `SIGTERM`: stop accepting new work, append a `service.stopping` event, drain
 in-flight work until `ExitTimeOut` minus a margin, persist what was interrupted so the
 next start resumes it, release the lock, exit 0.
 
+## Being managed by a host lifecycle broker
+
+A host may run a lifecycle broker: one always-on per-user service that agents ask to start,
+stop and restart products, instead of launching or killing them themselves. A product it manages
+has to survive being driven from outside:
+
+- **Quit reaches exit through both doors.** A broker asks the platform's own quit first — on
+  macOS `NSRunningApplication.terminate()`, the path Cmd+Q and the Dock take — and `SIGTERM` a few
+  seconds later. Handle both and exit inside the deadline (fabric-workspace LC-01). A desktop app
+  that answers `SIGTERM` by closing its window and staying alive is stopped late or not at all.
+- **A background launch stays in the background.** A broker opens the app non-activating
+  (`NSWorkspace.OpenConfiguration.activates = false`); do not call `app.focus()`, `show()` on a
+  focused window, or activate on `ready` when nobody asked for a window. Taking focus from the
+  person is the one side effect they always notice.
+- **Identity is the designated requirement.** A broker pins the app by team + bundle id, so an
+  update signed by the same team keeps working and anything else is refused (LC-05). Never ship an
+  ad-hoc or differently signed build to a machine that pins you.
+- **Starting is not ready.** Expose readiness the broker can probe without a person — the
+  well-known document for a service, a process-level answer for a plain app — and keep it honest
+  while the app is still starting.
+
 ## Linux
 
 Until a systemd adapter exists, declare `lifecycle.manager: "none"`. A `systemd --user`

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.6.1"
+  version: "0.6.3"
   contract-version: "0.1.0"
   contract-commit: "2ce392291c6668598d12cd38327e24696b5ca15c"
 ---
@@ -94,6 +94,13 @@ first commit:
 - an `AGENTS.md` that opens with the template's *Read first* block and closes with *After work*,
   and a `CLAUDE.md` whose first line is `@AGENTS.md`.
 
+**Every credential the agent uses comes from Project Observatory, by name**, from its first
+commit: the README's Configure section lists key NAMES; the agent finds them with
+`observatory_credentials` and runs with `use_secret.py run --vault-only` (a long-running
+service: `use_secret.py serve`), with `OBSERVATORY_VAULT_ONLY=1` in its environment. No `.env`
+of its own, no key file beside its data, no value in code, configuration or a commit. A
+workflow names the keys it needs in its checkpoint (`credentials`), never their values.
+
 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