LWLT-AIBOT/.project-docs/40-domain/business-rules.md

Business Rules

Durable Rules

• agent设计规范/business-adaptation-registry.md is the cross-session business entry; each business maps user input, Skill/action, ERP flow, contracts, implementation, fixtures, and verification status.
• Manual and AgentBus tasks share the same 19-route machine registry, task-scoped parser mode snapshot, and organization automation rules. The external Agent remains restricted to its original 18 routes; the Program-only shared-child batch route is accepted only by the deterministic program path. AgentBus intake evaluates the bound employee account's route grants rather than an administrator or whichever browser is online.
• The platform exposes one fixed deployment scope, not an organization-management product. Accounts use admin, team_lead, and user roles.
• Passwords must be non-empty but have no application-level length restriction. First login and administrator password reset do not force a subsequent password change; users may still change passwords voluntarily, administrators may reset them, and password changes revoke existing sessions according to the account lifecycle contract.
• Administrators are management-plane-only identities. They manage accounts, roles, passwords, sessions, employee route grants, AgentBus channels, parser routing, automation settings, and audit, but hold no business routes and cannot create, inspect, mutate, stream, claim, reconcile, archive, restore, force-delete, or submit results for tasks.
• Team leads and ordinary users start with no task grants, require explicit administrator allowlists, and may use normal task APIs only for manual or AgentBus tasks immutably assigned to themselves. A known ungranted route or a non-unique/unresolved employee route fails before parsing, plugin dispatch, or ERP execution. Authorization is rechecked for supplemental input, attachments, confirmation, automatic confirmation, and browser claim.
• Team leads may read all durably assigned manual and AgentBus work only through the platform-operations dashboard; administrators cannot access it. The dashboard uses immutable assigned_user_id as the employee dimension, excludes historical AgentBus rows without a reliable assignee, and is aggregate-first across task, person, original input, final output, time, task type, and completion state with business-facing drill-through. Its five summary cards are display-only; the explicit task-result filter defaults to all results. Internal attention or waiting-for-input states remain unchanged in task storage but are presented and filtered as “进行中”; the leadership view exposes no separate “待跟进” category. It is not an audit log and never renders technical payloads, internal identifiers, machine-shaped historical input, or technical failure text; this visibility does not grant cross-user task mutation, artifacts, SSE, global settings, audit administration, or AgentBus access.
• Separately, protected runtime configuration may enable one organization-level external Webhook for privacy-bounded summaries of future manual and AgentBus tasks assigned to non-administrator employees. Only stable completed, failed, cancelled, uncertain, and uncertain-then-resolved outcomes qualify. History is not backfilled; payloads are encrypted; the complete URL/token stay outside storage and status responses; messages never include raw instructions, attachments, customer/traveller data, URLs, or technical errors. Only HTTP 200 plus code=0 plus data=true is recorded as accepted, never as delivered. Explicit rejection, timeout, network failure, 5xx, invalid response, and stale sending lease are terminal and never automatically retried because the provider has no idempotency key. This projection grants no task mutation, executable event, confirmation, browser, reconciliation, AgentBus, or ERP authority, and its failure cannot block normal task services.
• Creator and input-turn attribution are durable, business inputs remain encrypted at rest, and denial audit excludes plaintext. Archive/restore is the owning employee's reversible routine removal path. Explicit owner force delete is a separate irreversible operation that may physically remove that employee's task in any lifecycle state, retains only a minimal non-content deletion audit marker, and cannot undo ERP effects already written or retract a task summary already accepted by the external Webhook. Administrators cannot invoke task removal.
• Each non-admin employee may carry one case-insensitively unique expected ERP account and one AgentBus channel. New manual and AgentBus tasks persist an immutable assignee; only that account may confirm, claim, reconcile, resume, or submit ERP execution results. Administrators manage the account and channel configuration but cannot inspect or execute the employee's tasks.
• A browser is execution-ready only when it is the account's sole fresh worker and the active ERP session proves the expected account from exactly one #Lable_UserName login node by Unicode/whitespace/case-normalized full equality. Missing, duplicate, blank, substring-only, or unrelated page-text matches fail closed without exposing the observed account. Concurrent fresh workers, unbound channels, and historical unassigned AgentBus tasks also fail closed; stale failover waits 90 seconds. Claim locking, active-execution detection, confirmed FIFO, and queue position are scoped to immutable assigned_user_id: the same account stays serialized while different accounts execute independently.
• Administrators are rejected from the task data plane at the database, service, route, and UI boundaries. Executable task reads, SSE history/live events, browser claims, plugin-result ingestion, and force-delete browser cleanup commands require a team-lead/user session matching the task assignee.
• The two passenger-list import routes and shared-child batch creation are Program-only. Passenger-list routes wait for exactly one .xls or .xlsx attachment before deterministic normalization.
• Shared-child batch creation requires one inclusive departure-date range, a product, customer, and passenger counts. It enumerates every visible product-matching shared mother plan in the range and validates unique complete parent identity before the first write; zero, duplicate, conflicting, incomplete, or oversized target sets fail closed. Valid targets execute in date/tid order through the single-child adapter, keep per-parent receipts, stop at the first blocked, failed, or uncertain outcome, leave remaining targets not started, and never automatically retry a write. Customer and leader are child-order fields and never filter mother plans.
• Passenger workbooks must contain exactly one complete ERP-semantic header within rows 1–100. The header may be on row 1 or follow metadata, column order is arbitrary, and only the finite approved aliases for the 12 required source semantics are selected. Identity-card, age, source document-type, hidden/local-formula, unheaded, and other ordinary non-import columns are ignored for row detection and selected-value validation and are never copied into the internal 13-column canonical TSV; canonical 证件类型 remains the implicit constant 护照. Missing/duplicate required semantics, multiple candidate headers, unsafe selected formulas/results, non-contiguous selected rows, macros, external relationships, hyperlinks, and external formulas fail closed.
• A WeChat attachment card is transport placeholder text, not file content. Only a structured payload.attachments[] entry can resume a roster task; missing metadata fails before ingestion and leaves the original task in awaiting_attachment instead of creating a new task.
• The trusted internal deployment accepts credential-free HTTPS roster attachment URLs whose host is internal, private/reserved IPv4/IPv6, or localhost. DNS pinning, redirect revalidation, download timeout, byte limits, declared-size checks, and optional SHA-256 verification remain mandatory.
• AgentBus attachment diagnostics may record stage, address count/family, status, byte count, code, outcome, and duration, but never URL, hostname, IP, file name, bytes, message text, or roster values.
• Passenger overwrite requires confirmation when target ERP rows are occupied; after full_replace + confirmed=true, every attachment-specified sequence is written even when values are unchanged.
• A single strict 领队 row supplies leader contact; ambiguous, incomplete, duplicate, or structurally inconsistent leader data fails closed.
• Shared-mother-plan 整团游客信息 export is only shared_plan + visitor-list + tid-only; independent and concrete shared-child visitor lists remain did+tid.
• Scatter-plan creation and independent batch-order creation resolve products from the currently loaded candidates first. If that is not uniquely resolvable, the adapter must dispatch the form's native non-empty S_chanpinming lookup using the complete product name or a name with only a trailing numeric duration shorthand such as 10D, 8天, or 8D7N removed, wait for Ajax settlement, and run the same deterministic local unique matcher. Only one bounded empty-query compatibility reload may follow; zero or multiple matches still stop before product selection or any write.
• Real writes require unique resolution, exact page identity, ownership, write projection, explicit server response, and action-specific completion evidence.
• Current business capability and verification status come from active source/contracts and the lifecycle release gate, never from archive wording.

Open Questions

• Fresh authorized runtime read verification remains for the shared-mother-plan whole-visitor export branch.
• Authorized current-version ERP write verification remains for SGL/TWN and four independent-order headcount categories.
• One live internal attachment verification of the newly integrated roster-header path remains unperformed and requires separate task-mutation/channel authorization.

Last Reviewed

2026-09-09