@passioncode-ai/passioncode 0.2.15 → 0.2.17

package/payload/plugins/observatory-log/hooks/session-start.sh

@@ -88,7 +88,8 @@ if [ -f "$root/tools/maintain.py" ]; then
 else
   # The bridge for engines from before 0.17.0, which carry no updater of their own:
   # once a day, check; when a newer stable release exists and the person has not turned
-  # automatic updates off (`updates.auto` false), install it with `full update --apply`.
+  # automatic updates off (the `auto-update` file says `off`, or `updates.auto` is false),
+  # install it with `full update --apply`.
   po=""
   [ -n "$venv" ] && [ -x "$venv/bin/project-observatory" ] && po="$venv/bin/project-observatory"
   [ -n "$po" ] || po="$(command -v project-observatory 2>/dev/null)"
@@ -96,10 +97,15 @@ else
     detach "$stamps/update-bridge.log" /bin/bash -c '
       po="$1"; py="$2"
       home="${OBSERVATORY_FULL_HOME:-${OBSERVATORY_HOME:-$HOME/.local/share/project-observatory-full}}"
-      off="$("$py" -c "import json,sys
-try: d=json.load(open(sys.argv[1]))
+      # The switch (LC-16): the file `auto-update` in the home, where only `off` is off;
+      # without one, `updates.auto: false` in settings.json, as those releases wrote it.
+      off="$("$py" -c "import json,os,sys
+f=os.path.join(sys.argv[1], \"auto-update\")
+if os.path.isfile(f) and not os.path.islink(f):
+    print(1 if open(f, errors=\"replace\").read(64).strip().lower() == \"off\" else 0); sys.exit()
+try: d=json.load(open(os.path.join(sys.argv[1], \"config\", \"settings.json\")))
 except Exception: d={}
-print(1 if (d.get(\"updates\") or {}).get(\"auto\") is False else 0)" "$home/config/settings.json" 2>/dev/null)"
+print(1 if (d.get(\"updates\") or {}).get(\"auto\") is False else 0)" "$home" 2>/dev/null)"
       [ "$off" = "1" ] && { echo "$(date -u +%FT%TZ) automatic updates are off"; exit 0; }
       "$po" full update --check >/dev/null 2>&1; rc=$?
       echo "$(date -u +%FT%TZ) check exit $rc"

package/payload/plugins/observatory-log/skills/explaining-changes/SKILL.md

@@ -15,7 +15,7 @@ description: >-
   decision with different evidence.
 license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 metadata:
-  version: "0.18.0"
+  version: "0.26.0"
 compatibility: >-
   Requires an initialized full Project Observatory installation to persist
   records. Uses its MCP server when available in the current host; the bundled
@@ -48,14 +48,25 @@ and nothing in the ledger can tell it from a measured one.
 
 ## Recording it
 
-The Observatory's Stop hook has already stored the facts as a `proposed` record
-and printed its id. Correct that record rather than creating a second one:
+The Observatory's Stop hook has already stored the facts as a `proposed` record.
+Its id arrives once, as context with the next prompt. There is no ask when, within
+2 seconds of the record being written, the hook finds in the last 4 MB of this
+session's transcript an Edit, Write, MultiEdit, NotebookEdit or Bash write (`>`,
+`>>`, `tee`, `sed -i`) that targeted a `decisions.md` or an `adr/` `.md`,
+`.markdown` or `.txt` file (outside vendored trees) with the entry's own
+heading (unique in the register) or, with no heading, most of its added lines, or that wrote a `decision:` /
+`stage:` line into `.task-pipeline/run.md`. Failed calls, subagent calls and
+Bash commands over 65,536 characters are not counted. The record then links
+that file, and keeps the link while the entry's exact heading line occurs once
+and the file is unchanged, or has only a new entry appended after it; any other
+edit to the file asks again.
+Correct that record rather than creating a second one:
 
 ```
 observatory_record(
   owner="agent:claude-code",
-  memory_id="<the id the hook printed>",
-  expected_revision=<the revision it printed>,
+  memory_id="<the id the hook gave>",
+  expected_revision=<the revision it gave>,
   statement="<the same claim, unchanged>",
   why="<one or two sentences>"
 )

package/payload/plugins/observatory-log/skills/handling-secrets/SKILL.md

@@ -10,7 +10,7 @@ description: >-
   provider permissions or choosing a project's authentication architecture.
 license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 metadata:
-  version: "0.18.0"
+  version: "0.26.0"
 compatibility: >-
   Requires an initialized full Project Observatory installation, Python 3.11+
   and local shell access on macOS or Linux. Provider operations additionally
@@ -30,7 +30,7 @@ names. Never ask the user to paste a credential into the conversation.
 2. Select the user's initialized `OBSERVATORY_HOME`. Run
    `project-observatory full doctor`. A missing workspace
    needs the documented onboarding before secret operations.
-3. Run `"$OBSERVATORY_PYTHON" "$OBSERVATORY_ROOT/tools/skill_check.py" handling-secrets 0.18.0`
+3. Run `"$OBSERVATORY_PYTHON" "$OBSERVATORY_ROOT/tools/skill_check.py" handling-secrets 0.26.0`
    (`full agent install` records that interpreter; the stock macOS `python3` is too old).
    If stale, read the installed skill once and follow its compatible commands.
    Do not turn an unavailable version check into a retry loop.
@@ -53,8 +53,8 @@ for it. A name or note shaped like a credential is refused, never stored.
 | List slots | `vault.py list PROJECT ENV` |
 | Run a command using a slot | `use_secret.py run [--env ENV] [--vault-only] PROJECT NAME -- COMMAND ARGUMENTS` (flags before PROJECT) |
 | Receive a value from another local command | `use_secret.py pipe NAME -- COMMAND ARGUMENTS` |
-| Bind a slot to the one MCP server allowed to receive it as a header (the operator, once) | `vault.py bind PROJECT ENV NAME --header-for https://HOST[:PORT]` (a bare host means https); `--clear` removes it; both are journalled |
-| Give an HTTP MCP server its bearer through Claude Code's `headersHelper` | `use_secret.py header [--env ENV] [--name Authorization] [--scheme Bearer] PROJECT NAME`, written into the server's `headersHelper` entry, never run by hand |
+| Bind a slot to the one MCP server allowed to receive it as a header (the operator, once) | `vault.py bind PROJECT ENV NAME --header-for https://HOST[:PORT]` (a bare host means https), or `http://127.0.0.1:PORT` / `http://[::1]:PORT` for a loopback server (`localhost` is refused); `--clear` removes it; both are journalled |
+| Give an HTTP MCP server its bearer through the client's header helper | `use_secret.py header [--env ENV] [--name Authorization] [--scheme Bearer] PROJECT NAME`, written into Claude Code's `headersHelper` entry; for Codex's `http_headers_helper` add `--server-url URL`, since Codex exports no server URL. Never run by hand |
 | Populate a project's ignored environment file | `vault.py inject PROJECT ENV DIRECTORY` |
 | Record an exposure | `vault.py leak PROJECT ENV NAME --where "location and evidence, no value"` |
 | Replace a stored value | `vault.py rotate PROJECT ENV NAME`, replacement on stdin |
@@ -80,14 +80,16 @@ not a sandbox: a child process can encode a value, transmit it, or write it to
 another file. Only run the command authorized by the task. Do not claim this
 filter prevents every leak.
 
-**The header door prints a value, so it serves only Claude Code.** `use_secret.py
+**The header door prints a value, so it serves only a client's header helper.** `use_secret.py
 header` writes one JSON object (`{"Authorization": "Bearer …"}`) for a
 `headersHelper`, which Claude Code merges into the MCP request rather than the
 conversation. It reads the vault only (never an env file or the environment), and
-refuses unless stdout is a program, `CLAUDE_CODE_MCP_SERVER_URL` names the scheme,
-host and port the slot is bound to, and the value has no control character. Never
-run it yourself, pipe it, or set `CLAUDE_CODE_MCP_SERVER_URL` to make it answer:
-that prints the value into your transcript. Each call is audited. Binding is the
+refuses unless stdout is a program, `CLAUDE_CODE_MCP_SERVER_URL` (or `--server-url`,
+for a client that exports none) names the scheme, host and port the slot is bound to,
+and the value has no control character; two URLs that disagree are refused
+(`url-conflict`). Never run it yourself, pipe it, or set `CLAUDE_CODE_MCP_SERVER_URL` or
+`--server-url` to make it answer: that prints the value into your transcript. Each call
+is audited, with the caller it claimed. Binding is the
 operator's decision; ask for it, do not run `bind` to make a call succeed.
 
 **Stdin carries one thing.** Never pipe a secret into `python3 -`, `node -` or
@@ -126,12 +128,77 @@ exposure and record it with `vault.py leak`. The design is
 
 ## Provider integrations
 
-Cloudflare and OpenRouter have separate tools, `cloudflare.py` and
-`openrouter.py`. Check their installed `--help` and non-secret inventory first.
+**A provider's MCP tool can be the leak.** Some tools return a credential in their
+answer by design, whatever you asked them for: DigitalOcean's `db-cluster-list`,
+`db-cluster-get`, `db-cluster-*-user`, `docr-docker-credentials`, `doks-get-kubeconfig`,
+`spaces-key-create`. The transcript keeps a tool result whole; it cannot be redacted
+afterwards: a `db-cluster-list` call asked for names can return every cluster's
+passwords. Do not call such a tool; get names from the provider CLI with an
+explicit `--format`, and credentials through the door below. Record any sighting with
+`vault.py leak` and rotate.
+
+DigitalOcean managed databases go through `digitalocean.py` in the operator's `doctl`
+context. `db list` and `db consumers CLUSTER` print metadata only; consumer discovery covers
+App Platform bindings, not every possible consumer. `db credential CLUSTER USER --db NAME
+--to vault:PROJECT/ENV/NAME` puts the connection URL in the vault on stdin.
+
+DigitalOcean rotation verifies every selected `--spec-env APP:KEY` literal before any reset.
+Its name is not evidence: a plain value must equal the selected database user's current
+provider password, or be a database URL with that password, user, engine and the provider's
+connection host/port. A `${…}` binding is never rewritten, at any level; `--db` must be one of
+the cluster's databases, and `db credential` checks `--db` the same way before it reads a
+password (a cluster the provider lists no databases for, and redis/valkey, refuse `--db` with
+their own reason). Opaque encrypted values and unverified pool endpoints are refused;
+migrate those consumers to App Platform database bindings before rotation. No command in
+this flow prints the current password. Only the named consumers are moved, with downtime
+between reset and ACTIVE; ACTIVE is not application health verification.
+
+The door writes an owner-only receipt under `store/digitalocean-rotations/` before reset,
+initially `reset: unknown`. A lost or malformed response, timeout or nonzero CLI result can
+follow a committed reset: exit 5 means **unknown**, not “nothing changed”. Never repeat
+`db rotate` to recover it. Use `db credential` to deliver the current value into the selected
+vault slot, then reconcile each consumer without another reset. Exit 1 is a refusal before
+reset; after an attempt, 2 means deployment unconfirmed, 3 vault delivery failed, 4 an app
+update/redeploy or temporary spec cleanup failed, and 6 receipt update failed. The largest
+code wins. Independent consumers continue after a confirmed reset despite another consumer's
+failure. Provider/vault error bodies are withheld. A crash or failed final receipt write
+leaves the earlier uncertain receipt; there is no automatic reconciliation, retry or claim
+of a transaction across provider and vault. A failed temporary-file cleanup may leave its
+owner-only spec file and is reported for local recovery.
+
+Reset, app updates and redeploys each make one attempt; only read calls retry.
+A lost/nonzero mutation response leaves that consumer `unknown`, even if the provider
+already applied it. The receipt distinguishes this from `not_started` for a local
+pre-call failure. Read current spec and deployment state before any retry; a blind
+redeploy is not recovery for a literal. Independent peers still continue. Deployment
+confirmation accepts a validated phase equal to `ACTIVE`, never a suffix or arbitrary
+provider text; malformed metadata remains unconfirmed and its body is not printed.
+
+
+Cloudflare, OpenRouter and Heroku have separate tools, `cloudflare.py`,
+`openrouter.py` and `heroku.py`. Check their installed `--help` and non-secret inventory first.
+A Heroku credential is `heroku.py issue --preset read|deploy|identity --vault
+<project>/<env>/<NAME> [--team <team>] [--app <app>]`: an OAuth authorization with that
+scope only, proved and delivered on stdin. Heroku cannot narrow one to a team or an app,
+so prefer `read` and name the app. Team and account membership (`heroku.py member`,
+`cloudflare.py member`) is a printed plan until `--apply`; apply only a change the task asked for.
 They require an explicitly configured integration and the user's own admin or
 provisioning credential. They do not make a new user inherit the author's
 accounts, budgets or tokens. Limit issuance and revocation to the task's scope.
 
+A project's own OpenRouter keys come from its spend policy: `openrouter.py
+issue-for-policy --policy FILE [--dry-run]` keeps their ceilings together within
+the project limit and exits 1 with `OVER LIMIT by $X now ($A against the $L
+limit); it ends after: …` when they are not. `rotate` is the one window past the
+limit: both keys are live while it runs, and until the J-3 change a rotate that
+fails can leave the successor `NAME-next` untracked or the predecessor uncounted —
+delete at the provider the one the slot does not hold, then run
+`issue-for-policy`. A pending row with no hash on an account past the listing is
+cleared with `revoke NAME --forget-pending --reason "…"` once its key is gone. The door must
+record the reason as a pre-action attestation before clearing the row; an
+unwritable journal refuses the change. This is an operator assertion, not
+provider verification. A separate completion event follows the ledger write.
+
 A project that must edit DNS in one zone (a custom domain, a CNAME to its host)
 gets `cloudflare.py issue --preset dns-edit --zone <zone> --vault <project>/<env>/<NAME>`:
 Zone Read and DNS Write on that zone only, verified against its records and
@@ -171,8 +238,11 @@ gets `cloudflare.py issue --preset email-send --account <slug> --vault
 group exists at account level only), verified by listing its suppressions.
 Adding an Email Routing rule in one zone — one address to a Worker — is
 `--preset email-routing --zone <zone>`, and deploying that Worker with its KV
-namespace is `--preset workers-edit --account <slug>`. Each is its own token in
-its own slot. When a preset's groups are unknown, `cloudflare.py groups
+namespace is `--preset workers-edit --account <slug>`; putting a Worker in front of
+a hostname (`example.com/*`) is the zone right `--preset workers-routes --zone <zone>`;
+sending one hostname to another at the edge (a Single Redirect, `www.` to the apex) is
+the zone right `--preset redirect-rules --zone <zone>`.
+Each is its own token in its own slot. When a preset's groups are unknown, `cloudflare.py groups
 --account <slug> --match "<words>"` lists the catalogue's names and levels,
 read-only and without ids.
 

package/payload/plugins/observatory-log/skills/tracking-resources/SKILL.md

@@ -15,7 +15,7 @@ description: >-
   the repository.
 license: AGPL-3.0-only OR LicenseRef-PassionCode-Commercial
 metadata:
-  version: "0.18.0"
+  version: "0.26.0"
 compatibility: >-
   Requires a full Project Observatory installation with organizations.json
   configured; the observatory MCP server or its local CLI. Creating the resource

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.15",
+  "version": "0.2.17",
   "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",