@soleur/opencode 3.354.14 → 3.354.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@soleur/opencode",
-  "version": "3.354.14",
+  "version": "3.354.16",
   "description": "Soleur AI organization plugin for OpenCode",
   "type": "module",
   "bin": {

package/skills/postmerge/references/deploy-status-debugging.md

@@ -57,6 +57,7 @@ The `soleur:ship` Phase 5.5 "Deploy Pipeline Fix Drift Gate" surfaces this contr
 | `canary_inngest_link_inspect_failed` | 1 | The Inngest link canary's `docker inspect` check failed: the canary's env was not exactly one https `INNGEST_BASE_URL` plus one pinned `NODE_EXTRA_CA_CERTS` (or the inspect call itself failed). The previous container keeps serving | Read the host's Better Stack `INNGEST_LINK: class=canary_failed level=error check=inspect cause=<token> url_lines= ...` row; decode per cause in `canary-probe-set.md` (Failure reads). No SSH |
 | `canary_inngest_link_failed` | 1 | An in-container Inngest link canary check failed (health, events, send, registry or the negative control). The previous container keeps serving | Same row, `check=<name> cause=<token>`; see `canary-probe-set.md`. No SSH |
 | `inngest_env_scrub_failed` | 1 | A flag-on deploy could not scrub `INNGEST_BASE_URL` / `NODE_EXTRA_CA_CERTS` from its env-file; aborted before any container started, the previous container keeps serving | Read `INNGEST_LINK: class=env_scrub_failed level=error stage=<read\|write\|recount>` and the per-stage action in `inngest-server.md` (Resolver events). `action=off` is always available |
+| `inngest_link_selfgate_failed` | 1 | The host-side Inngest link self-gate failed (three `curl --cacert <candidate>` attempts, no 200 with a verified TLS handshake): the CA was not installed and the previous container keeps serving. The `reason` is this constant (`INNGEST_LINK_REASON` is assigned only from fixed literals; `write_state` splices it as-is, no runtime enum check). The stage is carried as the closed-enum key `inngest_link_selfgate_phase` (same token as `phase=`; checked against its seven-token enum, `invalid` otherwise; absent when the gate did not fail) in two places only: the release run log's `jq .` dump of the state body on a non-zero terminal exit, and the deploy-status hook (the Call Pattern above) while no other deploy has run on that host. web-2's whole status, key included, is under `.peers["<web-2 ip>"]` in web-1's body when the last deploy fanned out (see "Response fields: `.peers`" below), and only once web-2 runs the new `ci-deploy.sh`. The flip run log prints only the reason, and a failed flip's automatic revert redeploy normally rewrites the state on both hosts about two minutes later (it is best-effort, so the key may survive), so for a flip failure the Better Stack event (`rc`, `http`, `attempts`, `tcp`, `tls`, `verify`) is the only record | Before any re-flip read `INNGEST_LINK: class=selfgate_failed level=error rc= http= attempts= phase= tcp= tls= verify=` with `--grep 'class=selfgate_failed'` (widen `--since` to cover the run: the default `1h` can miss it; read the failing row's own `dt` and host) and decode `phase` per `inngest-server.md` ("Reading `selfgate_failed`"). No row for the window is not a pass: widen the window once; for a failed flip an empty read means STOP and ask the owner for the shipper check (the state key is normally erased by the revert, so do not read it instead); a state-key read is for a failed release run only. Do not re-flip on the run-log reason alone, and every flip needs the owner's per-command go. `phase=request` means only TLS verified and no HTTP response: check the terminator and its upstream, not the certificate. No SSH |
 | `canary_failed` | 1 | Canary health-check failed 10x | Roll back; inspect canary container logs |
 | `production_start_failed` | 1 | Production container didn't start post-swap | Check docker state; consider manual rollback |
 | `plugin_seed_mount_unsafe` | 1 | The plugin-mount seed REFUSED to run: `PLUGIN_MOUNT_DIR` was not non-empty/absolute/under `/mnt/data/` ending `/plugins/soleur`. The seed's container-side `find -delete` runs as root on the bind source, so a wrong-path env value would be a recursive delete on an arbitrary host path — this reason means the guard caught that, not that the copy failed. Emits the stderr/journald marker `PLUGIN_SEED_MOUNT_UNSAFE` | Check what set `PLUGIN_MOUNT_DIR` (webhook.service env, `/etc/default/webhook-deploy`, an infra-config delivery) — the deploy never attempted the seed, so nothing was deleted. The correct value is `/mnt/data/plugins/soleur` |