@rubytech/create-sitedesk-code 0.1.607 → 0.1.609

package/payload/platform/lib/telegram-store-read/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../test/tmpdir-setup.ts"],
     environment: "node",
     globals: false,
     include: ["src/__tests__/**/*.test.ts"],

package/payload/platform/plugins/admin/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     environment: "node",
     include: ["src/**/__tests__/**/*.test.ts"],
     testTimeout: 10_000,

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what SiteDesk ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:be3aaf5fcd9b40508ba0a1d0e6b788422dc491432dec1eab64cbe8ce091139e6
+content-hash: sha256:10a85aebfe311aca7adc6d999fd75ed0b233f35c57f4bf26006e4c76cb170ecc
 brand: sitedesk-code
 product-name: SiteDesk
 ---
@@ -2961,6 +2961,41 @@ Telegram profile name and will tell you plainly that it cannot put a name to the
 Ask SiteDesk to save the Telegram ID against the contact. It is one change to one contact, and
 it takes effect on the very next message.
 
+## Correcting what a public agent told a visitor
+
+When one of your public bots tells a visitor something wrong, the fix is to instruct the agent that
+is talking to them, not to message the visitor yourself.
+
+The reason is worth understanding, because the obvious approach quietly fails. Every conversation is
+its own separate agent with its own memory. If you send the visitor a correction from your chat, they
+receive it, but the agent that has been talking to them never sees it: it is a different
+conversation, and nothing carries a message from yours into theirs. It carries on from what it
+believes, and repeats the mistake on the next question. That is exactly what happened on a live
+conversation where a corrected price was quoted wrong again ninety-seven seconds later.
+
+So tell SiteDesk what the visitor should be told, and name the bot and the chat: "Tell the
+visitor on chat 1234567890 that the price is 75, not 65." The instruction goes into that visitor's
+own conversation. The agent writes the message itself, in the same voice it has been using, and its
+own memory now holds what it said, so it will not contradict it a moment later. The visitor sees a
+normal message from the assistant they have been talking to, with no sign that anybody stepped in.
+
+Write the intent rather than the exact sentence. This is an instruction to the agent, not text
+delivered word for word, so "tell them we can do Thursday morning but not the afternoon" works better
+than a script.
+
+Four situations are refused, and each one says why rather than failing quietly:
+
+- The bot is not a public bot. Your own admin bot and any specialist bot are conversations with your
+  own side, not with a visitor, so there is nothing to instruct.
+- The agent has been switched off. Nothing is resurrected behind your back; turn it back on, or
+  message the person yourself.
+- The chat belongs to a connected business account. Those conversations are held separately and this
+  route cannot reach them.
+- The chat is a broadcast channel the bot does not allow. A channel post reaches every subscriber and
+  cannot be unsent.
+
+If you need the chat ID, ask "who can you reach on Telegram?" first.
+
 ## Getting a Chat ID
 
 To message a specific person or group, SiteDesk needs their chat ID. The easiest way:
@@ -3022,6 +3057,50 @@ Two things to know:
 Text only for now. Photos, files and voice notes are not available on Telegram
 from the dashboard.
 
+### What the agent knows about a message you typed
+
+When you type into a public bot's conversation, that agent's own memory is
+updated with what you sent, so its next answer does not contradict you. It knows
+the words came from you and that the visitor has already received them, so it
+sends nothing in reply. The visitor sees one message, yours.
+
+This matters because without it the agent carries on from what it believed. On a
+live conversation an operator sent a visitor the real prices by hand, and the
+agent's memory still held a visitor asking for a price it had never given.
+
+Four situations record nothing, and each one says which in the log rather than
+failing quietly:
+
+- The bot is not a public bot. Your own admin bot and any specialist bot are
+  conversations with your own side, so there is no agent knowledge to correct.
+- The agent has been switched off. Nothing is woken behind your back, which is
+  the whole point of having switched it off. Your message still goes out.
+- The chat belongs to a connected business account. Those conversations are held
+  separately and this route cannot reach them.
+- The conversation has not started yet. There is nothing to keep consistent, and
+  an agent started this way would be holding a visitor nobody asked it to answer.
+
+To check it is working, look at the log after sending:
+
+```bash
+grep -hE 'op=(sent|context-recorded)|telegram-manual-census|op=text-suppressed' ~/.maxy-code/logs/server.log
+```
+
+A healthy send shows one `op=sent … ok=true`, one `op=context-recorded …
+suppressed=yes reason=-`, and one `op=text-suppressed … reason=operator-sent` for
+that conversation. The standing line
+`[telegram-manual-census] sent=N recorded=N suppressed=N unrecorded=0 skipped=0
+leaked=0 window=60m` should show `recorded` and `suppressed` both equal to `sent`,
+once the four situations above are set aside.
+
+- **`unrecorded`** above zero: a send reached no conversation and nothing said
+  why.
+- **`leaked`** above zero: a send reached a conversation, and ten minutes later
+  nothing had reported holding that turn's reply back. Either the agent never
+  woke, or it answered on top of your message and the visitor saw it twice.
+- **`skipped`** above zero is normal. It is one of the four situations above, and
+  the `reason=` on that send's own line says which.
+
 ## Building your own Telegram functionality
 
 Telegram is a core plugin, so it is on every install and cannot be switched off.
