🎨 Pattern: How to count per-user task executions when ExecutionTrace sc...

Date: 2026-03-27
Time: 18:55:05 UTC
Session: gspace1-276.14
Agent: backend
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How to count per-user task executions when ExecutionTrace schema has no userId field?

Task: Wire 3/5/7: Per-user task counting across multiple wires

🎯 Decision Made

Chosen:

Use UserDossier.identity.totalInteractions as the per-user task counter. It's maintained by recordExecution() → dossierService.recordEvent() and is the canonical per-user interaction count.

Options Considered:

1. Add userId to ExecutionTrace schema (invasive migration)
2. Use traceModel.countDocuments({userId}) (fails — no field)
3. Use dossier.identity.totalInteractions (chosen — canonical counter)

💭 Reasoning

Root cause: ExecutionTrace schema was designed for task-centric analytics (taskId, taskType, outcome) not user-centric queries. It has no userId field. This pattern appeared in 3 separate wires (Wire 3 milestone detection, Wire 5 thought trace filtering, Wire 7 soul brief regeneration). Each time the plan assumed traceModel.countDocuments({userId}) would work — it doesn't. The dossier's totalInteractions counter is the correct proxy because: (1) it's incremented atomically on every recordExecution call, (2) it's indexed on userId (primary lookup), (3) it's already used for user-facing stats. Future anti-pattern to watch: any code that tries to query ExecutionTrace by userId will fail silently (returns 0 documents). If per-user trace queries become needed, add a userId index to ExecutionTrace schema.

📁 Files Involved

• APIs/backend-vitto-api/src/app/mind/mind.service.ts
• APIs/backend-vitto-api/src/app/users/schemas/user-dossier.schema.ts
• APIs/backend-vitto-api/src/app/proactive/proactive-reach.service.ts

🔗 Related

• Decision ID: dev_1774637705117_bvczcmf
• Session: 276
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation