mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-12 12:18:55 +02:00
86c3f30524
* fix(server): attribute agent-created issues so downstream A2A mentions keep the originator (MUL-4305) An agent creating an issue via the ordinary `issue create` path left the new issue with no origin link, so resolveOriginatorForIssueTask could not recover the top-of-chain human. Any assignment / squad-leader run derived from that issue lost the originator, and A2A @-mentions those runs emitted failed the canInvokeAgent gate against private agents (after MUL-3963). Fix (mirrors the comment.source_task_id stamp from MUL-4015): - CreateIssue stamps origin_type='agent_create' + origin_id=<acting task>, resolved from the SERVER-trusted X-Task-ID (never a client-reported field). - resolveOriginatorForIssueTask inherits the origin task's originator for agent_create just like quick_create. - Align the squad-leader gate originator with the enqueue path via the new exported OriginatorForIssueTask, so the gate and the persisted task row agree instead of drifting to an empty originator for agent-triggered assigns. - Migration 149 adds 'agent_create' to issue_origin_type_check. - Classify agent_create in analytics to avoid the unknown-origin warning. Tests: agent_create attribution + gate/enqueue consistency (service), and the HTTP boundary stamp + security regression (member / forged X-Agent-ID must not smuggle an agent_create origin). Co-authored-by: multica-agent <github@multica.ai> * test(server): add end-to-end regression for agent-created issue originator chain (MUL-4305) Locks the real product path the layered tests could miss, per PR review: 1. CreateAssignSquad_PrivateWorkerTriggered — human H triggers agent A → A creates an issue via the ordinary create path AND assigns it to a squad whose leader is a private agent owned by H → the leader's assignment run @-mentions a second private agent J (owned by H) → asserts the leader task carries H and J ends up with a queued task attributed to H. This is the exact line-failure shape from the issue. 2. UpdateAssignSquad_HandlerGateAdmitsPrivateLeader — agent A creates an unassigned issue then assigns it to a private-leader squad via UpdateIssue, exercising the handler enqueueSquadLeaderTask gate (which the create path's ungated service enqueue does not hit); asserts the leader task is enqueued carrying H. Both wire handler create stamp → origin resolution → squad-leader gate → comment source-task stamp → private-worker invocation gate. Verified they FAIL against a simulated pre-fix resolver (leader originator empty; private worker / leader get 0 tasks) and PASS with the fix. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>
14 lines
985 B
SQL
14 lines
985 B
SQL
-- Extend issue.origin_type to allow an agent's ordinary `issue create` to stamp
|
|
-- the new issue with origin_type='agent_create' + origin_id=<agent_task_queue.id>
|
|
-- (the acting task that created it). This is the load-bearing link that lets
|
|
-- resolveOriginatorForIssueTask inherit the top-of-chain human originator for
|
|
-- any run derived from the new issue (assignment / squad-leader). Without it an
|
|
-- agent-created issue was left unattributed, so downstream A2A mentions from
|
|
-- those runs failed the canInvokeAgent gate against private agents (MUL-4305).
|
|
-- Mirrors the quick_create link (060) — same origin_id semantics (an
|
|
-- agent_task_queue row), different label because this is the normal create path
|
|
-- rather than the daemon quick-create flow.
|
|
ALTER TABLE issue DROP CONSTRAINT IF EXISTS issue_origin_type_check;
|
|
ALTER TABLE issue ADD CONSTRAINT issue_origin_type_check
|
|
CHECK (origin_type IN ('autopilot', 'quick_create', 'lark_chat', 'slack_chat', 'agent_create'));
|