Files
hub/tasks/architecture/storage/enforce-parts-session-id-invariant.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

1.6 KiB

id, name, status, depends_on, scope, risk, impact, level
id name status depends_on scope risk impact level
enforce-parts-session-id-invariant Document and enforce parts.sessionId denormalization invariant completed
narrow high component implementation

Description

The invariant stated in sessions.md:96: "when inserting a part, always set sessionId to the message's sessionId. Never update messages.sessionId without updating all child parts." However, there is no DB trigger, no CHECK constraint, no application-level transaction pattern, and no immutability guarantee for sessionId.

The review recommends declaring sessionId on both messages and parts as immutable after creation, which eliminates the update problem. Define the application-level contract for part insertion and add an explicit "IMMUTABLE" note.

Acceptance Criteria

  • sessions.md documents that sessionId on both messages and parts is IMMUTABLE after creation
  • The column spec for messages.sessionId and parts.sessionId includes an IMMUTABLE annotation
  • The application-level contract for part insertion is documented: "read the message's sessionId and set it on the part within the same transaction"
  • The denormalization rationale is preserved but the invariant enforcement mechanism is explicit
  • Note added: "No DB trigger enforces this — immutability is respected by application layer; direct SQL must not update sessionId"

References

  • docs/reviews/storage-architecture-review-2026-04-21.md#C04
  • docs/architecture/storage/sessions.md:96
  • docs/architecture/storage/sessions.md:105

Notes

To be filled by implementation agent

Summary

To be filled on completion