E2E Test: Quoting Flow (Browser)

Manually test the quoting pipeline end-to-end via Gmail in the browser. Includes full verification of the task-based UI/UX where every buyer-blocking interaction creates an escalation or suggestion task linked to the RFQ and/or quote.

Port & Container Variables

This skill uses {{...}} placeholders throughout. You MUST resolve these before running any command.

Parse the xudo wt add output to get the values, then substitute:

Placeholder	How to resolve	Main env default
`{{NEXT_PORT}}`	`Next.js: http://localhost:<PORT>` from xudo output	`3000`
`{{API_PORT}}`	`FastAPI: http://localhost:<PORT>` from xudo output	`8000`
`{{DB_NAME}}`	`Database: <NAME>` from xudo output	`didero`
`{{API_CONTAINER}}`	Run `docker ps --format '{{.Names}}' \| grep fast-api-wt`	`didero-fast-api`
`{{DOCKER_COMPOSE}}`	`docker compose -f <worktree_path>/docker-compose.worktree.yml`	`docker compose`

Every command in this file uses these placeholders. If you see a literal {{...}} in a command you're about to run, STOP and substitute it first.

Video Recording

To record the E2E flow as a video (for demos or debugging), start ffmpeg before running:

ffmpeg -f avfoundation -framerate 30 -i "4:none" -vf "scale=1920:-2" \
  -c:v libx264 -preset ultrafast -crf 23 -pix_fmt yuv420p \
  e2e-screenshots/demo-recording.mp4

Press q to stop recording when done. This captures the full screen regardless of window focus.

Future: If we switch from Chrome DevTools MCP to Playwright for browser automation, Playwright has native video recording via browser.newContext({ recordVideo: { dir: '...' } }) — see https://playwright.dev/docs/videos#record-video. This would record only the browser viewport (not full screen) and wouldn't require ffmpeg.

Prerequisites

Check all of these before proceeding. Run the checks in parallel where possible.

Browser: Chrome automation tools must be available (e.g. mcp__claude-in-chrome__* tools). {{codex:If not available, ask one concise plain-text question with these options:||claude:If not available, use AskUserQuestion to ask how they'd like to proceed:}}
- Use Chrome DevTools MCP instead — fall back to the Chrome DevTools MCP server (mcp__chrome-devtools__* tools)
- Enable Claude Chrome MCP and retry — in the Claude VSCode extension's native UI, type @browser to enable it, then re-run this command
- Provide custom browser instructions — let the user give ad-hoc instructions on how to proceed with browser automation
- Skip browser use entirely — attempt to proceed without any browser automation (log checks only, no Gmail interaction)
Tunnel: ./scripts/start-tunnel.sh must be running. Check if it's already running (e.g. pgrep -f start-tunnel). Only start it if no existing process is found.
Docker: docker compose up must be running.
- If not running, start it with docker compose up -d and tell the user: "Docker containers starting — you may want to run docker compose logs -f to monitor."
- If already running, rebuild first with docker compose up --build -d to pick up any code changes. Wait for the rebuild to complete before proceeding.
Frontend: bun dev must be running in the next/ directory. Check if it's already running (e.g. check if the dev port is listening). If not, tell the user: "Please run cd next && bun dev in a separate terminal, then re-run this command." Do NOT start it yourself — dangling dev servers are painful to clean up.
Gmail account: bt@didero.ai

Foreground vs Background

Before starting the test, ask the user whether to run in the foreground or background.

Use the host's native question/prompt UI when available; otherwise ask in concise plain text.

Present foreground (recommended) first, then background as the second option.

Foreground (recommended) — run the test directly in the main conversation (no subagent). All tool calls, screenshots, logs, and DB checks happen inline. This gives the user full visibility and control.
Background — launch the quoting-e2e-tester subagent to run the test. Subagent context is completely isolated from the main conversation — tool calls, screenshots, and logs stay in the subagent's context window and never enter the main thread. Only a final summary is returned when the subagent finishes. The main conversation stays free for other work, but the tradeoff is less visibility into test progress.

If the user already made the choice explicit in their request (e.g. "run it in the background"), respect that without asking.

Execution Mode

Before starting the test, first check whether the user already made the execution mode explicit in the request or surrounding context.

Treat direct context such as in a xudo wt, inside a xudo wt, start a new xudo wt, or equivalent wording as an explicit choice of the fresh-new-xudo wt path.

Treat direct context such as already-prepared environment, existing worktree, or equivalent wording as an explicit choice of the prepared-environment path.

Only if the mode is still genuinely ambiguous should you explicitly ask the user whether this run should:

start in a fresh new xudo wt, or
use an already-prepared environment

If you need to ask, do so neutrally. Do not mark either option as recommended. When the host exposes a native question/prompt UI, use that UI directly for this decision instead of a plain-text question or commentary preamble.

Only the fresh-new-xudo wt path may assume a fresh DB instance.

If the user chooses a fresh new xudo wt, you MUST bootstrap quoting before any Gmail RFQ steps.

Before the bootstrap work begins, ask one concise follow-up whether to use SQL bootstrap (recommended) or manual browser bootstrap. Use the host's native question/prompt UI when it is available; otherwise ask in concise plain text.

If the user chooses SQL bootstrap (recommended):

Run cat /Users/briantu/.codex/skills/quoting-e2e-tester/references/fresh-wt-bootstrap.sql | docker exec -i didero-db-1 psql -U postgres -d {{DB_NAME}}
Treat the SQL path as responsible for the quoting feature flag, contractor role, initial allowlist rows, and the bt+buyer@didero.ai user record (needed for task assignment/resolution)
Do NOT rely on the SQL path to clone, validate, or select the quoting connection
After the SQL finishes, continue with the browser steps for the quoting connection itself before moving on

If the user chooses manual browser bootstrap:

Sign in as the internal admin lx@didero.ai / password
Go to http://localhost:{{NEXT_PORT}}/admin/developers/feature-flags and create the quoting flag with Enabled by default
Go to http://localhost:{{NEXT_PORT}}/admin/teams/9c5cb580-9e93-4a2f-9518-3e012c4c9bef, change Didero-1 Contractor to Team Admin, then impersonate that user
Go to http://localhost:{{NEXT_PORT}}/settings/team?tab=quoting and complete the Connect Gmail flow
Go to http://localhost:{{NEXT_PORT}}/settings/team?tab=email-allowlist and ensure these addresses are present in the team allowlist:
- bt@didero.ai
- bt+buyer@didero.ai
- bt+2@didero.ai
- bt+3@didero.ai
- bt+4@didero.ai
Create the bt+buyer@didero.ai user record for task assignment/resolution. Go to http://localhost:{{NEXT_PORT}}/admin/teams/9c5cb580-9e93-4a2f-9518-3e012c4c9bef and use the "Add immediately" flow to add a user with email bt+buyer@didero.ai and name Buyer. This user is needed so the quoting agent can assign tasks to the buyer persona and resolve tasks on their behalf.

Only after that bootstrap succeeds should you continue with the normal E2E steps below.

On fresh-worktree runs, an empty nylas_connection table or otherwise missing quoting/email connection state before bootstrap is expected and is not a blocker by itself. Do not stop or report failure for missing quoting/email connection state until the bootstrap flow above has been attempted.

If the user chooses an already-prepared environment, do not run the bootstrap automatically.

If the user chooses a fresh new xudo wt, then after the worktree has been created successfully and its branch/worktree identity is known, offer one additional concise follow-up: whether to run ~/.claude/skills/xudo-wt-dbeaver/SKILL.md to add the matching DBeaver connection for that worktree. Use the host's native question/prompt UI when it is available; otherwise ask in concise plain text.

Keep that offer neutral, treat it as best-effort local tooling, and do not block the quoting run on it. If the user says yes, run the DBeaver sync before moving on to browser/bootstrap work. If the user says no or the local DBeaver tooling is unavailable, continue the quoting E2E normally.

Mail-send Surface

If a gws CLI path is available, or the user explicitly asked for it, ask one concise follow-up whether to use gws CLI for mail sends (recommended) or manual browser actions for mail sends. Present gws first. Use the host's native question/prompt UI when it is available; otherwise ask in concise plain text.

If the user chooses gws:

Use it for buyer-side sends by default
Use it for supplier sends only when it can issue a true Gmail API reply with the original threadId, matching In-Reply-To / References headers, the correct sender alias, and the bt@didero.ai recipient fixup
Fall back to the documented Gmail browser workflow for any step that still needs Gmail-only interaction, attachment handling, or verification that gws cannot provide

Buyer RFQ documents

Before composing the buyer RFQ, determine whether this run includes buyer-side document attachments such as an RFQ PDF.

If the user already made that attachment choice explicit, do not ask again.

If the attachment choice is still ambiguous, ask one concise follow-up whether to send the buyer RFQ with no documents or with attached document(s). Use the host's native question/prompt UI when it is available for that yes/no choice; otherwise ask in concise plain text.

If document(s) are requested:

Use /Users/briantu/.codex/skills/quoting-e2e-tester/references/rfq-sample.pdf as the default sample attachment for fixture-based runs, or collect alternate absolute local file path(s) and expected filename(s) before compose/send begins
Confirm the file(s) exist and are readable before opening the attachment picker
Keep supplier identities and other routing context in the buyer email body; the attachment should contain only the quoted requirements being requested
Do not invent, regenerate, or silently skip the document if the path is missing; stop and ask for the correct path or updated instructions
Treat attachment upload and sent-thread attachment visibility as part of the buyer-send verification, not as optional evidence
If the chosen mail surface cannot attach and verify the requested document(s), use the Gmail browser workflow for the buyer RFQ step

Login & Impersonation

To test the quoting UI from the buyer's perspective:

Sign in as the admin: lx@didero.ai / password

Impersonate Buyer (bt+buyer@didero.ai) from Admin > Users > ... menu > Impersonate

The buyer user must exist in the DB before impersonation (created by the SQL bootstrap or manual browser bootstrap step 6)

If the ... menu doesn't open via the a11y tree click, use the Better Auth API directly:

// First get the user ID
const res = await fetch('/api/auth/admin/list-users?limit=50', { credentials: 'include' });
const { users } = await res.json();
const buyer = users.find(u => u.email === 'bt+buyer@didero.ai');
// Then impersonate
await fetch('/api/auth/admin/impersonate-user', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ userId: buyer.id }),
  credentials: 'include',
});

Navigate to the page you want to test (e.g. /quoting, /)

UI Verification Philosophy

Check the UI at every intermediate step, not just at the end. After each major agent action (RFQ created, suppliers added, quotes created, fanout completed, supplier responded, task created, task resolved), navigate to the relevant UI page and take a screenshot to verify the data appears correctly. This catches rendering bugs, missing data, and stale cache issues early.

Verification Cadence

Do not treat validation as an end-of-run sweep. For every major action in this workflow, complete the validation loop before moving on:

Confirm the Gmail-side action actually happened.
Check the relevant backend logs.
Check the relevant DB rows and status transitions.
Check for task creation/resolution — query the task, task_rfq, task_quote, and task_email tables when the step involves a buyer-blocking interaction.
Check the relevant user-facing UI state (/quoting, /, settings, or the Gmail thread itself).
Verify task rows in the quoting UI — RFQ-level tasks above the supplier table, quote-level tasks under their supplier row with teal/primary styling.
Check GCP or Cloud Task side effects when the step depends on queueing, scheduling, or fanout.
Verify "Manage this task in Didero" footer in buyer-facing emails that are linked to tasks.

Use that cadence after:

buyer RFQ send
buyer follow-up send
buyer confirmation send (also check task resolution for supplier-approval task)
supplier creation / quote creation
outbound supplier RFQ send
each supplier reply
orchestrator comparison send (also check comparison task creation)
every buyer-blocking interaction that creates a task (supplier approval, clarification, comparison, deadline, escalation)
every task resolution (via email reply or in-app action)

If one layer disagrees with another, stop and record the mismatch instead of advancing as if the step passed.

Task Verification Helper

Use this query template after every step where a task should be created or resolved. Substitute $RFQ_ID with the actual RFQ ID.

List tasks for an RFQ:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, t.summary, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 10;
"

Verify task-email linkage:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id as task_id, t.task_type, t.status, te.email_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_email te ON te.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 10;
"

Verify task junction tables:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id as task_id, t.task_type, tr.rfq_id, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 10;
"

Task UI Verification Helper

When checking the /quoting page for task rows:

