Add the complete project-scoped Zopu chat, Signal extraction, and work-routing loop: Backend (signalRouting.ts): - Agent-token-gated functions for the full routing cycle: list evidence, create signal, list signals, list active issues, attach signal to issue, create issue from signal, begin issue, get project context, list projects - attachSignalToIssue requires signal.projectId to exist and equal issue.projectId (org equality alone is insufficient) - createIssueFromSignal is idempotent: queries existing attachments before creating, returns created/reused flag - Duplicate attach retries return existing relation without emitting a duplicate event - All functions deny-by-default with agent token validation Schema: - Add signalIssueAttachments table with indexes by signal, issue, and the composite (signalId, issueId) for idempotent lookups Agent tools (tools/signals.ts): - Nine Flue tool definitions bound to the organization-scoped agent instance ID, calling the agent-gated Convex functions - Organization ID never accepted as free input; always from the bound instance Zopu agent (zopu.ts): - Comprehensive routing-loop instructions: assess actionability, identify project, create signal only when actionable, route via attach or create, explain outcome, optionally begin - Wiring of routing tools into the agent definition Tests (signalRouting.test.ts): - Authentication: invalid token rejected on every function - Project scoping: evidence, signals, issues scoped correctly - Idempotency: duplicate attach, duplicate create-from-signal, duplicate signal creation - Attach vs create: both paths verified - Cross-project rejection: signal and issue must be in same project - Org-scoped signal attach rejected (no projectId) - Provenance: exact raw text preserved through routing loop - Begin issue: transition and auth verification
Convex Backend
This directory contains the Convex control plane for the app and daemon runtime. Generated files under _generated/ are maintained by Convex and should not be edited by hand.
Daemon Control Plane
schema.tsdefines daemon definitions, high-churn daemon presence, leased daemon commands, append-only command events, and the sampletodostable.daemons.tsmanages stable daemon definitions withupsert,get, andlist.daemonRuntime.tsrecords daemon session lifecycle:connect,heartbeat,disconnect,recordEvent, and bounded event listing.daemonCommands.tsowns the command queue:enqueue,available,claim,start,succeed,fail,cancel, and bounded command listing.
Commands are claimed by daemon session. Preserve the claimedBySessionId ownership checks, leaseExpiresAt expiry semantics, terminal statuses, and bounded query results when changing this flow.
Usage
Convex functions are exposed by file path through the generated api object, for example api.daemonCommands.enqueue or api.daemonRuntime.connect. Run bun run dev:server from the repository root to start the development deployment, and bun run dev:setup when configuring Convex for the first time.