hub/tasks/architecture/storage/fix-parts-timestamps-spec.md at 2b63cda1c76446ac4662aa2be9ddad6d90cc4bfe

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.5 KiB

Raw Blame History

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

name

status

depends_on

scope

risk

impact

level

fix-parts-timestamps-spec

Fix Parts Table Timestamp NOT NULL and onUpdate Spec

completed

narrow

low

isolated

implementation

Description

W22: The parts table defines its own id, metadata, createdAt, updatedAt instead of using commonCols, but the spec only says "defaults to now()" without specifying NOT NULL or $onUpdate. If the Drizzle implementation omits $onUpdate, parts rows never have updatedAt updated on modification. If timestamps are not NOT NULL, they can become NULL.

The parts table spec must explicitly state that createdAt and updatedAt are NOT NULL and that updatedAt includes $onUpdate(() => new Date()). Either replicate these details from commonCols with an explicit override note for id, or reference commonCols with the id exception documented.

Acceptance Criteria

sessions.md parts table: createdAt and updatedAt specified as NOT NULL
updatedAt specified with $onUpdate(() => new Date())
Note added explaining why parts uses custom columns instead of commonCols (sortable ID vs UUIDv4)
id column exception documented (sortable ID, not UUIDv4 from commonCols)

References

docs/reviews/storage-architecture-review-2026-04-21.md#W22
docs/architecture/storage/sessions.md:99-107
docs/architecture/storage/README.md:69-82

Notes

To be filled by implementation agent

Summary

To be filled on completion

1.5 KiB Raw Blame History