@rubytech/create-realagent 1.0.814 → 1.0.815

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-realagent",
-  "version": "1.0.814",
+  "version": "1.0.815",
   "description": "Install Real Agent — Built for agents. By agents.",
   "bin": {
     "create-realagent": "./dist/index.js"

package/payload/platform/plugins/admin/skills/onboarding/SKILL.md

@@ -6,6 +6,8 @@ After completing each step, persist progress immediately by calling `onboarding-
 
 Every user selection and every document presentation in onboarding renders through `render-component` — never as markdown text, bullet lists, or inline chat content. Selections use `single-select` or `multi-select`; file content (SOUL, KNOWLEDGE, config) uses `document-editor`. Describing options in prose or pasting file content into a chat message bypasses the UI and the user's ability to review and edit before saving. Never use directional words ("above", "below") when referring to a rendered component — just name it or refer to "the browser", "the editor", etc. The `document-editor` component renders one file at a time — never call `render-component` with `document-editor` twice in the same turn. Present one file, wait for the user's approval or edit, then present the next.
 
+**Turn-completion contract (Task 879 §C).** Any onboarding turn that advances `currentStep` (via `onboarding-complete-step`) OR narrates a step transition with phrases like "Moving to step N", "Proceeding to step N", "Step N done" MUST end with one of: a `render-component` call surfacing the next step's UI, OR a `?`-terminated question. Bare prose statements like "Moving to step 9 — operator persona and profile bootstrap." with nothing after are forbidden — they leave the operator with no actionable surface and force a manual nudge. The post-restart resume contract for step 7 is the canonical case: when the cloudflare-relay turn arrives at `currentStep=7`, the agent's first turn must acknowledge AND immediately render the step-8 prompt (or `anthropic-setup`'s next surface) without an intervening dead-end paragraph. Same rule applies turn-by-turn through step 9. The `assistant-step-advance-deadend` review-detector rule (`platform/ui/app/lib/review-detector/rules.ts`) fires when this contract is violated, so an agent that drifts back to bare prose surfaces a `[review-detector]` alert against itself.
+
 ## Step 1 — Plugin selection
 
 *(skip if `currentStep` >= 1)*

package/payload/platform/plugins/docs/references/cloudflare.md

@@ -31,6 +31,8 @@ When you submit, the `/api/admin/cloudflare/setup` endpoint runs — in strict o
 - `config.yml` and `tunnel.state` written under `${CFG_DIR}`.
 - **Step-7 onboarding completion persisted** — the script writes `${ACCOUNT_DIR}/onboarding/step7-complete` (a JSON marker with the completion timestamp and tunnel ID) before arming the restart. Stream log: `step=onboarding-persist result=ok|error reason=<r>`. The marker is consumed by the next admin session's first state read and advances `OnboardingState.currentStep` to 7. Without this, the service restart below would SIGTERM the admin agent before it could persist step-7 completion, and the next session would re-ask the Cloudflare question you just finished. Both invocation surfaces (the form-driven action and the agent-via-Bash path) declare `ACCOUNT_DIR` explicitly because `systemd-run --user` does not inherit parent env — when ACCOUNT_DIR isn't reaching the script you'll see `result=skipped reason=no-account-dir` in the stream log instead of `result=ok`.
 - **Chat-relay queued for the operator's "Cloudflare setup completed" turn** (Task 867) — when the form's ActionLogPanel reports `code=0`, the form fires `POST /api/admin/cloudflare/relay-completion`. The route enqueues a record at `${ACCOUNT_DIR}/queue/action-completion-relay-<actionId>.json` (write-once via Node's `wx`/O_EXCL flag) BEFORE the brand restart kills the in-flight admin agent. After the restart, the brand service's boot-drain hook ([server/index.ts](../../../../platform/ui/server/index.ts)) consumes the queue once and dispatches a server-driven agent turn via a synthetic one-shot session bound to the queued conversationId; the agent's hoisted user-message persist (Task 867 `admin-agent.ts` + `public-agent.ts` write `role=user` BEFORE the SDK invoke now) captures the operator's relay even if SIGTERM hits mid-generation. The diagnostic line you grep on the working path is `[action-completion-relay] phase=consumed actionId=<id> conversationId=<cid> ageMs=<n> outcome=injected`. Failure modes are surfaced by the `cloudflare-setup-relay-not-acknowledged` review rule.
+- **Chat-surface restart-pending banner** (Task 879 §A) — the same `admin-chat:await-relay` CustomEvent that registers the relay-poll now also carries `reason: 'cloudflare-setup'` so the chat hook ([useAdminChat.ts](../../../../platform/ui/app/useAdminChat.ts)) renders an inline `"Service restarting after Cloudflare setup — picking back up…"` banner the moment the form fires. Closes the visible-silence window between the form's `Completed · 20s` and the first post-restart agent token. Idempotent on duplicate dispatch. Copy is keyed by `reason` so future restart sources (plugin-install, npm-update) can plug in their own banner without inventing a new chat surface state. Generic fallback `"Service restarting — reconnect will happen automatically."` is used when the dispatch omits `reason`.
+- **Client sessionKey rebind on first post-restart poll** (Task 879 §D.2) — when the relay-poll observes its first `200` for the captured cid (server-side cookie-bridge has just hydrated `(accountId, userId)` onto the wiped sessionStore entry), the chat hook fires `POST /api/admin/session/rebind` exactly once with `{session_key, lastKnownConversationId}`. The endpoint validates accountId scope via `getConversationOwner(cid).accountId === sessionAccountId` and binds the conversationId to the session via `setConversationIdForSession`. `sendMessage` awaits the in-flight rebind promise before opening the next chat POST, closing the silent-fork race where the operator's next turn would otherwise create a NEW Conversation and the `[admin/conversation-flush] result=missing-userId|writer-failed` line never reached the chat surface. Diagnostic: `grep '\[admin/session/rebind\]' ~/{configDir}/logs/server.log` — expects `result=ok conversationId=<cid8>` once per restart cycle; `result=conflict` means the server holds a different canonical cid (client adopts it).
 - `systemctl --user restart ${BRAND}.service` — restarts the platform service so the new tunnel spawns via the service's `ExecStartPre=resume-tunnel.sh`.
 - Post-restart verification — `ps -ef | grep '[c]loudflared'` confirms the connector is alive, then `curl -I https://<hostname>` against each subdomain (up to 60 s per host) confirms a non-530 response.