@@ -3047,7 +3126,9 @@ it puts the answer in the card itself and does not add a sentence beside it. On
 public bot, that following sentence is held back on purpose, so the visitor sees
 the card once and not the same thing twice. And when someone presses a button,
 your conversation view shows the button's own wording — "1 passenger", "One way"
-— rather than the code behind it.
+— rather than the code behind it. A card SiteDesk sends into a different
+chat appears in that chat's conversation, where the person who received it is,
+and not in the conversation you asked for it from.
 
 The same is now true of most of what Telegram sends. Reply to one of
 SiteDesk's messages and it sees the message you replied to, so "yes, do

package/payload/platform/plugins/admin/skills/whats-new/SKILL.md

@@ -9,6 +9,20 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-08-15 (0.1.609)
+
+- An account created after an install now starts its first conversation. It halted on a folder-trust prompt, which finishes the fix begun in the previous release for accounts that already existed.
+- A message you send by hand now reaches the conversation. It was accepted and went nowhere.
+- Writing a memory into another account works. It was permitted and then refused at the point of writing, so the feature had never once succeeded.
+- A stuck sub-account conversation restarts under its own account rather than the main one, and starting a conversation no longer reports success when the assistant behind it never came up.
+- An account being set up is no longer reported as a privacy leak. The check counted it while provisioning was still in progress.
+
+## 2026-08-15 (0.1.608)
+
+- You can now steer a public agent while it is mid-conversation with someone, rather than waiting for the exchange to end.
+- A card sent into a different chat is filed in that chat, not in the conversation of whoever sent it.
+- Routines already running on your installs now use the work-check gates added over the past week. They kept their old always-run behaviour until this backfill, and routines left behind with nothing to run are removed.
+
 ## 2026-08-14 (0.1.607)
 
 - Upgrades no longer fail on a Raspberry Pi with a 16K page size. The system's own Chromium launcher adds a setting that current Chromium has removed, so the browser exited on startup and the install stopped when it could not reach it. The installer now runs Chromium directly, skipping that launcher.

package/payload/platform/plugins/aeo/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     environment: "node",
     include: ["src/**/__tests__/**/*.test.ts"],
     testTimeout: 10_000,

package/payload/platform/plugins/cloudflare/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     environment: "node",
     include: ["__tests__/**/*.test.ts"],
     exclude: process.env.RUN_LIVE === "1" ? [] : ["__tests__/live/**"],

package/payload/platform/plugins/connector/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     environment: "node",
     include: ["src/**/__tests__/**/*.test.ts"],
   },

package/payload/platform/plugins/contacts/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     environment: "node",
     // Scoped to src, matching plugins/telegram/mcp: without it vitest also
     // collects dist/__tests__/*.test.js, which `tsc -p` emits because this

package/payload/platform/plugins/docs/references/telegram-guide.md

@@ -138,6 +138,41 @@ Telegram profile name and will tell you plainly that it cannot put a name to the
 Ask {{productName}} to save the Telegram ID against the contact. It is one change to one contact, and
 it takes effect on the very next message.
 
+## Correcting what a public agent told a visitor
+
+When one of your public bots tells a visitor something wrong, the fix is to instruct the agent that
+is talking to them, not to message the visitor yourself.
+
+The reason is worth understanding, because the obvious approach quietly fails. Every conversation is
+its own separate agent with its own memory. If you send the visitor a correction from your chat, they
+receive it, but the agent that has been talking to them never sees it: it is a different
+conversation, and nothing carries a message from yours into theirs. It carries on from what it
+believes, and repeats the mistake on the next question. That is exactly what happened on a live
+conversation where a corrected price was quoted wrong again ninety-seven seconds later.
+
+So tell {{productName}} what the visitor should be told, and name the bot and the chat: "Tell the
+visitor on chat 1234567890 that the price is 75, not 65." The instruction goes into that visitor's
+own conversation. The agent writes the message itself, in the same voice it has been using, and its
+own memory now holds what it said, so it will not contradict it a moment later. The visitor sees a
+normal message from the assistant they have been talking to, with no sign that anybody stepped in.
+
+Write the intent rather than the exact sentence. This is an instruction to the agent, not text
+delivered word for word, so "tell them we can do Thursday morning but not the afternoon" works better
+than a script.
+
+Four situations are refused, and each one says why rather than failing quietly:
+
+- The bot is not a public bot. Your own admin bot and any specialist bot are conversations with your
+  own side, not with a visitor, so there is nothing to instruct.
+- The agent has been switched off. Nothing is resurrected behind your back; turn it back on, or
+  message the person yourself.
+- The chat belongs to a connected business account. Those conversations are held separately and this
+  route cannot reach them.
+- The chat is a broadcast channel the bot does not allow. A channel post reaches every subscriber and
+  cannot be unsent.
+
+If you need the chat ID, ask "who can you reach on Telegram?" first.
+
 ## Getting a Chat ID
 
 To message a specific person or group, {{productName}} needs their chat ID. The easiest way:
