hub/tasks/architecture/storage/resolve-message-id-adr-contradiction.md at main

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

2.1 KiB

Raw Permalink Blame History

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

name

status

depends_on

scope

risk

impact

level

resolve-message-id-adr-contradiction

Resolve ADR-003 vs sessions.md on message IDs

completed

narrow

high

component

implementation

Description

Three-way inconsistency on message IDs:

ADR-003 states: "Parts and messages tables use sortable timestamp-based IDs instead of commonCols.id"
sessions.md defines messages using commonCols (UUIDv4)
table-reference.md only mentions parts for sortable IDs

The composite index idx_messages_session_id_created_at_id on (session_id, created_at, id) relies on created_at for ordering, making UUIDv4 sortable IDs unnecessary — but this contradicts ADR-003's stated rationale.

Decision (D2)

Option B chosen: Amend ADR-003 to state that only parts uses sortable IDs. messages keeps UUIDv4 and relies on the composite index for ordering.

Rationale:

Composite index provides efficient ordering without requiring sortable IDs on messages
Simpler opencode conversation import — opencode uses UUIDv4 message IDs natively
Parts benefit more from sortable IDs (they're frequently paginated/ordered within a message)
The created_at column in the composite index provides the ordering property that sortable IDs would give

Acceptance Criteria

ADR-003 is amended: scope sortable IDs to parts only, explain that messages uses composite index for ordering
The messages table column spec in sessions.md keeps commonCols (UUIDv4)
table-reference.md note on sortable IDs is updated: only parts uses sortable IDs, messages uses composite index
The ordering rationale is explicitly stated in ADR-003 amendment
All three sources are consistent after changes

References

docs/reviews/storage-architecture-review-2026-04-21.md#C02
docs/decisions/ADR-003
docs/decisions/storage-spec-phase1-resolutions.md#D2
docs/architecture/storage/sessions.md:42-46
docs/architecture/storage/table-reference.md:48

Notes

To be filled by implementation agent

Summary

To be filled on completion

2.1 KiB Raw Permalink Blame History