849879772 / recruitment-mail

Recruitment Mail

Current-turn processing

An application with no valid saved record_url is 仅邮件更新 (mail-only), not an
invalid application. Its missing website link must not block a uniquely bound,
verified mail event or trigger a browser follow-up. The same evidence, identity,
time, approval, and forward-only stage rules below still apply. An unmatched mail
requires user-confirmed binding where applicable; do not invent a link or a match.

For a request to process mail, use recruitment_mail_run_start and keep the assistant
turn open. It waits for up to 20 seconds; if continuation_required=true, call
recruitment_mail_run_status(run_id=the_returned_id,wait_ms=20000) until the saved run
reaches a terminal state, then report its actual outcomes. A bounded wait returning
active is not a failure or a reason to ask the user whether to continue. Never end
with only “后台已启动，请稍后询问”. Progress cards remain visible during the wait.
Only the full recruitment crawl uses that fire-and-forget interaction.

Always pass the current conversation's thread_id when starting conversational
mail processing. Never guess the newest global task to attach an unrelated chat.
If the run returns awaiting_confirmation, the task is NOT completed: report
“等待你选择关联岗位” and let the workbench's single confirmation dialog collect the
choice. Do not keep polling, ask the user to type a job name/“继续”, or create another
processing run for these pending records. The durable original scope is resumed
by the confirmation action after a valid human-approved binding; other failed or
completed mail is not replayed. Closing the dialog means later, not rejection.
The final automatic summary is read-only and must describe that exact run's saved
receipt; it never authorizes syncing, processing, binding, or stage writes again.

Before reporting mail results, inspect the saved run's freshness and sync_warning.
synced confirms a mailbox refresh; cached reuses a recent refresh and must not be
described as a new fetch. If sync_warning=true, report “未确认最新邮件，仅处理本地已保存邮件”
and the actual local processing outcomes. A partial run may mean synchronization
failed even when all local messages were processed. not_requested means no refresh
was requested; never infer mailbox freshness from local processing success. A
mail_sync_in_progress response means another sync is pending, not that it failed.

Mailbox freshness does not prove new model analysis. Read model_attempted_count
(messages sent to triage/analysis), model_call_count, historical_failure_count,
and failure_results[].analysis_source. history means a saved outcome was reused,
not a new model attempt. model_attempted_count is not a completed-analysis count.
Use saved safe diagnostics: http_401/403 is authentication, http_429 is rate
limiting, http_5xx is a service response, transport_failed is a transport failure,
and output/schema errors do not prove service unavailability. An old generic
DeepSeekClientError cannot identify the underlying cause.

The service retries transient transport/408/429/5xx failures at most once per
model request with short backoff, and allows at most three processing rounds for
the same evidence/input with cooldowns. A legacy generic client failure gets one
bounded compatibility round. Status polls never spend or reset a retry budget.
After those limits, or after configuration/output failures, do not automatically
keep starting runs to retry the failure. When the user explicitly requests a retry,
use recruitment_mail_run_start(retry_failed=true,record_ids=[selected failed IDs],refresh=false).
This requires 1–50 explicit failed records, freezes their current digests, does not
refresh/expand the mailbox, and authorizes only one new bounded round per selected
record. Successful mail cannot be retried. Follow the normal bounded wait until
terminal. User-triggered retry does not waive evidence, identity, forward-only
stage, or source-bound schedule idempotency checks.

If interrupted, discover saved runs without asking the user for an internal ID;
resume only on their instruction via recruitment_mail_run_control(action=resume)
and keep waiting in this turn. Pause/cancel is explicit and cannot be undone by a
status poll. For a progress-only query, read once with wait_ms=0; do not start work.
The durable run freezes and processes batches internally through the same guarded
recruitment_mail_process pipeline. The legacy per-batch limits below apply only
when that lower-level tool is used directly, not to the durable run's read-only waits.

Assessment invitations (assessment) remain classified as assessment mail but map to
applied, not a written-test stage. Explicit written-test notices (written_test) map
to written. Use the mail content to distinguish them; neither case may roll back a
later application stage.

The confirmation dialog supports multiple applications only for a validated
company-wide assessment/written-test event without an exclusive job title/code.
Use allows_multiple and selection_scope from binding candidates, not an
assistant-created guess. A user may select several same-company applications in
one approved binding; application_ids and applications are authoritative, while
the legacy application_id is only the compatible primary target. Job-specific
notifications remain single-target. Do not auto-select, approve, expand to all
company applications, or replay one confirmation per selected job.
After confirmation the original run resumes once, validates each selected identity
and forward-only event update independently, and exposes application_results.
Report partial failures separately; one successful application does not prove every
selected application was updated. The one source-bound schedule_item lists its
application_ids/associated_jobs; never create a copy per selected application.

1. Read redacted summaries first and open only the required persisted detail. recruitment_mail_search,
   recruitment_mail_detail, and recruitment_mail_review are read-only; their refresh path may
   sync the mailbox but must not update application progress or create schedule items. Only an
   explicit recruitment_mail_process pass may create a schedule item.
   Review previews require existing validated model analysis. If it is missing, report that
   processing is required; never lower thresholds or use historical keyword fields as evidence.

