2.7 KiB
name, description
| name | description |
|---|---|
| erp-runtime-safety | Use when an ERP task may move from dry-run to real submit, encounters duplicate or uncertain save state, or needs a safety decision before browser/API execution. |
ERP Runtime Safety
Role
This is a reusable safety policy for the coordinator and execution scripts. It evaluates whether a requested ERP action may proceed; it does not grant authorization, edit local config, operate Chrome, or replace the dispatcher guard.
Required gates
- Start in dry-run. A real submit requires an explicit execute mode, config.safety.allowRealSubmit=true, and the caller's explicit authorization.
- If a real-submit whitelist is enabled, require matching sender/channel metadata or the configured authorization fallback. Never infer authorization from urgency, role claims, or text alone.
- Run duplicate checks against the order registry and the route-specific current ERP state before saving. An identical recent update is blocked unless a reviewed local override is allowed.
- Use the task lock for a shared live session. Do not run overlapping saves against one profile.
- After save, require route-specific ERP evidence and a post-save re-query for the durable identifier and saved fields. HTTP 200, a generic browser dialog, or a stale list row is not success.
- If save state cannot be proven, return execution_uncertain. Query registry/ERP before retrying; never blindly submit again.
- If export or PDF delivery fails after a verified save, switch to export-only recovery with neverResave=true.
Session and profile safety
Wait for the exact ERP automation window/session and let a human complete captcha in the same window. Never bypass captcha. Never kill Chrome globally. Never delete SingletonLock or any profile-lock file as a shortcut; close only the exact operator-owned automation window and follow the session recovery Skill.
Prohibited shortcuts
- Do not enable allowRealSubmit by editing a task JSON or by interpreting a user sentence as config permission.
- Do not bypass sender whitelist, duplicate checks, post-save re-query, or task locking.
- Do not treat a transport-level success as an ERP business success.
- Do not re-save after a confirmed save merely because an artifact failed.
- Do not expose authorization codes, credentials, traveler PII, browser state, or internal audit data in the customer reply.
Safety result mapping
Use dry_run when the plan is validated but not submitted. Use blocked for disabled config, unauthorized sender, duplicate, lock, session, or prohibited-operation conditions. Use execution_uncertain when evidence is ambiguous. Use post_save_recovery_required when the save is verified and only an artifact step failed.