LWLT-AIBOT/.project-docs/30-worklog/tasks/20260915-latest-roster-target-01a0858b.md

Latest pending roster task attachment association

Scope and gate

• Feature task on main, sole worktree /Users/andy/IdeaProjects/LWLT-AIBOT, base ede1d47c4710b4d8d6976bdb37baaf5c316ccd07. Main thread only.
• Existing untracked .idea/ and dist/ltjt-order-assistant-0.5.184.zip are unrelated and preserved. No overlapping tracked changes or other worktrees. Overlap: Clear.
• User authorizes selecting the newest waiting roster task when an attachment arrives without a task ID; historical waiting tasks are expected during debugging. Users continue sending business text and a workbook.
• Own attachment target selection in control-plane/src/task-service.ts, focused tests, AgentBus reply contract and this task record. Canonical project memory is read-only.
• No real attachment downloads, database access, task submission, ERP writes, deployment, restart, external messages or historical task cleanup.

Evidence and plan

• Supplied production logs show attachment download and size/hash validation succeeding, followed by task_selection_required. The existing selection query orders pending tasks by last update and rejects more than one candidate.
• Select the newest created eligible roster task, with a deterministic ID tie-break, within existing organization, owner, channel and conversation boundaries. Explicit task selection retains precedence.
• Preserve transactional state/access rechecks and idempotency protections. Do not fall back to an older task after a selected task changes state during validation.
• Test target selection, explicit selection, missing candidates, transaction state changes and duplicate delivery; run required repository, type, control-plane, legacy and build checks.

Results

• Attachment-only intake now selects one unarchived awaiting_attachment roster task by created_at DESC, id DESC, using the existing organization, owner, channel and conversation filters. Both independent and shared-child roster routes are eligible. The multiple-pending-task rejection is removed only from this attachment path.
• Explicit task IDs retain precedence, including selection of an older task. Text and attachment in the same message still use that message's created task. Historical waiting tasks are not mutated or archived by target selection.
• Existing target-row locking, state/access checks and message idempotency remain intact. A selected task that changes state during validation fails without selecting another task. Replaying a message already linked to another task still rejects the conflicting association without writing an attachment or updating that task.
• Added four regression tests for SQL selection/scope contracts, explicit selection and mismatches, missing targets, and the real attachment transaction with mocked storage/normalization. Transaction checks cover successful routing, state races and cross-task replay rejection; no live database or ERP was used.
• Focused intake/target tests 10/10; full control-plane 245/245 and legacy 402/402 (647 total); type check and build PASS. Repository checks 10/10 in a 2702-file byte-verified isolated copy excluding secrets and pre-existing unrelated residue. Legacy HTTP tests used approved local loopback access. Existing .idea/, ignored residue and release ZIP are preserved.
• Main-thread final read-only review PASS. No plugin changes, migration, task replay, ERP write, deployment, restart, commit or push. Service deployment/restart is required before this server-side selection rule takes effect.
• Verification evidence.

Promotion candidates

• After integration, document attachment-only selection by newest task creation time in canonical roster intake guidance. User has approved this product rule; no user-visible task ID is required for normal use.