# Commercial Sales Assistant API

Commercial Sales Assistant API is the unified OpenAPI entry point for daigakujoho.com paid-service follow-up.
OpenClaw / Hermes-style assistants should read this first, then use the route-specific Admissions Concierge Operator
API or For Schools Operator API when deeper field detail is needed.

## Public schema

- /api/commercial/operator-openapi: unified OpenAPI 3.1 schema across B2C and B2B commercial workflows
- /api/admissions-concierge/operator-openapi: route-specific Admissions Concierge Operator API
- /api/for-schools/operator-openapi: route-specific For Schools Operator API

## Protected endpoints

These endpoints require Authorization Bearer credentials:

- GET /api/commercial/operator-readiness
- GET /api/commercial/operator-queue
- POST /api/commercial/operator-autopilot
- GET /api/commercial/operator-autopilot-cron
- POST /api/commercial/operator-send-buyer-reply
- GET /api/commercial/operator-execution-events
- POST /api/commercial/operator-execution-events
- POST /api/commercial/operator-send-follow-up
- POST /api/commercial/operator-reply-intake
- POST /api/commercial/operator-reply-intake-record
- POST /api/commercial/operator-payment-evidence-record
- POST /api/commercial/operator-payment-evidence-import
- GET /api/commercial/operator-inbound-replies
- POST /api/commercial/operator-inbound-replies
- POST /api/commercial/operator-inbound-autopilot
- GET /api/commercial/operator-inbound-autopilot-cron
- POST /api/commercial/operator-inbound-email
- GET /api/admissions-concierge/operator-leads
- POST /api/admissions-concierge/operator-actions
- GET /api/for-schools/operator-leads
- POST /api/for-schools/operator-actions
- GET /api/for-schools/operator-prospects
- POST /api/for-schools/operator-outreach-actions
- POST /api/for-schools/operator-prospect-leads

## Commercial Operator Readiness

GET /api/commercial/operator-readiness returns Commercial Operator Readiness for setup checks. Use operator-readiness before assuming email, payment, inbound, or persistence automation is configured. It never returns secret values: it reports env names, presence-derived status, coverageItems, setupArtifacts, manualClosePackets, and nextBestSetupActions only.
Status ready means automation is configured. Status manual_fallback means the commercial workflow can continue manually, but the assistant should not assume an automated provider exists. For payment URLs, manual_fallback means the B2C/B2B paymentRequestPack should continue with the manual_invoice fallback until direct payment URLs are configured. Summary includes paymentDirectUrlCoverageLabel, paymentDirectUrlReadyCount, paymentDirectUrlTotalCount, paymentManualFallbackSkuCount, paymentManualInvoiceStillRequired, paymentMissingSkuLabels, and paymentMissingEnvVars. Do not claim direct checkout is ready while paymentManualInvoiceStillRequired is true. Payment checks may include coverageItems for SKU-level payment readiness; use them to verify each public B2C/B2B SKU before claiming direct checkout is ready. Supabase checks may include coverageItems for table-level Supabase persistence readiness, including commercial_acquisition_inquiry_leads; if evidence includes primary_crm_table_missing, treat the backup event stream as recoverable but do not claim the primary CRM table is ready.
/commercial/operator renders a Close coverage matrix as the operator-facing 90% close coverage view. Read it before enabling send mode: it maps B2C checkout close, B2B school close, Inbound reply close, Payment evidence close, and Asset buyer close to the current automation gate, the assistant move, the Human 10% gate, and the fallback packet. If a row is not ready, use the listed fallback packet or manual-cockpit paste path rather than inventing checkout, payment evidence, valuation, or private data-room state.
When setupArtifacts are present, use the artifact path and copyText as a human-reviewed setup packet. For primary_crm_table_missing, copy scripts/supabase/commercial_crm_tables.sql into the Supabase SQL Editor or apply it through a Postgres migration user, then refresh operator-readiness. SQL setupArtifacts contain no secret values and include commercial_acquisition_inquiry_leads for acquisition buyer inquiries.
For direct checkout setup, operator-readiness may return setupArtifacts with kind payment_provider_setup and path docs/payment-provider-setup.md. Copy that payment_provider_setup packet into the selected payment provider setup task, create one-time checkout links for all six public SKUs, preserve metadata.itemId or client_reference_id as admissions_concierge:{leadId} or for_schools:{leadId}, and send completed payment evidence to /api/commercial/operator-payment-evidence-import with x-commercial-payment-evidence-secret. Do not give payment providers the operator cockpit token.
For email automation setup, operator-readiness may return setupArtifacts with kind email_automation_setup and path docs/email-automation-setup.md. Copy that email_automation_setup packet into the selected Resend and mailbox-forwarder setup task, configure RESEND_API_KEY for outbound sends, wire the mailbox to POST /api/commercial/operator-inbound-email with x-commercial-inbound-secret, and keep payment_confirmed blocked until external payment evidence exists. Do not give mailbox forwarders the operator cockpit token.
Use manualClosePackets when provider automation is missing, partial, or failing. Use manual_close_revenue_rescue for shared recovery steps, manual_close_admissions_concierge for B2C paid leads, manual_close_for_schools for school-side paid leads, and manual_close_acquisition_buyer for acquisition_buyer asset-buyer data-room handoffs. Replace placeholders from the selected queue item, send from the owned mailbox, record payment_request_sent only after the buyer-facing payment request was actually sent, record acquisition_qualification_sent only after the asset-buyer qualification reply was sent, and keep payment_confirmed blocked until external payment evidence exists.

