hub/tasks/architecture/storage/resolve-sessions-rolename-validation.md at 85ff26ae51e1045207da9ef7ae4fc8f963e2a913

alkdev/hub

Files

glm-5.1 2b63cda1c7 Setup repo: migrate architecture specs, code stubs, and tasks from alkhub_ts

Copy architecture docs, ADRs, storage domain specs, research, reviews,
and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for
standalone @alkdev/hub repo structure (src/ not packages/hub/).

Sanitize all sensitive information:
- Replace private IPs (10.0.0.1) with localhost defaults
- Remove internal server hostnames (dev1, ns528096)
- Replace /workspace/ private paths with npm package references
- Remove hardcoded credentials from examples
- Rewrite infrastructure.md without private network details

Add Deno project scaffolding: deno.json (pinned deps), .gitignore,
AGENTS.md, entry point. Migrate existing code stubs (crypto, config
types, logger) with updated import paths.

2026-05-25 10:56:32 +00:00

1.7 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

resolve-sessions-rolename-validation

Resolve sessions.roleName validation strategy (FK or intentional omission)

completed

narrow

medium

component

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

1.7 KiB Raw Blame History