{ "interval": { "intervalStart": "2025-10-29T00:00:00.000Z", "intervalEnd": "2025-10-30T00:00:00.000Z", "intervalType": "day" }, "repository": "elizaos/eliza", "overview": "From 2025-10-29 to 2025-10-30, elizaos/eliza had 3 new PRs (4 merged), 0 new issues, and 6 active contributors.", "topIssues": [ { "id": "I_kwDOMT5cIs7TJ1DS", "title": "Add Discord button to top header Nav and Farcaster to Bottom Footer Nav", "author": "linear", "number": 6089, "repository": "elizaos/eliza", "body": "as req by kenk — pending mintlify customer service response", "createdAt": "2025-10-22T22:36:15Z", "closedAt": "2025-10-29T01:04:23Z", "state": "CLOSED", "commentCount": 0 } ], "topPRs": [ { "id": "PR_kwDOMT5cIs6wAm-b", "title": "feat: Add PostgreSQL Row-Level Security (RLS) multi-tenant isolation", "author": "standujar", "number": 6101, "body": "# Relates to\r\n\r\nThis PR implements database-level tenant isolation for ElizaOS using PostgreSQL Row-Level Security (RLS), enabling multiple independent ElizaOS servers to safely share a single PostgreSQL database.\r\n\r\n# Risks\r\n\r\n**Medium Risk**\r\n\r\n**What could be affected:**\r\n- Database schema migrations (new `owners` table and `owner_id` column)\r\n- PostgreSQL connection handling (new `application_name` parameter)\r\n- Server initialization flow (RLS setup during startup)\r\n- Multi-tenant deployments using PostgreSQL\r\n\r\n**Mitigation:**\r\n- RLS is **opt-in** via `ENABLE_RLS_ISOLATION=true` environment variable\r\n- Backward compatible when RLS is disabled\r\n- Automatic cleanup with `uninstallRLS()` when RLS is disabled\r\n- Comprehensive test coverage (39 unit tests)\r\n- Tested with multiple servers sharing the same database\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\nThis PR adds PostgreSQL Row-Level Security (RLS) to enable secure multi-tenant isolation in ElizaOS. Key features:\r\n\r\n1. **Database-level isolation**: Uses PostgreSQL RLS policies to enforce tenant boundaries at the database layer\r\n2. **Dynamic server ID assignment**: Each server uses its `owner_id` (derived from auth token) as its `serverId` when RLS is enabled\r\n3. **Automatic RLS management**: Installs/uninstalls RLS functions and policies based on configuration\r\n4. **Complete tenant isolation**: All tables with `owner_id` column are protected by RLS policies\r\n5. **Backward compatible**: Existing deployments continue to work without changes\r\n\r\n## What kind of change is this?\r\n\r\n**Features** (non-breaking change which adds functionality)\r\n\r\n## Why are we doing this?\r\n\r\n### Problem\r\nCurrently, running multiple ElizaOS servers requires either:\r\n- Multiple separate PostgreSQL databases (expensive, complex to manage)\r\n- Sharing a database without isolation (security risk, data leakage possible)\r\n\r\n### Solution\r\nRow-Level Security provides:\r\n- **Cost efficiency**: One PostgreSQL database for multiple tenants\r\n- **Security**: Database-enforced isolation (not application-level)\r\n- **Simplicity**: No complex application logic for tenant filtering\r\n- **Performance**: RLS policies are optimized by PostgreSQL query planner\r\n\r\n### Use Cases\r\n- Development/testing with multiple server instances\r\n- Multi-tenant SaaS deployments\r\n- Cost-optimized production deployments\r\n- Shared staging environments\r\n\r\n# Documentation changes needed?\r\n\r\n**My changes require a change to the project documentation.**\r\n\r\nDocumentation should be added covering:\r\n- How to enable RLS isolation (`ENABLE_RLS_ISOLATION=true`)\r\n- Requirements (PostgreSQL database, not SQLite/PGLite)\r\n- How `owner_id` is derived from `ELIZA_SERVER_AUTH_TOKEN`\r\n- Multi-tenant deployment architecture\r\n- Migration guide for existing deployments\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\n1. Review the RLS implementation in [packages/plugin-sql/src/rls.ts](packages/plugin-sql/src/rls.ts)\r\n2. Check the schema changes in [packages/plugin-sql/src/schema/owners.ts](packages/plugin-sql/src/schema/owners.ts) and [packages/plugin-sql/src/schema/agent.ts](packages/plugin-sql/src/schema/agent.ts)\r\n3. Review server initialization changes in [packages/server/src/index.ts](packages/server/src/index.ts) (lines 376-427 for RLS setup)\r\n4. Examine the test suites for RLS logic validation\r\n\r\n## Detailed testing steps\r\n\r\n### Automated Tests\r\n\r\n```bash\r\n# Run RLS unit tests (18 tests)\r\nbun test packages/plugin-sql/src/__tests__/unit/rls.test.ts\r\n\r\n# Run RLS server tests (21 tests)\r\nbun test packages/server/src/__tests__/rls-server.test.ts\r\n```\r\n\r\n**All 39 tests passing** ✅\r\n\r\n### Manual Testing - Multi-Tenant Isolation\r\n\r\n**Setup: Two servers sharing one PostgreSQL database**\r\n\r\n1. **Server 1** (port 3000):\r\n```env\r\nENABLE_RLS_ISOLATION=true\r\nELIZA_SERVER_AUTH_TOKEN=server1-auth-token-abc123\r\nELIZA_SERVER_PORT=3000\r\n```\r\n\r\n2. **Server 2** (port 3001):\r\n```env\r\nENABLE_RLS_ISOLATION=true\r\nELIZA_SERVER_AUTH_TOKEN=server2-auth-token-xyz789\r\nELIZA_SERVER_PORT=3001\r\n```\r\n\r\n**Verification Steps:**\r\n\r\n1. Start both servers (they share the same PostgreSQL database)\r\n2. Create agents on each server:\r\n - POST to `http://localhost:3000/agents` → creates agent in tenant 1\r\n - POST to `http://localhost:3001/agents` → creates agent in tenant 2\r\n3. List agents on each server:\r\n - GET `http://localhost:3000/agents` → only shows tenant 1 agents\r\n - GET `http://localhost:3001/agents` → only shows tenant 2 agents\r\n4. Cross-tenant access attempt:\r\n - GET `http://localhost:3000/agents/{tenant2-agent-id}` → 404 Not Found ✅\r\n5. Test all messaging APIs:\r\n - Servers, channels, sessions, messages are all isolated\r\n6. Test memories:\r\n - Each agent only accesses its own tenant's memories\r\n\r\n**Results from previous testing session:**\r\n- Complete isolation verified across all API endpoints\r\n- No cross-tenant data leakage\r\n- Messages, channels, servers, and memories properly isolated\r\n- RLS policies correctly enforced at database level\r\n\r\n### Testing with RLS Disabled (Backward Compatibility)\r\n\r\n1. Set `ENABLE_RLS_ISOLATION=false` or omit the variable\r\n2. Start server\r\n3. Verify:\r\n - Server uses default UUID `00000000-0000-0000-0000-000000000000`\r\n - No RLS policies applied\r\n - Existing functionality unchanged\r\n\r\n### Server ID Assignment Logic\r\n\r\n```typescript\r\n// When RLS enabled: serverId = owner_id\r\nconst rlsEnabled = process.env.ENABLE_RLS_ISOLATION === 'true';\r\nthis.serverId = rlsEnabled && this.rlsOwnerId\r\n ? (this.rlsOwnerId as UUID)\r\n : '00000000-0000-0000-0000-000000000000';\r\n```\r\n\r\n### Tests\r\n- `packages/plugin-sql/src/__tests__/unit/rls.test.ts` (NEW) - 18 unit tests\r\n- `packages/server/src/__tests__/rls-server.test.ts` (NEW) - 21 integration tests\r\n\r\n### Schema Updates\r\n- Multiple schema files updated to include `owner_id` foreign key\r\n\r\n# Deploy Notes\r\n\r\n## Database Changes\r\n\r\n**Migration required for existing PostgreSQL deployments:**\r\n\r\n1. New `owners` table will be created automatically\r\n2. `owner_id` column will be added to existing tables\r\n3. Existing rows will have `NULL` owner_id (works fine when RLS disabled)\r\n4. When RLS is first enabled, owner record is auto-created from auth token\r\n\r\n**No migration needed for:**\r\n- SQLite databases (RLS only works with PostgreSQL)\r\n- PGLite databases (RLS not supported)\r\n- Deployments that don't enable RLS\r\n\r\n## Deployment Instructions\r\n\r\n### Option 1: Enable RLS for new deployment\r\n```env\r\nENABLE_RLS_ISOLATION=true\r\nELIZA_SERVER_AUTH_TOKEN=your-unique-token-here\r\n```\r\n\r\n### Option 2: Keep existing behavior (default)\r\n```env\r\n# RLS disabled by default\r\n# ENABLE_RLS_ISOLATION=false\r\n```\r\n\r\n### Multi-tenant deployment\r\n1. Use same PostgreSQL database URL for all servers\r\n2. Set unique `ELIZA_SERVER_AUTH_TOKEN` for each server\r\n3. Enable `ENABLE_RLS_ISOLATION=true` on all servers\r\n4. Each server will automatically get isolated tenant\r\n\r\n## Environment Variables\r\n\r\n| Variable | Required | Default | Description |\r\n|----------|----------|---------|-------------|\r\n| `ENABLE_RLS_ISOLATION` | No | `false` | Enable RLS multi-tenant isolation |\r\n| `ELIZA_SERVER_AUTH_TOKEN` | Yes (when RLS enabled) | - | Unique token for this server/tenant |\r\n| PostgreSQL URL | Yes (when RLS enabled) | - | RLS requires PostgreSQL |\r\n\r\n## Performance Considerations\r\n\r\n- RLS policies use indexes on `owner_id` columns\r\n- PostgreSQL query planner optimizes RLS policy checks\r\n- Minimal overhead compared to application-level filtering\r\n- Recommended: Monitor query performance in production\r\n\r\n## Security Notes\r\n\r\n- **FORCE ROW LEVEL SECURITY** ensures even table owners respect policies\r\n- Owner ID derived from auth token using deterministic UUID generation\r\n- `application_name` connection parameter used for session context\r\n- All queries automatically filtered by PostgreSQL\r\n- **⚠️ IMPORTANT**: RLS policies do NOT apply to PostgreSQL superuser accounts. For production deployments, use a regular database user (non-superuser) to ensure RLS policies are enforced. Superusers bypass RLS by design.\r\n\r\n---\r\n\r\n- Full backward compatibility maintained\r\n", "repository": "elizaos/eliza", "createdAt": "2025-10-27T22:55:30Z", "mergedAt": "2025-10-29T07:57:28Z", "additions": 1381, "deletions": 136 }, { "id": "PR_kwDOMT5cIs6wRHTw", "title": "feat(server): add public health check endpoints", "author": "standujar", "number": 6103, "body": "## Relates to\r\n\r\nFixes the issue where health check endpoints require authentication when `ELIZA_SERVER_AUTH_TOKEN` is configured, breaking load balancer health checks in production deployments.\r\n\r\n## Risks\r\n\r\n**Low risk**\r\n\r\n- Only adds new public endpoints at the root level (`/healthz` and `/health`)\r\n- Does not modify existing authentication middleware behavior\r\n- All `/api/*` routes remain protected as before\r\n- No breaking changes to existing functionality\r\n\r\n**What could be affected:**\r\n- Load balancers and monitoring systems can now perform health checks without API keys\r\n- Production deployments can properly configure ALB/K8s health probes\r\n\r\n## Background\r\n\r\n### What does this PR do?\r\n\r\nAdds two public health check endpoints that work **without authentication**, even when `ELIZA_SERVER_AUTH_TOKEN` is configured:\r\n\r\n- **`GET /healthz`**: Lightweight health check that always returns `200 OK`\r\n ```json\r\n { \"status\": \"ok\", \"timestamp\": 1730158466789 }\r\n ```\r\n\r\n- **`GET /health`**: Comprehensive health check with agent status\r\n - Returns **200** if agents are running\r\n - Returns **503** (Service Unavailable) if no agents are active\r\n ```json\r\n { \"status\": \"healthy\", \"agentCount\": 3, \"timestamp\": 1730158466789 }\r\n ```\r\n\r\nThese endpoints are placed **before** the authentication middleware in the request pipeline, making them accessible without the `X-API-KEY` header.\r\n\r\n### What kind of change is this?\r\n\r\n**Features** (non-breaking change which adds functionality)\r\n\r\n### Why are we doing this? Any context or related work?\r\n\r\nCurrently, when `ELIZA_SERVER_AUTH_TOKEN` is set, the authentication middleware is applied globally to **all** `/api/*` routes (line 697-699 in `index.ts`). This includes health check endpoints like `/api/server/health`, which require the `X-API-KEY` header.\r\n\r\n**Problem:** Standard load balancers (AWS ALB, Kubernetes liveness/readiness probes, Docker health checks) typically don't support custom authentication headers. This makes it impossible to properly configure health checks in production environments.\r\n\r\n**Solution:** Following industry best practices, this PR adds dedicated health endpoints at the root level that are intentionally excluded from authentication requirements.\r\n\r\n**Use cases:**\r\n- AWS ECS/Fargate with Application Load Balancer health checks\r\n- Kubernetes liveness and readiness probes\r\n- Docker Compose health checks\r\n- Monitoring systems (Prometheus, Datadog, etc.)\r\n\r\n## Testing\r\n\r\n### Where should a reviewer start?\r\n\r\n1. Review changes in [`packages/server/src/index.ts`](packages/server/src/index.ts#L610-L628)\r\n2. Verify endpoints are added **before** the authentication middleware (line 692)\r\n3. Note the log message confirming public health endpoints are enabled\r\n4. Run the test scenarios below\r\n\r\n### Detailed testing steps\r\n\r\n#### ✅ Test 1: Health endpoints work WITHOUT authentication\r\n\r\n1. Set `ELIZA_SERVER_AUTH_TOKEN` in your `.env`:\r\n ```bash\r\n ELIZA_SERVER_AUTH_TOKEN=test-secret-key-123\r\n ```\r\n\r\n2. Start the Eliza server:\r\n ```bash\r\n bun run dev\r\n ```\r\n\r\n3. Test public endpoints (no `X-API-KEY` needed):\r\n ```bash\r\n # Test /healthz\r\n curl http://localhost:3000/healthz\r\n # Expected: {\"status\":\"ok\",\"timestamp\":1730158466789}\r\n\r\n # Test /health\r\n curl http://localhost:3000/health\r\n # Expected: {\"status\":\"healthy\",\"agentCount\":N,\"timestamp\":1730158466789}\r\n ```\r\n\r\n4. Verify authenticated endpoints still require API key:\r\n ```bash\r\n # Without API key - should fail\r\n curl http://localhost:3000/api/agents\r\n # Expected: 401 Unauthorized: Invalid or missing X-API-KEY\r\n\r\n # With API key - should succeed\r\n curl -H \"X-API-KEY: test-secret-key-123\" http://localhost:3000/api/agents\r\n # Expected: [...agent list...]\r\n ```\r\n\r\n### Security Considerations\r\n\r\n✅ **Safe**: These endpoints only expose:\r\n- Server availability (`/healthz`)\r\n- Agent count and basic status (`/health`)\r\n\r\n❌ **No sensitive data exposed**:\r\n- No agent names, IDs, or configurations\r\n- No API keys or secrets\r\n- No internal system details\r\n- No user data or conversations\r\n\r\n### Endpoint Comparison\r\n\r\n| Endpoint | Auth Required | Status Codes | Response Time | Use Case |\r\n|----------|---------------|--------------|---------------|----------|\r\n| `/healthz` | ❌ No | 200 | <5ms | ALB health checks, simple monitoring |\r\n| `/health` | ❌ No | 200, 503 | <10ms | Kubernetes readiness, detailed monitoring |\r\n| `/api/server/health` | ✅ Yes | 200, 503 | <20ms | Authenticated admin checks |\r\n| `/api/server/ping` | ✅ Yes | 200 | <5ms | Authenticated simple ping |\r\n\r\n### Backwards Compatibility\r\n\r\n✅ **Fully backwards compatible**\r\n- Existing endpoints unchanged\r\n- Existing authentication behavior unchanged\r\n- No breaking changes to API contracts\r\n- No configuration changes required", "repository": "elizaos/eliza", "createdAt": "2025-10-29T01:03:32Z", "mergedAt": "2025-10-29T08:15:59Z", "additions": 253, "deletions": 0 }, { "id": "PR_kwDOMT5cIs6wXBEu", "title": "fix: use actual server ID for DM channel creation to resolve 403 error", "author": "standujar", "number": 6105, "body": "# Relates to\r\n\r\nFixes 403 Forbidden error when creating DM channels in the GUI client.\r\n\r\n# Risks\r\n\r\n**Low**.\r\n\r\n- Affects only DM channel creation flow in the client\r\n- Changes query key structure for DM channels (existing channels remain unaffected)\r\n- Server-side validation now receives correct server IDs no only default hardcoded\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\nFixes a 403 Forbidden error that occurred when users tried to create DM channels with agents. The client was sending a hardcoded default server ID (`00000000-0000-0000-0000-000000000000`) instead of the actual server ID, causing the server's Row-Level Security (RLS) check to reject the request.\r\n\r\nAdditionally fixes the \"Loading chat context...\" infinite loading state by including the server ID in React Query cache keys, ensuring proper query invalidation after channel creation.\r\n\r\n## What kind of change is this?\r\n\r\nBug fixes (non-breaking change which fixes an issue)\r\n\r\n# Documentation changes needed?\r\n\r\nMy changes do not require a change to the project documentation.\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\nTest DM channel creation with an active agent in the GUI client.\r\n\r\n## Detailed testing steps\r\n\r\n1. Start the Eliza server with at least one active agent\r\n2. Open the GUI client at `http://localhost:3000`\r\n3. Navigate to chat with an agent (e.g., `/chat/{agentId}`)\r\n4. Verify that:\r\n - No 403 error appears in the browser console\r\n - DM channel is created successfully\r\n - Chat interface loads without \"Loading chat context...\" stuck state\r\n - Messages can be sent and received\r\n5. Create a second DM channel with the same agent (click the \"+\" button)\r\n6. Verify both channels appear in the sidebar and can be switched between\r\n\r\n## Expected behavior\r\n\r\n- DM channels create successfully with HTTP 201 response\r\n- Channel list updates immediately after creation\r\n- No 403 Forbidden errors in console\r\n- Chat interface loads and is interactive\r\n\r\n## Changes summary\r\n\r\n**Files modified:**\r\n- `packages/client/src/routes/chat.tsx` - Fetch server ID and pass to Chat component\r\n- `packages/client/src/hooks/use-dm-channels.ts` - Add serverId parameter and include in query keys\r\n- `packages/client/src/components/chat.tsx` - Use actual server ID instead of default UUID\r\n\r\n**Key changes:**\r\n- Added `useServers()` hook to fetch real server ID in chat route\r\n- Pass server ID to `useCreateDmChannel` mutation\r\n- Include server ID in React Query cache keys for proper invalidation\r\n- Use actual server ID for all DM channel operations instead of hardcoded default\r\n", "repository": "elizaos/eliza", "createdAt": "2025-10-29T12:35:13Z", "mergedAt": "2025-10-29T13:20:14Z", "additions": 153, "deletions": 15 }, { "id": "PR_kwDOMT5cIs6wTnHJ", "title": "allow custom options", "author": "tcm390", "number": 6104, "body": "\n> [!NOTE]\n> Allow arbitrary custom options on `Action` via an index signature (`[key: string]: unknown`).\n> \n> Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit c3b83f9975a7fffb1292454e747a974960a3dc86. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).\n", "repository": "elizaos/eliza", "createdAt": "2025-10-29T07:42:14Z", "mergedAt": "2025-10-29T07:42:31Z", "additions": 3, "deletions": 0 } ], "codeChanges": { "additions": 1790, "deletions": 151, "files": 28, "commitCount": 15 }, "completedItems": [ { "title": "feat: Add PostgreSQL Row-Level Security (RLS) multi-tenant isolation", "prNumber": 6101, "type": "feature", "body": "# Relates to\r\n\r\nThis PR implements database-level tenant isolation for ElizaOS using PostgreSQL Row-Level Security (RLS), enabling multiple independent ElizaOS servers to safely share a single PostgreSQL database.\r\n\r\n# Risks\r\n\r\n**Medium Ris", "files": [ "packages/plugin-sql/src/__tests__/unit/rls.test.ts", "packages/plugin-sql/src/index.node.ts", "packages/plugin-sql/src/index.ts", "packages/plugin-sql/src/pg/manager.ts", "packages/plugin-sql/src/rls.ts", "packages/plugin-sql/src/schema/agent.ts", "packages/plugin-sql/src/schema/index.ts", "packages/plugin-sql/src/schema/owners.ts", "packages/plugin-sql/tsconfig.build.node.json", "packages/plugin-sql/types/index.d.ts", "packages/server/src/__tests__/rls-server.test.ts", "packages/server/src/api/messaging/channels.ts", "packages/server/src/api/messaging/core.ts", "packages/server/src/api/messaging/servers.ts", "packages/server/src/api/messaging/sessions.ts", "packages/server/src/index.ts", "packages/server/src/services/message.ts", "packages/server/src/socketio/index.ts", "examples/jobs-api-client-example.ts", "packages/cli/src/commands/containers/actions/delete.ts", "packages/cli/src/commands/containers/actions/list.ts", "packages/cli/src/commands/containers/actions/logs.ts" ] }, { "title": "fix: use actual server ID for DM channel creation to resolve 403 error", "prNumber": 6105, "type": "bugfix", "body": "# Relates to\r\n\r\nFixes 403 Forbidden error when creating DM channels in the GUI client.\r\n\r\n# Risks\r\n\r\n**Low**.\r\n\r\n- Affects only DM channel creation flow in the client\r\n- Changes query key structure for DM channels (existing channels remain ", "files": [ "packages/client/src/components/chat.tsx", "packages/client/src/hooks/__tests__/use-dm-channels.test.ts", "packages/client/src/hooks/use-dm-channels.ts", "packages/client/src/routes/chat.tsx" ] }, { "title": "allow custom options", "prNumber": 6104, "type": "other", "body": "\n> [!NOTE]\n> Allow arbitrary custom options on `Action` via an index signature (`[key: string]: unknown`).\n> \n> Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit c3b83f9975a7fffb12924", "files": [ "packages/core/src/types/components.ts" ] }, { "title": "feat(server): add public health check endpoints", "prNumber": 6103, "type": "feature", "body": "## Relates to\r\n\r\nFixes the issue where health check endpoints require authentication when `ELIZA_SERVER_AUTH_TOKEN` is configured, breaking load balancer health checks in production deployments.\r\n\r\n## Risks\r\n\r\n**Low risk**\r\n\r\n- Only adds ne", "files": [ "packages/server/src/__tests__/health-endpoints.test.ts", "packages/server/src/index.ts" ] } ], "topContributors": [ { "username": "standujar", "avatarUrl": "https://avatars.githubusercontent.com/u/16385918?u=718bdcd1585be8447bdfffb8c11ce249baa7532d&v=4", "totalScore": 83.54613169686468, "prScore": 83.54613169686468, "issueScore": 0, "reviewScore": 0, "commentScore": 0, "summary": "standujar: Focused on both feature development and bug fixes, delivering a new public health check endpoint in elizaos/eliza via PR #6103 and resolving a DM channel creation issue in elizaos/eliza via PR #6105, demonstrating a balanced contribution to server functionality and stability." }, { "username": "0xbbjoker", "avatarUrl": "https://avatars.githubusercontent.com/u/54844437?u=90fe1762420de6ad493a1c1582f1f70c0d87d8e2&v=4", "totalScore": 25.257585092994045, "prScore": 25.257585092994045, "issueScore": 0, "reviewScore": 0, "commentScore": 0, "summary": "0xbbjoker: Primarily focused on bugfix work, resolving a TypeScript type error in a tokenization utility within elizaos-plugins/plugin-openai via PR #20, while also modifying 72 files with a significant volume of code changes (+3117/-1240 lines) across bugfix, feature, and refactor work." }, { "username": "yungalgo", "avatarUrl": "https://avatars.githubusercontent.com/u/113615973?u=92e0f29f7e2fbb8ce46ed13c51f692ca803de02d&v=4", "totalScore": 23.540096538021483, "prScore": 23.540096538021483, "issueScore": 0, "reviewScore": 0, "commentScore": 0, "summary": "yungalgo: Contributed to documentation by merging PR elizaos/docs#78, which added a Discord/community CTA, indicating a focus on community engagement and configuration updates." }, { "username": "tcm390", "avatarUrl": "https://avatars.githubusercontent.com/u/60634884?u=c6c41679b8322eaa0c81f72e0b4ed95e80f0ac16&v=4", "totalScore": 21.884147180559943, "prScore": 21.884147180559943, "issueScore": 0, "reviewScore": 0, "commentScore": 0, "summary": "tcm390: Contributed to the `elizaos/eliza` repository by merging a pull request (#6104) that introduced custom options, indicating a focus on enhancing feature flexibility. This work involved modifying 3 files with a net change of +6 lines, primarily in code." }, { "username": "ChristopherTrimboli", "avatarUrl": "https://avatars.githubusercontent.com/u/27584221?u=0d816ce1dcdea8f925aba18bb710153d4a87a719&v=4", "totalScore": 5, "prScore": 0, "issueScore": 0, "reviewScore": 5, "commentScore": 0, "summary": "ChristopherTrimboli: No activity today." }, { "username": "wtfsayo", "avatarUrl": "https://avatars.githubusercontent.com/u/82053242?u=98209a1f10456f42d4d2fa71db4d5bf4a672cbc3&v=4", "totalScore": 0.2, "prScore": 0, "issueScore": 0, "reviewScore": 0, "commentScore": 0.2, "summary": "wtfsayo: Demonstrated a broad impact today, modifying 108 files across 13 commits (+2949/-713 lines) with a primary focus on feature work, bug fixes, and refactoring, and also provided one PR comment." } ], "newPRs": 3, "mergedPRs": 4, "newIssues": 0, "closedIssues": 1, "activeContributors": 6 }