@inetafrica/open-claudia 3.0.27 → 3.0.29

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## v3.0.29 — The owner actually gets the approval request
+
+- **The external-speaker guardrail no longer swallows approval requests.** When a non-owner talks to a bot and the guard holds the reply, the bot escalates to the owner with Approve/Deny buttons and tells the external "let me check with the owner." That escalation resolved the owner's channel through `relationship.ownerTarget()`, which read **only** `people.owners()`. On a bot seeded from legacy `auth.json` the people store is empty, so it returned no owner, escalation failed with "no reachable owner," and the owner got **nothing** — while the external was still told a follow-up was coming. (Seen live: `kazee-people` deferred to the owner in a Kazee Spaces thread and no approval ever arrived.)
+- **`ownerTarget()` now falls back to the configured-owner env identity** — the same operator-declared signal the guardrail already trusts *inbound* (`identity.isConfiguredOwnerChannel`: Telegram `TELEGRAM_CHAT_ID`, Kazee/Spaces `KAZEE_OWNER_USER_ID`). When no people-record handle exists it derives a deliverable target from env, preferring Telegram (native buttons, and the chat id is the send target) and otherwise resolving the owner's Kazee 1:1 DM via the adapter's idempotent `openDirectChat` (a Kazee send target is a chat-document id, not a user id). Only channels actually loaded on the bot are considered; `ownerTarget()` is now async.
+- **Fail-closed contract preserved.** If no configured owner channel is reachable the guard still blocks (returns no target) — the fix only *restores* the owner's approval prompt, it never widens what an external can do. Loopback's Spaces-approval binding gets the same fallback. No autonomy change; B2+ and Track A stay gated.
+- **Agent-space / OpenClaw:** no new deps, no new env, no schema change; Docker image builds identically (FROM the pre-baked `:base`). Existing pods pick this up on their next approved upgrade.
+
+## v3.0.28 — /upgrade stops crying wolf on a slow roll
+
+- **A client-side `/upgrade` timeout is no longer reported as a failure.** When the bot runs inside an AgentSpace pod, `/upgrade` calls the control plane, which triggers a fire-and-forget rollout and returns 202. If the pod is mid-roll its own in-flight request gets cut off, so the 15s HTTP wait would expire and the bot announced "Upgrade request failed … timeout" — a false negative that invited repeated re-runs (and a storm of redundant rollouts, seen as 11 ReplicaSets in 7 minutes). A timed-out request now surfaces as **pending** ("sent but the reply timed out — likely because I'm already restarting; give it a minute"), and the request timeout is raised 15s → 30s.
+- **Pairs with a control-plane probe fix (the actual root cause).** The pod's `/health` probes carried no `timeoutSeconds`, so k8s defaulted it to 1s; a cold-start event-loop stall past 1s flapped the liveness probe and SIGTERM'd the pod in a restart loop. That fix — explicit `timeoutSeconds: 5` on every probe and liveness `failureThreshold` 3 → 5 — ships in the agent-space control plane and reaches existing pods on their next reconcile (`/cluster sync`).
+- **Agent-space / OpenClaw:** no new deps, no new env, no schema change; Docker image builds identically (FROM the pre-baked `:base`). Existing pods pick this up on their next approved upgrade.
+
 ## v3.0.27 — Agency ledger, advisory "what's next", owner-guardrail capture, and a reboot that waits for the turn to end
 
 - **`/agenda` — one read-only work list across everything (Track B0).** A new aggregator normalises your persistent tasks, `spaces mine`, and connector inbox/notifications into a single list (source, title, status, due, staleness, blocked-on, last-touched). Pure visibility — it reads, it never acts. `/agency` is an alias.

package/core/enforcer.js

@@ -293,7 +293,7 @@ async function escalate({
   const approvals = require("./approvals");
   const relationship = require("./relationship");
   const audit = safeAudit();
-  const owner = relationship.ownerTarget();
+  const owner = await relationship.ownerTarget();
   if (!owner) {
     if (audit) audit.log("enforcer.escalate.failed", { reason: "no reachable owner", guardKind: kind, person: speaker && speaker.name });
     return { ok: false, escalated: false, reason: "no reachable owner to approve" };

package/core/handlers.js

@@ -624,7 +624,7 @@ async function requestAgentSpaceUpgrade() {
       res.on("end", () => resolve({ status: res.statusCode, body: data }));
     });
     req.on("error", (e) => resolve({ status: 0, body: String(e.message || e) }));
-    req.setTimeout(15000, () => { req.destroy(new Error("timeout")); });
+    req.setTimeout(30000, () => { req.destroy(new Error("timeout")); });
     req.end();
   });
 }
