Files

inman 19628c7519 Initial commit

2026-07-13 19:57:46 +08:00

3.5 KiB

Raw Permalink Blame History

name, description

name	description
erp-export-recovery	Use when a saved LaoTai/LianTai ERP order needs confirmation, JOB, visitor-detail export, or post-save export recovery without creating or saving the order again.

ERP Export Recovery

Scope

This Skill handles source-artifact export for an existing ERP identifier and recovery after a confirmed save whose export or delivery failed. It never creates an order, edits an order, or re-saves a saved order. The deterministic entrypoint is scripts/run_export_recovery.js.

Require a real existing ERP identifier from the user or local registry. If the identifier is missing or ambiguous, return needs_clarification. A parent plan is not a customer order and cannot be exported as a customer confirmation.

Export type policy

Default to xingyou-confirm, the source confirmation artifact used by the current API-first flow.
Allow liantai-confirm only when the user explicitly requests Liantai.
Allow job-order for JOB/filing only when explicitly requested.
Allow visitor-detail only when the user explicitly asks for visitor/customer detail output and the runtime supports it.
Do not silently bundle types. Normalize aliases such as confirmation, xingyou, liantai, job, and beian before validation.
Block split_parent confirmation export.

Recovery policy

For an order that has already saved, set recovery.exportOnly: true and recovery.neverResave: true. Export failure must produce a recovery task or blocked result, never a new create_order task. If the save state is uncertain, use execution_uncertain and query the ERP/registry before any retry. Do not infer a saved identifier from a stale browser row.

Source artifacts remain the primary output. PDF conversion is a separate delivery concern handled by erp-pdf-delivery; it is not automatically triggered by this Skill. Keep the source file when PDF conversion fails.

Task shape

The ready task contains status: "ready", operation: "export_confirmation", task.schemaVersion: "erp-task-v1", a non-empty identifier, exportTypes, recovery.exportOnly, recovery.neverResave, attachments, and originalText.

Example:

{
  "status": "ready",
  "operation": "export_confirmation",
  "task": {
    "schemaVersion": "erp-task-v1",
    "taskId": "task-20260712-003",
    "operation": "export_confirmation",
    "identifier": "D14079",
    "exportTypes": ["xingyou-confirm"],
    "recovery": { "exportOnly": true, "neverResave": true },
    "attachments": [],
    "originalText": "订单已保存但确认件失败，请只恢复导出"
  }
}

Script handoff

Use validation and the export-only wrapper:

node scripts/validate_erp_task.js --task <task.json> --json
node scripts/run_export_recovery.js --task <task.json> --mode dry-run --config config/erp-deployment.local.json --json

Dry-run is the default. Execute still requires local safety/config authorization, registry lookup, session readiness, and artifact verification. Do not expose internal artifact paths or browser details in customer replies.

Results

dry_run: the identifier and requested source export are planned; nothing was saved.
completed: report the existing identifier and safe artifact names/types.
blocked or invalid_task: report the missing identifier, forbidden parent export, unsupported type, registry gap, or safety condition.
post_save_recovery_required: continue with this Skill only; do not route back to create.
execution_uncertain: re-query before retrying.

3.5 KiB Raw Permalink Blame History