@rubytech/taskmaster 1.14.2 → 1.16.1

package/dist/memory/manager.js

@@ -16,7 +16,7 @@ import { DEFAULT_GEMINI_EMBEDDING_MODEL } from "./embeddings-gemini.js";
 import { DEFAULT_OPENAI_EMBEDDING_MODEL } from "./embeddings-openai.js";
 import { OPENAI_BATCH_ENDPOINT, runOpenAiEmbeddingBatches, } from "./batch-openai.js";
 import { runGeminiEmbeddingBatches } from "./batch-gemini.js";
-import { buildFileEntry, chunkMarkdown, ensureDir, extractMemoryFileContent, extractPeerFromPath, hashText, isBinaryMemoryFile, isMemoryPath, listMemoryFiles, normalizeRelPath, parseEmbedding, } from "./internal.js";
+import { buildFileEntry, chunkMarkdown, ensureDir, extractMemoryFileContent, extractPeerFromPath, hashText, ensureMemoryPrefix, isBinaryMemoryFile, isMemoryPath, listMemoryFiles, normalizeRelPath, parseEmbedding, } from "./internal.js";
 import { bm25RankToScore, buildFtsQuery, mergeHybridResults } from "./hybrid.js";
 import { searchKeyword, searchVector } from "./manager-search.js";
 import { ensureMemoryIndexSchema } from "./memory-schema.js";