## Commercial Operator Queue

/api/commercial/operator-queue is the single next-best-action queue for commercial follow-up. It merges B2C Admissions
Concierge leads, B2B For Schools inbound leads, and B2B outbound school prospects into one protected response.

Each Commercial Operator Queue item includes:

- segment and kind
- priorityScore and priorityReasons
- amountJPY and totalPipelineValueJPY summary
- protectedDetailEndpoint for the source queue
- recordActionEndpoint for the workflow write
- recommendedActionPayload for the next safe action
- buyerReplyDraft for the actual buyer-facing email draft
- postSubmitAssistantClosePacket for the exact OpenClaw / Hermes post-submit close instruction
- completionGuard with evidencePrompt and requiredConfirmations
- fulfillmentPacket with copyText and deliveryChecklist for paid delivery or school repair handoff
- followUpPlan with cadenceLabel, nextCheckpoint, nextSteps, fallbackIfNoReply, stopConditions, and copyText
- followUpDraft with subject, body, copyText, mailtoHref, sendAllowed, reason, safetyChecklist, and recordActionAfterSend
- pipelineState with statusLabel, urgency, blocker, lastActionLabel, actionCount, shouldStop, and nextBestOutcome
- actionTimeline with the last three recorded actions, operator label, note, and createdAt
- replyReadiness with mode, sendAllowed, recordAllowed, handoffToHuman, requiredBeforeSend, and prohibitedActions
- actionExecution with mode, canRecordNow, recordEndpoint, recordAction, recordAfter, requiredEvidence, onSuccess, onFailure, and humanHandoffReason
- assistantPacket for the reply or outreach draft basis

Use postSubmitAssistantClosePacket before generic assistantPacket for submitted B2C/B2B leads. Do not ask the same SKU, school-list, or school package question again; use the packet to close, clarify the single remaining question, and record the route-specific sent action only after the reply is sent.

