@rubytech/taskmaster 1.16.3 → 1.17.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/taskmaster",
-  "version": "1.16.3",
+  "version": "1.17.4",
   "description": "AI-powered business assistant for small businesses",
   "publishConfig": {
     "access": "public"

package/skills/log-review/SKILL.md

@@ -20,12 +20,13 @@ Load `references/review-protocol.md` for the full review and analysis protocol.
 
 ### Rules
 
-1. **Scan system logs** — use `logs_read(action: "system")` for gateway-level errors and warnings
+1. **Scan system logs** — use `logs_read(action: "system", minLevel: "warn")` to retrieve only warnings and errors. Do not call without `minLevel` — full logs will overflow context.
 2. **Scan session logs** — use `logs_read(action: "sessions")` across all agents for tool failures and agent errors
 3. **Triage by severity** — critical, warning, info. Deduplicate repeated errors.
-4. **Analyse each issue** — plain-language explanation, likely root cause, suggested admin action
-5. **Escalation guidance** — for issues beyond local resolution, advise forwarding this report to the Taskmaster public agent on WhatsApp for support
-6. **All-clear confirmation** — if no issues found, confirm briefly so admins know the review ran
+4. **Deduplicate** — group identical messages from repeated occurrences and report as "N× [message]" rather than listing each separately.
+5. **Analyse each issue** — plain-language explanation, likely root cause, suggested admin action
+6. **Escalation guidance** — for issues beyond local resolution, advise forwarding this report to the Taskmaster public agent on WhatsApp for support
+7. **All-clear confirmation** — if no issues found, confirm briefly so admins know the review ran
 
 ### Output Format
 
@@ -37,8 +38,20 @@ The report should follow this structure:
 - **Escalation** — if any issues warrant Taskmaster support, advise forwarding this report
 - **Summary** — issue count or all-clear confirmation
 
+Each individual issue entry must be formatted exactly as:
+
+```
+**N. Title** _(HH:MM or HH:MM–HH:MM Nx)_
+- What: ...
+- Why: ...
+- Action: ...
+```
+
+The time in parentheses is mandatory. Extract it from the log line's `time` field (UTC ISO format, e.g. `2026-03-05T10:35:22.000Z`) — take the `HH:MM` part, which is characters 11–15 of the string (e.g. `10:35`). For repeated occurrences show the first–last range and count: `08:36–09:48 (3×)`. Never omit the time — if the log line has no `time` field, write `(?:??)` as a placeholder.
+
 ### Constraints
 
+- **Only report what is directly evidenced in the log data returned by the tools.** Do not infer, extrapolate, or report issues that do not appear verbatim in the log lines. Every issue in the report must be traceable to a specific log entry you received.
 - Keep total execution under 2 minutes
 - Be honest — if nothing surfaced, say "all clear" rather than padding the report
 - Use plain language — the admin is not a developer

package/skills/log-review/references/review-protocol.md

@@ -4,9 +4,7 @@ Run this protocol on schedule or when triggered by an admin. Be thorough in anal
 
 ## Step 1: System Log Scan
 
-Use `logs_read` with `action: "system"` to pull recent gateway logs.
-
-Focus on entries containing `[ERROR]` and `[WARN]`. Ignore routine info-level entries unless they reveal a pattern (e.g. repeated restarts, auth refresh cycles).
+Use `logs_read(action: "system", minLevel: "warn")` to pull only warnings and errors. **Never call without `minLevel`** — the full log will overflow context.
 
 Look for:
 - Service crashes or unexpected restarts
@@ -18,7 +16,7 @@ Look for:
 
 ## Step 2: Session Log Scan
 
-Use `logs_read` with `action: "sessions"` to pull recent session transcripts across all agents.
+Use `logs_read(action: "sessions")` to pull recent error entries across all agents. Only error-type entries are returned — tool failures, agent exceptions, and crashed sessions.
 
 Look for:
 - Tool call failures or errors
@@ -46,6 +44,8 @@ For each issue provide:
 
 Be specific with actions. "Check the logs" is not a useful suggestion — the whole point of this skill is that the admin doesn't have to.
 
+**CRITICAL: Only report issues present in the log data you received.** Do not draw on your knowledge of the codebase, providers, or past conversations to invent or infer issues. If a provider name, error code, or warning does not appear in a log line you read, it must not appear in the report. Fabricating issues destroys trust.
+
 ## Step 5: Escalation Guidance
 
 If any issue meets these criteria, advise the admin to escalate to Taskmaster support:

package/taskmaster-docs/USER-GUIDE.md

@@ -1166,6 +1166,20 @@ Occasionally, AI providers like Claude experience temporary outages or slowdowns
 2. **Check your logs** — If replies are failing, open **Advanced → Logs → Session Logs** and filter by "errors" to see what's happening.
 3. **Wait it out** — Most AI service outages resolve within minutes to hours. Your assistant will automatically use the primary provider again once it's back.
 
+### Sharing logs with support
+
+If you're still stuck after trying the steps above, export your logs and send them to Taskmaster support on WhatsApp. Logs give the support team exact error messages and timing, which speeds up diagnosis.
+
+1. Go to the **Advanced** tab in the Control Panel and tap **Logs**
+2. Select the view that covers your issue:
+   - **Session Logs** — for problems with replies, conversations, or tool errors
+   - **System Logs** — for connection, startup, or gateway issues
+3. Tap **Filters** to open the filter panel
+4. Tap **Export** — the browser downloads a log file to your device
+5. Send the file to Taskmaster support on WhatsApp
+
+> **Tip:** If you're not sure which view to use, export both — Session Logs and System Logs — and send them together.
+
 ### "sudo: unable to resolve host taskmaster" warning?
 
 This harmless warning appears when the Pi's hostname isn't listed in `/etc/hosts`. Every `sudo` command still works — it's just a cosmetic message. To fix it, open a terminal on the Pi and run:

package/templates/beagle-zanzibar/agents/admin/AGENTS.md

@@ -77,9 +77,12 @@ When you receive `[System: Ride Dispatch — Trip Request]`:
    - Update their status to `awaiting_response` via `memory_write`
    - Write `shared/active-negotiations/{driver-phone-digits}.md` with `job_id`, `driver_name`, and `contacted_at`
 5. Message each driver in Swahili via the `message` tool with route details, pickup time, passengers, and job ID
-6. Message the tourist confirming drivers have been contacted and quotes are being gathered
-7. When driver replies arrive (dispatched as `[System: Ride Dispatch — Driver Reply]`), compile offers
-8. Message the tourist with up to 3 competing offers — fare, rating, vehicle type, journey time. Do NOT reveal driver name, phone, or plate (gated by payment)
+6. When driver replies arrive (dispatched as `[System: Ride Dispatch — Driver Reply]`), compile offers
+7. Message the tourist at `tourist_phone` using the `message` tool with `accountId` from this dispatch
+   - Include up to 3 offers: fare, vehicle type, driver rating, estimated journey time
+   - Do NOT reveal driver name, phone, or plate — those are gated by payment
+   - Cross-agent echo will relay the WhatsApp message to the tourist's active session automatically
+   - Do NOT write a dispatch file for the offers — message directly
 
 ### Booking Confirmation
 
@@ -87,18 +90,21 @@ When you receive `[System: Ride Dispatch — Booking Confirmation]`:
 
 1. Load the `stripe` skill and generate a Checkout Session for the booking fee
    - Set metadata: `booking_id`, `tourist_phone`, `account_id` (for webhook routing)
-2. Message the tourist with the payment link and booking terms
+2. Message the tourist at `tourist_phone` using the `message` tool with the payment link and booking terms
+   - Cross-agent echo relays the message to the tourist's active session automatically
 3. Record booking details in `shared/bookings/{job-id}.md` via `memory_write`
+   - Include `tourist_phone` for post-payment messaging
 4. Clear `shared/active-negotiations/{phone}.md` for drivers NOT selected
 
 ### Payment Confirmed
 
 When you receive `[System: Ride Dispatch — Payment Confirmed]`:
 
-1. Read the booking record at `shared/bookings/{job-id}.md` for driver details
+1. Read the booking record at `shared/bookings/{job-id}.md` for driver details and `tourist_session_key`
 2. Generate the pickup PIN and QR code (see `references/pin-qr.md`)
-3. Message the tourist with: driver name, phone, vehicle details, plate, and pickup PIN
-4. Message the driver with: passenger name, pickup time/location, fare, and QR code URL
+3. Message the tourist at `tourist_phone` (from the booking record) using the `message` tool with driver details and pickup PIN
+   - Cross-agent echo relays to the tourist's active session automatically
+4. Message the driver with passenger name, pickup time/location, fare, and QR code URL
 5. Update the booking record status to `confirmed`
 6. Clear the active negotiation file for the confirmed driver
 
@@ -106,7 +112,9 @@ When you receive `[System: Ride Dispatch — Payment Confirmed]`:
 
 When you receive `[System: Ride Dispatch — Driver Reply]`:
 
-Process the driver's message in the context of the ongoing negotiation. If it's a fare quote, note it. When enough quotes are gathered (or after a reasonable wait), compile and send offers to the tourist. If the driver declines, update their status and remove their active negotiation file.
+1. If the driver is quoting a fare: record it in their memory profile (`memory_write` on `drivers/{name}.md`)
+2. When all expected quotes are received (or after a reasonable wait): compile the offers and message the tourist directly using the `message` tool at the `tourist_phone` from the trip-request earlier in this session — do NOT write a dispatch file
+3. If the driver is declining: update their status in memory to `idle` and delete their `shared/active-negotiations/{phone-digits}.md` file
 
 ### Active Negotiation Index
 

package/templates/beagle-zanzibar/agents/public/AGENTS.md

@@ -23,6 +23,7 @@ Before responding:
 - Proactively look up contact details for people mentioned in system messages
 
 If a user asks for information about another person, politely decline — it would violate strict security protocols.
+**Declined conversations stay declined.** When you've correctly identified a message as misdirected or outside your scope and responded accordingly, that conversation is concluded. If the same sender follows up with requests of any kind, decline and end the conversation. Performing services for someone you've already turned away contradicts your own assessment and opens the service to general-purpose misuse.
 
 ---
 
@@ -54,6 +55,10 @@ The knowledge base is the single source of truth. If it doesn't cover what's bei
 
 This is a **prescribed workflow**. When a tourist requests a ride, execute every step in order. Do not stop, skip, or defer any step. The only reason to pause is to ask the tourist for missing information or if the tourist explicitly cancels.
 
+### Step 0 — Confirm identification
+
+All users are verified before they reach you — WhatsApp users by their phone number, webchat users by OTP verification. The tourist's phone number is their session identifier. Use it as `tourist_phone` in dispatch files.
+
 ### Step 1 — Capture the request
 
 Gather: pickup location, destination, date/time, number of passengers, luggage, special requests. If the tourist gave everything in one message, proceed immediately. If anything is missing, ask — then resume from Step 2 when they reply.
@@ -74,7 +79,7 @@ Write a dispatch file via `memory_write` to `shared/dispatch/{job-id}-trip-reque
 # Dispatch: Trip Request
 job_id: BGL-XXXX
 phase: trip-request
-tourist_phone: +XXXXXXXXXXX
+tourist_phone: [the tourist's phone number — from WhatsApp session or OTP-verified phone]
 tourist_name: [name if given]
 pickup: [pickup location]
 destination: [destination]
@@ -93,7 +98,7 @@ After writing the dispatch file, tell the tourist: "I'm reaching out to our driv
 
 ### Step 6 — Present offers
 
-When driver offers appear in your conversation (injected by the operations agent), present up to 3 competing offers to the tourist: fare, driver rating, vehicle type, estimated journey time. No driver personal details at this stage — name, phone, and plate are gated by payment. See `references/ride-matching.md` for formatting.
+When driver offers appear in your conversation as a `[System: Ride Dispatch — Driver Offers]` message, present up to 3 competing offers to the tourist: fare, driver rating, vehicle type, estimated journey time. No driver personal details at this stage — name, phone, and plate are gated by payment. See `references/ride-matching.md` for formatting.
 
 ### Step 7 — Confirm booking
 
@@ -103,7 +108,7 @@ When the tourist chooses an offer, confirm the details and write a booking confi
 # Dispatch: Booking Confirmation
 job_id: BGL-XXXX
 phase: booking-confirm
-tourist_phone: +XXXXXXXXXXX
+tourist_phone: [same phone used in trip-request]
 tourist_name: [name]
 driver_name: [selected driver name from offer]
 driver_phone: [selected driver phone from offer]
@@ -113,11 +118,11 @@ account_id: [your account ID]
 
 ### Step 8 — Payment
 
-The operations agent will generate a Stripe payment link and send it directly to the tourist. You will see this message appear in your conversation via cross-agent echo. If the tourist has questions about payment, explain the booking fee and terms. Payment confirmation is automatic via Stripe webhook — the tourist does not need to tell you they've paid.
+The operations agent will generate a Stripe payment link and relay it to your conversation as a `[System: Ride Dispatch — Payment Link]` message. Present the payment link and terms to the tourist. If the tourist has questions about payment, explain the booking fee. Payment confirmation is automatic via Stripe webhook — the tourist does not need to tell you they've paid.
 
 ### Step 9 — Post-payment
 
-Once payment is confirmed (the operations agent will inject driver details and pickup PIN into the conversation), acknowledge the details to the tourist. Explain the PIN verification process: "Your driver has a QR code. You have the PIN. Scan the QR or ask the driver to quote your PIN — works without internet."
+Once payment is confirmed, the operations agent will relay driver details and the pickup PIN to your conversation as a `[System: Ride Dispatch — Booking Complete]` message. Present the driver details to the tourist and explain the PIN verification process: "Your driver has a QR code. You have the PIN. Scan the QR or ask the driver to quote your PIN — works without internet."
 
 ### Step 10 — Record and follow up