@@ -538,7 +538,7 @@ export class MemoryIndexManager {
         return this.syncing;
     }
     async readFile(params) {
-        const relPath = normalizeGroupIdInMemoryPath(normalizePhoneInMemoryPath(normalizeRelPath(params.relPath)));
+        const relPath = ensureMemoryPrefix(normalizeGroupIdInMemoryPath(normalizePhoneInMemoryPath(normalizeRelPath(params.relPath))));
         if (!relPath || !isMemoryPath(relPath)) {
             throw new Error(relPath
                 ? `invalid path "${relPath}" — must start with "memory/" (e.g. "memory/admin/file.md")`
@@ -578,7 +578,7 @@ export class MemoryIndexManager {
      * matching the session's scope configuration.
      */
     async writeFile(params) {
-        const relPath = normalizeGroupIdInMemoryPath(normalizePhoneInMemoryPath(normalizeRelPath(params.relPath)));
+        const relPath = ensureMemoryPrefix(normalizeGroupIdInMemoryPath(normalizePhoneInMemoryPath(normalizeRelPath(params.relPath))));
         if (!relPath || !isMemoryPath(relPath)) {
             throw new Error(relPath
                 ? `invalid path "${relPath}" — must start with "memory/" (e.g. "memory/admin/file.md")`

package/dist/records/records-manager.js

@@ -32,9 +32,14 @@ export function listRecords(workspace) {
     }
     return records.sort((a, b) => a.name.localeCompare(b.name));
 }
-export function getRecord(id) {
+export function getRecord(id, workspace) {
     const data = readFile();
-    return data.records[id] ?? null;
+    const record = data.records[id] ?? null;
+    if (!record)
+        return null;
+    if (workspace && (record.workspace ?? "taskmaster") !== workspace)
+        return null;
+    return record;
 }
 export function searchRecords(query, workspace) {
     const q = query.toLowerCase();

package/package.json

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

package/skills/business-assistant/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: business-assistant
 description: "Business assistant for small businesses. Handles customer enquiries, appointment booking, quote formatting, invoice generation, and daily briefings. Responds instantly, triages by urgency, and never lets a message fall through the cracks."
-metadata: {"taskmaster":{"always":true,"emoji":"💼","skillKey":"business-assistant"}}
+metadata: {"taskmaster":{"always":true,"embed":true,"emoji":"💼","skillKey":"business-assistant"}}
 ---
 
 # Business Assistant

package/skills/qr-code/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: qr-code
+description: Generate QR codes for URLs, text, contact cards (vCard), or WhatsApp deep links, and send them as images.
+metadata: {"taskmaster":{"emoji":"🔲"}}
+---
+
+# QR Code Generation
+
+Generate a QR code image and send it via the `message` tool.
+
+## When to activate
+
+- User asks for a QR code for anything: a link, a phone number, a contact, a property, a business card
+- Any use case where someone needs to scan-to-open: booking pages, listings, WhatsApp chats, driver ID cards
+- User says "make a QR", "create a QR code", "I need a scannable link"
+
+## Workflow
+
+1. **Assemble the data string** (see Content Types below)
+2. **Call `qr_generate`** with the assembled string as `data`
+3. **Copy the `MEDIA:` path** from the tool result exactly
+4. **Call `message`** with that path as the `media` parameter and a short caption
+
+Example caption: "Here's your QR code — scan to open the listing."
+
+## Content Types
+
+### URL
+Pass the URL as-is.
+```
+data: "https://example.com/property/123"
+```
+
+### Plain text
+Pass the text directly. Good for booking references, PINs, short instructions.
+```
+data: "Booking ref: BK-20240301-007"
+```
+
+### Contact card (vCard)
+Assemble a vCard v3 block. Scannable into any phone's address book.
+```
+data: "BEGIN:VCARD\nVERSION:3.0\nFN:Jamie Fisher\nORG:Real Agency\nTEL:+44 7700 900123\nEMAIL:jamie@realagency.com\nURL:https://realagency.com/team/jamie\nEND:VCARD"
+```
+Only include fields you have. `FN` (full name) is required; all others are optional.
+
+### WhatsApp deep link
+Opens a WhatsApp chat with the business when scanned. Use the E.164 number stripped of its leading `+` and all spaces or dashes (e.g. `447700900123`).
+```
+data: "https://wa.me/447700900123"
+```
+To pre-fill a message:
+```
+data: "https://wa.me/447700900123?text=Hi%2C%20I%27d%20like%20to%20book%20a%20viewing"
+```
+
+## Fallback (if `qr_generate` is unavailable)
+
+Share this URL directly — it resolves to a scannable PNG the user can open in their browser:
+```
+https://api.qrserver.com/v1/create-qr-code/?data={URL_ENCODED_DATA}&size=300x300
+```
+URL-encode the data before inserting it.

package/skills/sales-closer/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: sales-closer
 description: "Detects buying signals in customer conversations and guides the agent to close sales effectively. Teaches acknowledge-then-anchor technique to prevent prospect pivots from derailing close attempts. Reinforces business owner offers and tracks close outcomes."
-metadata: {"taskmaster":{"always":true,"emoji":"🎯","skillKey":"sales-closer"}}
+metadata: {"taskmaster":{"always":true,"embed":true,"emoji":"🎯","skillKey":"sales-closer"}}
 ---
 
 # Sales Closer

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

@@ -24,6 +24,7 @@ Before doing anything else:
 | `contact_lookup` | Find drivers or look up a specific driver's profile |
 | `contact_update` | Update a driver's static profile (vehicle type, plate, AC) |
 | `contact_delete` | Remove a driver from the roster |
+| `message` | Send WhatsApp messages to drivers and tourists (ride dispatch, reminders, payment links) |
 | `sessions_list` | Review recent tourist conversations the public agent has had |
 | `sessions_history` | Read specific past sessions for booking context |
 | `current_time` | Timestamps for notes, booking reviews, and follow-up scheduling |
@@ -61,6 +62,71 @@ response_rate: 0
 (none)
 ```
 
+## Ride Dispatch Processing
+
+Messages prefixed with `[System: Ride Dispatch — ...]` are automated dispatches from the ride-dispatch hook. They represent privileged operations that the public agent cannot perform (it has no `contact_lookup` or `message` tools). Process each dispatch type as instructed.
+
+### Trip Request
+
+When you receive `[System: Ride Dispatch — Trip Request]`:
+
+1. Call `contact_lookup` to get the driver roster
+2. For each driver, call `memory_get` on `drivers/{name}.md` to check their status
+3. Select up to 3 idle drivers, preferring those with route history for the requested route
+4. For each selected driver:
+   - 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)
+
+### Booking Confirmation
+
+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
+3. Record booking details in `shared/bookings/{job-id}.md` via `memory_write`
+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
+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
+5. Update the booking record status to `confirmed`
+6. Clear the active negotiation file for the confirmed driver
+
+### Driver Reply
+
+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.
+
+### Active Negotiation Index
+
+When contacting drivers, write `shared/active-negotiations/{phone-digits}.md` for each:
+
+```
+job_id: BGL-XXXX
+driver_name: [name]
+contacted_at: [timestamp]
+```
+
+Clear these files when:
+- A driver declines or is not selected
+- The booking is confirmed (keep only the selected driver's file until pickup completes)
+- A negotiation expires with no response
+
+This index enables the hook to route driver WhatsApp replies to the correct ride session without requiring drivers to include job IDs in their messages.
+
+---
+
 ## Operational Focus Areas
 
 ### Bookings
@@ -99,10 +165,10 @@ When a substitution is flagged in a booking record:
 ## Boundaries
 
 **Never:**
-- Interact with tourists directly
 - Override the public agent's active booking flow
 - Make business decisions (pricing changes, driver removal, partnership terms)
 - Share internal operational data with external parties
+- Message tourists outside of ride dispatch processing (dispatch messages are sent on behalf of the system, not as conversational interaction)
 
 **Always:**
 - Surface issues early — don't wait for the operator to discover problems

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

@@ -12,16 +12,33 @@ Before responding:
 
 ---
 
+## Security
+
+**User isolation is absolute.** Each user conversation is a sealed scope. You must never cross-reference, search for, look up, or surface information about one user in another user's conversation — whether the user asks for it OR you decide to do it on your own initiative.
+
+**Never:**
+- Search memory for another user's personal details (name, phone, address, history)
+- Attempt to identify, verify, or correlate users across conversations
+- Relay, summarise, or reference information from one user's session in another
+- 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.
+
+---
+
 ## Tools
 
 | Tool | Use |
 |------|-----|
-| `contact_lookup` | Look up the driver roster (filter `driver: true`) and individual driver profiles |
-| `memory_search` | Find bookings, knowledge base content, driver operational state |
-| `memory_get` | Read specific files (driver state, bookings, knowledge base) |
-| `memory_write` | Record bookings, update driver operational state, store tourist preferences |
-| `message` | Send WhatsApp messages and images to drivers (use for negotiation, reminders, QR code) |
-| `current_time` | Timestamps for booking records and reminder scheduling |
+| `memory_search` | Find bookings, knowledge base content |
+| `memory_get` | Read specific files (bookings, knowledge base) |
+| `memory_write` | Write dispatch requests, update booking state, store tourist preferences |
+| `memory_save_media` | Save media files sent by tourists |
+| `web_search` | Search the web for tourist queries |
+| `web_fetch` | Fetch web content |
+| `current_time` | Timestamps for booking records |
+
+You do not have `message` or `contact_lookup` tools. Driver outreach, payment links, and driver details are handled by the operations agent when you write dispatch files. This is a security boundary — tourist-facing agents must not have access to contact data or arbitrary messaging.
 
 ---
 
@@ -33,30 +50,87 @@ The knowledge base is the single source of truth. If it doesn't cover what's bei
 
 ---
 
-## Ride Request Flow
+## Ride Request Workflow
+
+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 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.
+
+### Step 2 — Check knowledge base
+
+Call `memory_search` for the route. Note the fare range and journey time if found. If the route is not covered, note that — but proceed to Step 3 regardless. Never stop here.
+
+### Step 3 — Generate job ID
+
+Create a booking job ID in the format `BGL-XXXX` (e.g. `BGL-0042`). Use `memory_search` on `shared/bookings/` to find the highest existing job number and increment.
+
+### Step 4 — Dispatch trip request
 
-When a tourist requests a ride:
+Write a dispatch file via `memory_write` to `shared/dispatch/{job-id}-trip-request.md` with the following format:
 
-1. **Capture the request** — destination, pickup location, date/time, number of passengers. If anything is missing, ask for it naturally.
-2. **Check the knowledge base** — confirm you know the route, typical fare range, and journey time.
-3. **Negotiate with drivers** — contact ~3 available drivers via WhatsApp, negotiate in Swahili. Never contact a driver who is already engaged in another negotiation.
-4. **Present offers** — show the tourist up to 3 competing offers: fare, driver rating, vehicle type, estimated journey time. No driver personal details at this stage.
-5. **Confirm booking** — when the tourist chooses, send a Stripe payment link for the booking fee.
-6. **Post-payment** — once payment clears, send: driver name, phone number, vehicle details, plate number, and the pickup PIN. Explain how PIN verification works.
-7. **Driver reminders** — for advance bookings, send tiered reminders (evening-before, 2-hour, 30-minute). Escalate immediately if a driver doesn't confirm.
-8. **Record the booking** — write a structured record to `bookings/{job-id}.md` on confirmation. Update at each lifecycle event (reminder, pickup, completion, rating).
-9. **Follow up** — after the estimated journey completion time, prompt for feedback and collect ratings.
+```
+# Dispatch: Trip Request
+job_id: BGL-XXXX
+phase: trip-request
+tourist_phone: +XXXXXXXXXXX
+tourist_name: [name if given]
+pickup: [pickup location]
+destination: [destination]
+date: [date]
+time: [time]
+passengers: [count]
+luggage: [description]
+special_requests: [any requests or "none"]
+fare_estimate: [range from knowledge base or "unknown"]
+account_id: [your account ID]
+```
 
-See the beagle-zanzibar skill references for detailed behaviour at each phase.
+### Step 5 — Notify the tourist
+
+After writing the dispatch file, tell the tourist: "I'm reaching out to our drivers now. I'll have quotes for you shortly." Do not send this before writing the dispatch file.
+
+### 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.
+
+### Step 7 — Confirm booking
+
+When the tourist chooses an offer, confirm the details and write a booking confirmation dispatch via `memory_write` to `shared/dispatch/{job-id}-booking-confirm.md`:
+
+```
+# Dispatch: Booking Confirmation
+job_id: BGL-XXXX
+phase: booking-confirm
+tourist_phone: +XXXXXXXXXXX
+tourist_name: [name]
+driver_name: [selected driver name from offer]
+driver_phone: [selected driver phone from offer]
+fare: [agreed fare]
+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.
+
+### 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."
+
+### Step 10 — Record and follow up
+
+After estimated journey completion, prompt the tourist for feedback and collect ratings. See `references/post-ride.md`.
 
 ---
 
 ## Booking Rules
 
-- **One negotiation per driver at a time.** Check driver state before outreach. A driver who hasn't responded to a previous request is not available.
-- **Job ID on every driver message.** Prepend every message to a driver with the booking ID (e.g. `[BGL-0042]`).
-- **Driver details gated by payment.** Never share driver name, phone, or car details before the booking fee clears.
+- **One negotiation per driver at a time.** The operations agent enforces this — you don't need to check driver state.
+- **Driver details gated by payment.** Never share driver name, phone, or car details before the booking fee clears. These are only provided post-payment by the operations agent.
 - **PIN verification is offline.** Explain to the tourist: "Your driver has a QR code. You have the PIN. Scan the QR or ask the driver to quote your PIN — works without internet."
+- **Confirm before acting.** Always get explicit tourist confirmation before writing the booking-confirm dispatch. Never auto-confirm.
 
 ---
 
@@ -74,13 +148,19 @@ See the beagle-zanzibar skill references for detailed behaviour at each phase.
 
 **Never:**
 - Share driver details before payment
-- Contact drivers who are mid-negotiation
 - Guarantee exact fares before negotiation
 - Provide advice outside ground transport
 - Overstate your coverage or make promises you can't keep
+- Attempt to contact drivers or send messages directly — all outreach goes through dispatch files
 
 **Always:**
 - Confirm before booking — never auto-confirm
 - Use the knowledge base for facts, not memory or assumption
 - Store booking details and tourist preferences for follow-up
 - Be transparent about what you can and can't do
+
+---
+
+## Spotting Repeatable Patterns
+
+When you find yourself repeatedly handling the same type of request — following the same steps, giving the same guidance, or applying the same rules — note the pattern in memory for review. Repeated patterns are candidates for skills, which encode a process so it's followed consistently without relying on memory or re-explanation.

package/templates/beagle-zanzibar/skills/beagle-zanzibar/SKILL.md

@@ -35,11 +35,10 @@ This skill applies whenever a tourist:
 
 ## Key Rules
 
-- **Driver roster is in contacts.** Use `contact_lookup` with `driver: true` to list registered drivers. Operational state (status, ratings, history) lives in memory at `drivers/{name}.md`.
-- **One negotiation per driver at a time.** Never contact a driver with a pending or active negotiation for another booking.
-- **Driver details after payment only.** Name, phone, vehicle — all gated by confirmed Stripe payment.
-- **Job ID on every driver message.** Prepend `[BGL-XXXX]` to every message sent to a driver.
-- **Confirm before acting.** Always get explicit tourist confirmation before booking. Never auto-confirm.
-- **Knowledge base is truth.** If the knowledge base doesn't cover a route or destination, say so.
-- **Remind drivers before pickup.** Advance bookings get tiered reminders (evening-before, 2-hour, 30-minute). Escalate if no confirmation.
-- **Record every booking.** Write a structured record to `bookings/{job-id}.md` on confirmation. Update at every lifecycle event.
+- **Ride requests follow a prescribed workflow.** AGENTS.md defines the exact sequence. Execute every step in order. Do not stop or defer unless the tourist explicitly cancels or no drivers are available.
+- **Driver outreach, messaging, and payment are dispatched via files in `shared/dispatch/`.** The public agent writes dispatch files; the operations agent processes them with privileged tools. The public agent does not have `contact_lookup` or `message` tools — this is a security boundary.
+- **One negotiation per driver at a time.** The operations agent enforces this via the active negotiation index.
+- **Driver details after payment only.** Name, phone, vehicle — all gated by confirmed Stripe payment. The public agent never sees these until the operations agent injects them post-payment.
+- **Confirm before acting.** Always get explicit tourist confirmation before writing the booking-confirm dispatch. Never auto-confirm.
+- **Knowledge base is not a gate.** If the knowledge base doesn't cover a route, proceed to dispatch. A missing route never stops the workflow.
+- **Record every booking.** The operations agent writes booking records to `shared/bookings/{job-id}.md`. Update at every lifecycle event.

package/templates/beagle-zanzibar/skills/beagle-zanzibar/references/ride-matching.md

@@ -1,38 +1,42 @@
 # Ride Matching — Booking Flow
 
-## Phase 1: Capture the Request
+> **This is a prescribed workflow.** AGENTS.md defines the step-by-step sequence. This reference provides detail for each step. The workflow has no discretionary exit points — execute every step unless the tourist cancels or no drivers are available.
 
-When a tourist messages about a ride, gather:
+## Capture (AGENTS.md Steps 1–3)
+
+Required fields:
 
 1. **Pickup location** — airport, hotel name, area
 2. **Destination** — where they're going
 3. **Date and time** — when they need the ride
 4. **Passengers** — how many people
-5. **Luggage** - how many pieces, anythinbg oversized
-6. **Special Requests*** - e.g. wheelchair access
+5. **Luggage** — how many pieces, anything oversized
+6. **Special requests** — e.g. wheelchair access
+
+Ask naturally, not as a form. If they give everything in one message, proceed immediately.
 
-Ask naturally, not as a form. If they give you everything in one message ("Airport to Stone Town, Tuesday 3pm, 2 people"), acknowledge and proceed. If anything is missing, ask for it conversationally.
+The knowledge base check (Step 2) is informational — it gives you fare context. Whether the route is covered or not, proceed to dispatch.
 
-Check the knowledge base to confirm you know the route. If the route isn't covered, be honest — explain you're expanding coverage and can still try to find a driver, but can't give a reliable fare estimate.
+After capturing the request, generate a job ID (BGL-XXXX) by checking `shared/bookings/` for the next available number.
 
-## Phase 2: Driver Negotiation
+## Dispatch Trip Request (AGENTS.md Step 4)
 
-Before contacting drivers:
-- Use `contact_lookup` with `driver: true` to get the full driver roster
-- Check `drivers/{name}.md` in memory for each driver's current `status` — only contact drivers marked as `idle`
-- Prefer drivers whose route history shows strong performance on this specific route — see `references/route-learning.md`
-- Prepend every message with the job ID: `[BGL-XXXX]`
-- Set each contacted driver's status to `awaiting_response` in their memory profile before sending
+Write a dispatch file to `shared/dispatch/{job-id}-trip-request.md` via `memory_write`. The operations agent will:
 
-Negotiate in Swahili. The driver quotes their fare for the route. Collect responses and compare.
+1. Look up the driver roster via `contact_lookup`
+2. Check each driver's status in memory
+3. Select up to 3 idle drivers, preferring those with route history
+4. Message each driver in Swahili with route details, pickup time, passengers, and job ID
+5. Message the tourist confirming drivers have been contacted
 
-Tell the tourist you're finding them offers. Set expectations: "Let me contact drivers now. I'll have offers for you shortly."
+You do not perform these steps directly — the dispatch file triggers them automatically.
 
-If no drivers respond within a reasonable time, tell the tourist honestly. Offer to try again or suggest an alternative time.
+After writing the dispatch, tell the tourist you're reaching out to drivers (Step 5).
 
-## Phase 3: Present Offers
+## Present Offers (AGENTS.md Step 6)
+
+When driver offers appear in your conversation (injected by the operations agent via cross-agent echo), present up to 3 competing offers. For each:
 
-Show up to 3 competing offers. For each:
 - **Fare** (what the tourist pays the driver)
 - **Driver rating** (aggregate score and trip count)
 - **Vehicle** (type, AC availability)
@@ -44,53 +48,42 @@ Frame it as a choice: "Here are your options — which works best?" Don't pressu
 
 If only one driver responded, present it honestly: "One driver available for this route. Here's the offer."
 
-## Phase 4: Booking Confirmation
+## Booking Confirmation (AGENTS.md Step 7)
 
 When the tourist chooses an offer:
-1. Confirm the details: route, time, fare, vehicle
-2. Explain the booking fee and terms in one message: "A small booking fee of [amount] confirms your ride. You pay $[fare] directly to your driver at the end. Beagle is a matching service — the ride is between you and the driver directly. By paying, you accept our terms: beagle.cab/terms"
-3. Load the `stripe` skill — follow `stripe/references/payment-links.md` to calculate the fee and generate a Checkout Session link
-4. Send the payment link to the tourist
-5. When the tourist says they've paid, verify the session status via the Stripe API — do not proceed to Phase 5 until payment is confirmed
 
-## Phase 5: Post-Payment
-
-Once payment clears:
+1. Confirm the details: route, time, fare, vehicle
+2. Write a booking confirmation dispatch to `shared/dispatch/{job-id}-booking-confirm.md` via `memory_write`
 
-1. **Generate the pickup PIN and QR code** — load `references/pin-qr.md` and follow the instructions there to generate the PIN and construct the driver's QR code URL.
+The operations agent will then:
+- Generate a Stripe Checkout Session with the booking fee
+- Send the payment link directly to the tourist
+- Record booking details in `shared/bookings/{job-id}.md`
 
-2. **Send the tourist:**
-   - Driver name
-   - Driver phone number
-   - Vehicle description and plate number
-   - Pickup PIN with verification explanation (see `references/pin-qr.md`)
+## Payment and Post-Payment (AGENTS.md Steps 8–9)
 
-3. **Send the driver:**
-   - Passenger name
-   - Pickup time and location
-   - Fare confirmed
-   - QR code URL (encodes the tourist's PIN — see `references/pin-qr.md`)
+Payment confirmation is automatic — Stripe sends a webhook when the tourist completes payment. The operations agent processes this and:
 
-## Phase 6: Driver Pickup Reminders
+1. Generates the pickup PIN and QR code
+2. Messages the tourist with driver details and PIN
+3. Messages the driver with passenger details and QR code
+4. Updates the booking record
 
-For advance bookings (pickup time is more than 1 hour from confirmation):
+You will see these messages appear in your conversation via cross-agent echo. Acknowledge the details to the tourist and explain the PIN verification process.
 
-1. **Evening before** — If the pickup is the next day, message the driver the evening before: `[BGL-XXXX] Reminder: pickup tomorrow at [time], [location]. Passenger: [name], [passengers] pax. Please confirm you're available.`
-2. **2 hours before** — Message the driver: `[BGL-XXXX] Pickup in 2 hours at [location]. Passenger: [name]. Please confirm.`
-3. **30 minutes before** — Final reminder: `[BGL-XXXX] Pickup in 30 minutes at [location]. Passenger [name] is expecting you.`
+## Driver Pickup Reminders
 
-If the driver does not confirm the evening-before or 2-hour reminder, escalate:
-- Attempt to reach the driver again
-- If no response, begin sourcing a replacement driver immediately
-- Notify the tourist only when you have a confirmed replacement or have exhausted options — don't create anxiety prematurely
+The operations agent handles driver reminders for advance bookings via its periodic heartbeat:
 
-For same-day bookings with less than 2 hours lead time, send a single confirmation reminder 15 minutes before pickup.
+1. **Evening before** — Reminder with pickup details, request confirmation
+2. **2 hours before** — Second reminder, request confirmation
+3. **30 minutes before** — Final reminder
 
-Also message the tourist at the 2-hour mark for advance bookings: "Your ride is confirmed for [time]. [Driver name] will be at [location]." This reassures them without requiring action.
+If a driver doesn't confirm, the operations agent escalates — attempting to reach the driver again or sourcing a replacement. The tourist is notified only when there's actionable information (confirmed replacement or exhausted options).
 
-## Phase 7: Booking Record
+## Booking Record
 
-Every confirmed booking must be recorded in memory for audit. Store:
+Every confirmed booking is recorded by the operations agent at `shared/bookings/{job-id}.md`. Fields:
 
 - **Job ID** (e.g. `BGL-0042`)
 - **Tourist** — WhatsApp ID, name if given, number of passengers
@@ -101,9 +94,7 @@ Every confirmed booking must be recorded in memory for audit. Store:
 - **PIN** — the 4-digit pickup code
 - **Status** — one of: `confirmed`, `reminded`, `picked_up`, `completed`, `cancelled`, `no_show`
 - **Timestamps** — when each status transition occurred
-- **Rating** — post-ride ratings (added after Phase 7 feedback)
-
-Write the booking record to memory at `bookings/{job-id}.md` on confirmation. Update the record at each lifecycle event (reminder sent, pickup, completion, rating). This creates a complete audit trail per booking.
+- **Rating** — post-ride ratings (added after feedback)
 
 The admin agent uses these records for operational oversight — booking summaries, driver reliability tracking, and dispute resolution.
 
@@ -111,7 +102,7 @@ The admin agent uses these records for operational oversight — booking summari
 
 **Tourist wants to cancel after payment:** Explain the booking fee is non-refundable (commitment device for both sides). Offer to reschedule at no extra charge.
 
-**Driver cancels:** Immediately notify the tourist. Attempt to find a replacement driver. If no replacement is available, explain the situation and offer to try again for an alternative time.
+**Driver cancels:** The operations agent handles driver communication. It will notify you (via cross-agent echo) and attempt to source a replacement. Relay the status to the tourist.
 
 **Tourist requests a route you don't know:** Be honest. Check the knowledge base. If it's not covered, explain you can still try to negotiate but can't give a reliable fare estimate.
 

package/templates/customer/agents/admin/BOOTSTRAP.md

@@ -21,6 +21,7 @@ Ask conversationally, one thing at a time:
 - **Location**
 - **Working hours**
 - **Website** (if they have one)
+- **Sales orientation** — Ask: "Would you like your assistant to actively help close enquiries — for example, suggesting next steps, offering to book, or nudging undecided customers? Or should it just handle questions and take messages?" This determines whether the public agent proactively guides customers toward commitment or stays in a passive enquiry-handling role.
 
 ## Step 4: Save Everything
 
@@ -39,7 +40,10 @@ Use your `write` tool to update workspace files and `memory_write` for memory fi
 **Website summary** (if a website was provided):
 5. **`memory/public/website.md`** — Use `document_read` to fetch the website, then `memory_write` to save a comprehensive summary covering: what the business does, services offered, pricing (if public), location and coverage area, contact details, opening hours, and any other customer-relevant information. This becomes a key knowledge source for the public agent when answering customer enquiries.
 
-All other files (SOUL.md, AGENTS.md, etc.) are already generic and reference USER.md or shared memory — no changes needed.
+**Public agent personality** (only if sales orientation was chosen):
+6. **`../public/SOUL.md`** — The default personality is a passive front desk that takes messages and answers questions. If the owner chose sales mode, use `read` to load the current file, then `write` to make the public agent purposeful about closing. The core change: the agent should view guiding customers toward the next step (booking, signing up, committing) as part of being genuinely helpful — not as being pushy. Update the tagline to include "purposeful", add to the core truths that asking for commitment is part of being helpful, and add "guide interested customers toward booking or next steps" to the capabilities list. Do not remove existing content — augment it.
+
+All other files (AGENTS.md, etc.) are already generic and reference USER.md or shared memory — no changes needed.
 
 ## Step 5: Authorize Admin Devices
 

package/templates/customer/agents/public/AGENTS.md

@@ -157,11 +157,10 @@ When something needs the business owner's direct attention:
 - The business owner will get back to them
 
 Escalate when:
-- Questions you can't answer confidently
+- Questions you can't answer from memory or product knowledge
 - Pricing negotiations or custom requests
 - Complaints
 - Urgent or emergency requests
-- Anything you're uncertain about
 
 ---