The queue response also includes highIntentSignals from anonymous B2C and B2B commercial asset events. Treat
search_decision_brief_copy_click, compare_decision_brief_download_click, university_decision_brief_concierge_click,
ranking_decision_brief_concierge_click, search_parent_approval_pack_copy_click,
search_parent_approval_pack_concierge_click, search_parent_approval_close_packet_copy_click,
search_results_close_bar_copy_click, search_results_close_bar_checkout_click, search_results_close_bar_parent_click, compare_parent_approval_pack_copy_click,
compare_parent_approval_pack_concierge_click, compare_receipt_concierge_click, ranking_parent_approval_pack_copy_click,
ranking_parent_approval_pack_concierge_click, ranking_parent_approval_close_packet_copy_click,
university_parent_objection_pack_copy_click, university_parent_objection_pack_concierge_click,
university_parent_objection_close_packet_copy_click, university_search_close_bar_copy_click,
university_search_close_bar_compare_click, university_search_close_bar_checkout_click,
university_search_close_bar_official_click, university_hensachi_reality_check_copy_click,
university_hensachi_reality_check_compare_click, university_hensachi_reality_check_checkout_click,
university_open_campus_visit_plan_view, university_open_campus_visit_plan_copy_click,
university_open_campus_visit_plan_compare_click, university_open_campus_visit_plan_checkout_click,
university_schedule_conflict_pack_view, university_schedule_conflict_pack_copy_click,
university_schedule_conflict_pack_compare_click, university_schedule_conflict_pack_checkout_click,
news_schedule_conflict_spotlight_compare_click, news_schedule_conflict_spotlight_checkout_click,
concierge_search_query_handoff_request_click, concierge_search_query_handoff_sample_click,
news_schedule_conflict_lens_copy_click,
news_schedule_conflict_lens_compare_click, news_schedule_conflict_lens_checkout_click,
news_open_campus_visit_plan_view, news_open_campus_visit_plan_copy_click,
news_open_campus_visit_plan_compare_click, news_open_campus_visit_plan_checkout_click,
open_campus_after_visit_pack_copy_click,
open_campus_after_visit_pack_concierge_click, open_campus_after_visit_close_packet_copy_click, entrance_route_deadline_pack_copy_click,
entrance_route_deadline_pack_concierge_click, entrance_route_deadline_close_packet_copy_click, tuition_parent_budget_pack_copy_click,
tuition_parent_budget_pack_concierge_click, tuition_parent_budget_close_packet_copy_click, housing_move_commute_pack_copy_click,
housing_move_commute_pack_concierge_click, housing_move_commute_close_packet_copy_click, gourmet_daily_life_pack_copy_click,
gourmet_daily_life_pack_concierge_click, gourmet_daily_life_close_packet_copy_click, career_fit_pack_copy_click,
career_fit_pack_concierge_click, career_fit_close_packet_copy_click, career_vertical_pack_copy_click,
career_vertical_pack_concierge_click, career_vertical_close_packet_copy_click, and related B2C decision
brief events as Admissions Concierge purchase readiness evidence. Treat news_decision_brief_concierge_click, news_search_answer_paid_decision_click, news_search_receipt_close_report_click, news_decision_digest_concierge_click, changes_signal_digest_concierge_click, and changes_decision_brief_concierge_click as paid Decision OS evidence from SEO update readers. Treat public_info_search_rescue_strip_view and public_info_search_recovery_panel_view as Public Info Search Recovery exposure, public_info_search_rescue_copy_click as Public Info Search Rescue Brief copied evidence, public_info_search_rescue_checkout_click and public_info_search_bridge_concierge_click as Public Info Search Recovery checkout evidence, and column_decision_brief_concierge_click as paid Decision OS evidence from content readers. Use B2C decision brief events as Admissions Concierge purchase readiness evidence. Treat
Commercial Services high-intent events such as services_route_advisor_result_click,
services_handoff_admissions_checkout_click, services_delivery_schools_click, and
services_objection_schools_copy_click as route, payment, delivery, and objection-readiness evidence. Treat
for_schools_proposal_sample_download_click and for_schools_procurement_preview_copy_click as
school-side demand evidence. Treat for_schools_scorecard_sample_copy_click,
for_schools_scorecard_sample_download_click, and for_schools_scorecard_sample_request_click as school-side AI surface
diagnosis demand evidence. Treat home_post_portal_router_copy_click,
home_post_portal_router_admissions_click, home_post_portal_router_schools_click,
home_post_portal_router_operator_click, and home_post_portal_router_acquisition_click as homepage post-portal purchase
router evidence: preserve source=home_post_portal_router, keep the Post-Portal Purchase Brief, and move toward the
selected paid output instead of restarting directory search. Use highIntentSignals as demand evidence, not as permission to email an anonymous visitor.
Read highIntentSignals.closeStage before count-only sorting: ready_for_payment_request means a buyer-facing payment request can be prepared only after an identifiable lead or checkout request is matched; checkout_handoff means preserve source/brief/offer and ask one missing blocker; close_packet_copied means reuse the copied close packet once a real lead or inbound reply exists; anonymous_interest is page/product demand only. Use assistantNextStep and humanGate before generic nextAction, and sort highIntentSignals by priorityScore before count when choosing what to review.
Wait for an identifiable Admissions Concierge lead, For Schools lead, inbound reply, or operator-owned outreach prospect
before sending email.

