Files
hub/docs/decisions/ADR-002-jsonb-nullability-rationale.md
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

808 B

ADR-002: JSONB nullability rationale

  • Status: Accepted
  • Date: 2026-04-19
  • Deciders: alkdev

Context

Some JSONB columns are NOT NULL (messages.data, parts.data, operations.inputSchema) while others are nullable (sessions.data, spokes.hostInfo, operations.outputSchema). Need a consistent rationale for when JSONB should be nullable.

Decision

JSONB columns are NOT NULL when data is required for the record to be meaningful — a message without role-specific metadata or a part without type-specific content is incomplete. Nullable JSONB columns are for optional, evolving, or context-dependent data.

Consequences

Minimal — this is a convention that matches the semantic meaning of each column. Positive: consistent mental model for schema design. Negative: none significant.