@rubytech/create-realagent 1.0.406

package/payload/platform/plugins/business-assistant/references/scheduling.md

@@ -0,0 +1,127 @@
+# Scheduling & Briefings
+
+## Booking Protocol
+
+When booking an appointment:
+
+1. Check memory for the business owner's schedule and known commitments
+2. **Check geography** — where is the customer? What postcode area? Where are existing jobs that day?
+3. **Prefer geographic clustering** — offer slots where the business owner is already nearby:
+   - Use your knowledge of geography, towns, and postcodes to judge proximity. **Do NOT rely on postcode prefixes alone** — different prefixes can be adjacent (e.g., CM23 and CB11 are ~15 minutes apart despite different area codes), and same prefixes can span large areas.
+   - Think in terms of **towns and travel time**, not prefix strings.
+   - If a routing tool (OSRM) is available, use it for accurate drive times.
+   - If the customer's area matches an existing job day, offer that day first: "[name]'s already in the Stansted area on Tuesday — would Tuesday afternoon work?"
+4. Offer 2-3 time options (never just one — gives the customer choice)
+5. Allow enough time per job type (load from industry overlay)
+6. Leave travel time between jobs:
+   - Same town / nearby villages: 10-20 minutes
+   - Neighbouring towns: 20-35 minutes
+   - Different areas (30+ miles): 45+ minutes
+   - If a routing tool is available, use actual drive times instead of estimates
+7. **Check for squeeze-in opportunities** — if there's a gap between existing jobs and the new customer is nearby, offer that gap
+8. Confirm with customer
+9. If customer can't make any options → offer alternatives, handle the ping-pong
+10. Only escalate to business owner if: no slots available, customer insists on a taken time, or unusual job type
+
+**Always store the customer's postcode/area in memory.** Essential for future geographic clustering.
+
+**Escalation format:** Short, include location context:
+> "New booking request: Mrs Jenkins, 42 Oak Lane, CM23. Boiler not firing — sounds like ignition. She's available Tue/Wed/Thu afternoon. You're already in CM23 on Tuesday (Dave Smith, 9am). Shall I book her in for Tuesday 11am?"
+
+## Schedule Optimisation
+
+**You are the business owner's logistics manager, not just a diary.** Minimise driving. Maximise billable time. Think geographically.
+
+### Rescheduling suggestions (proactive, to business owner)
+
+When you notice a scheduling inefficiency, suggest a fix:
+
+> "[name] — Mr Thompson's boiler service is booked for Wednesday in Saffron Walden. But you've got two jobs there on Thursday already. If he's flexible, moving him to Thursday would save you a 40-min round trip. Want me to ask him?"
+
+Only suggest rescheduling when:
+- The customer is known to be flexible (check memory)
+- The saving is significant (20+ minutes of driving)
+- The job isn't urgent
+- It doesn't push the job more than a few days
+
+### Emergency reshuffling
+
+When an emergency comes in, check what can move:
+
+> "Emergency call — burst pipe in Thaxted, active flooding. Your next job (Mrs Jenkins, 2pm, CM23) is a routine boiler service. She's usually flexible. Want me to reschedule her and slot this in?"
+
+Always ask the business owner before reshuffling. Never move a job without approval.
+
+## Morning Briefing
+
+If a scheduled event is set up for morning briefings, send a daily summary. **Group jobs by area, not just time.** Include postcodes, estimated travel, and total driving time.
+
+> **Morning [name]! Here's your Tuesday:**
+>
+> **Stansted area:**
+> 9:00am — Mrs Jenkins, 42 Oak Lane, CM23 (boiler service, ~1hr)
+> 10:30am — Dave Smith, 15 Park Road, CM24 (dripping tap, ~30min)
+>
+> **Newport area** (~25 min drive):
+> 12:00pm — Mrs Wilson, 8 High St, CB11 (power flush, ~3hrs)
+>
+> Total: 3 jobs, ~55 min driving. Home by 4pm.
+>
+> **Waiting on:**
+> - Quote sent to Mr Brown (bathroom refit, £4,500) — sent 2 days ago, no reply yet
+> - Invoice unpaid: Mr Thompson, £180, 18 days overdue. Reminder sent Monday
+>
+> **New messages overnight:**
+> - Sarah Collins asked about a leaking radiator. She's in CM23 — I've offered her Wednesday 10am. Waiting for her to confirm.
+
+## Travel Time Estimation
+
+- If a routing tool (OSRM) is available, use it for accurate drive times
+- Otherwise, **use your knowledge of geography** — think in terms of actual places, not postcode prefix strings
+- Same town / nearby villages: ~10-15 minutes
+- Neighbouring towns: ~20-35 minutes
+- Cross-area (different towns, 30+ miles): ~45+ minutes
+- Always err on the side of more travel time, not less
+- When in doubt, ask: "How long does it take you to get from [A] to [B]?" and store the answer
+
+## GPS Integration
+
+If the business owner's phone is paired as a node, you can query their GPS location on demand using `location.get`:
+
+- **Customer asks "where is he?"** → Check GPS, give ETA: "[name] left his last job about 15 minutes ago. He should be with you in about 20 minutes."
+- **Late detection** → Query GPS 10 minutes before each appointment. If far away, proactively message the customer about the delay.
+- **End-of-day** → If near home postcode, stop offering same-day appointments.
+- Do NOT track location continuously. Only query when you have a specific reason.
+- Do NOT share exact GPS coordinates with customers. Approximate ETAs and area descriptions only.
+
+## Geographic Intelligence Over Time
+
+- Week 1: Only know postcodes from new bookings. Clustering is basic.
+- Month 1: Know 30+ customer locations. Clustering is effective.
+- Month 3: Know typical areas, preferred days per zone, how long jobs actually take. You're a logistics expert.
+- With Kickstart data import: Know 200+ locations from Day 1.
+
+## Holiday Mode
+
+When the business owner says they're going away:
+
+1. Note the dates in memory
+2. Continue responding to customers normally — **DO NOT tell customers the business owner is away** (security risk — empty house)
+3. Instead: "[name]'s fully booked this week but has availability from [return date]. Shall I pencil you in?"
+4. Queue non-urgent matters for when they return
+5. Escalate genuine emergencies (refer to another business owner if one is specified in memory)
+6. Send a summary when they return
+
+## Onboarding (First Conversation)
+
+When the business owner first messages, learn their business conversationally:
+
+1. "What industry is your business in?" → load industry overlay
+2. "What's your standard rate or pricing structure?"
+3. "What area do you cover?"
+4. "What are your working hours?"
+5. "Do you want me to handle incoming WhatsApp messages from customers?"
+6. "Anything else I should know?" (materials markup, specialities, things you don't do)
+7. "Should I give you a morning briefing each day?"
+
+Store everything in memory. Don't ask all at once — be conversational.

package/payload/platform/plugins/business-assistant/references/task-management.md

@@ -0,0 +1,155 @@
+# Task & Session Management
+
+Every conversation maps to a named, purposeful task. Sessions are not chat logs — they are units of work. This reference governs how you create, track, and complete tasks, and how you name and close sessions.
+
+---
+
+## Core Principle
+
+One session, one task. A session exists to accomplish something specific. If a conversation drifts into a second topic, finish the first, then suggest starting a fresh session for the next piece of work.
+
+---
+
+## Task Lifecycle
+
+```
+pending → active → completed
+                ↘ failed
+                ↘ cancelled
+```
+
+| status | Meaning |
+|---|---|
+| `pending` | Identified but not yet started |
+| `active` | Work is in progress |
+| `completed` | Done — outcome achieved |
+| `failed` | Abandoned or blocked |
+| `cancelled` | No longer relevant |
+
+### When to create a task
+
+Create a task whenever:
+- The user identifies a piece of work to be done ("we need to set up Telegram")
+- You identify work that needs to happen before the user can proceed
+- A multi-step process begins that will span more than one message
+
+Do not create tasks for simple one-turn exchanges (answering a question, looking up a price).
+
+### Creating a task
+
+Use `task-create`. Always pass `sessionKey` (from your system prompt — "Current session key: ...") to link the task to the current conversation automatically:
+
+```
+task-create {
+  name: "Telegram setup",
+  description: "Configure Telegram bot and webhook for the business",
+  status: "active",
+  priority: "normal",
+  sessionKey: "<value from system prompt>"
+}
+```
+
+### Updating a task
+
+Use `task-update` to change status or append a progress note:
+
+```
+task-update {
+  taskId: "<id>",
+  status: "completed",
+  note: "Webhook configured and verified"
+}
+```
+
+Notes are append-only — never overwritten. Always include a brief note with any status change.
+
+### Completing a task
+
+Use `task-complete` as a shorthand — it sets status to `completed` and appends a closing note:
+
+```
+task-complete {
+  taskId: "<id>",
+  note: "Telegram bot live, webhook responding"
+}
+```
+
+---
+
+## Session Lifecycle
+
+### Session start
+
+At the beginning of a session:
+1. Call `session-list` to see recent sessions and open tasks
+2. If there are open or in-progress tasks, surface them: "I can see we started setting up Telegram on Tuesday — want to continue with that, or is there something else?"
+3. If the user's first message makes the session purpose clear, name the session immediately and proceed
+4. If the purpose is not clear from the first message, ask once: "What would you like to work on today?" — then name the session once you have the answer
+5. Never name the session before you know what it's for
+
+### Naming the session
+
+Name the Conversation node once the session purpose is clear — this happens after the user's first reply, not on the agent's opening turn:
+
+```
+session-name {
+  sessionKey: "<value from system prompt>",
+  name: "Telegram setup"
+}
+```
+
+If the session drifts to a substantially different topic, rename it to reflect what was actually worked on. `session-name` overwrites the previous name.
+
+### Session end
+
+When the session is wrapping up:
+1. Summarise what was accomplished
+2. List any pending items or follow-ups
+3. Mark the task complete (or failed/cancelled if blocked)
+4. Close with something like: "That's the Telegram webhook configured. I've marked the task complete."
+
+---
+
+## Querying Sessions and Tasks
+
+### List recent sessions
+
+```
+session-list {}
+```
+
+Returns recent conversations with their names, session keys, and any linked tasks. Use this at session start and when the user asks what sessions or work is in progress.
+
+### List open tasks
+
+```
+task-list { status: "active" }
+task-list { status: "pending" }
+```
+
+### Get a specific task
+
+```
+task-get { taskId: "<id>" }
+```
+
+---
+
+## Cross-Session Progress Tracking
+
+If a user returns to work on a previous task:
+1. Call `session-list` to find the original session and task
+2. Call `task-update` to set `status: "active"` and note the resumption
+3. Pass `sessionKey` in `task-create` for any new tasks in the new session — it links them to the current conversation automatically
+
+A task can span multiple sessions. Use `task-create` with `sessionKey` each time work resumes in a new conversation.
+
+---
+
+## Session-Task Mapping Rules
+
+- **One active task per session.** Don't split focus.
+- **Multiple sessions per task is fine.** Complex work spans multiple conversations.
+- **Suggest a new session when scope drifts.** "That's a different topic — let me finish the invoice here and we can start a fresh session for the website changes."
+- **Never leave a task in `active` indefinitely.** If work is clearly abandoned, mark it `failed` with a note.
+- **Proactively surface tasks that need attention.** If a task has been active for more than a few days, mention it when the user starts a new session.

package/payload/platform/plugins/cloudflare/PLUGIN.md

@@ -0,0 +1,48 @@
+---
+name: cloudflare
+description: Cloudflare Tunnel setup and management via SDK with browser-guided auth
+metadata: {"taskmaster":{"emoji":"🌐"}}
+tools:
+  - cf-set-token
+  - tunnel-login
+  - cf-zone-status
+  - tunnel-status
+  - tunnel-install
+  - tunnel-create
+  - tunnel-enable
+  - tunnel-disable
+  - tunnel-add-hostname
+  - dns-lookup
+---
+
+# Cloudflare Tunnel Setup
+
+Guides through setting up a Cloudflare Tunnel so customers can reach this assistant via a custom domain (e.g., `chat.mybusiness.com`). Tunnel and DNS operations use the Cloudflare SDK. Connection key creation and domain addition happen in the VNC browser via browser-specialist — the user never leaves the chat.
+
+## When to activate
+
+- User mentions Cloudflare, custom domain, public access, or internet access
+- User wants to expose the assistant publicly with a custom URL
+- User asks about setting up remote access with a custom domain
+- User says "set up Cloudflare" or similar
+
+## What it unlocks
+
+- Public internet access via a custom domain
+- Reliable mobile admin access (replacing or supplementing Tailscale)
+- Custom-branded public chat URLs
+- Webhook endpoints on a stable domain
+
+## Skills
+
+| Skill | Purpose |
+|-------|---------|
+| [setup-tunnel.md](skills/setup-tunnel.md) | Browser-guided tunnel setup — connection key creation in VNC, domain verification, tunnel creation, and activation |
+
+## References
+
+| Reference | Topics |
+|-----------|--------|
+| [setup-guide.md](references/setup-guide.md) | Prerequisites, domain setup, troubleshooting, tool reference |
+
+Load the relevant skill or reference based on the task.

package/payload/platform/plugins/cloudflare/mcp/dist/index.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=index.d.ts.map

package/payload/platform/plugins/cloudflare/mcp/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":""}