Assistants should fetch this queue first, handle the highest priority actionable item, send or prepare the reply, then
record the completed step through recommendedActionPayload. Do not record recommendedActionPayload until every completionGuard.requiredConfirmations item is true.
When completionGuard.evidenceNoteRequired is true, write a non-empty evidence note before recording recommendedActionPayload; put it into completionGuard.evidenceNoteTargetField.
Use fulfillmentPacket.copyText for paid delivery or school repair handoff, and follow fulfillmentPacket.deliveryChecklist before recording fulfillment or scope confirmation.
Use followUpPlan.copyText to decide when to send reminders or close-loop follow-up, and stop when followUpPlan.stopConditions apply.
Use followUpDraft only when followUpDraft.sendAllowed is true. It is a one-time operator-reviewed follow-up draft, not a drip campaign; when it is false, use followUpDraft.reason and pipelineState.blocker to wait or hand off.
Use pipelineState.statusLabel and pipelineState.blocker to decide whether the item is waiting, blocked, or ready to close; if pipelineState.shouldStop is true, do not send sales follow-up unless the buyer or school replies with a new request.
Use actionTimeline before sending a reply so you do not repeat a recent outreach, payment request, or delivery action.
Use replyReadiness as the final send gate before emailing or recording an action: send only when replyReadiness.sendAllowed is true, wait when mode is wait, and hand off when replyReadiness.handoffToHuman is true.
For B2C Admissions Concierge, buyerReplyDraft should include parentPurchaseApprovalPack before the payment request when family approval is likely. Use parentPurchaseApprovalPack.nextReplyText in the queue-owned buyerReplyDraft so the buyer can paste the family-approved reply without inventing payment scope.
For B2C and B2B payment asks, the queue-owned payment buyerReplyDraft must expose buyerReplyDraft.purchasePolicyUrl and include the 購入前ポリシー line plus paymentRequestPack.confirmationText before asking for payment.
Checkout-intent Admissions Concierge leads with candidateSchools skip the generic first reply and go straight to send_payment_nudge. Use paymentRequestPack.confirmationText or the direct payment URL/manual_invoice instruction, then record payment_requested only after the buyer-facing payment request was sent.
Buyer auto-email may record payment_requested only after buyerEmailed=true. The API response exposes autoEmailActionRecorded, autoEmailAction, and autoEmailActionReason so assistants can tell whether the first buyer-facing payment request was already recorded or whether the queue still needs operator-send-buyer-reply. Search Decision Receipt and Ranking Decision Receipt checkout leads should auto-record payment_requested after the buyer-facing payment request email is sent, because the receipt-to-paid-report context already includes candidate schools, purchase scope, and the one remaining family blocker.
Services route advisor Admissions Concierge leads with candidateSchools also skip the generic first reply and enter send_payment_nudge because the buyer already selected a paid route from /services. Reuse the Services route advisor handoff, paymentRequestPack, and parentPurchaseApprovalPack instead of asking the same route-selection question again.
Services route advisor close packet leads with handoff=route_advisor_close_packet are stronger: the buyer or assistant already captured checkoutUrl, purchasePolicyUrl, assistantInstruction, and humanGate. Treat them as Route Advisor Close Packet Admissions Concierge checkout handoff, Route Advisor Close Packet For Schools checkout handoff, Route Advisor Close Packet Commercial Operator schema handoff, or Route Advisor Close Packet Acquisition inquiry handoff. Move B2C/B2B leads to the paymentRequestPack / purchaseAuthorizationPack confirmation without repeating route-selection questions; move assistant leads to operator-openapi plus dryRun=true first; move asset-buyer leads to public proof pack, buyer qualification, and Acquisition Inquiry Form without quoting valuation or releasing private data-room URLs.
POST /api/commercial/operator-autopilot is the one-step assistant runner. Run operator-autopilot first with dryRun=true. operator-autopilot runs exactly one highest-priority send_then_record work item from the queue, does not accept arbitrary recipient email or arbitrary record endpoint, prefers postSubmitAssistantClosePacket for submitted B2C/B2B close packets when assistantSendMode and recordAfterSend match the selected action, and returns selectedItem, sendResult, recordResult, and executionEvent. If dryRun=false, it sends buyerReplyDraft or the selected postSubmitAssistantClosePacket and records recommendedActionPayload only after emailSent=true. Optional recordDryRunEvent is for scheduled evidence and writes a handoff execution event without sending email or recording CRM action. When no safe work item exists, recordDryRunEvent can write an idle heartbeat event, proving cron is alive without sending email or recording CRM action.
GET /api/commercial/operator-autopilot-cron is the scheduled execution layer. The 3060 local cron calls operator-autopilot-cron daily and authorizes it with CRON_SECRET. By default the cron stays dry-run; set COMMERCIAL_OPERATOR_AUTOPILOT_MODE=send only after reviewing dry-run output and email provider readiness. Cron dry-runs write a Commercial Operator Execution Event with status handoff when a candidate is selected or an idle heartbeat when no candidate is safe. The cron route uses the server-side operator token and does not accept query-string overrides for send mode, recipient, or record endpoint.
POST /api/commercial/operator-send-buyer-reply sends the selected queue item's buyerReplyDraft by itemId, or the exact postSubmitAssistantClosePacket when bodySource=postSubmitAssistantClosePacket. Use operator-send-buyer-reply only after replyReadiness.sendAllowed is true. It sends the queue item's buyerReplyDraft or requested postSubmitAssistantClosePacket and rejects arbitrary recipients. Use bodySource=postSubmitAssistantClosePacket for submitted B2C/B2B close packets so OpenClaw / Hermes does not ask the same SKU, school-list, or school package question again. Payment buyerReplyDraft bodyOverride must include buyerReplyDraft.purchasePolicyUrl; otherwise the send endpoint blocks with payment_policy_missing_from_body_override. Exact paid fulfillmentPacket.copyText bodyOverride is exempt from that purchasePolicyUrl guard. Then record recommendedActionPayload and post a Commercial Operator Execution Event. For paid delivery, use the same endpoint with bodyOverride from fulfillmentPacket.copyText and subjectOverride from the delivery packet title; record report_delivered or repair_delivered only after emailSent=true.
POST /api/commercial/operator-send-follow-up sends the selected queue item's followUpDraft by itemId. Use operator-send-follow-up only after followUpDraft.sendAllowed is true. It sends the queue item's followUpDraft and rejects arbitrary recipients. It records a Commercial Operator Execution Event, but does not automatically record recommendedActionPayload. In watch_payment it may send one payment-help follow-up for invoice or payment-link friction. Do not record payment_confirmed from a payment-help follow-up; wait for external payment evidence. A successful follow-up execution event disables repeat follow-up sends for that item.
POST /api/commercial/operator-reply-intake triages a pasted inbound buyer or school reply by itemId. Use operator-reply-intake when a buyer or school replies by email. It classifies reply intent and returns a safe triage object with recordAllowed, recordEndpoint, recordBody, evidenceNote, nextStep, and replyDraft for operator-reviewed customer replies. Use replyDraft.copyText only after human/assistant review; reply_draft_does_not_record_workflow_action. Do not record payment_confirmed from buyer email alone; payment claims require external payment evidence first. payment_claim_requires_external_payment_evidence. Refund or cancellation questions become refund_cancellation_question with purchase_policy_answer; send only the reviewed policy reply and do not record refund, cancel, payment, delivery, or closed_lost state from that reply alone. refund_cancellation_reply_does_not_record_workflow_action. Missing promised deliverable or free correction requests become deliverable_correction_request with correction_request_answer; answer the 1回補正 boundary and collect the item ID, missing promised section, expected wording, and official/source evidence, but do not record payment, delivery, refund, cancellation, or closed_lost state from that reply alone. free_correction_request_does_not_record_workflow_action.
Reply-intake also handles objection replies as first-class customer-service intents: price_objection, guarantee_objection, manual_invoice_question, procurement_roi_objection, and competitor_alternative_question. Objection reply drafts are customer replies only: send or copy replyDraft.copyText after review, but do not record workflow progress from the objection alone. objection_reply_does_not_record_workflow_action. Price objections must not be answered with discounts; no-guarantee objections must not become admission, ranking, or inquiry-volume guarantees. Competitor or alternative-tool questions are customer replies only: competitor_alternative_question returns competitor_alternative_answer and should explain that Manavision, PassNavi, and StudySapuri are discovery portals while daigakujoho sells post-portal decision output and official answer repair; do not record workflow progress from that reply alone. Asset buyer proof pack requests are customer replies only: asset_proof_pack_request returns asset_proof_pack_answer for traffic proof pack, revenue proof pack, automation proof pack, or risk cleanup proof pack and includes selected proof pack artifacts such as traffic proof artifact, revenue proof artifact, automation proof artifact, and risk cleanup artifact; it is not a valuation number and not a valuation guarantee, and asset_proof_pack_reply_does_not_record_workflow_action. NDA/private data-room requests are human-reviewed handoffs only: acquisition_private_data_room_request returns acquisition_private_data_room_handoff, does not release private data-room URLs or non-public artifacts, and private_data_room_reply_does_not_release_private_data. Acquisition or valuation questions are customer replies only: acquisition_inquiry returns acquisition_next_step_answer with the public data room, proof-to-valuation underwriting checklist, and buyer qualification request; it does not quote an asking price, valuation number, multiple, or revenue guarantee, and acquisition_inquiry_reply_does_not_record_workflow_action. Proof or sample requests are customer replies only: proof_sample_request returns proof_sample_answer with the public deliverable sample and inbox proof links; do not record payment, delivery, scope confirmation, or closed-lost workflow progress from that reply alone. Sample/proof accepted and payment requested becomes post_sample_payment_request with payment_request_ready_answer. Use the queue-owned paymentRequestPack or buyerReplyDraft, then record payment_requested only after the buyer-facing payment request was sent; post_sample_payment_request_does_not_record_payment_confirmed.
POST /api/commercial/operator-reply-intake-record analyzes a pasted inbound buyer or school reply and records one safe action when the server-generated triage allows it. Use operator-reply-intake-record only when you want the server to analyze and record one safe reply action. It does not accept arbitrary record endpoints or recordBody. It will not record payment_confirmed from buyer email alone; payment claims return human handoff until external payment evidence is confirmed.
POST /api/commercial/operator-payment-evidence-record records reviewed external payment provider evidence for Admissions Concierge and For Schools, then records payment_confirmed when the payer, amount, and lead match. Use itemId admissions_concierge:{leadId} or for_schools:{leadId}. Use operator-payment-evidence-record only after external payment provider evidence exists. Do not use buyer email claims as payment evidence. It does not accept arbitrary record endpoints or recordBody. On success, read postPaymentFulfillment (commercial.post_payment_fulfillment.v1). Use postPaymentFulfillment after payment evidence is recorded: send fulfillmentPacket.copyText through /api/commercial/operator-send-buyer-reply, use fulfillmentPacket.title as subjectOverride, and recordActionAfterDelivery only after emailSent=true.
Use operator-payment-evidence-import for payment provider webhook or import automation. POST /api/commercial/operator-payment-evidence-import accepts generic or Stripe-like payloads with itemId in top-level itemId, metadata.itemId, metadata.commercialItemId, or client_reference_id, then calls the same payment evidence recorder. Forwarder auth uses x-commercial-payment-evidence-secret or Authorization Bearer, but that bearer value is the dedicated payment evidence import secret. Do not give payment providers the operator cockpit token.
Use operator-inbound-replies as the provider-agnostic inbox for buyer or school email replies. It stores sanitized text, not raw HTML. GET /api/commercial/operator-inbound-replies lists recent replies, and POST /api/commercial/operator-inbound-replies records a reply from a manual paste, forwarder, or mail provider. Then use operator-reply-intake-record for matched replies.
POST /api/commercial/operator-inbound-autopilot runs exactly one matched inbound reply through reply-intake and prepares the selected replySendMode. Run operator-inbound-autopilot first with dryRun=true. operator-inbound-autopilot runs exactly one matched inbound reply, skips matched inbound replies whose replyDraft is not sendRecommended, does not accept arbitrary recipient email, recordEndpoint, or recordBody, and returns selectedInboundReply, skippedInboundReplies, triage, replySendMode, sendResult, recordResult, executionEvent, and assistantHandoff. assistantHandoff uses schema commercial.operator_inbound_autopilot_assistant_handoff.v1 and gives sendEndpoint, sendRequestBody, reviewBeforeSendSource, sendAllowedNow, recordActionAfterSend, recordEndpointSource, completionCondition, acquisitionClosingPacketSource, acquisitionClosingPacketSnapshot, nextStep, and safetyChecklist. Read assistantHandoff before enabling dryRun=false so OpenClaw / Hermes can execute one safe next step without inventing recipient, recordEndpoint, or recordBody. Normal replies use replySendMode=reply_intake_draft and do not record workflow action from inbound handling. asset_proof_pack_request, acquisition_private_data_room_request, and acquisition_inquiry stay reply_intake_draft only and do not record valuation, deal state, or workflow action from inbound handling; when acquisitionClosingPacketSource is queue.acquisitionClosingPacket, use acquisitionClosingPacketSnapshot.selectedProofPack, send_selected_public_proof_pack_before_private_data, and private_data_room_requires_human_review before releasing any private data-room URL or non-public artifact. post_sample_payment_request uses the queue-owned paymentRequestPack buyerReplyDraft with replySendMode=queue_buyer_reply_draft only when the queue recommendedActionPayload is payment_requested or payment_request_sent, then records the queue-owned payment request action only after emailSent=true. If dryRun=false, it sends the selected replySendMode; queue_buyer_reply_draft can record the queue-owned payment request action only after emailSent=true.
GET /api/commercial/operator-inbound-autopilot-cron is the scheduled inbound-reply layer. The 3060 local cron calls operator-inbound-autopilot-cron daily and authorizes it with CRON_SECRET. By default the inbound cron stays dry-run; set COMMERCIAL_OPERATOR_INBOUND_AUTOPILOT_MODE=send only after reviewing dry-run output and email provider readiness. Inbound cron dry-runs write a Commercial Operator Execution Event with status handoff when a matched reply is selected. The cron route uses the server-side operator token and does not accept query-string overrides for send mode, recipient, recordEndpoint, or recordBody.
Use operator-inbound-email for real mailbox or forwarder automation. POST /api/commercial/operator-inbound-email accepts Cloudflare Email Routing, Gmail Apps Script, Resend inbound, or generic email-forwarder JSON. Forwarder auth uses x-commercial-inbound-secret or Authorization Bearer, but that bearer value is the dedicated inbound email secret. Do not give forwarders the operator cockpit token. The endpoint normalizes sender, subject, text/plainText/bodyText/strippedText or html/bodyHtml into the same sanitized inbound reply inbox.
Use actionExecution to record successful sends or external events, and to choose wait or human handoff on failure; never invent a record endpoint when actionExecution.recordEndpoint is null.
Do not record payment_confirmed, report_delivered, or scope_confirmed until the external event actually happened.