@@ -199,6 +234,50 @@ Two things to know:
 Text only for now. Photos, files and voice notes are not available on Telegram
 from the dashboard.
 
+### What the agent knows about a message you typed
+
+When you type into a public bot's conversation, that agent's own memory is
+updated with what you sent, so its next answer does not contradict you. It knows
+the words came from you and that the visitor has already received them, so it
+sends nothing in reply. The visitor sees one message, yours.
+
+This matters because without it the agent carries on from what it believed. On a
+live conversation an operator sent a visitor the real prices by hand, and the
+agent's memory still held a visitor asking for a price it had never given.
+
+Four situations record nothing, and each one says which in the log rather than
+failing quietly:
+
+- The bot is not a public bot. Your own admin bot and any specialist bot are
+  conversations with your own side, so there is no agent knowledge to correct.
+- The agent has been switched off. Nothing is woken behind your back, which is
+  the whole point of having switched it off. Your message still goes out.
+- The chat belongs to a connected business account. Those conversations are held
+  separately and this route cannot reach them.
+- The conversation has not started yet. There is nothing to keep consistent, and
+  an agent started this way would be holding a visitor nobody asked it to answer.
+
+To check it is working, look at the log after sending:
+
+```bash
+grep -hE 'op=(sent|context-recorded)|telegram-manual-census|op=text-suppressed' ~/.maxy-code/logs/server.log
+```
+
+A healthy send shows one `op=sent … ok=true`, one `op=context-recorded …
+suppressed=yes reason=-`, and one `op=text-suppressed … reason=operator-sent` for
+that conversation. The standing line
+`[telegram-manual-census] sent=N recorded=N suppressed=N unrecorded=0 skipped=0
+leaked=0 window=60m` should show `recorded` and `suppressed` both equal to `sent`,
+once the four situations above are set aside.
+
+- **`unrecorded`** above zero: a send reached no conversation and nothing said
+  why.
+- **`leaked`** above zero: a send reached a conversation, and ten minutes later
+  nothing had reported holding that turn's reply back. Either the agent never
+  woke, or it answered on top of your message and the visitor saw it twice.
+- **`skipped`** above zero is normal. It is one of the four situations above, and
+  the `reason=` on that send's own line says which.
+
 ## Building your own Telegram functionality
 
 Telegram is a core plugin, so it is on every install and cannot be switched off.
@@ -224,7 +303,9 @@ it puts the answer in the card itself and does not add a sentence beside it. On
 public bot, that following sentence is held back on purpose, so the visitor sees
 the card once and not the same thing twice. And when someone presses a button,
 your conversation view shows the button's own wording — "1 passenger", "One way"
-— rather than the code behind it.
+— rather than the code behind it. A card {{productName}} sends into a different
+chat appears in that chat's conversation, where the person who received it is,
+and not in the conversation you asked for it from.
 
 The same is now true of most of what Telegram sends. Reply to one of
 {{productName}}'s messages and it sees the message you replied to, so "yes, do

package/payload/platform/plugins/email/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     environment: "node",
     include: ["src/**/__tests__/**/*.test.ts"],
     testTimeout: 10_000,

package/payload/platform/plugins/filesystem/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     include: ["src/**/__tests__/**/*.test.ts"],
     environment: "node",
   },

package/payload/platform/plugins/graph-viewer/mcp/vitest.config.ts