RFQ-level tasks (no linked quote) appear above the supplier table in the accordion area. Look for task rows with title, description, confidence score, and action buttons (Accept / Dismiss).
Quote-level tasks (linked to a specific quote via task_quote) appear as indented rows under their supplier's quote row in the supplier table, styled with teal/primary background color.
Tasks have a quote_id field in the API response for grouping — this determines whether they render at RFQ-level or quote-level.
Verify that task rows show:
- Title text
- Description/summary text
- Confidence score (if present)
- Action buttons — these differ by task type:
  - Escalation tasks (task_type = escalation): render as TaskRow (checkbox + Dismiss + expand caret). All actions open the sidebar. The sidebar content depends on escalation subtype:
    - Buyer-side escalation (RFQ-level, no linked quote): Sidebar shows "AGENT NEEDS YOUR INPUT" with the escalation context and an answer/context textarea. The buyer types their answer and clicks "Submit Answer". The agent then posts the answer in the source buyer thread (blockquoted, Zendesk-style) and proceeds. The buyer can also resolve by replying directly in the buyer email thread.
    - Supplier-side escalation (quote-level, linked to a specific quote): Sidebar shows "REPLY TO SUPPLIER" email compose form with To (supplier), CC (buyer), Subject (threaded reply), and the escalation context blockquoted. The buyer composes and sends an email to the supplier via the agent. The buyer can also resolve by replying directly in the supplier email thread (they are CC'd on the escalation email), which triggers auto-resolve.
  - Suggestion tasks (task_type = suggestion): show "Send Email" and "Dismiss" buttons. Clicking "Send Email" opens an email compose modal (reused from PO management) pre-filled with the draft email subject/body from the suggestion's draft_email_subject and draft_email_body fields.

Escalation Flow Verification

Buyer-Side Escalation (agent needs info from buyer)

This flow occurs when the agent cannot proceed because the buyer's RFQ is missing information (e.g. weight, dimensions, commodity details).

Agent processes buyer's RFQ email and determines it needs more info
Agent calls reply_to_buyer() asking for clarification in the source thread AND create_escalation() with rfq_id (no quote_id) to create an escalation task
Verify: escalation task exists in DB with task_type = "escalation", linked to RFQ via task_rfq but NOT to any quote via task_quote, and has NO send_email action in the action table
Verify: quoting UI shows the task as a TaskRow at RFQ level (above supplier table)
Click the task → sidebar opens with "AGENT NEEDS YOUR INPUT" header, escalation context, and answer textarea
Resolution path A (UI): Type answer in textarea, click "Submit Answer" → task resolves with note containing the answer → agent posts answer in buyer thread
Resolution path B (email): Buyer replies directly in the buyer email thread → agent picks up the reply and resolves the escalation

Supplier-Side Escalation (supplier asked a question)

This flow occurs when a supplier responds with questions or conditions the agent cannot answer (e.g. liftgate requirements, packaging details).

Supplier replies to the RFQ with a conditional quote or questions
Agent processes the supplier reply and determines it needs buyer input
Agent calls create_escalation() with both rfq_id and quote_id → creates task with send_email action (To: supplier, CC: buyer, Subject: threaded reply, Body: escalation context blockquoted)
Verify: escalation task exists in DB linked to BOTH RFQ and quote, with send_email action
Verify: quoting UI shows the task as a TaskRow at quote level (under the supplier's row)
Click the task → sidebar opens with "REPLY TO SUPPLIER" email compose form pre-filled
Resolution path A (UI): Buyer composes and sends email via Didero → email sent to supplier with buyer CC'd → task resolves
Resolution path B (email auto-resolve): Buyer replies directly in the supplier thread (they were CC'd on the escalation email) → agent detects buyer reply in supplier thread → escalation task auto-resolves → supplier agent still processes the email content

Auto-Resolve Verification

After a buyer replies directly in a supplier thread where an open escalation exists:

Query task table to confirm the escalation task status changed from "open" to "accepted"
Verify the resolution happened automatically (no UI interaction needed)
Verify the supplier agent still processed the buyer's reply (the email content should be available to the agent)

Email Footer Verification

After each buyer-facing email that is linked to a task, verify the email body contains a "Manage this task in Didero" footer with a link to /quoting. This can be checked in Gmail or via DB:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.subject, sel.body LIKE '%Manage this task in Didero%' as has_task_footer
  FROM sent_email_log sel
  WHERE sel.rfq_id = '$RFQ_ID'
  ORDER BY sel.created_at DESC
  LIMIT 5;
"

Parallel Supplier Reply Phase

Once supplier fanout is fully confirmed, the supplier reply phase may run in parallel.

When the run has the standard three-supplier shape (bt+2@didero.ai / TwoCo, bt+3@didero.ai / ThreeCo, and bt+4@didero.ai / FourCo), treat that as the default parallelization target.

If the host tooling supports delegated workers and a distinct browser tab or isolated browser context per worker, launch exactly 3 supplier workers after fanout confirmation: one for bt+2@didero.ai, one for bt+3@didero.ai, and one for bt+4@didero.ai.

If the host tooling cannot give each worker a distinct tab or context, do not force parallel supplier workers. Keep supplier Gmail actions serialized in the main agent or in manually managed tabs owned by the main agent.

Fanout is considered fully confirmed only when all of the following are true:

the buyer approval step is complete
the actual supplier set is known
outbound supplier RFQ emails are visible in Gmail
quote rows exist for every supplier in scope
the Quote Manager UI shows the same supplier set for the RFQ

After those conditions hold, it is valid to split supplier replies by supplier and run them concurrently in separate browser tabs, separate browser contexts, or separate subagents when the host tooling supports that cleanly.

Parallel-phase rules:

Keep one owner per supplier. A worker that owns bt+2@didero.ai / TwoCo must not touch bt+3@didero.ai / ThreeCo, and so on.
Keep one shared owner for the non-supplier phases. The main agent remains responsible for the checklist, buyer-side phases, fanout verification, final comparison verification, and the final PASS / PARTIAL / FAIL report.
Require isolated browser contexts when available. If the browser surface cannot isolate concurrent Gmail work reliably, separate tabs are acceptable, but each worker must claim and keep one dedicated tab for exactly one supplier thread.
Each supplier worker must still run the full validation loop for its supplier before reporting success:
- verify From
- verify recipient fixup to bt@didero.ai
- confirm Gmail send
- confirm backend ingress
- confirm quote status and parsed details in DB
- confirm Quote Manager UI state
- confirm any task creation triggered by this supplier reply (escalation or suggestion)
Before acting, each supplier worker must record the browser tab or context it owns. If it cannot prove distinct browser ownership, stop that worker and report a blocker instead of proceeding on a shared page opportunistically.
The main agent must not reassign a supplier worker's tab/context to another supplier during the same phase. One worker, one supplier, one tab/context.
If one supplier worker hits a bug or blocker, report it immediately, but do not automatically stop the other supplier workers unless the failure is clearly systemic.
Do not parallelize the supplier phase before fanout is confirmed. Buyer follow-up, buyer approval, and supplier fanout remain serialized.

Autonomy

Once the run starts, continue autonomously through the normal E2E flow. Do not pause for routine user confirmation between expected steps.

Only stop early when:

a genuine blocker emerges
a meaningful product or workflow bug is found
the user interrupts or redirects the run
or the run has reached a stable PASS / PARTIAL / FAIL conclusion

Key pages to check:

/quoting — Quote Manager monitoring page (RFQ list, supplier statuses, expand/collapse, task rows)
/ (Orders dashboard) — Verify suppliers appear in the supplier list after being created
Gmail inbox/sent — Verify emails were sent/received, check for "Manage this task in Didero" footer on task-related emails

Gmail automation tips

These apply to ALL steps involving Gmail compose/reply:

NEVER expand to full-screen compose. Always work in the mini-composer in the bottom-right corner. It has everything needed (From, To, Subject, Body, Send). Never click the expand/pop-out icon.
To field — CRITICAL: Do NOT use find to locate the To field — the "To - Select contacts" link opens a contact selector dialog that wipes all fields. Instead, click directly on the To input area (the text input next to "To") by coordinate, then type the address and press Tab to confirm.
Confirming email chips: After typing an address in To/CC/BCC, press Tab (not Enter) to confirm the chip. If you don't, the address won't be added.
Subject field: Never clear the subject by selecting all + deleting — this can accidentally clear it to "(no subject)". Click the Subject field, then type the text directly.
From field: Click the From area (e.g. "Brian Tu") to expand the header, then click the From dropdown arrow to select the alias. Verify it changed.
Buyer RFQ From is mandatory: The very first RFQ email to bt@didero.ai MUST be sent from bt+buyer@didero.ai. Sending it from bt@didero.ai is a tester mistake, not a product result.
Body field — CRITICAL: Gmail's body is a contenteditable div, NOT a regular textarea. The type action and form_input tool often silently fail.
- Working approach: Use javascript_tool with document.execCommand:
```
const body = document.querySelector('div[aria-label="Message Body"]');
body.focus();
document.execCommand('selectAll');
document.execCommand('delete');
document.execCommand('insertText', false, 'Your body text here');
```
- Do NOT use find → click → type for the body — it looks like it works but the text often doesn't register.
- Do NOT use cmd+a / Backspace to clear the body — it can select/delete the entire page including subject and To fields.
Minimize screenshots: Don't take unnecessary screenshots between simple sequential actions. Only screenshot to verify state when something might have gone wrong.

Gmail compose From selector — CRITICAL: The From dropdown uses a custom Gmail widget. Regular .click() does NOT open it. You MUST use the full pointer event sequence:

const fromBtn = document.querySelector('.J-JN-M-I.az2[role="button"]');
fromBtn.focus();
const rect = fromBtn.getBoundingClientRect();
const cx = rect.x + rect.width / 2, cy = rect.y + rect.height / 2;
for (const type of ['pointerdown', 'mousedown', 'pointerup', 'mouseup', 'click']) {
  fromBtn.dispatchEvent(new PointerEvent(type, {
    bubbles: true, cancelable: true, composed: true,
    clientX: cx, clientY: cy, button: 0,
    pointerId: 1, pointerType: 'mouse',
  }));
}

Then find the alias in visible .J-N elements and click with the same pointer event sequence. ALWAYS verify From actually changed after selection:

const fromDisplay = document.querySelector('.J-JN-M-I.az2 .J-JN-M-I-Jm span');
console.log("From:", fromDisplay?.innerText); // Must show the alias, not "Brian Tu <bt@didero.ai>"

If From didn't change, do NOT send — the email will come from the wrong address and be dropped by the webhook. Treat a failed alias switch as a tester failure unless the product blocked the switch explicitly.

Gmail split-pane view: Split-pane mode blocks thread navigation (clicking rows doesn't open them). Disable it first by clicking "Toggle split pane mode" button. After disabling, you can click rows to open threads normally.
Attachments: If the buyer RFQ includes document(s), attach them before sending and wait until Gmail shows the expected filename chip/list with upload complete. Do NOT click Send while an attachment is still uploading. After send, verify the same filename(s) are visible in the sent thread or sent mailbox evidence.
Supplier replies MUST be in-thread: Composing a new email with a matching subject (e.g. "Re: RFQ...") does NOT create the same thread_id. The quoting router matches incoming emails by thread_id against sent_email_log.provider_thread_id. If the thread_id doesn't match, the email gets routed to the RFQ parser (wrong agent) instead of the per-supplier agent. Always use the Reply button on the original RFQ email sent to the supplier, then pop it out to a compose window to edit From/To.
Run UUID is mandatory: Before the first buyer RFQ is sent, generate one RUN_UUID for the whole test with docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -Atqc 'select uuidv7();'. Reuse that exact value for the rest of the run. Every buyer-originated new-thread subject must replace the old #<N> project suffix with #<RUN_UUID> so the app under test carries that same identifier into the supplier fanout thread subjects. Do NOT infer the latest prior run number.
In-thread reply workflow (for supplier responses):
1. Disable Gmail split-pane mode
2. Find and click the original RFQ email thread for this exact run by searching the shared RUN_UUID (and the supplier alias if needed), then open the thread whose subject still includes #<RUN_UUID>
3. Click Reply at the bottom of the thread
4. Click "Open in a pop-up" button (found via take_snapshot → search for button "Open in a pop-up" near textbox "Message Body")
5. Click the To text (e.g. bt+2@didero.ai) to expand the header — this reveals From and To fields
6. Verify From is already the supplier alias (Gmail auto-selects it based on who the original email was sent to)
7. Fix To: remove the supplier chip (it auto-populates with the supplier address), add bt@didero.ai instead
8. Set body, verify From one more time, then Send
Gmail plus-aliases DO work as separate senders when properly configured as "Send mail as" aliases in Gmail settings. The From field MUST be set correctly (see above). If From is wrong, the email arrives as bt@didero.ai and gets dropped by the allowlist check.

Webhook Delivery Fallback

WARNING — Do not modify Terraform-managed Pub/Sub subscriptions. The base subscriptions (po-topic-{slug}, quoting-topic-{slug}) are managed by Terraform and point to the engineer's named tunnel ({slug}.didero.dev). Never run gcloud pubsub subscriptions modify-push-config or any equivalent on these subscriptions. Only worktree-specific subscriptions (*-{slug}-{worktree-key}) may be created, deleted, or modified by agents or scripts. Modifying the base subscriptions will break webhook delivery for the engineer's entire local dev environment.

Nylas notifications flow through: Nylas → Nylas Router (Cloud Run) → Pub/Sub → push to local dev via tunnel. If Pub/Sub isn't delivering (no webhook logs after ~60s despite confirmed Gmail send and healthy tunnel), use this manual fallback.

Detecting Pub/Sub failure:

After a confirmed Gmail send, check backend logs for Email created: within 60s
If nothing appears, verify the tunnel is healthy: curl -s https://bt.didero.dev/api/v1/health
If the tunnel is healthy but no webhooks arrive, Pub/Sub push isn't reaching the local dev
Try re-registering the grant with the router (see below), then resend the email
If re-registration doesn't help, fall back to manual webhook injection

Re-registering the grant:

docker exec {{API_CONTAINER}} python -c "
from app.services.router_client import get_router_client
client = get_router_client()
resp = client._client.post(
    f'{client.router_url}/grants',
    json={
        'grant_id': '<GRANT_ID>',
        'topics': ['po-topic', 'quoting-topic'],
        'env': 'local',
        'dev': 'bt',
    },
    headers=client._get_headers(),
)
print(f'Status: {resp.status_code}, Body: {resp.text}')
"

Manual webhook injection — CRITICAL RULES:

When manually POSTing to /api/v1/emails/webhook/po, the webhook handler reads the email body directly from the payload — it does NOT fetch the body from Gmail or Nylas. This means:

NEVER use placeholder body text. The body in the webhook payload IS what the agent processes. If you send 'supplier reply' as the body, the agent will see only those two words and escalate for missing data.
Always include the exact same body that was composed in Gmail / sent via gws. Copy-paste the full text.
Use the real Gmail message ID as the id field when possible (gws returns it in the send response). If you must fabricate an ID, the per-supplier agent will fail to send acknowledgment replies (Nylas can't find the message on the provider), but quote processing will still succeed.
Use the correct thread_id — match it to the provider_thread_id in sent_email_log for the supplier's outbound RFQ email. This is how the router determines per-supplier vs buyer-thread routing.

Payload template:

import base64, json

payload = {
    'nylas': {'type': 'message.created', 'data': {'object': {
        'grant_id': '<GRANT_ID>',
        'id': '<GMAIL_MESSAGE_ID>',
        'thread_id': '<GMAIL_THREAD_ID>',
        'subject': '<FULL_SUBJECT>',
        'from': [{'email': '<FROM_EMAIL>', 'name': '<FROM_NAME>'}],
        'to': [{'email': 'bt@didero.ai', 'name': 'Brian Tu'}],
        'body': '<FULL_EMAIL_BODY>',  # NEVER a placeholder
    }}},
    'router': {'grant_id': '<GRANT_ID>', 'env': 'local', 'dev': 'bt', 'routed_topics': ['quoting-topic']}
}
pubsub_msg = {
    'message': {
        'data': base64.b64encode(json.dumps(payload).encode()).decode(),
        'messageId': '<UNIQUE_MSG_ID>',
        'publishTime': '<ISO_TIMESTAMP>',
        'attributes': {}
    },
    'subscription': 'projects/brian-tu/subscriptions/quoting-push-bt'
}
# POST to http://localhost:{{API_PORT}}/api/v1/emails/webhook/po

Deduplication: The handler checks nylas_message_id in the nylas_email table. If a message ID was already processed, it returns {"status": "duplicate"}. Use a different ID for retries.

Steps

1. Open Gmail

Navigate to https://mail.google.com
Verify the active account is bt@didero.ai

2. Compose a new RFQ email

Before opening Compose, generate and record one RUN_UUID for this test run:
```
RUN_UUID="$(docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -Atqc 'select uuidv7();')"
echo "$RUN_UUID"
```
Reuse that exact value everywhere in this run: buyer-thread lookup, supplier-thread lookup, screenshots, and the final report.
Click Compose
From: Change sender to bt+buyer@didero.ai (click the From area to open dropdown, select "Buyer")
To: bt@didero.ai — type it then press Tab to confirm the chip
Subject: RFQ: Stainless Steel Hex Bolts #<RUN_UUID>
- Example: RFQ: Stainless Steel Hex Bolts #019d1234-5678-7abc-9def-0123456789ab
- This is the project identifier for the run; it replaces the old incrementing #<N> suffix
Body: Use javascript_tool with document.execCommand('insertText', ...) — see "Gmail automation tips" above. Do NOT use find + type.

Use the host's native question/prompt UI when available, otherwise ask concisely in plain text, to ask how to write the body:
- Specify everything (default happy path)
- Omit supplier emails (forces agent to ask buyer for contact info)
- Omit names/companies (forces agent to ask who they are)
- Omit both
Default "specify everything" body:
```
Please get quotes from the following supplier:

Supplier(s): bt+2@didero.ai (TwoName @ TwoCo), bt+3@didero.ai (ThreeName @ ThreeCo), bt+4@didero.ai (FourName @ FourCo)

Item: 1/2"-13 x 2" Stainless Steel Hex Bolts (Grade 18-8)
Quantity: 5,000 each
Specs: ASTM A193 Grade B8, plain finish

Deadline: 2 days

Please include lead time and minimum order quantity in the response.
```
Optional buyer attachments: If the run includes buyer-side document(s), keep the supplier list and other routing context in the email body, then attach the requirement-only RFQ document after the body is ready. Use /Users/briantu/.codex/skills/quoting-e2e-tester/references/rfq-sample.pdf as the default sample attachment for fixture-based runs, or another user-supplied absolute path for ad hoc runs. Verify the expected filename(s) are visible in Gmail before continuing. If the file path was not supplied or the file is unreadable, stop and ask for the correct path instead of sending without the attachment.

3. Send the email

Click Send button
Before clicking Send on the initial buyer RFQ, explicitly confirm the visible From alias is bt+buyer@didero.ai.
If buyer document(s) are included, explicitly confirm the expected attachment filename(s) are visible and that Gmail is no longer showing upload progress.
CRITICAL: Do not proceed to backend/log verification until Gmail itself confirms the send. Acceptable confirmation is:
- a visible Message sent toast, or
- the message appearing in the Sent mailbox or sent-thread list
If buyer document(s) are included, the send is not fully confirmed until the sent mailbox or sent thread also shows the expected attachment filename(s).
If neither confirmation appears, treat the step as not sent. Retry/fix the compose or send action once, then re-check Gmail before continuing.

4. Verify agent processing (RFQ parser)

Do not treat this as an immediate step. After a confirmed Gmail send, allow a longer polling window for fresh-worktree runs.

Recommended verification order:

Wait ~30s and check for ingress milestones
If no ingress appears yet, wait again and re-check instead of declaring failure immediately
On fresh-worktree runs, allow roughly up to 2 minutes for ingress before reporting a missed email
After ingress starts, allow roughly up to 6 minutes for the first-stage quoting flow to complete before treating it as stalled

The milestone progression is:

ingress: Email created
task enqueue: Created Cloud Task
routing: Routing to RFQ parser agent
execution start: Running RFQ parser quoting engine

Then check:

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(rfq|quoting|ensure_supplier|create_quote|create_rfq|agent|error|warning|completed)" | grep -v "sqlalchemy|WatchFiles|pubsub_service|metrics_pubsub" | tail -30

Expected log sequence:

Email created: <nylas_msg_id> — webhook received
Created Cloud Task: ... action_type=process_quoting_email_reasoning — task enqueued
Routing to RFQ parser agent: email_id=... — task dispatched
Running RFQ parser quoting engine: trigger_type=email — agent started
Email sent successfully — agent replied to buyer
Quoting email reasoning completed: ... success=True — done

Expected agent behavior (with "specify everything" body):

Agent parses the RFQ details (item, qty, specs, deadline, suppliers)
Agent notices suppliers aren't in the system yet
Agent sends a confirmation email back to the buyer asking to confirm adding the suppliers
Creates RFQ record in DB

Task verification — supplier approval creates an escalation task:

After the RFQ parser sends the confirmation email asking the buyer to approve suppliers, verify that an escalation task was created:

RFQ_ID=$(docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -t -A -c "SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1")
echo "RFQ_ID=$RFQ_ID"

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, t.summary, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected:

An escalation task with status = open asking the buyer to confirm/approve the suppliers
The task is linked to the RFQ via task_rfq
No quote_id link yet (this is an RFQ-level task)

Verify task-email linkage:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id as task_id, t.task_type, te.email_id, sel.subject
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_email te ON te.task_id = t.id
  LEFT JOIN sent_email_log sel ON sel.id = te.email_id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected:

The task is linked to the sent email via task_email
The linked email's subject matches the buyer confirmation email

Verify "Manage this task in Didero" footer in the sent email:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.subject, sel.body LIKE '%Manage this task in Didero%' as has_task_footer
  FROM sent_email_log sel
  WHERE sel.rfq_id = '$RFQ_ID'
  ORDER BY sel.created_at DESC
  LIMIT 3;
"

Expected: has_task_footer = true for the confirmation email

UI check — Quote Manager: Navigate to http://localhost:{{NEXT_PORT}}/quoting (impersonating Buyer) and verify the new RFQ appears. At this point it should be empty or not yet visible if the RFQ was just created.

UI check — Task rows: After expanding the RFQ row in the Quote Manager, verify:

An RFQ-level task row appears above the supplier table (the supplier-approval task)
The task row shows the title, description, and action buttons

5. Buyer confirms suppliers

After agent asks "Should we add these suppliers?", reply as the buyer to confirm:

Search Gmail for the exact RUN_UUID, then open the buyer thread whose subject includes #<RUN_UUID>
The agent's reply (from bt@didero.ai -> bt+buyer) should ask about adding the suppliers
Click Reply
CRITICAL — Fix the To field: Gmail auto-populates To with bt+buyer@didero.ai (wrong — that's the buyer alias, not the Didero inbox). You MUST fix this:
1. Click the To field to expand it
2. Click the X on the bt+buyer@didero.ai chip to remove it
3. Click away from the To field to dismiss any contact popup
4. Click the To field again
5. Type bt@didero.ai
6. Press Tab to confirm the chip
Change From to bt+buyer@didero.ai (Buyer) if not already set
Type a short confirmation: Yes, please add them and send out the RFQs.
Click Send

Then verify processing (~30s wait):

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(rfq|quoting|ensure_supplier|create_quote|supplier_ready|fan.?out|per.supplier|orchestrat|email.*sent)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -30

Expected log sequence:

Email created: <nylas_msg_id> — webhook received for buyer's reply
Created Cloud Task: ... action_type=process_quoting_email_reasoning — task enqueued for buyer's reply
Routing to RFQ parser agent — task dispatched
Running RFQ parser quoting engine: trigger_type=email — agent started
Supplier ready: name=TwoCo, ... created=True — supplier created + allowlisted
Supplier ready: name=ThreeCo, ... created=True — supplier created + allowlisted
Supplier ready: name=FourCo, ... created=True — supplier created + allowlisted
INSERT INTO quote (x3) — quotes created for each supplier
Email sent successfully — confirmation email sent to buyer
Fanning out 3 supplier tasks — fanout started
Enqueued supplier reasoning task: quote_id=... (x3) — per-supplier Cloud Tasks created
Processing supplier fanout: quote_id=... (x3) — per-supplier agents started

Expected agent behavior:

Agent re-runs on the thread, reads buyer confirmation
Calls ensure_supplier_ready for each supplier (creates supplier + adds to email allowlist)
Calls create_quote for each supplier
Sends confirmation email: "I've added [suppliers] to our system and created the quote requests"
Fan-out creates three per-supplier Cloud Tasks
Per-supplier agents each send an RFQ email to their assigned supplier

Task verification — supplier-approval task resolved by buyer reply:

The buyer's confirmation reply should trigger task resolution. The orchestrator checks for open tasks on the RFQ and resolves the supplier-approval task via resolve_task().

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, t.summary, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected:

The supplier-approval task from step 4 now has status = resolved (or equivalent completed status)
The list_open_tasks_for_rfq() tool was used to find the open task, and resolve_task() was called

Verify resolution event in buyer thread:

{{DOCKER_COMPOSE}} logs fast-api --since 180s 2>&1 | grep -iE "(resolve_task|task.*resolved|list_open_tasks)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -10

Expected:

Log evidence of list_open_tasks_for_rfq being called
Log evidence of resolve_task being called for the supplier-approval task
System messages appended to buyer and supplier threads noting the resolution

RFQ confirmation email does NOT create a new task — the confirmation email sent after suppliers are added is informational and should NOT create a new task. Verify:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT count(*) as total_tasks
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID';
"

Expected: Total task count should still be 1 (the original supplier-approval task, now resolved). The RFQ confirmation is informational and does not create a new task.

UI check — Suppliers on Orders dashboard: Navigate to http://localhost:{{NEXT_PORT}}/ (impersonating Buyer) and verify that the newly created suppliers (TwoCo, ThreeCo, FourCo) appear in the supplier list on the Orders dashboard. The header must show exactly "3 Suppliers" — if it shows more (e.g. "6 Suppliers"), the agent created duplicate supplier rows via the concurrent find-or-create race condition (see DNLI-160). File a bug.

DB check — No duplicate suppliers: Run the following query and verify each supplier name appears exactly once:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT name, COUNT(*) as cnt FROM supplier GROUP BY name HAVING COUNT(*) > 1;
"

Expected: 0 rows. If any rows appear, the find-or-create race condition created duplicates (see DNLI-160).

UI check — Quote Manager: Navigate to http://localhost:{{NEXT_PORT}}/quoting and verify:

The RFQ appears under "Open RFQs" (since final_comparison_message_id is not set)
Expanding the RFQ shows all three suppliers (TwoCo, ThreeCo, FourCo) with "Pending" status
Response dots show 3 gray (unanswered) dots
The previously open supplier-approval task row should no longer appear as an active task (it has been resolved)

6. Verify supplier RFQ emails

After fanout completes (~30s after step 5), check:

{{DOCKER_COMPOSE}} logs fast-api --since 180s 2>&1 | grep -iE "(supplier.*fanout|supplier.*reasoning|per.supplier|quote_id|RFQ.*sent|Email sent)" | grep -v "sqlalchemy|WatchFiles" | tail -20

Expected:

Three per-supplier agent runs, one per quote
Each sends an RFQ email to the respective supplier (bt+2@didero.ai, bt+3@didero.ai, bt+4@didero.ai)
Verify in Gmail Sent folder that RFQ emails were sent to all three suppliers

Idempotency check: The per-supplier agent checks sent_email_log_id on the quote record. If the email was already sent, it skips. You can verify this by checking that each supplier only received one RFQ email.

Note on supplier RFQ emails and tasks: The outbound supplier RFQ emails are NOT buyer-blocking and do NOT create tasks. They are purely informational outbound messages. Verify no new tasks were created:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT count(*) as total_tasks, count(*) FILTER (WHERE t.status = 'open') as open_tasks
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID';
"

Expected: open_tasks = 0 (all previous tasks resolved, no new ones from fanout)

7. Simulate supplier responses

Reply to each supplier's RFQ thread as the respective supplier. The RFQ emails were sent as new threads (not replies to the buyer thread), so find them by searching the exact RUN_UUID and then selecting the thread for the correct supplier alias. Do not rely on "latest matching subject" or the most recent generic bolts RFQ.

Use the host's native question/prompt UI when available, otherwise ask concisely in plain text, to ask which variant to test:

Full quote (default happy path — complete pricing, terms, lead time)
Escalation path (TwoCo asks the buyer to clarify sustainability requirements)
Automatic deadline closure (do not reply as suppliers; shorten the RFQ deadline and verify automatic closure)
Omit lead time (forces orchestrator to note incomplete data)
Omit pricing (forces orchestrator to note missing pricing)
Supplier followup threading (do not reply as suppliers; trigger followup timer and verify it sends in-thread)
Something else (custom)

For each supplier (bt+2, bt+3, and bt+4), use the in-thread reply workflow described in Gmail tips:

Disable Gmail split-pane if active (click "Toggle split pane mode")
Find the original RFQ thread for this supplier by searching the shared RUN_UUID, then open the supplier thread whose subject includes #<RUN_UUID> and whose visible supplier alias matches the worker you are handling
Click the thread to open it, then click Reply at the bottom
Pop out the reply (click "Open in a pop-up" button near "Message Body")
Click the To text to expand the header — reveals From and To fields
Verify From is already the supplier alias (Gmail auto-selects based on who the RFQ was sent to)
Fix To: remove the supplier chip, add bt@didero.ai instead
Set body using document.execCommand('insertText', ...)
Verify From one more time, then Send

CRITICAL: Do NOT compose a new email — it creates a different thread_id and the quoting router won't match it. Always reply in-thread.

Default "full quote" bodies:

bt+2 (TwoName @ TwoCo):

Dear Brian,

Thank you for your RFQ and for the opportunity to quote.

Please find our quotation details below:

Item Details
- Product: 1/2"-13 x 2" Stainless Steel Hex Bolts (Grade 18-8)
- Specification: ASTM A193 Grade B8, plain finish
- Quantity: 5,000 pcs

Pricing
- Unit Price: $0.42 per piece
- Total Price: $2,100.00 (USD), excluding applicable taxes and shipping

Delivery & Lead Time
- Lead Time: 3-4 weeks from receipt of purchase order
- Estimated Delivery Date: March 8-15, 2026

Commercial Terms
- Minimum Order Quantity: 1,000 pcs
- Quote Validity: 30 days (valid through March 11, 2026)
- Incoterms: FOB Origin
- Payment Terms: Net 30 days from invoice date

Please let us know if you require freight pricing, certifications (e.g., material test reports), or any additional documentation.

We look forward to supporting your requirements and are happy to answer any questions.

Best regards,
TwoName
Sales Manager
TwoCo
bt+2@didero.ai
(555) 123-4567

bt+2 (TwoName @ TwoCo) — escalation / buyer-intervention path:

Use this instead of the standard TwoCo body when the user selects the escalation path. The goal is to make the per-supplier agent set status="awaiting_buyer" with details.buyer_escalation so the buyer-side escalation flow is exercised. This version includes two preliminary pricing options to test that tasks render correctly under suppliers with multiple quote options.

Dear Brian,

Thank you for your RFQ for the stainless steel hex bolts.

We have prepared two preliminary pricing options based on what we know so far:

Option A — Standard Lead Time (3-4 weeks):
  Unit price: $0.85/pc
  Total price: $2,125.00
  Delivery: Ground freight, FOB Origin

Option B — Expedited Lead Time (1-2 weeks):
  Unit price: $1.05/pc
  Total price: $2,625.00
  Delivery: Air freight, FOB Destination

However, before we can finalize these prices, our compliance team needs clarification from the buyer on the sustainability and environmental compliance requirements for this order.

Please confirm:
- whether any recycled-content minimum is required
- whether a carbon footprint / sustainability report must be included with the quote
- whether REACH, RoHS, or other environmental declarations are mandatory for award

Pricing may change depending on the compliance requirements. We can move quickly once those requirements are confirmed.

Best regards,
TwoName
Sales Manager
TwoCo
bt+2@didero.ai
(555) 123-4567

bt+3 (ThreeName @ ThreeCo) — multi-tier shipping quote:

ThreeCo provides 3 separate pricing tiers (express, standard, economy) to test that the per-supplier agent correctly parses multiple options into quote.details.options[].

Dear Brian,

Thank you for your RFQ. We're pleased to provide quotations across three shipping tiers for your review.

Item Details
- Product: 1/2"-13 x 2" Stainless Steel Hex Bolts (Grade 18-8)
- Specification: ASTM A193 Grade B8, plain finish
- Quantity: 5,000 pcs

OPTION 1 — EXPRESS SHIPPING (1-3 business days)
- Unit Price: $0.48 per piece
- Total Price: $2,400.00 (USD)
- Lead Time: 1 week from receipt of PO
- Estimated Delivery: within 10 business days
- Shipping: Air freight, FOB Destination

OPTION 2 — STANDARD SHIPPING (5-7 business days)
- Unit Price: $0.39 per piece
- Total Price: $1,950.00 (USD)
- Lead Time: 3-4 weeks from receipt of PO
- Estimated Delivery: March 22-29, 2026
- Shipping: Ground freight, FOB Origin

OPTION 3 — ECONOMY SHIPPING (10-14 business days)
- Unit Price: $0.34 per piece
- Total Price: $1,700.00 (USD)
- Lead Time: 5-6 weeks from receipt of PO
- Estimated Delivery: April 5-12, 2026
- Shipping: Ocean freight, EXW

Commercial Terms (all options)
- Minimum Order Quantity: 2,000 pcs
- Quote Validity: 14 days
- Payment Terms: Net 45 days from invoice date

Material test reports available upon request. Please let us know which option best suits your timeline and budget.

Best regards,
ThreeName
Account Manager
ThreeCo
bt+3@didero.ai
(555) 987-6543

bt+4 (FourName @ FourCo) — alternate label for the same semantic field:

FourCo intentionally uses a different field name for the same concept that ThreeCo expresses as a tier. This is meant to stress-test schema deduping so the extractor reuses the existing semantic column rather than creating a near-duplicate such as shipping_level alongside shipping_tier.

Dear Brian,

Thank you for the opportunity to quote. We are providing three shipping levels for your review.

Item Details
- Product: 1/2"-13 x 2" Stainless Steel Hex Bolts (Grade 18-8)
- Specification: ASTM A193 Grade B8, plain finish
- Quantity: 5,000 pcs

SHIPPING LEVEL A — EXPRESS
- Unit Price: $0.47 per piece
- Total Price: $2,350.00 (USD)
- Lead Time: 8 days
- Estimated Delivery: within 2 weeks
- Shipping Method: Air freight

SHIPPING LEVEL B — STANDARD
- Unit Price: $0.40 per piece
- Total Price: $2,000.00 (USD)
- Lead Time: 24 days
- Estimated Delivery: March 24-31, 2026
- Shipping Method: Ground freight

SHIPPING LEVEL C — ECONOMY
- Unit Price: $0.35 per piece
- Total Price: $1,750.00 (USD)
- Lead Time: 40 days
- Estimated Delivery: April 5-12, 2026
- Shipping Method: Ocean freight

Commercial Terms
- Minimum Order Quantity: 1,500 pcs
- Quote Validity: 21 days
- Payment Terms: Net 30

Best regards,
FourName
Account Executive
FourCo
bt+4@didero.ai
(555) 246-8101

After sending each supplier reply, wait ~60s and check logs:

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(Email created|Routing to per-supplier|update_quote|update_rfq_schema|Updated RFQ schema|quote.*status|completed|error)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -20

Expected log sequence per supplier reply:

Email created: <nylas_msg_id> — webhook received
Routing to per-supplier agent: email_id=..., quote_id=..., rfq_id=... — correctly routed by thread_id match
UPDATE quote SET status=..., details=... — quote updated with parsed response
Updated RFQ schema: rfq=..., columns=N — per-supplier agent called update_rfq_schema to register dynamic columns from this supplier's response
Supplier quoting reasoning completed: quote_id=..., success=True

NOTE: Schema extraction is incremental. Each per-supplier agent calls update_rfq_schema independently after parsing its supplier's response. The schema is additive — columns accumulate across suppliers without overwriting, and semantically equivalent dynamic fields should be deduped onto the existing schema instead of added as near-duplicates. This means:

After the FIRST supplier responds, rfq.details.schema will have the required columns plus any dynamic columns from that supplier's data.
After the SECOND supplier responds, the schema will have merged columns from both suppliers.
After the THIRD supplier responds, the schema should reuse any pre-existing semantic field when the supplier uses a different label for the same concept (for example, FourCo's shipping level should map onto the existing tier field created from ThreeCo rather than creating a duplicate).
If Updated RFQ schema does NOT appear in the logs, the per-supplier agent didn't call the tool — check that the supplier prompt's <response_steps> includes the "SCHEMA EXTRACTION" instruction.

If you see Routing to RFQ parser agent instead — the reply wasn't in-thread. The email's thread_id didn't match any sent_email_log.provider_thread_id. You must reply IN the original RFQ thread (see "In-thread reply workflow" in Gmail tips).

If you see Ignoring email with no allowlisted participants — the From alias wasn't set correctly. Gmail sent the email as bt@didero.ai instead of the supplier alias. Verify From was set before sending (see "Gmail compose From selector" in Gmail tips).

If the user selected the escalation path for TwoCo, replace the TwoCo-specific happy-path expectations above with the escalation checks in the optional 7e through 10e section below.

Task verification — supplier replies on the happy path do NOT create tasks:

On the happy path (full quote replies), supplier responses that result in status = responded do NOT create buyer-blocking tasks. Verify no new open tasks were created:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
    AND t.status = 'open'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected: No open tasks (happy-path supplier responses go straight to responded without buyer intervention).

7.5. Verify incremental schema extraction after each supplier

Schema extraction happens incrementally — each per-supplier agent adds columns from its own response. Verify this after each supplier reply is processed.

After FIRST supplier reply is processed (e.g. TwoCo):

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    r.id,
    r.details->'schema' as schema,
    jsonb_array_length(COALESCE(r.details->'schema', '[]'::jsonb)) as num_columns
  FROM rfq r
  ORDER BY r.created_at DESC
  LIMIT 1;
"

Expected after first supplier:

schema should be non-null (the per-supplier agent called update_rfq_schema)
Should contain the 4 required columns (responded_at, lead_time_days, total_price, summary) plus any dynamic columns from this supplier's data (e.g. unit_price, shipping_method, moq, payment_terms, valid_until)
Should NOT yet have a tag-type column for distinguishing tiers (TwoCo has a single-option quote)

After SECOND supplier reply is processed (e.g. ThreeCo):

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    r.id,
    r.details->'schema' as schema,
    jsonb_array_length(COALESCE(r.details->'schema', '[]'::jsonb)) as num_columns
  FROM rfq r
  ORDER BY r.created_at DESC
  LIMIT 1;
"

Expected after second supplier:

Schema should now have columns from BOTH suppliers merged together
A tag-type column should appear for distinguishing ThreeCo's tiers (the agent names it dynamically — e.g. shipping_tier, option_tier, service_level, etc.)
Total column count should be >= what it was after the first supplier (additive merge)
No duplicate columns — each key appears only once

After THIRD supplier reply is processed (e.g. FourCo):

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    r.id,
    r.details->'schema' as schema,
    jsonb_array_length(COALESCE(r.details->'schema', '[]'::jsonb)) as num_columns
  FROM rfq r
  ORDER BY r.created_at DESC
  LIMIT 1;
"

Expected after third supplier:

Schema should continue to grow only for genuinely new fields.
The extractor should reuse the existing shipping-tier semantic column created from ThreeCo rather than adding a duplicate near-match such as shipping_level.
Total column count may increase for genuinely new fields, but there should still be exactly one tier-like dynamic tag field for shipping speed/service semantics.
If both shipping_tier and shipping_level-style fields appear, file a bug for failed semantic deduping.

If schema is null after a supplier reply: The per-supplier agent didn't call update_rfq_schema. This is a prompt issue — check step 4 ("SCHEMA EXTRACTION") in the supplier user prompt's <response_steps> block.

8. Verify required quote option fields in DB

After both supplier responses are processed, verify the per-supplier agent stored the required fields in quote.details.options[]:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT q.id, s.name as supplier,
    q.status,
    jsonb_array_length(q.details->'options') as num_options,
    q.details->'options'->0->>'lead_time_days' as lead_time,
    q.details->'options'->0->>'total_price' as total_price,
    q.details->'options'->0->>'summary' as summary,
    jsonb_object_keys(q.details->'options'->0) as option_keys
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.status = 'responded'
  ORDER BY q.created_at DESC
  LIMIT 5;
"

Expected:

TwoCo: 1 option with lead_time_days, total_price, and summary all populated.
ThreeCo: 3 options, each with lead_time_days, total_price, and summary populated. Should also have a dynamically-named distinguishing field (e.g. shipping_tier, option_tier, etc.) — the exact key name is up to the agent.
FourCo: 3 options, each with lead_time_days, total_price, and summary populated. The distinguishing field should map onto the same pre-existing semantic column used for ThreeCo rather than creating a duplicate.

Required fields per option (these MUST be present — if any are null, the per-supplier agent prompt needs fixing):

lead_time_days (number) — e.g. 25, 7, 38
total_price (number) — e.g. 2100.00, 2400.00, 1950.00
summary (string) — e.g. "Standard shipping, FOB Origin, Net 30"

Verify ThreeCo/FourCo share one semantic tier field rather than duplicating it:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    jsonb_pretty(q.details->'options'->0) as first_option
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE s.name ILIKE ANY (ARRAY['%ThreeCo%', '%FourCo%'])
    AND q.status = 'responded'
  ORDER BY q.created_at DESC
  LIMIT 2;
"

Expected: Each multi-option supplier should have a field beyond the required three that distinguishes the tiers. The field name is dynamic, but ThreeCo and FourCo should converge on a single shared semantic column for shipping/service tier. If no distinguishing field exists, or if both suppliers create separate near-duplicate fields for the same idea, file a bug.

9. Verify orchestrator compiles quotes and extracts dynamic schema

After all suppliers respond, the per-supplier agent should trigger the orchestrator for comparison:

{{DOCKER_COMPOSE}} logs fast-api --since 300s 2>&1 | grep -iE "(orchestrat|comparison|final|reply_to_buyer|record_final|update_rfq_schema)" | grep -v "sqlalchemy" | tail -15

Expected:

Running quoting orchestrator engine: trigger_type=comparison — orchestrator kicked off
update_rfq_schema — orchestrator finalized the schema (per-supplier agents already extracted most columns)
reply_to_buyer with tag quote_comparison — comparison email sent to buyer
record_final_comparison — comparison message_id recorded on RFQ

If the orchestrator fails with "Comparison trigger missing RFQ ID", that's a known bug — file it but don't block on it.

Task verification — comparison does NOT create a task (DNLI-131):

The comparison email is the terminal step of the quoting process. The agent should NOT create an escalation or suggestion task for it. Verify no new open tasks were created by the comparison:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT count(*) FILTER (WHERE t.status = 'open') as open_tasks
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID';
"

Expected: open_tasks = 0 — the comparison is informational and does not create a new task. All previous tasks should already be resolved.

Verify "Manage this task in Didero" footer in comparison email:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.subject, sel.body LIKE '%Manage this task in Didero%' as has_task_footer
  FROM sent_email_log sel
  WHERE sel.rfq_id = '$RFQ_ID'
  ORDER BY sel.created_at DESC
  LIMIT 3;
"

Expected: has_task_footer = true for the comparison email

9.5. Verify dynamic schema extraction in DB

After orchestrator completes, verify rfq.details.schema was populated with the right columns:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    r.id,
    r.details->'schema' as schema,
    jsonb_array_length(r.details->'schema') as num_columns
  FROM rfq r
  ORDER BY r.created_at DESC
  LIMIT 1;
"

Expected:

schema is a JSON array with 5+ columns
Required columns always present (first 4):
- {"key": "responded_at", "label": "Responded", "type": "date", "required": true}
- {"key": "lead_time_days", "label": "Lead Time", "type": "number", "unit": "days", "required": true}
- {"key": "total_price", "label": "Total Price", "type": "number", "unit": "USD", "required": true}
- {"key": "summary", "label": "Summary", "type": "text", "required": true}
Dynamic columns — additional columns extracted by per-supplier agents (e.g. unit_price, shipping_method, moq, payment_terms, etc.)
Tag-type column (should appear because ThreeCo/FourCo have multiple tiers): a column with "type": "tag" that distinguishes options. The key name is dynamic, but there should be one semantic tier column reused across suppliers.

If schema is null: Neither per-supplier agents nor orchestrator called update_rfq_schema().

If no tag-type column exists: The agent didn't detect that the multi-tier suppliers require a distinguishing field. This is an LLM compliance issue with the prompt, not a code bug.

If multiple near-duplicate tier columns exist: The semantic deduping logic failed. For example, if ThreeCo yields shipping_tier and FourCo yields shipping_level as separate columns, file a bug.

10. Final UI verification — dynamic columns, service level pills, and task rows

Navigate through all relevant pages and take screenshots at each step:

/ (Orders dashboard) — Verify TwoCo, ThreeCo, and FourCo appear in the supplier list
/quoting — Quote Manager shows:
- RFQ with correct supplier count and response dots (green = responded)
- "Open RFQ" if orchestrator hasn't sent comparison, "Closed RFQ" if it has
Expand the RFQ row — Supplier table should match the Figma design at figma.com/design/brFYlVanXLZEjWNhHvbIUn/Quoting?node-id=216-3677:
- Column headers: SUPPLIER, STATUS, RESPONDED, SERVICE LEVEL, LEAD TIME, TOTAL PRICE, SUMMARY
- SERVICE LEVEL column should appear (dynamic column extracted by orchestrator)
- TwoCo: 1 row with lead time, total price, summary populated. Service Level cell should be empty (single-option quote).
- ThreeCo: 3 rows (one per option — express/standard/economy):
  - Service Level shows as colored outlined pills (not plain text):
    - Express → magenta pill
    - Standard → purple pill
    - Economy → cyan pill
  - Supplier name, status, and responded date only shown on the first row (blank for subsequent options)
  - Each row has its own lead time, total price, and summary
- FourCo: 3 rows (one per option — using "shipping level" language in the source email), but rendered into the same shared tier column as ThreeCo rather than a duplicate column
- All responded suppliers show "Complete" status badge
Verify no empty columns — Lead Time, Total Price, and Summary should all have data (not blank)
Compare against Figma — The expanded table should visually match the Figma design:
- Colored pills for service level tiers
- Multi-option grouping (supplier name on first row only)
- Right-aligned total price column
- Summary text in gray

6. Verify task rows in the expanded RFQ:

RFQ-level tasks (e.g. the comparison review task) should appear above the supplier table in the accordion area
The comparison task row should show the task title, description, and action buttons (Accept / Dismiss)
If no RFQ-level tasks are open, verify the resolved tasks are not shown (or shown in a collapsed/completed state)
No quote-level task rows should appear on the happy path (all supplier responses were clean)

This final sweep catches rendering bugs, missing data, and stale cache issues.

10.5. Verify CSV download

After UI verification, test the CSV download functionality on the expanded RFQ row.

Ensure the RFQ row is expanded on /quoting (from step 10)

Click the download button — it's a DownloadSimpleIcon button on the RFQ row header (near the expand/collapse toggle). Use the a11y tree or take_snapshot to locate it:

// Look for download button in the RFQ row
const downloadBtn = document.querySelector('[data-testid="download-csv"]')
  || document.querySelector('button[aria-label*="download" i]')
  || [...document.querySelectorAll('button')].find(b => b.querySelector('svg') && b.closest('[data-rfq-id]'));

Capture the CSV content via JavaScript — since browser automation can't easily intercept file downloads, override the download mechanism to capture the CSV data:

// Intercept the next blob download and capture its contents
const originalCreateObjectURL = URL.createObjectURL;
let capturedCsvContent = null;

URL.createObjectURL = function(blob) {
  // Read the blob content
  const reader = new FileReader();
  reader.onload = () => { capturedCsvContent = reader.result; };
  reader.readAsText(blob);
  // Still create the URL so the download flow completes
  return originalCreateObjectURL.call(URL, blob);
};

// Now click the download button
const btn = document.querySelector('[data-testid="download-csv"]')
  || document.querySelector('button[aria-label*="download" i]');
if (btn) btn.click();

// Wait a moment for the blob to be read
await new Promise(r => setTimeout(r, 500));

// Restore and log
URL.createObjectURL = originalCreateObjectURL;
console.log('CSV Content:', capturedCsvContent);

Alternative — check the download directory if the JavaScript interception doesn't work:

ls -lt ~/Downloads/ | head -5
# Look for a recently created .csv file
cat ~/Downloads/<rfq-name>*.csv

Verify CSV contents:

Header row — should contain all column names including dynamic ones:
- Required columns: Supplier, Status, Responded, Lead Time (days), Total Price (USD), Summary
- Dynamic columns (if extracted): Service Level, plus any others the agent added (e.g. Unit Price, MOQ, Payment Terms)
Data rows — one row per supplier option (7 total):
- TwoCo: 1 row with lead_time_days, total_price, summary populated
- ThreeCo: 3 rows (one per option), each with all required fields populated
- FourCo: 3 rows (one per option), each with all required fields populated and mapped to the same tier column semantics as ThreeCo
Verification checklist:
- Header row present with all expected column names
- 7 data rows total (1 TwoCo + 3 ThreeCo + 3 FourCo)
- No empty cells for required fields (lead_time_days, total_price, summary)
- If a tag-type column exists, ThreeCo and FourCo rows both use that same semantic column with distinct values
- TwoCo row has no value for the tag column (single-option quote)
- No duplicate tier columns are present in the CSV header
- Supplier name appears on every row (not grouped like in the UI)
- Numeric values are unformatted (no $ signs or commas in CSV — those are for display only)

OPTIONAL VARIANT: Automatic Deadline Closure Before Suppliers Respond

This variant tests the real deadline timer path rather than manually forcing the deadline handler. Use it when the invoker specifically wants to verify that an RFQ is automatically closed once the deadline is reached, even if suppliers have not responded yet.

Before starting this variant, ask one short follow-up for deadline duration:

3 minutes (recommended)
Custom — ask the invoker for the exact duration to use

Use the real timer path. Do NOT manually call process_deadline() or the internal Cloud Tasks deadline endpoint in this variant.

When this variant is selected:

Do NOT send any supplier replies
Shorten the existing RFQ to the chosen duration after fanout is complete and the supplier RFQ emails are visible
Wait for the real deadline timer to fire automatically
Verify the buyer receives the deadline notice and the RFQ is no longer treated as open/active
If the timer fires but the RFQ remains open, record that as a bug against the intended deadline-close behavior

Replace steps 7-10.5 with the following:

7d. Shorten the RFQ deadline

After step 6 confirms fanout and outbound supplier RFQ emails, set the active RFQ deadline to a short window.

Get the latest RFQ ID:

RFQ_ID=$(docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -t -A -c "SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1")
echo "$RFQ_ID"

Resolve the deadline duration:

For the recommended path, use DEADLINE_MINUTES=3
For a custom path, set DEADLINE_MINUTES to the invoker-provided value

Compute the new deadline and update it through the API:

export DEADLINE_MINUTES=3
DEADLINE_AT=$(python - <<'PY'
from datetime import datetime, timedelta, UTC
import os
minutes = int(os.environ["DEADLINE_MINUTES"])
print((datetime.now(UTC) + timedelta(minutes=minutes)).isoformat())
PY
)

curl -X PATCH "http://localhost:{{API_PORT}}/api/v1/rfqs/$RFQ_ID/deadline" \
  -H "Content-Type: application/json" \
  -d "{\"deadline_at\": \"$DEADLINE_AT\"}"

Verify the deadline persisted:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT id, deadline_at, details->>'response_deadline' as response_deadline
  FROM rfq
  WHERE id = '$RFQ_ID';
"

Expected:

deadline_at is within the chosen short window
details.response_deadline is updated to the same value

8d. Verify the deadline timer was rescheduled

Check logs after the deadline update:

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(Scheduled deadline timer|deadline_at|update_rfq_deadline|reschedul)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -20

Expected:

a log line confirming the deadline timer was scheduled or rescheduled for the new deadline_at
no immediate deadline execution before the chosen time unless the deadline was set incorrectly in the past

9d. Wait for the real deadline to fire automatically

Do not send any supplier replies. Instead, wait for the chosen duration plus a small buffer, then poll logs every ~30 seconds until the timer fires or a reasonable timeout is hit.

Recommended wait budget:

for the 3-minute path: wait up to 5 minutes total
for a custom path: wait up to duration + 2 minutes

Check logs:

{{DOCKER_COMPOSE}} logs fast-api --since 600s 2>&1 | grep -iE "(Running deadline handler|Deadline reached for RFQ|quote_deadline_notice|reply_to_buyer|record_final|comparison|pending)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -30

Expected:

Running deadline handler for rfq_id=... (0/... responded, ... pending) — real timer fired automatically
system message noting the deadline was reached and suppliers are still pending
buyer-facing deadline notification via reply_to_buyer using the deadline-notice path
no supplier-response ingress because no suppliers were replied to manually

If the timer never fires within the wait budget, fail the variant and report a deadline-scheduling bug or environment issue.

10d. Verify automatic closure outcome (with task verification)

Verify the buyer notice and closure semantics in DB and UI.

Buyer thread / Gmail

Verify the buyer received the deadline email/notice
The notice should explain that the response deadline passed with no supplier responses and should suggest next steps such as extending or canceling

RFQ record

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    id,
    deadline_at,
    final_comparison_message_id,
    details->>'response_deadline' as response_deadline
  FROM rfq
  WHERE id = '$RFQ_ID';
"

Quote statuses

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT s.name as supplier, q.status
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = '$RFQ_ID'
  ORDER BY s.name;
"

Task verification — deadline creates an escalation task:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, t.summary, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected:

A new escalation task with status = open notifying the buyer that the deadline has passed
The task is linked to the RFQ via task_rfq
The task title/summary mentions the deadline and pending suppliers

Verify task-email linkage for deadline notice:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id as task_id, t.task_type, te.email_id, sel.subject
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_email te ON te.task_id = t.id
  LEFT JOIN sent_email_log sel ON sel.id = te.email_id
  WHERE tr.rfq_id = '$RFQ_ID'
    AND t.status = 'open'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected: The deadline task is linked to the deadline notice email

Verify "Manage this task in Didero" footer in deadline email:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.subject, sel.body LIKE '%Manage this task in Didero%' as has_task_footer
  FROM sent_email_log sel
  WHERE sel.rfq_id = '$RFQ_ID'
  ORDER BY sel.created_at DESC
  LIMIT 3;
"

Expected: has_task_footer = true for the deadline notice email

Quote Manager UI

Open http://localhost:{{NEXT_PORT}}/quoting
Refresh after the deadline handler has run
Verify whether the RFQ moved out of the active open state
Verify the deadline task row appears above the supplier table when the RFQ is expanded
The task row should show the deadline notice title, description, and action buttons

Expected target behavior for this variant:

the deadline fired automatically without a manual trigger
the buyer received the deadline notice
an escalation task was created for the deadline event
the task appears in the quoting UI
the RFQ is no longer treated as an active open RFQ waiting on supplier replies

Important interpretation note: the current UI groups RFQs into Open vs Closed using has_final_comparison. If the deadline notice is sent but the RFQ still appears under Open RFQs because no final-comparison marker was recorded, file a bug: the deadline fired but the RFQ did not auto-close as intended.

Once these checks are done, it is valid to stop the run without sending supplier replies. This variant is specifically about deadline behavior, not quote comparison.

OPTIONAL VARIANT: Supplier Escalation / Buyer Inquiry

This variant tests the supplier-escalation path behind the Quote Manager task-bar treatment shown in Figma at https://www.figma.com/design/brFYlVanXLZEjWNhHvbIUn/Quoting?node-id=22-4856&m=dev.

Before supplier replies begin, ask the invoker whether to run this variant. If they say yes, use the escalation-specific TwoCo body from step 7 instead of the standard TwoCo quote body.

When this variant is selected:

Do NOT expect TwoCo to end in responded until after the buyer clarification and TwoCo's final quote (steps 11e-13e)
Do NOT expect the final comparison to trigger while TwoCo remains awaiting_buyer
Steps 7e-10e verify escalation creation; steps 11e-15e continue through buyer clarification, forwarding, TwoCo's final quote, and comparison
It is valid to stop after step 10e (escalation creation checkpoint) and report PARTIAL if the full resolution flow is not needed, but the complete variant runs through step 16e
If you still reply as ThreeCo or FourCo for extra coverage, keep those on the standard bodies, but comparison should remain blocked until the buyer resolves TwoCo's escalation

Replace the TwoCo portion of steps 7-10.5 with the following:

7e. Simulate TwoCo escalation reply

Reply to only TwoCo's RFQ thread (bt+2@didero.ai) using the same in-thread reply workflow from step 7, but use the escalation body instead of the standard quote body.

After TwoCo's reply is processed (~60s), check logs:

{{DOCKER_COMPOSE}} logs fast-api --since 180s 2>&1 | grep -iE "(Email created|Routing to per-supplier|Running quoting orchestrator engine|Escalation created:|Not all quotes resolved|awaiting_buyer|error)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -25

Expected:

Email created: <nylas_msg_id> — webhook received
Routing to per-supplier agent: email_id=..., quote_id=..., rfq_id=... — reply stayed in-thread
the quote is updated into awaiting_buyer rather than responded
Running quoting orchestrator engine: trigger_type=supplier_escalation — buyer-side escalation path triggered
Escalation created: task_id=..., team_id=..., title=... — native escalation task created
Not all quotes resolved for rfq_id=... — comparison remains blocked because awaiting_buyer is intentionally non-terminal

Failure clues:

Routing to RFQ parser agent means the reply was not sent in-thread
Running quoting orchestrator engine: trigger_type=comparison before the buyer resolves the escalation is a bug
if the quote lands in responded with pricing, the supplier prompt did not take the escalation path

Verify escalation ack email sent to supplier with buyer CC'd (DNLI-130):

After the orchestrator creates the escalation task, it automatically sends an acknowledgment email to the supplier thread ("We've forwarded your request to the appropriate person on our team") with the buyer CC'd. Verify this:

# Get the TwoCo supplier thread ID
TWOCO_THREAD_ID=$(docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -t -A -c "
  SELECT sel.provider_thread_id
  FROM sent_email_log sel
  JOIN quote q ON q.sent_email_log_id = sel.id
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE s.name ILIKE '%TwoCo%'
    AND q.rfq_id = '$RFQ_ID'
  LIMIT 1;
")
echo "TWOCO_THREAD_ID=$TWOCO_THREAD_ID"

# Check for ack email in the supplier thread with buyer CC'd
docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.to_recipients::text, sel.cc_recipients::text, sel.subject,
    sel.body LIKE '%forwarded%' OR sel.body LIKE '%appropriate person%' as is_ack
  FROM sent_email_log sel
  WHERE sel.provider_thread_id = '$TWOCO_THREAD_ID'
  ORDER BY sel.created_at DESC
  LIMIT 5;
"

Expected:

An ack email exists in TwoCo's supplier thread (after the original outbound RFQ)
The ack email's cc_recipients contains the buyer's email (bt+buyer@didero.ai)
The body mentions forwarding the request to the appropriate person (or similar language)
This is an automatic system action — it happens without buyer involvement

8e. Verify DB state for buyer escalation (with task and junction table verification)

Verify that the quote persisted the buyer-escalation payload instead of a completed quote:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    s.name as supplier,
    q.status,
    q.details->'buyer_escalation' as buyer_escalation,
    q.details->'buyer_escalation'->>'intervention_type' as intervention_type,
    q.details->'options' as options
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = (SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1)
    AND s.name ILIKE '%TwoCo%';
"

Expected:

supplier = TwoCo
status = awaiting_buyer
buyer_escalation is non-null with title, summary, and details
intervention_type is either "suggestion" or "escalation" — the orchestrator determines which based on the content:
- "escalation" — the supplier's request requires buyer action/decision (used with create_escalation())
- "suggestion" — the orchestrator has a recommended action and provides a draft email (used with create_quoting_suggestion(), includes draft_email_subject and draft_email_body)
the escalation content clearly references sustainability / environmental requirements
options should contain 2 preliminary pricing options (standard and expedited) with total_price and lead_time_days populated — these are not finalized but the agent should still parse them

Verify the RFQ did not prematurely finalize:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    id,
    final_comparison_message_id IS NOT NULL as comparison_sent
  FROM rfq
  ORDER BY created_at DESC
  LIMIT 1;
"

Expected: comparison_sent = false

Verify an open escalation or suggestion task exists and is linked to both the RFQ and the quote:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    t.id,
    t.task_type,
    t.status,
    t.title,
    t.subject,
    t.summary,
    tr.rfq_id,
    tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE t.task_type IN ('escalation', 'suggestion')
  ORDER BY t.created_at DESC
  LIMIT 3;
"

Expected:

newest task is task_type = escalation or task_type = suggestion (matching intervention_type)
task status = open
title / summary describe the supplier clarification blocker rather than a generic quote-comparison action
rfq_id is populated — the task is linked to the RFQ via task_rfq
quote_id is populated — the task is linked to the TwoCo quote via task_quote

Verify task-email linkage:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id as task_id, t.task_type, te.email_id, sel.subject
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_email te ON te.task_id = t.id
  LEFT JOIN sent_email_log sel ON sel.id = te.email_id
  WHERE t.task_type IN ('escalation', 'suggestion')
    AND t.status = 'open'
  ORDER BY t.created_at DESC
  LIMIT 3;
"

Expected: Task is linked to the buyer-facing escalation email

Verify "Manage this task in Didero" footer:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.subject, sel.body LIKE '%Manage this task in Didero%' as has_task_footer
  FROM sent_email_log sel
  WHERE sel.rfq_id = '$RFQ_ID'
  ORDER BY sel.created_at DESC
  LIMIT 3;
"

Expected: has_task_footer = true for the escalation email

If intervention_type = suggestion, additionally verify the suggestion fields:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    q.details->'buyer_escalation'->>'draft_email_subject' as draft_subject,
    q.details->'buyer_escalation'->>'draft_email_body' as draft_body
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = (SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1)
    AND s.name ILIKE '%TwoCo%';
"

Expected: Both draft_email_subject and draft_email_body are non-null when intervention_type = suggestion

9e. Verify buyer-facing state (with task UI verification)

Check the buyer-facing UI and messaging surfaces:

/quoting — the RFQ should still be under "Open RFQs". TwoCo should not appear as complete, and the RFQ should not look comparison-ready.
Task row under TwoCo's quote — since this task is linked to a specific quote via task_quote, it should appear as a full-width row under TwoCo in the supplier table (spanning all columns, starting from column 1):
- The task row has teal/primary background styling
- Shows the task title (e.g. "Respond to inquiry" or equivalent)
- Shows the description mentioning the supplier's sustainability question
- Shows confidence score if present
- Action buttons differ by task type (DNLI-128):
  - If intervention_type = escalation: shows "Send Email" and "Dismiss" buttons. Clicking "Send Email" opens an email compose modal pre-filled with the escalation context (supplier email, reply subject, blockquoted details). Verify the modal opens and is pre-filled correctly (DNLI-156).
  - If intervention_type = suggestion: shows "Send Email" and "Dismiss" buttons. Clicking "Send Email" opens an email compose modal (reused from PO management) pre-filled with the draft email subject and body from draft_email_subject / draft_email_body. Verify the modal opens and is pre-filled correctly.
Buyer communications — if the orchestrator emailed the buyer, verify the message concisely summarizes the supplier blocker. If no buyer email was sent but the escalation task exists, record that as the observed behavior; the prompt currently makes the buyer email optional for supplier escalations.

10e. Intermediate checkpoint for the escalation variant

At this point, verify all of the following are true before continuing:

Gmail send was explicitly confirmed for the TwoCo reply
backend routing stayed on the per-supplier path
TwoCo's quote ended in awaiting_buyer
details.buyer_escalation is populated with the sustainability clarification request
details.buyer_escalation.intervention_type is either "suggestion" or "escalation"
a native open escalation/suggestion task was created
the task is linked to both the RFQ (via task_rfq) and the quote (via task_quote)
the task is linked to the buyer-facing email (via task_email)
the buyer-facing email has the "Manage this task in Didero" footer
the task appears in the quoting UI under TwoCo's quote row with teal styling
the task action buttons match the intervention type: "Send Email" + "Dismiss" for both escalation and suggestion (DNLI-128, DNLI-156)
clicking "Send Email" opens the email compose modal pre-filled with draft subject/body (suggestion) or escalation context (escalation)
the RFQ did NOT send a final comparison prematurely

If any of these fail, stop and record the failure. Do not proceed to step 11e.

If all pass, continue to step 11e to resolve the escalation through buyer clarification.

11e. Buyer responds with clarification in the buyer thread

The buyer replies in the BUYER thread (not the supplier thread) with the sustainability clarification. The buyer thread is the thread between bt+buyer@didero.ai and bt@didero.ai — the original RFQ thread whose subject includes #<RUN_UUID>.

Body:

No specific recycled-content minimum, no sustainability report needed, and no REACH/RoHS declarations required for this order.

Sending the reply:

Use gws +reply if available and the run is using the gws mail surface. The reply goes to bt@didero.ai from bt+buyer@didero.ai, replying to the latest agent message in the buyer thread.

If using Gmail browser reply:

Search Gmail for the RUN_UUID and open the buyer thread (the one between bt+buyer@didero.ai and bt@didero.ai, NOT a supplier thread)
Click Reply on the latest message in that thread
Fix From to bt+buyer@didero.ai if not already set
Fix To to bt@didero.ai (remove any wrong auto-populated chip, add bt@didero.ai, press Tab)
Set body using document.execCommand('insertText', ...) — see "Gmail automation tips"
Verify From one more time, then Send
Wait for Gmail to confirm the send (visible toast or sent mailbox evidence)

CRITICAL: This reply goes in the buyer thread, not the supplier thread. The buyer-thread orchestrator (RFQ parser agent) processes replies in the buyer thread and coordinates with per-supplier agents.

Webhook Delivery Fallback: If Pub/Sub isn't delivering (no webhook logs after ~60s despite confirmed Gmail send and healthy tunnel), use the manual webhook injection from the "Webhook Delivery Fallback" section. The payload must:

Use the buyer thread's thread_id (matching the original buyer RFQ thread, NOT a supplier thread)
Set from to bt+buyer@didero.ai
Set to to bt@didero.ai
Include the exact clarification body text (never a placeholder)
Use the real Gmail message ID if available (from gws response or Gmail)

After the send is confirmed, wait ~60s and check logs:

{{DOCKER_COMPOSE}} logs fast-api --since 180s 2>&1 | grep -iE "(Email created|Routing to RFQ parser|Running RFQ parser|buyer.*clarif|escalation.*resolv|resolve_task|forward|per.supplier|orchestrat|error)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -30

Expected log sequence:

Email created: <nylas_msg_id> — webhook received for buyer's reply
Created Cloud Task: ... action_type=process_quoting_email_reasoning — task enqueued
Routing to RFQ parser agent — routed to the buyer-thread orchestrator (NOT per-supplier)
Running RFQ parser quoting engine: trigger_type=email — orchestrator started
Evidence of the orchestrator recognizing the buyer clarification resolves the TwoCo escalation
Evidence of forwarding the clarification to TwoCo's supplier thread (e.g. per-supplier task enqueued, or reply_to_supplier / email sent for the TwoCo thread)
Evidence of task resolution (e.g. resolve_task, task status change)

Failure clues:

Routing to per-supplier agent means the reply landed in a supplier thread, not the buyer thread — check the thread_id
If the orchestrator does not recognize the clarification, it may ask the buyer another question — record this as a prompt compliance issue
If no forwarding to the supplier thread occurs, the orchestrator may not be coordinating with the per-supplier agent — record this as the observed behavior

12e. Verify buyer agent forwards clarification to supplier

After the buyer's clarification is processed (~60s after step 11e logs appear), verify the full resolution flow:

Check logs for forwarding evidence:

{{DOCKER_COMPOSE}} logs fast-api --since 300s 2>&1 | grep -iE "(forward|per.supplier|supplier.*email|TwoCo|quote_id|awaiting_supplier|resolve_task|task.*resolved|escalation.*resolv|Email sent)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -25

Expected:

The buyer-thread orchestrator forwarded the buyer's clarification to TwoCo's supplier thread
A per-supplier agent run was triggered for TwoCo (either via trigger_type=buyer_clarification, trigger_type=email, or equivalent)
The clarification content was sent as an email to TwoCo in the supplier thread (visible as Email sent successfully or equivalent)

Verify the buyer's clarification was forwarded to the supplier thread with buyer CC'd (DNLI-130):

# Check sent_email_log for the forwarded clarification in TwoCo's supplier thread
docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.to_recipients::text, sel.cc_recipients::text, sel.subject,
    sel.body LIKE '%blockquote%' OR sel.body LIKE '%<blockquote%' as has_blockquote,
    sel.body LIKE '%recycled-content%' OR sel.body LIKE '%sustainability%' as has_clarification_content
  FROM sent_email_log sel
  WHERE sel.provider_thread_id = '$TWOCO_THREAD_ID'
  ORDER BY sel.created_at DESC
  LIMIT 5;
"

Expected:

A new email in TwoCo's supplier thread (after the ack from step 7e) containing the buyer's clarification
The email body includes a blockquote of the buyer's note (the sustainability clarification)
The buyer (bt+buyer@didero.ai) is CC'd on this forwarded email (cc_recipients contains the buyer)
The email is addressed to TwoCo (the supplier)

Verify duplicate response guard (DNLI-130):

The duplicate guard prevents the agent from sending a redundant forwarded response if the buyer already replied directly in the supplier thread (via the CC). To verify this works correctly, check that only ONE forwarded clarification email exists in the supplier thread (not duplicates):

# Count forwarded clarification emails in TwoCo's supplier thread (excluding the original RFQ and the ack)
docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT count(*) as forwarded_count
  FROM sent_email_log sel
  WHERE sel.provider_thread_id = '$TWOCO_THREAD_ID'
    AND (sel.body LIKE '%blockquote%' OR sel.body LIKE '%<blockquote%')
    AND (sel.body LIKE '%recycled-content%' OR sel.body LIKE '%sustainability%');
"

Expected: forwarded_count = 1 — exactly one forwarded clarification, not duplicated

Verify the escalation task was resolved:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 10;
"

Expected:

The escalation/suggestion task created in step 8e now has status = resolved (or equivalent completed status)
No new unexpected open tasks were created

Verify TwoCo's quote status transitioned:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT s.name as supplier, q.status
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = '$RFQ_ID'
  ORDER BY s.name;
"

Expected:

TwoCo's quote status transitioned from awaiting_buyer to awaiting_supplier (the escalation is resolved, now waiting for TwoCo to respond with a final quote)
ThreeCo and FourCo quotes remain in their current status (unchanged by the TwoCo escalation resolution)

Verify the RFQ did NOT prematurely finalize:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT id, final_comparison_message_id IS NOT NULL as comparison_sent
  FROM rfq
  WHERE id = '$RFQ_ID';
"

Expected: comparison_sent = false — TwoCo still needs to send a final quote

UI check — Quote Manager: Navigate to http://localhost:{{NEXT_PORT}}/quoting (impersonating Buyer) and verify:

The RFQ is still under "Open RFQs"
TwoCo's status has changed (no longer showing the escalation/awaiting state — now shows "Pending" or equivalent awaiting_supplier state)
The escalation task row under TwoCo's quote should no longer appear as an active open task (it has been resolved)
ThreeCo and FourCo statuses are unchanged

13e. TwoCo responds with final full quote

Now that TwoCo has the buyer's sustainability clarification, they respond with a complete final quote. Reply in-thread on TwoCo's supplier thread (the bt+2@didero.ai thread, NOT the buyer thread).

Use the same in-thread reply workflow from step 7:

Search Gmail for the RUN_UUID and open TwoCo's supplier thread (the thread sent to bt+2@didero.ai)
Click Reply on the latest message in the thread
Pop out the reply, verify From is bt+2@didero.ai, fix To to bt@didero.ai
Set the body to TwoCo's post-clarification final quote body. This body must acknowledge the clarification the buyer provided (sustainability/compliance). Do NOT use the generic happy-path body — TwoCo is responding to the clarification they received, not sending an unsolicited quote:

Dear Brian,

Thank you for confirming the sustainability and compliance requirements. Since no specific recycled-content minimum, sustainability report, or REACH/RoHS declarations are required for this order, we are pleased to confirm our final pricing:

Item Details
- Product: 1/2"-13 x 2" Stainless Steel Hex Bolts (Grade 18-8)
- Specification: ASTM A193 Grade B8, plain finish
- Quantity: 5,000 pcs

Pricing
- Unit Price: $0.42 per piece
- Total Price: $2,100.00 (USD), excluding applicable taxes and shipping

Delivery & Lead Time
- Lead Time: 3-4 weeks from receipt of purchase order
- Estimated Delivery Date: April 8-15, 2026

Commercial Terms
- Minimum Order Quantity: 1,000 pcs
- Quote Validity: 30 days
- Incoterms: FOB Origin
- Payment Terms: Net 30 days from invoice date

Please let us know if you require freight pricing, certifications (e.g., material test reports), or any additional documentation.

Best regards,
TwoName
Sales Manager
TwoCo
bt+2@didero.ai
(555) 123-4567

Verify From one more time, then Send
Wait for Gmail to confirm the send

Webhook Delivery Fallback: If Pub/Sub isn't delivering, use manual webhook injection. The payload must:

Use TwoCo's supplier thread thread_id (matching sent_email_log.provider_thread_id for TwoCo's outbound RFQ)
Set from to bt+2@didero.ai
Set to to bt@didero.ai
Include the exact full quote body text above (never a placeholder)

After the send is confirmed, wait ~60s and check logs:

{{DOCKER_COMPOSE}} logs fast-api --since 180s 2>&1 | grep -iE "(Email created|Routing to per-supplier|update_quote|update_rfq_schema|quote.*status|responded|comparison|trigger_type|error)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -25

Expected log sequence:

Email created: <nylas_msg_id> — webhook received
Routing to per-supplier agent: email_id=..., quote_id=..., rfq_id=... — correctly routed by thread_id match
UPDATE quote SET status=..., details=... — quote updated with parsed final response
Updated RFQ schema: rfq=..., columns=N — per-supplier agent called update_rfq_schema
Supplier quoting reasoning completed: quote_id=..., success=True

Failure clues:

Routing to RFQ parser agent means the reply was not in-thread — check the thread_id
If the quote remains in awaiting_supplier or awaiting_buyer, the per-supplier agent did not process the response as a final quote
If trigger_type=comparison appears in this same log window, that is EXPECTED — it means all quotes are now resolved and the comparison was triggered (proceed to step 14e)

14e. Verify TwoCo quote is now `responded` and comparison triggers

Verify TwoCo's quote status:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT s.name as supplier, q.status,
    jsonb_array_length(COALESCE(q.details->'options', '[]'::jsonb)) as num_options,
    q.details->'options'->0->>'total_price' as total_price,
    q.details->'options'->0->>'lead_time_days' as lead_time
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = '$RFQ_ID'
  ORDER BY s.name;
"

Expected:

TwoCo: status = responded, 1 option with total_price = 2100 (or similar), lead_time_days populated
ThreeCo: status = responded (if replied in step 7), 3 options
FourCo: status = responded (if replied in step 7), 3 options
All 3 quotes are now responded → comparison should trigger

Verify comparison was triggered:

{{DOCKER_COMPOSE}} logs fast-api --since 300s 2>&1 | grep -iE "(trigger_type=comparison|Running quoting orchestrator engine|reply_to_buyer|record_final|comparison)" | grep -v "sqlalchemy" | tail -15

Expected:

Running quoting orchestrator engine: trigger_type=comparison — orchestrator kicked off
reply_to_buyer with tag quote_comparison — comparison email sent to buyer
record_final_comparison — comparison message_id recorded on RFQ

Task verification — comparison creates an escalation task:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, t.summary, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 10;
"

Expected (DNLI-131):

No new open tasks — the comparison is terminal and does NOT create a task
The earlier TwoCo escalation task remains resolved (or accepted)
Total open tasks should be 0

15e. Verify comparison + final state

Verify RFQ finalization in DB:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    r.id,
    r.final_comparison_message_id IS NOT NULL as comparison_sent,
    r.details->'schema' IS NOT NULL as schema_extracted,
    jsonb_array_length(COALESCE(r.details->'schema', '[]'::jsonb)) as num_columns
  FROM rfq r
  WHERE r.id = '$RFQ_ID';
"

Expected:

comparison_sent = true
schema_extracted = true
num_columns >= 5 (4 required + dynamic columns)

Verify comparison email was sent to buyer in Gmail:

Search Gmail for the RUN_UUID and verify the buyer received a comparison email
The comparison email should include pricing details from all 3 suppliers
The comparison email should contain the "Manage this task in Didero" footer

UI verification — Quote Manager:

Navigate to http://localhost:{{NEXT_PORT}}/quoting (impersonating Buyer) and verify:

RFQ moved to Closed RFQs — since final_comparison_message_id is now set, the RFQ should appear under "Closed RFQs" (not "Open RFQs")
Response dots — all 3 dots should be green (all suppliers responded)
Expand the RFQ row — Supplier table should show:
- TwoCo: Status "Complete", 1 option with lead time, total price, and summary populated
- ThreeCo: Status "Complete", 3 options (if replied in step 7)
- FourCo: Status "Complete", 3 options (if replied in step 7)
- Column headers include dynamic columns (SERVICE LEVEL or equivalent tag column for multi-tier suppliers)
Task rows in the expanded RFQ:
- RFQ-level: The comparison review task should appear above the supplier table with title, description, and action buttons (Accept / Dismiss)
- Quote-level (TwoCo): The earlier TwoCo escalation task should NOT appear as an active task (it was resolved in step 12e)
- No unexpected open tasks
All response dots green — take a screenshot confirming all 3 supplier response indicators are green/complete

16e. Completion criteria for the escalation variant

Treat the escalation variant as passing only when ALL of the following are true:

Steps 7e-10e (escalation creation):

Gmail send was explicitly confirmed for the TwoCo escalation reply
backend routing stayed on the per-supplier path
TwoCo's quote ended in awaiting_buyer
details.buyer_escalation is populated with the sustainability clarification request
details.buyer_escalation.intervention_type is either "suggestion" or "escalation"
a native open escalation/suggestion task was created
the task is linked to both the RFQ (via task_rfq) and the quote (via task_quote)
the task is linked to the buyer-facing email (via task_email)
the buyer-facing email has the "Manage this task in Didero" footer
the task appears in the quoting UI under TwoCo's quote row with teal styling
the task action buttons match the intervention type: "Send Email" + "Dismiss" for both escalation and suggestion (DNLI-128, DNLI-156)
an escalation ack email was sent to the supplier thread with the buyer CC'd (DNLI-130)
the RFQ did NOT send a final comparison prematurely

Step 11e (buyer clarification):

Buyer's sustainability clarification was sent in the buyer thread (not supplier thread)
The buyer-thread orchestrator processed the reply
The orchestrator recognized the reply resolves the TwoCo escalation

Step 12e (forwarding + resolution):

The clarification was forwarded to TwoCo in the supplier thread
The forwarded email includes a blockquote of the buyer's note (DNLI-130)
The buyer is CC'd on the forwarded email (DNLI-130)
The duplicate response guard is working — exactly one forwarded clarification exists, no duplicates (DNLI-130)
The escalation task was resolved (status changed from open to resolved)
TwoCo's quote transitioned from awaiting_buyer to awaiting_supplier
The RFQ did not prematurely finalize

Step 13e (TwoCo final quote):

TwoCo's final full quote was sent in-thread on the supplier thread
The per-supplier agent processed it and updated the quote to responded
update_rfq_schema was called

Step 14e (comparison trigger):

All 3 quotes are responded
trigger_type=comparison appeared in logs
Comparison email sent to buyer
Comparison does NOT create a task — it is the terminal step (DNLI-131)
No new open tasks after comparison

Step 15e (final state):

final_comparison_message_id set on RFQ
RFQ moved to Closed RFQs in the UI
All 3 response dots green
Dynamic columns (including tag/tier column) rendered correctly
Resolved TwoCo escalation task no longer showing as active in the UI

If any of steps 7e-10e fail, stop and report failure for the escalation creation phase. If steps 7e-10e pass but any of 11e-15e fail, report PARTIAL — escalation creation passed but resolution flow failed, with details on which step failed. If all steps pass, report PASS for the full escalation variant.

OPTIONAL VARIANT: Task Resolution via Didero App

This variant tests resolving a task through the in-app UI instead of via email reply. It should be run AFTER an escalation task has been created (e.g. after the escalation variant steps 7e-9e, or after any other step that creates an open task).

Prerequisites for this variant:

At least one open task exists for the RFQ (escalation or suggestion type)
The task appears in the /quoting UI

11t. Navigate to the task in the quoting UI

Navigate to http://localhost:{{NEXT_PORT}}/quoting (impersonating Buyer)
Expand the RFQ row
Locate the task row:
- If the task is RFQ-level (no quote_id): look above the supplier table
- If the task is quote-level (has quote_id): look under the supplier's quote row, styled with teal/primary background
Take a screenshot to verify the task is visible with:
- Title text
- Description/summary text
- Confidence score (if present)
- Action buttons (Send Email / Dismiss for quoting tasks)

12t. Record the pre-action state

Before clicking any action button, capture the current state for comparison:

# Record task status
docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
    AND t.status = 'open'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

# Record quote status (for quote-level tasks)
docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT q.id, s.name as supplier, q.status
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = '$RFQ_ID'
  ORDER BY s.name;
"

13t. Click Send Email on the task

In the quoting UI, click the Send Email button on the task row
The email compose modal opens, pre-filled with the email payload (to, subject, body with blockquoted context for escalations, or draft email for suggestions)
Optionally edit the email fields, then click Send in the modal
Wait ~5s for the action to process
Take a screenshot to verify the task row updated (should disappear or show resolved state)

14t. Verify task resolution in DB

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected:

The task that was previously open is now resolved (or equivalent completed status)
No other tasks were unexpectedly modified

15t. Verify system messages, Zendesk email, and supplier forwarding

Task resolution (accept/dismiss) should append system messages to both the buyer and supplier threads. Additionally, for in-app resolutions (DNLI-130), verify the Zendesk-style email and supplier forwarding.

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(task.*resolved|task.*accepted|task.*dismissed|system.*message|thread.*message|resolve_task|Forwarded buyer|post.*resolution|Approved in Didero)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -20

Expected:

Log evidence of resolve_task being called
System messages appended to the buyer thread
System messages appended to the supplier thread (for quote-level tasks)

Verify Zendesk-style system email in buyer thread (DNLI-130):

When a task is resolved from the Didero app (not via email reply), a system-style email is posted to the buyer thread so the email conversation stays in sync:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.subject, sel.body_html LIKE '%Approved in Didero%' as has_zendesk_msg
  FROM sent_email_log sel
  WHERE sel.provider_thread_id = (
    SELECT provider_thread_id FROM sent_email_log
    WHERE team_id = '$TEAM_ID'
    ORDER BY created_at ASC LIMIT 1
  )
  ORDER BY sel.created_at DESC
  LIMIT 3;
"

Expected:

has_zendesk_msg = true — the system email contains "Approved in Didero by [buyer name]"
The email body includes a blockquote of the resolution note
This email appears in the buyer thread (not the supplier thread)

Verify buyer's clarification was forwarded to the supplier thread (DNLI-130):

For accepted escalation tasks, the buyer's clarification should be forwarded to the supplier thread with the buyer CC'd:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT sel.id, sel.to_recipients::text, sel.cc_recipients::text,
    sel.body_html LIKE '%blockquote%' as has_blockquote
  FROM sent_email_log sel
  WHERE sel.provider_thread_id = '$SUPPLIER_THREAD_ID'
  ORDER BY sel.created_at DESC
  LIMIT 5;
"

Expected:

A new email in the supplier thread containing the buyer's clarification in a blockquote
The buyer is CC'd (cc_recipients contains the buyer's email)
Only ONE forwarded clarification (duplicate guard prevents multiples)

16t. Verify quote status transition (for quote-level escalation tasks)

If the resolved task was a quote-level escalation (linked to a quote in awaiting_buyer status), verify the quote status transitioned:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT q.id, s.name as supplier, q.status
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = '$RFQ_ID'
  ORDER BY s.name;
"

Expected:

The quote that was awaiting_buyer has transitioned to awaiting_supplier (accepting the task tells the orchestrator to proceed, which forwards the buyer's clarification to the supplier)
The forwarding email was sent to the supplier thread with the buyer CC'd (verified in step 15t)
Other quotes remain unchanged

17t. Verify UI reflects the resolution

Navigate to http://localhost:{{NEXT_PORT}}/quoting
Expand the RFQ row
Take a screenshot and verify:
- The resolved task row is no longer showing as an active task
- The supplier's quote status has updated (e.g. from "Needs Attention" to "Pending" or equivalent)
- No unexpected UI artifacts remain

18t. Test Dismiss action (optional follow-up)

If additional open tasks exist, repeat steps 11t-17t but click Dismiss instead of Send Email:

Expected differences for Dismiss:

Task status changes to dismissed instead of resolved
Quote status may NOT transition (dismiss means the buyer chose not to act)
System messages still written to threads noting the dismissal
The task row disappears from the active task UI

Completion criteria for the task resolution variant

Treat this variant as passing only when all of the following are true:

The task was visible in the quoting UI before action
Clicking Send Email opened the compose modal, and sending resolved the task in the DB
System messages were written to both buyer and supplier threads
Quote status transitioned appropriately (for quote-level tasks)
The UI updated to reflect the resolution
No unexpected side effects on other tasks or quotes

OPTIONAL VARIANT: Deadline Before All Suppliers Respond

This variant tests the "deadline reached" path where the orchestrator is triggered by a deadline timer instead of all suppliers responding. Instead of replying as both suppliers (step 7), only reply as ONE supplier and then trigger the deadline.

Replace steps 7-10 with the following:

7v. Simulate partial supplier response (ONE supplier only)

Reply to only ONE supplier's RFQ thread (e.g., TwoCo / bt+2). Use the same in-thread reply workflow from step 7 with the same TwoCo body. Do NOT reply as ThreeCo.

After TwoCo's reply is processed (~60s), verify:

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(Email created|Routing to per-supplier|update_quote|quote.*status|completed|error)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -20

Expected:

TwoCo's reply is routed to the per-supplier agent and quote updated to responded
_maybe_trigger_comparison logs: Not all quotes resolved for rfq_id=... (1/2) — comparison NOT triggered yet
ThreeCo's quote remains awaiting_supplier

Verify in DB:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT q.id, s.name as supplier, q.status
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = (SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1)
  ORDER BY s.name;
"

Expected: TwoCo = responded, ThreeCo = awaiting_supplier

8v. Trigger the deadline

The RFQ has a 2-day deadline scheduled via Cloud Tasks. To test without waiting, manually trigger the deadline endpoint:

# Get the most recent RFQ ID
RFQ_ID=$(docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -t -A -c "SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1")

# Get the team_id
TEAM_ID=$(docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -t -A -c "SELECT team_id FROM rfq WHERE id = '$RFQ_ID'")

# Trigger the deadline handler directly via the internal Cloud Tasks endpoint
docker exec {{API_CONTAINER}} python -c "
import asyncio
from app.dependencies import get_db_connection
from app.services.email.quoting_reasoning import QuotingEmailReasoningService
from app.dependencies import build_quoting_reasoning_service
from uuid import UUID

async def trigger():
    async with get_db_connection() as db:
        svc = await build_quoting_reasoning_service(db)
        result = await svc.process_deadline(UUID('$RFQ_ID'))
        print(f'Deadline result: success={result.success}, summary={result.result.summary if result.result else None}')

asyncio.run(trigger())
"

Alternative — use the Cloud Tasks HTTP endpoint (if the above doesn't work due to import path differences):

curl -X POST http://localhost:{{API_PORT}}/api/internal/cloud-tasks/process_quoting_deadline \
  -H "Content-Type: application/json" \
  -H "X-CloudTasks-TaskName: manual-deadline-test" \
  -H "X-Team-Id: $TEAM_ID" \
  -H "X-User-Id: 00000000-0000-0000-0000-000000000000" \
  -d "{\"rfq_id\": \"$RFQ_ID\"}"

Then check logs:

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(deadline|orchestrat|comparison|partial|reply_to_buyer|trigger_type)" | grep -v "sqlalchemy" | tail -20

Expected log sequence:

Running deadline handler for rfq_id=... (1/2 responded, 1 pending) — deadline handler started
System message injected: Deadline reached for RFQ. 1/2 suppliers have responded. 1 still pending.
Running quoting orchestrator engine: trigger_type=deadline — orchestrator started with deadline trigger
Orchestrator calls get_rfq() to see current state
Orchestrator sends partial comparison to buyer via reply_to_buyer() with tag quote_comparison
record_final_comparison — comparison message_id recorded on RFQ

9v. Verify partial comparison behavior (with task verification)

Check the orchestrator sent a partial comparison and noted the pending supplier:

{{DOCKER_COMPOSE}} logs fast-api --since 300s 2>&1 | grep -iE "(orchestrat|comparison|reply_to_buyer|record_final|deadline|pending)" | grep -v "sqlalchemy" | tail -15

Expected:

Orchestrator identified 1 responded (TwoCo) and 1 pending (ThreeCo)
Sent partial comparison email to buyer noting ThreeCo hasn't responded
Called record_final_comparison(rfq_id, message_id)

Verify in DB:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    r.id,
    r.final_comparison_message_id IS NOT NULL as comparison_sent,
    r.details->'schema' IS NOT NULL as schema_extracted
  FROM rfq r
  ORDER BY r.created_at DESC
  LIMIT 1;
"

Expected: comparison_sent = true, schema_extracted = true

Task verification — deadline creates an escalation task:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id, t.task_type, t.status, t.title, t.summary, tq.quote_id
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_quote tq ON tq.task_id = t.id
  WHERE tr.rfq_id = '$RFQ_ID'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected:

An escalation task with status = open for the deadline / partial comparison
The task is linked to the RFQ via task_rfq

Verify task-email linkage and footer:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT t.id as task_id, te.email_id, sel.subject,
    sel.body LIKE '%Manage this task in Didero%' as has_task_footer
  FROM task t
  LEFT JOIN task_rfq tr ON tr.task_id = t.id
  LEFT JOIN task_email te ON te.task_id = t.id
  LEFT JOIN sent_email_log sel ON sel.id = te.email_id
  WHERE tr.rfq_id = '$RFQ_ID'
    AND t.status = 'open'
  ORDER BY t.created_at DESC
  LIMIT 5;
"

Expected: Task is linked to the partial comparison email, and the email has the task footer

10v. UI verification — partial comparison state (with task rows)

Navigate through the relevant pages:

/quoting — Quote Manager should show:
- RFQ under "Closed RFQs" (since final_comparison_message_id is now set)
- Response dots: 1 green (TwoCo responded), 1 gray (ThreeCo pending)
Expand the RFQ row — Supplier table should show:
- TwoCo: Status "Complete", with lead time, total price, and summary populated
- ThreeCo: Status "Pending" (still awaiting_supplier), with empty quote data columns
- Task row above the supplier table: The deadline/comparison task should appear as an RFQ-level task with title, description, and action buttons
Gmail inbox — Verify the buyer received a partial comparison email that:
- Includes TwoCo's pricing details
- Notes that ThreeCo has not responded
- Was sent with the correct quote_comparison tag
- Contains the "Manage this task in Didero" footer with a link to /quoting

OPTIONAL VARIANT: Supplier Followup Threading

This variant tests that supplier followup reminder emails are sent in the original supplier thread rather than starting new threads. Use it after fanout is confirmed (step 6) to verify the followup threading path end-to-end.

When this variant is selected:

Do NOT reply as any supplier — leave all quotes in awaiting_supplier
Manually trigger the supplier followup via the internal Cloud Tasks endpoint
Verify the followup email was sent with reply_to_message_id (in-thread) and not as a new thread
If the followup sends but starts a new thread (missing reply_to_message_id), that is a BLOCKER bug

Replace steps 7-10.5 with the following:

7f. Wait for outbound RFQ emails to sync via webhook

After step 6 confirms supplier RFQ emails were sent, verify that the webhook has synced the outbound emails back (creating email and nylas_email rows). This is required for followup threading to work.

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    sel.provider_message_id,
    e.id as email_id,
    ne.nylas_message_id,
    ne.grant_id
  FROM sent_email_log sel
  LEFT JOIN email e ON e.nylas_message_id = sel.provider_message_id
  LEFT JOIN nylas_email ne ON ne.email_id = e.id
  WHERE sel.subject ILIKE '%RFQ%'
  ORDER BY sel.created_at DESC
  LIMIT 5;
"

Expected:

Each sent RFQ email has a corresponding email row (non-null email_id)
Each email has a nylas_email row (non-null nylas_message_id and grant_id)
If email_id is null, the webhook hasn't synced yet — wait 30-60 seconds and retry

Failure clues:

email_id is null for all rows — webhook isn't processing outbound emails (allowlist issue?)
email_id exists but nylas_message_id in nylas_email is null — junction row wasn't created

8f. Identify the quote and RFQ IDs to trigger a followup

Pick one supplier quote that is still awaiting_supplier:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    q.id as quote_id,
    q.rfq_id,
    q.status,
    s.name as supplier,
    q.sent_email_log_id,
    q.followup_task_name
  FROM quote q
  JOIN supplier_team st ON st.id = q.supplier_id
  JOIN supplier s ON s.id = st.supplier_id
  WHERE q.rfq_id = (SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1)
    AND q.status = 'awaiting_supplier'
  LIMIT 1;
"

Save the quote_id and rfq_id for the next step.

9f. Manually trigger the supplier followup

Call the internal Cloud Tasks endpoint to simulate the followup timer firing:

curl -X POST "http://localhost:{{API_PORT}}/api/v1/emails/execute/process-quoting-supplier-followup" \
  -H "Content-Type: application/json" \
  -d "{\"semantic_key\": \"test-followup\", \"payload\": {\"quote_id\": \"$QUOTE_ID\", \"rfq_id\": \"$RFQ_ID\"}, \"version\": 1}"

Then check logs for the followup processing:

{{DOCKER_COMPOSE}} logs fast-api --since 120s 2>&1 | grep -iE "(supplier.?follow|send_supplier_followup|reply_to_message_id|reply_to_email|threading|NylasEmailError|Cannot resolve threading)" | grep -v "sqlalchemy|WatchFiles|pubsub_service" | tail -20

Expected:

Logs show the followup agent was triggered with trigger_type=supplier_followup
send_supplier_followup was called and succeeded
No NylasEmailError or Cannot resolve threading errors

Failure clues:

Cannot resolve threading for email — the nylas_email junction row is missing (step 7f prerequisite failed)
Initial RFQ email row not found — webhook didn't sync the outbound email
NylasEmailError — threading resolution failed, followup would have been sent as a new thread in old code

10f. Verify the followup was sent in-thread

Check the sent_email_log for the followup email and verify it has reply_to_message_id in its metadata:

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    sel.subject,
    sel.provider_message_id,
    sel.provider_thread_id,
    sel.metadata->>'reply_to_message_id' as reply_to_message_id,
    sel.status
  FROM sent_email_log sel
  WHERE sel.subject ILIKE '%follow%' OR sel.metadata->>'reply_to_message_id' IS NOT NULL
  ORDER BY sel.created_at DESC
  LIMIT 3;
"

Expected:

The followup email has a non-null reply_to_message_id in its metadata — proves it was sent as an in-thread reply
The provider_thread_id should match the original RFQ email's thread ID
status = sent

Critical failure: If reply_to_message_id is null, the followup was sent as a new thread.

Also verify that a followup-related task was created (if the task-based flow applies):

docker exec didero-db-1 psql -U postgres -d {{DB_NAME}} -c "
  SELECT
    t.id as task_id,
    t.title,
    t.task_type,
    t.status,
    t.rfq_id,
    t.quote_id
  FROM task t
  WHERE t.rfq_id = (SELECT id FROM rfq ORDER BY created_at DESC LIMIT 1)
    AND t.task_type ILIKE '%followup%'
  ORDER BY t.created_at DESC
  LIMIT 3;
"

Expected (if followup tasks are implemented): A task row with task_type containing "followup" linked to the correct RFQ and quote. If no followup task type exists yet, this query returning empty is acceptable — note it in the report as "followup tasks not yet implemented."

10f.5 Verify in Gmail (optional visual check)

If time permits, check the supplier's Gmail inbox to visually confirm:

The followup email appears in the same thread as the original RFQ
It does NOT appear as a separate conversation

Completion criteria for the followup threading variant

Treat this variant as passing only when:

Outbound RFQ emails were synced back via webhook (step 7f)
Supplier followup was triggered successfully (step 9f)
Followup sent_email_log has reply_to_message_id in metadata (step 10f)
provider_thread_id matches the original RFQ thread
No NylasEmailError or threading resolution failures in logs
If followup tasks are implemented: task row exists and is linked to the correct RFQ/quote

btoo/SKILL.md

E2E Test: Quoting Flow (Browser)

Port & Container Variables

Video Recording

Prerequisites

Foreground vs Background

Execution Mode

Mail-send Surface

Buyer RFQ documents

Login & Impersonation

UI Verification Philosophy

Verification Cadence

Task Verification Helper

Task UI Verification Helper

Escalation Flow Verification

Buyer-Side Escalation (agent needs info from buyer)

Supplier-Side Escalation (supplier asked a question)

Auto-Resolve Verification

Email Footer Verification

Parallel Supplier Reply Phase

Autonomy

Gmail automation tips

Webhook Delivery Fallback

Steps

1. Open Gmail

2. Compose a new RFQ email

3. Send the email

4. Verify agent processing (RFQ parser)

5. Buyer confirms suppliers

6. Verify supplier RFQ emails

7. Simulate supplier responses

7.5. Verify incremental schema extraction after each supplier

8. Verify required quote option fields in DB

9. Verify orchestrator compiles quotes and extracts dynamic schema

9.5. Verify dynamic schema extraction in DB

10. Final UI verification — dynamic columns, service level pills, and task rows

10.5. Verify CSV download

OPTIONAL VARIANT: Automatic Deadline Closure Before Suppliers Respond

7d. Shorten the RFQ deadline

8d. Verify the deadline timer was rescheduled

9d. Wait for the real deadline to fire automatically

10d. Verify automatic closure outcome (with task verification)

OPTIONAL VARIANT: Supplier Escalation / Buyer Inquiry

7e. Simulate TwoCo escalation reply

8e. Verify DB state for buyer escalation (with task and junction table verification)

9e. Verify buyer-facing state (with task UI verification)

10e. Intermediate checkpoint for the escalation variant

11e. Buyer responds with clarification in the buyer thread

12e. Verify buyer agent forwards clarification to supplier

13e. TwoCo responds with final full quote

14e. Verify TwoCo quote is now responded and comparison triggers

15e. Verify comparison + final state

16e. Completion criteria for the escalation variant

OPTIONAL VARIANT: Task Resolution via Didero App

11t. Navigate to the task in the quoting UI

12t. Record the pre-action state

13t. Click Send Email on the task

14t. Verify task resolution in DB

15t. Verify system messages, Zendesk email, and supplier forwarding

16t. Verify quote status transition (for quote-level escalation tasks)

17t. Verify UI reflects the resolution

18t. Test Dismiss action (optional follow-up)

Completion criteria for the task resolution variant

OPTIONAL VARIANT: Deadline Before All Suppliers Respond

7v. Simulate partial supplier response (ONE supplier only)

8v. Trigger the deadline

9v. Verify partial comparison behavior (with task verification)

10v. UI verification — partial comparison state (with task rows)

OPTIONAL VARIANT: Supplier Followup Threading

7f. Wait for outbound RFQ emails to sync via webhook

8f. Identify the quote and RFQ IDs to trigger a followup

9f. Manually trigger the supplier followup

10f. Verify the followup was sent in-thread

10f.5 Verify in Gmail (optional visual check)

Completion criteria for the followup threading variant

14e. Verify TwoCo quote is now `responded` and comparison triggers