## Commercial Operator Execution Events

GET /api/commercial/operator-execution-events returns the recent server-side execution trail for the cockpit and
assistants. Read execution events before retrying so browser changes do not erase the operational trail.

POST /api/commercial/operator-execution-events records success, failure, or human handoff after an action attempt.
Post an execution event after each success, failure, or human handoff. Use status success only after
recommendedActionPayload succeeds, failed when an endpoint or external send fails, and handoff when a human operator
must review the item before more buyer-facing work.

## B2C Admissions Concierge workflow

Use Admissions Concierge for students and parents buying one-time decision output.

send_first_reply -> request_missing_info -> send_payment_nudge -> watch_payment -> deliver_report -> post_report_growth

The assistant should use tonightDecisionPack, admissions_concierge.tonight_decision_pack.v1,
parentPurchaseApprovalPack, admissions_concierge.parent_purchase_approval_pack.v1, and
paymentRequestPack.confirmationText before asking for payment. If payment URLs are missing, continue with the
manual_invoice fallback instead of dropping the lead. Include the purchase policy URL https://daigakujoho.com/purchase-policy in
paymentRequestPack.confirmationText before asking for payment. SKU-level payment readiness comes from operator-readiness
coverageItems. After report_delivered, use post_report_growth once, record post_report_follow_up_sent, and do not turn
the relationship into a subscription drip. Do not promise admission results.