@@ -2,6 +2,7 @@ import { defineConfig } from "vitest/config";
 
 export default defineConfig({
   test: {
+    setupFiles: ["../../../test/tmpdir-setup.ts"],
     include: ["src/**/*.test.ts"],
     environment: "node",
   },

package/payload/platform/plugins/memory/mcp/dist/index.js

@@ -68,6 +68,10 @@ import { resolve } from "node:path";
 import { enumerateValidAccountIds, isProvisionedAccount } from "../../../../lib/account-enumeration/dist/index.js";
 import { readHouseAdminScope } from "../../../../lib/account-scope/dist/index.js";
 import { makeResolveToolAccount } from "./index-testable.js";
+// Task 2731 — cross-account write observability. `isInvalidAccountIdError` is
+// the gate's own discriminator, so the outcome line never matches on prose.
+import { isInvalidAccountIdError } from "../../../../lib/graph-write/dist/index.js";
+import { noteXacctWriteCall, noteXacctWriteOutcome, formatWriteOutcome, writeOutcomeReason, startXacctCensus, } from "./lib/xacct-counters.js";
 const server = new McpServer({
     name: "maxy-memory",
     version: "0.1.0",
@@ -116,6 +120,47 @@ const XACCT_DESC = "House-scoped admin only: operate on the named sub-account su
 // resolved (possibly cross-account) id. A resolved id != this is a cross-account
 // call (the resolver only returns a target for a house-authorised session).
 const BOOT_ACCOUNT_ID = accountId;
+// Task 2731 — the standing census over cross-account writes. Armed at boot so a
+// window of zero is still reported: a capability nobody invokes looks identical
+// to one that works, which is how the allow-then-refuse defect survived. The
+// handle is unref'd, so it never keeps this stdio child alive past its session.
+//
+// Not armed in a read-only child, which registers no write tool at all. Its
+// `writeCalls` could only ever be zero, and a zero that means "this process
+// cannot write" is indistinguishable from the zero that means "nobody exercised
+// the feature" — which is the one the operator needs to read.
+if (!readOnly)
+    startXacctCensus();
+/**
+ * Task 2731 — the paired write-outcome line, emitted only for a cross-account
+ * call so it sits one-for-one against the resolver's `[xacct] op=call` line.
+ * `decision=allow` followed by `gate=rejected` for the same target is the
+ * defect this task fixed, and must never appear again.
+ *
+ * `gate` reports the graph-write ACCOUNT gate alone. A write that failed for any
+ * other reason — schema validation, a system-managed key, a missing target node
+ * — got past that gate and reads `gate=passed reason=write-failed`. Conflating
+ * the two would hide the one pairing worth watching.
+ *
+ * `reason` is one of three names, never an error message. An operator greps
+ * `reason=invalid-account-id`, and a message pasted in here would carry its own
+ * spaces, punctuation and account slice into the field, matching nothing. The
+ * detail of a non-gate failure is already on the `[mcp:memory] … result=error`
+ * line for the same call.
+ */
+function noteCrossAccountWriteOutcome(o) {
+    if (!o.targetAccountId)
+        return;
+    const gate = isInvalidAccountIdError(o.err) ? "rejected" : "passed";
+    noteXacctWriteOutcome(gate);
+    process.stderr.write(formatWriteOutcome({
+        tool: o.tool,
+        caller: o.caller ?? "unknown",
+        target: o.target,
+        gate,
+        reason: writeOutcomeReason(gate, o.err !== null),
+    }));
+}
 async function resolveProfileIdentity(toolName, crossAccount, resolvedAccountId, callerUserId) {
     // Resolve the facts the pure classifier needs. On the own-account path the
     // account's owner is resolved only when the caller is NOT operating their
@@ -893,6 +938,12 @@ if (!readOnly) {
         targetAccountId: z.string().optional().describe(XACCT_DESC),
     }, async ({ labels, properties, scope, relationships, producedByTaskId, mergeOn, targetAccountId }) => {
         const scoped = resolveToolAccount("memory-write", targetAccountId);
+        // Task 2731 — count the cross-account call before its outcome is known,
+        // so a denied call still lands in the census. Own-account calls are not
+        // counted: `writeCalls=0` must mean "nobody targeted another account",
+        // not "nobody wrote".
+        if (targetAccountId)
+            noteXacctWriteCall(!("reject" in scoped));
         if ("reject" in scoped)
             return scoped.reject;
         const accountId = scoped.accountId;
@@ -912,6 +963,13 @@ if (!readOnly) {
                 producedByTaskId,
                 mergeOn,
             });
+            noteCrossAccountWriteOutcome({
+                targetAccountId,
+                tool: "memory-write",
+                caller: BOOT_ACCOUNT_ID,
+                target: accountId,
+                err: null,
+            });
             return {
                 content: [
                     {
@@ -922,6 +980,13 @@ if (!readOnly) {
             };
         }
         catch (err) {
+            noteCrossAccountWriteOutcome({
+                targetAccountId,
+                tool: "memory-write",
+                caller: BOOT_ACCOUNT_ID,
+                target: accountId,
+                err,
+            });
             return {
                 content: [
                     {