[High] Fix agent action logging to attribute rebalances per user/position`

[robertocarlous]

---

Labels: priority/high, area/agent, feature, bug

Body:

## Summary
Agent decisions (rebalance, scan, alert) are persisted to `agent_logs`, but the current implementation attaches actions to an arbitrary user. This makes analytics, support, and auditing unreliable.

## Problem
In `src/agent/router.ts`:

```ts
// Log to all users for now - in production, could be per-user
const users = await db.user.findMany({
  select: { id: true },
  take: 1, // For now, just log to first user
});
const userId = users[0].id;
await db.agentLog.create({ data: { userId, action, status, ... } });

## Acceptance criteria

 No agent log row is written against a random/first user
 Rebalance logs include correct userId and affected positionId(s)
 System-level scans are distinguishable from user-level actions
 Unit tests for logAgentAction with multiple users
 Integration test: rebalance job creates logs for each impacted user
 Update AgentLog indexes if querying by userId + createdAt becomes hot path

[shadrach68]

I would like to work on this issue because I am a full-stack developer with 5+ years experience. I focus on identifying root causes and delivering clean, efficient, and maintainable solutions, with thorough testing to ensure reliable results.

[bakarezainab]

Hi Maintainer, I am a web3 fullstack developer. I’ve reviewed this issue and I understand the requirements. I’d like to implement this and submit a clean PR. Kindly assign this issue to me
I have 5+ years of full-stack development experience with deep expertise in TypeScript, Node.js, and database modeling using Prisma/PostgreSQL, including building robust logging systems and background job processors in production environments. My approach begins by analyzing the agent decision flow to understand which actions are truly user-scoped (rebalances, alerts) versus system-level (scans), then refactoring the logging pattern to accept explicit userId and optional positionId parameters rather than querying for a random user. For rebalance actions, I will modify the job handler to iterate through impacted users and positions, calling logAgentAction for each with the correct context, ensuring the agent_logs table accurately captures the relationship between decisions, users, and positions through proper foreign keys
I will update the schema to support nullable userId for system-level scans (distinguishable by a scope enum field), and add composite indexes on (userId, createdAt) to optimize analytics and support queries as the hot path.
My testing strategy includes unit tests for logAgentAction verifying correct attribution across multiple users, an integration test confirming rebalance jobs create separate logs per impacted user-position pair, and edge cases where user or position references are missing.
I will also audit existing logs to prevent backfill data corruption, and ensure backward compatibility by handling null values gracefully without breaking existing queries or dashboard logic. I am prepared to deliver this high-priority fix within 1 day with thorough documentation and PR review readiness

[Senorespecial]

I would like to work on this issue, pls assign

[TheDEV111]

I’m applying to this issue with the following approach: by fixing agent activity logging so decisions are correctly associated with the users and positions they affect instead of being attached to an arbitrary account. I’ll update the agent logging flow to support accurate user-level and system-level actions, improve audit reliability, and add the required unit and integration tests. I’ll also review database indexing needs to keep agent log queries efficient as usage grows.

[oche2920]

Hi, I am interested in taking ownership of this issue. I have hands-on experience deploying and managing containerized applications using Docker and Kubernetes, including ingress configuration, autoscaling, service discovery, secrets management, and production-grade infrastructure. I will migrate the existing Docker Compose setup into robust Kubernetes manifests, configure resource optimization and HPA policies, implement secure ingress with SSL termination, and ensure reliable inter-service communication. I will validate rolling updates, load-testing scenarios, and failover behavior to achieve a resilient and scalable deployment architecture. In addition, I will document the deployment process and ensure all tests, CI checks, and acceptance criteria are satisfied before submitting a PR. I look forward to contributing a maintainable and production-ready Kubernetes solution to the project.