/admissions-concierge includes a buyer proof packet Admissions Concierge handoff before checkout confirmation. If a
visitor arrives with source=buyer_proof_packet&intent=checkout&brief=buyer_proof_packet, treat the buyer as having
already seen the 48-hour action report sample, paymentRequestPack.confirmationText, manual_invoice fallback, OpenClaw /
Hermes first reply, and Human 10% gate. Do not ask the same proof questions again; confirm only candidate schools,
scope, and payment method before sending paymentRequestPack.confirmationText. Track proof readiness through
concierge_buyer_proof_packet_copy_click, concierge_buyer_proof_packet_download_click, and
concierge_buyer_proof_packet_checkout_click.

/admissions-concierge also includes the Purchase Route Closer handoff. If a visitor arrives with
source=concierge_purchase_router and brief=receipt_to_report_router, brief=parent_approval_router, or
brief=deadline_close_router, treat the buyer as having already selected a SKU route, paid output,
assistantNextAction, and humanGate. The high-intent event is concierge_purchase_router_checkout_click. Use the
Purchase Route Closer as SKU-selection evidence; preserve the selected offer and route, avoid repeating the route
question, and confirm only the minimum missing scope before paymentRequestPack.confirmationText.

## B2B For Schools inbound workflow

Use For Schools for school-side inbound repair and AI-answer package leads.

