Summary
Follow-up hardening from PR #161.
A few agent tables duplicate ownership information without enforcing it at the database layer:
agents.parent_agent_id can point at an agent owned by a different user.
agent_schedule_runs.user_id / agent_schedule_runs.agent_id can drift from the referenced agent_schedules row.
Why this is worth tracking
- Current application write paths appear consistent, so this did not block the schema-sync PR.
- The denormalized owner fields are convenient for querying, but they become dangerous if they can silently drift.
- Note: subagents intentionally have their own conversations, so this issue is about same-user consistency, not same-conversation enforcement.
Affected migrations
migrations/2026-02-10-214235_maple_agent_mvp_storage
migrations/2026-03-23-180000_agent_schedules_v1
Follow-up direction
- Add DB-level validation that
parent_agent_id stays within the same tenant/user scope.
- Add DB-level validation that
agent_schedule_runs.user_id / agent_id remain consistent with the referenced schedule.
- Preserve the existing Feb/Mar migration lineage by addressing this in a new forward migration rather than editing the historical migration files.
Summary
Follow-up hardening from PR #161.
A few agent tables duplicate ownership information without enforcing it at the database layer:
agents.parent_agent_idcan point at an agent owned by a different user.agent_schedule_runs.user_id/agent_schedule_runs.agent_idcan drift from the referencedagent_schedulesrow.Why this is worth tracking
Affected migrations
migrations/2026-02-10-214235_maple_agent_mvp_storagemigrations/2026-03-23-180000_agent_schedules_v1Follow-up direction
parent_agent_idstays within the same tenant/user scope.agent_schedule_runs.user_id/agent_idremain consistent with the referenced schedule.