---
id: resolve-sessions-rolename-validation
name: Resolve sessions.roleName validation strategy (FK or intentional omission)
status: completed
depends_on: []
scope: narrow
risk: medium
impact: component
level: implementation
---

## Description

`sessions.roleName` is bare `text` with no FK to `roles.name` and no documented reason why. Open questions:
- Is this intentional to support file-based roles in Phase 1 (before DB sync)?
- What happens if the role name has a typo?
- What about sessions referencing a role that was deleted?

Choose one:
- **(A)** Add FK → `roles.name` with `onDelete: SET NULL` — role deletions detach sessions
- **(B)** Document why the FK is intentionally omitted: "Role definitions may come from `.opencode/agents/*.md` files before DB sync; application-level validation checks against known role names at session creation time."

## Acceptance Criteria

- [ ] Decision is documented with rationale in `sessions.md` and `roles.md`
- [ ] If option A: `sessions.roleName` FK cascade is added to `table-reference.md`; sessions.md column spec updated; `roles.md` notes that role.name deletions SET NULL on dependent sessions
- [ ] If option B: `sessions.md` documents the intentional omission and the application-level validation strategy; `roles.md` notes that `name` is used as a reference target by sessions
- [ ] The Phase 1→Phase 2 migration path for role validation is noted (file-based → DB FK)

## References

- docs/reviews/storage-architecture-review-2026-04-21.md#C05
- docs/architecture/storage/sessions.md:26
- docs/architecture/storage/table-reference.md:100-101
- docs/architecture/storage/roles.md

## Notes

> To be filled by implementation agent

## Summary

> To be filled on completion