send_school_reply -> request_official_url -> prepare_scope_confirmation -> scope_confirmed -> send_payment_request -> watch_payment -> deliver_school_repair

The assistant should open with surfaceDiagnosisPack, for_schools.surface_diagnosis_pack.v1, then ask for one official
URL before drafting claims. Use paymentRequestPack.confirmationText after scope is clear, and continue with the
manual_invoice fallback when direct payment URLs are missing. Include the purchase policy URL https://daigakujoho.com/purchase-policy
in paymentRequestPack.confirmationText before asking for payment. Record payment_request_sent after sending the payment
request, record payment_confirmed only after external payment evidence, then deliver the Admissions Surface Repair Kit
and record repair_delivered.

/for-schools includes a school buyer proof packet For Schools handoff before the request form. If a visitor arrives
with source=school_buyer_proof_packet&intent=checkout&brief=school_buyer_proof_packet, treat the school buyer as having
already seen the AI進路面スコアカード sample, paymentRequestPack.confirmationText,
purchaseAuthorizationPack.internalApprovalMemo, manual_invoice fallback, OpenClaw / Hermes first reply, and Human 10%
gate. Do not ask the same proof questions again; confirm one official URL, scope, and payment method before sending
paymentRequestPack.confirmationText. Track proof readiness through for_schools_buyer_proof_packet_copy_click,
for_schools_buyer_proof_packet_download_click, and for_schools_buyer_proof_packet_checkout_click.