@@ -678,6 +678,14 @@ register({
           await send("Upgrade requested — AgentSpace will pull latest image and restart, see you in a minute.");
           return;
         }
+        // A client-side timeout is not a failure: the control plane triggers the
+        // rollout fire-and-forget, and a pod being rolled is exactly when its own
+        // in-flight request gets cut off. Framing it as "failed" invites a retry
+        // storm of redundant rollouts, so surface it as pending instead.
+        if (result && result.status === 0 && /timeout/i.test(result.body || "")) {
+          await send("Upgrade request sent but the reply timed out — likely because I'm already restarting. Give it a minute before re-running; I should come back on the new image.");
+          return;
+        }
         await send(`Upgrade request failed (status ${result?.status || "?"}). ${(result?.body || "").slice(0, 300)}`);
         return;
       } catch (e) {

package/core/loopback.js

@@ -533,7 +533,7 @@ async function handleJson(req, res, url, kind) {
       let approverChannel = "";
       const spacesOrigin = adapter.type === "spaces";
       if (spacesOrigin) {
-        const owner = require("./relationship").ownerTarget();
+        const owner = await require("./relationship").ownerTarget();
         const oa = owner
           ? (registry.findAdapter(owner.adapter) || registry.getAdapters().find((a) => a.type === owner.adapter))
           : null;

package/core/relationship.js

@@ -108,27 +108,63 @@ function isCurrentSpeakerGuarded() {
   return guardActive(currentSpeaker());
 }
 
+// Fallback owner target derived from the operator-declared .env identity — the
+// SAME trusted signal identity.isConfiguredOwnerChannel already accepts INBOUND.
+// This closes the resolution asymmetry that silently swallowed approval
+// requests: a bot seeded from legacy auth has an empty people store, so the
+// people-record path below finds no owner handle and escalation failed with
+// "no reachable owner" even though the owner was reachable on a configured
+// channel. Prefers Telegram (the owner's native-button channel, and the send
+// target IS the chat id) and falls back to Kazee, whose send target is a
+// chat-document id — so the owner's user id is resolved to a 1:1 DM via the
+// adapter's idempotent openDirectChat. Only channels actually loaded on THIS
+// bot are considered. person is null (no record), which downstream tolerates
+// (enforcer.ownerFirstName → "the owner"). Returns null when no configured owner
+// channel is reachable, preserving the fail-closed contract.
+async function configuredOwnerTarget() {
+  let cfg, registry;
+  try { cfg = require("./config"); registry = require("./adapter-registry"); }
+  catch (e) { return null; }
+  const adapters = registry.getAdapters();
+  const loaded = (type) => adapters.find((a) => a.type === type) || null;
+
+  const tgChatId = (cfg.CHAT_IDS || [])[0];
+  if (tgChatId && loaded("telegram")) {
+    return { adapter: "telegram", channelId: String(tgChatId), person: null };
+  }
+
+  const kzOwner = cfg.config && cfg.config.KAZEE_OWNER_USER_ID;
+  const kazee = loaded("kazee");
+  if (kzOwner && kazee && typeof kazee.openDirectChat === "function") {
+    try {
+      const chatId = await kazee.openDirectChat(String(kzOwner));
+      if (chatId) return { adapter: "kazee", channelId: String(chatId), person: null };
+    } catch (e) { /* outreach unavailable → fall through to no owner */ }
+  }
+  return null;
+}
+
 // The owner's approval channel — where escalation buttons are posted. Resolves
-// the first owner's primary (or first) handle. null if there is no reachable
-// owner handle, in which case escalation cannot proceed and the caller must
-// fail closed (block).
-function ownerTarget() {
+// the first owner's primary (or first) people-record handle, then falls back to
+// the configured-owner env identity. null only if there is no reachable owner
+// channel at all, in which case escalation cannot proceed and the caller must
+// fail closed (block). Async because the Kazee fallback resolves a DM over the
+// network.
+async function ownerTarget() {
   try {
     const people = require("./people");
     const owner = (people.owners() || [])[0];
-    if (!owner) return null;
-    const handles = owner.handles || [];
-    if (!handles.length) return null;
-    const primary = owner.primaryChannel
-      ? handles.find((h) => h.adapter === owner.primaryChannel.adapter &&
-          String(h.channelId) === String(owner.primaryChannel.channelId))
-      : null;
-    const handle = primary || handles[0];
-    if (!handle) return null;
-    return { adapter: handle.adapter, channelId: String(handle.channelId), person: owner };
-  } catch (e) {
-    return null;
-  }
+    if (owner) {
+      const handles = owner.handles || [];
+      const primary = owner.primaryChannel
+        ? handles.find((h) => h.adapter === owner.primaryChannel.adapter &&
+            String(h.channelId) === String(owner.primaryChannel.channelId))
+        : null;
+      const handle = primary || handles[0];
+      if (handle) return { adapter: handle.adapter, channelId: String(handle.channelId), person: owner };
+    }
+  } catch (e) { /* fall through to the env fallback */ }
+  return configuredOwnerTarget();
 }
 
-module.exports = { speakerFor, currentSpeaker, guardActive, isCurrentSpeakerGuarded, ownerTarget };
+module.exports = { speakerFor, currentSpeaker, guardActive, isCurrentSpeakerGuarded, ownerTarget, configuredOwnerTarget };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@inetafrica/open-claudia",
-  "version": "3.0.27",
+  "version": "3.0.29",
   "description": "An always-on, provider-agnostic coding-agent harness for Claude Code and OpenAI Codex via chat",
   "main": "bot.js",
   "bin": {

package/test-enforcer.js

@@ -19,6 +19,12 @@ process.env.ENTITIES_DIR = path.join(tmp, "entities");
 process.env.PEOPLE_FILE = path.join(tmp, "people.json");
 process.env.APPROVALS_DIR = path.join(tmp, "approvals");
 fs.mkdirSync(process.env.OPEN_CLAUDIA_CONFIG_DIR, { recursive: true });
+// Configured-owner env identity for the ownerTarget fallback test below. No
+// TELEGRAM_CHAT_ID → the telegram branch is skipped and the fallback resolves
+// the owner's Kazee DM (the real Kazee-only-bot scenario). Captured at config
+// load, so it MUST be set before any core module (which pulls in config) loads.
+delete process.env.TELEGRAM_CHAT_ID;
+process.env.KAZEE_OWNER_USER_ID = "owner-kz-999";
 
 // ── stub the model (destructured at enforcer load) and the transport (lazily
 //    required in adapterFor) BEFORE requiring the enforcer. ──────────────────
@@ -47,10 +53,22 @@ const fakeAdapter = {
   type: "telegram", id: "telegram",
   send: async (channelId, text, opts) => { sends.push({ channelId: String(channelId), text, opts: opts || {} }); return { message_id: sends.length }; },
 };
+// A loaded Kazee adapter whose openDirectChat resolves the owner's user id to a
+// 1:1 DM chat-document id — the send target the ownerTarget env fallback needs.
+let kazeeDmRequestedFor = null;
+const fakeKazee = {
+  type: "kazee", id: "kazee",
+  send: async (channelId, text, opts) => { sends.push({ channelId: String(channelId), text, opts: opts || {}, adapter: "kazee" }); return { message_id: sends.length }; },
+  openDirectChat: async (userId) => { kazeeDmRequestedFor = String(userId); return "dm-chat-777"; },
+};
+const registryAdapters = [fakeAdapter, fakeKazee];
 const registryPath = require.resolve("./core/adapter-registry");
 require.cache[registryPath] = {
   id: registryPath, filename: registryPath, loaded: true,
-  exports: { findAdapter: (id) => (id === "telegram" ? fakeAdapter : null), getAdapters: () => [fakeAdapter] },
+  exports: {
+    findAdapter: (id) => registryAdapters.find((a) => a.id === id) || null,
+    getAdapters: () => registryAdapters.slice(),
+  },
 };
 
 const people = require("./core/people");
@@ -209,5 +227,19 @@ const extSpeaker = relationship.speakerFor("telegram", CH_EXT);
   assert.ok(!auditRaw.includes("hunter2"), "blocked reply content never enters the audit log");
   assert.ok(!auditRaw.includes("May only discuss invoicing status"), "owner-authored mandate never enters the audit log");
 
+  // ── ownerTarget env fallback: a bot with an empty people store still reaches
+  // the owner via the configured-owner env identity. This is the fix for the
+  // silently-swallowed approval request — the people-record path finds no owner
+  // handle, so escalation used to fail "no reachable owner" even though the
+  // owner was reachable on a configured channel. Telegram is skipped (no
+  // TELEGRAM_CHAT_ID), so it resolves the owner's Kazee 1:1 DM. ──
+  kazeeDmRequestedFor = null;
+  const fbTarget = await relationship.configuredOwnerTarget();
+  assert.ok(fbTarget, "configuredOwnerTarget resolves an owner channel from env");
+  assert.strictEqual(fbTarget.adapter, "kazee", "falls back to the configured Kazee owner");
+  assert.strictEqual(fbTarget.channelId, "dm-chat-777", "resolves the owner's 1:1 DM chat id, not the raw user id");
+  assert.strictEqual(fbTarget.person, null, "env-derived owner target carries no people record");
+  assert.strictEqual(kazeeDmRequestedFor, "owner-kz-999", "the DM is opened for the configured owner user id");
+
   console.log("enforcer OK");
 })().catch((e) => { console.error(e); process.exit(1); });

package/test-provider-language.js

@@ -32,18 +32,19 @@ assert.doesNotMatch(setup, /Your Claude Code bot is connected|Description=Claude
 
 const pkg = JSON.parse(read("package.json"));
 assert.match(pkg.description, /provider-agnostic coding-agent harness/i);
-// 3.0.27 approved by Sumeet 2026-07-15 ("work through till it's done and push it
-// out"): the non-gated architecture batch. (1) X0 — always-on prompt-budget
-// instrumentation: measure the fixed floor vs per-turn recall payload, telemetry
-// only (no prompt change, no trim). (2) B0 — /agenda read-only work ledger
-// (tasks + Spaces + notifications). (3) B1 — /next advisory deliberation that
-// proposes a pick and acts on nothing. (4) C0/C1 — owner-guardrail capture:
-// "from now on / never / stop" statements become always-loaded lessons (asked or
-// auto-captured with announce + one-tap undo), owner-only, never from externals.
-// (5) Turn-aware reboot: the Telegram 10-min poll-wedge backstop defers its
-// self-exit while any turn is running/queued so a restart never interrupts
-// in-flight work. B2+ autonomy and Track A stay gated.
-assert.strictEqual(pkg.version, "3.0.27", "release version must remain unchanged without explicit approval");
+// 3.0.29 approved by Sumeet 2026-07-15 ("Yes fix"): closes an owner-resolution
+// asymmetry in the external-speaker guardrail that silently swallowed approval
+// requests. Inbound, identity.isConfiguredOwnerChannel recognises the owner via
+// the operator-declared .env identity (telegram CHAT_IDS, kazee/spaces
+// KAZEE_OWNER_USER_ID). Outbound, relationship.ownerTarget() read ONLY
+// people.owners() — empty on bots seeded from legacy auth — so escalation failed
+// "no reachable owner" and the external was told the bot would follow up while
+// the owner got NOTHING. ownerTarget() now falls back to the SAME configured
+// env identity when no people handle exists, resolving the owner's Kazee 1:1 DM
+// (via adapter.openDirectChat) or Telegram chat. Now async. No autonomy change:
+// it only restores the owner's approval prompt; the guard still fails closed
+// (blocks) when no owner channel is reachable. B2+ and Track A stay gated.
+assert.strictEqual(pkg.version, "3.0.29", "release version must remain unchanged without explicit approval");
 for (const keyword of ["claude", "codex", "coding-agent", "provider-agnostic"]) {
   assert.ok(pkg.keywords.includes(keyword), `package keyword missing: ${keyword}`);
 }

package/test-relationship.js

@@ -113,34 +113,39 @@ assert.strictEqual(inChat(CH_EXT, () => relationship.currentSpeaker().name), "Ze
 assert.strictEqual(relationship.currentSpeaker(), null, "no chat context → null speaker");
 assert.strictEqual(relationship.isCurrentSpeakerGuarded(), false, "no context → not guarded");
 
-// ── ownerTarget resolves the owner's PRIMARY handle for escalation buttons ────
-const target = relationship.ownerTarget();
-assert.ok(target, "ownerTarget resolves an owner handle");
-assert.strictEqual(target.adapter, "telegram", "ownerTarget adapter");
-assert.strictEqual(target.channelId, CH_OWNER_ALT, "ownerTarget picks the primary channel, not the first");
-
-// ── split-brain fix: an owner channel unified via /link (identities.json) but
-// NEVER mirrored onto the people record must STILL resolve to the owner. This
-// is the production bug — a Kazee handle /link'd to the owner's canonical id was
-// invisible to people.findByHandle, so the guardrail falsely treated the owner
-// as an external speaker. Ownership now flows through canonical identity. ──
-const identity = require("./core/identity");
-const ownerCanon = identity.ownerCanonical();
-assert.ok(ownerCanon, "owner has a canonical id");
-identity.setIdentityMapping("kazee", "owner-linked-kazee", ownerCanon);
-assert.strictEqual(people.findByHandle("kazee", "owner-linked-kazee"), null,
-  "precondition: the /link'd kazee channel is absent from the people record");
-const linkedSp = relationship.speakerFor("kazee", "owner-linked-kazee");
-assert.strictEqual(linkedSp.isOwner, true, "owner-canonical channel → owner even without a people handle");
-assert.strictEqual(linkedSp.relationship, "owner", "owner-canonical channel relationship");
-assert.strictEqual(linkedSp.mandate, "", "owner never carries a mandate");
-assert.strictEqual(relationship.guardActive(linkedSp), false, "owner-canonical channel is never guarded");
-
-// ── and the fix must NOT widen: an unmapped channel on the same transport that
-// does not resolve to the owner canonical stays external + guarded. ──
-const strayKazee = relationship.speakerFor("kazee", "some-stranger-999");
-assert.strictEqual(strayKazee.isOwner, false, "unmapped kazee channel is not owner");
-assert.strictEqual(strayKazee.relationship, "external", "unmapped kazee channel → external");
-assert.strictEqual(relationship.guardActive(strayKazee), true, "unmapped kazee channel stays guarded");
-
-console.log("relationship OK");
+// ownerTarget is async (its env fallback may resolve a Kazee DM over the
+// network); the owner here has a people-record handle, so it resolves via the
+// synchronous people path — the fallback is exercised in test-enforcer.
+(async () => {
+  // ── ownerTarget resolves the owner's PRIMARY handle for escalation buttons ──
+  const target = await relationship.ownerTarget();
+  assert.ok(target, "ownerTarget resolves an owner handle");
+  assert.strictEqual(target.adapter, "telegram", "ownerTarget adapter");
+  assert.strictEqual(target.channelId, CH_OWNER_ALT, "ownerTarget picks the primary channel, not the first");
+
+  // ── split-brain fix: an owner channel unified via /link (identities.json) but
+  // NEVER mirrored onto the people record must STILL resolve to the owner. This
+  // is the production bug — a Kazee handle /link'd to the owner's canonical id was
+  // invisible to people.findByHandle, so the guardrail falsely treated the owner
+  // as an external speaker. Ownership now flows through canonical identity. ──
+  const identity = require("./core/identity");
+  const ownerCanon = identity.ownerCanonical();
+  assert.ok(ownerCanon, "owner has a canonical id");
+  identity.setIdentityMapping("kazee", "owner-linked-kazee", ownerCanon);
+  assert.strictEqual(people.findByHandle("kazee", "owner-linked-kazee"), null,
+    "precondition: the /link'd kazee channel is absent from the people record");
+  const linkedSp = relationship.speakerFor("kazee", "owner-linked-kazee");
+  assert.strictEqual(linkedSp.isOwner, true, "owner-canonical channel → owner even without a people handle");
+  assert.strictEqual(linkedSp.relationship, "owner", "owner-canonical channel relationship");
+  assert.strictEqual(linkedSp.mandate, "", "owner never carries a mandate");
+  assert.strictEqual(relationship.guardActive(linkedSp), false, "owner-canonical channel is never guarded");
+
+  // ── and the fix must NOT widen: an unmapped channel on the same transport that
+  // does not resolve to the owner canonical stays external + guarded. ──
+  const strayKazee = relationship.speakerFor("kazee", "some-stranger-999");
+  assert.strictEqual(strayKazee.isOwner, false, "unmapped kazee channel is not owner");
+  assert.strictEqual(strayKazee.relationship, "external", "unmapped kazee channel → external");
+  assert.strictEqual(relationship.guardActive(strayKazee), true, "unmapped kazee channel stays guarded");
+
+  console.log("relationship OK");
+})().catch((e) => { console.error(e); process.exit(1); });