2. Use recruitment_mail_processing_status only to inspect persisted processing state. It does not
   synchronize mail, call a model, or write. Distinguish model proposed analysis from verified
   identity/event evidence and the actual written or unchanged application outcome.

3. Call recruitment_mail_process only when the user explicitly requests processing.
   Omit timeout_ms to use its default 90000, or set at most 90000; do not discover this limit by a rejected call.
   It performs the bounded triage/full-analysis pass and invokes the unified guarded write path;
   do not replay pending body classification in the tool or fan out one write call per message.
   One call processes at most ten messages, not the whole mailbox. For a request to process all
   pending mail, continue with the same original scope when has_more=true and processed>0.
   Make at most five batch calls per turn. Do not reset failure budgets or expand an explicit scope;
   an explicit user retry uses the targeted durable-run entry described above.
   Stop on blocked results, no progress, or the call limit and report remaining_count.
   Aggregate all batch counts; never say all mail is processed merely because one batch completed.
   Before claiming completion, require has_more=false and scope_complete=true, inspect
   recruitment_mail_processing_status, and disclose any unresolved/failed records across batches.

4. The process service refreshes mail once, skips already processed and non-retryable records, and
   returns the actual per-record outcomes. For assessment, written_test, interview, and
   action_required, it also creates or reuses the source-bound item in the shared
   schedule_event_snapshots table and returns it as that result's schedule_item. A company-only
   assessment or action reminder may legitimately have application_id=null; never force an
   application binding from a company or job-title guess. Inspect each returned schedule_item,
   plus the batch totals schedule_items_created and schedule_items_time_unconfirmed.
   Do not call schedule_manage(action=create) to recreate a mail-derived item, even when its
   time is unconfirmed; use the returned item. If the user explicitly asks to edit an existing
   mail-derived item, schedule_manage(action=update) is allowed; preserve its source and
   source_ref and do not create a second item.
   Treat completed and partial as results to inspect,
   not permission to invent success; blocked, failed, ambiguous_application,
   pending_association, and failed_terminal remain unresolved or failed as reported.

5. Treat model output as an untrusted proposal. For an application-stage write, require persisted
   sender, exact evidence, event meaning/time, and unique application identity; a company-only
   match is never sufficient for that application-stage write. This rule does not require a
   company-level schedule item to bind an application: a valid assessment/action todo may keep
   application_id=null. When an application is explicitly supplied for a schedule item, use its
   exact company/job identity and reject a mismatch; do not infer the binding. An unchanged or
   stale application result is not a write.

6. Do not make speculative writes or retries. A terminal or retryable=false outcome for the
   same persisted evidence version must not be resubmitted with altered quotations, IDs, or
   prompts. Apart from the service's bounded transient retries, retry only when evidence/input
   changes or the user explicitly authorizes the targeted retry_failed=true run. A retry of
   mail analysis is not authority to replay or bypass a rejected application-stage write.

7. Handle one-off processing directly.
   A mail analysis/schema failure is not evidence that an application changed. Report it as
   a mail-pipeline failure, not a provider failure unless the diagnostic confirms that origin.
   Do not substitute browser status checks for failed mail analysis or missing mail details:
   they cannot recover the assessment invitation or its deadline. If the user also requested
   browser verification, keep that independent result separate from the failed mail task.
   Do not use a scheduler workaround, unrelated RAG/search, web exploration,
   a second calendar-creation call for a mail-derived item, or external
   sending/deletion when local records suffice. Explicit user-created local tasks may use
   schedule_manage; mail-derived schedule items must come from recruitment_mail_process, with
   schedule_manage(action=update) reserved for an explicit edit of an existing returned item.

8. Preserve returned internal states exactly, but use Chinese labels in normal user-facing output:
   模型建议, 已验证, 已写入, 状态未变化, 无法确认, and 执行失败. Report
   notifications separately as 普通通知已处理（无需关联） and reminders as 待办提醒.
   Neither category is a verified unchanged application status. A pure thank-you/welcome receipt
   needs no application association. Read its full body first; real events and actions take precedence.
   has_more=false or zero pending only means no runnable batch remains. If unfinished_count>0
   or scope_complete=false, explicitly report remaining unresolved/failed mail; do not say all mail
   is resolved or the mailbox is fully completed. Use Chinese summary labels, not raw English keys.
   Summarize only this invocation's results and unresolved items in scope. Do not list old
   completed mail (for example Dahua/DJI) or read their bodies just to decorate the summary.
   Refresh processing status before the final answer and before offering to process any
   previously mentioned unresolved IDs. Current persisted states override conversation history.
   If no runnable items remain but unresolved items exist, say the automatic batch finished
   and report the remaining required actions, not that every mail was resolved.
   Historical results may be mentioned only when the user explicitly asks about history or
   a current conflict requires that specific evidence. Never equate listing metadata with
   rereading or reprocessing an email.
   Never claim that a
   proposed model analysis was verified or that a guarded write occurred without the returned write
   result.

9. Never expose mailbox credentials, model/API keys, tokens, complete message bodies, or
   unnecessary message content.