/for-schools also includes a School Purchase Route Closer between the school buyer proof packet and the request form.
It uses source=school_purchase_router with brief=school_diagnosis_router, brief=open_campus_bridge_router, or
brief=official_answer_router. Use the School Purchase Route Closer as school-side SKU-selection evidence: preserve the
selected package, paid deliverable, assistant next action, and human gate, then confirm only the official URL, scope, and
payment method before paymentRequestPack.confirmationText. Track this route through
for_schools_purchase_router_checkout_click.

## B2B outbound workflow

Outbound school prospecting starts from the protected prospect queue:

send_outreach -> wait_for_reply -> convert_reply_to_lead

Use /api/for-schools/operator-prospects to pick a prospect, record outreach_sent with
/api/for-schools/operator-outreach-actions, then use /api/for-schools/operator-prospect-leads after school_replied to
create a payable For Schools lead. Each prospect includes outreachSalesPack with schema
for_schools.outreach_sales_pack.v1, firstEmailSubject, firstEmailBody, internalForwardText, replyQualification,
conversionTrigger, assistantChecklist, and guardrails. Use the sales pack as the canonical first-contact script; do not
record school_replied from opens, clicks, or anonymous demand signals.

## Guardrails

- Do not promise admission results.
- Do not promise placement, ranking, or admission outcomes.
- Do not imply university referral compensation.
- Do not invent official facts, fees, deadlines, Open Campus dates, or admission requirements.
- Ask for one official URL before drafting claims for a school.
- Use payment_confirmed only after external payment evidence exists.
- Record actions after the operator or assistant has actually sent the reply or completed the step.