v0.1.37-alpha

v0.1.37-alpha — schema and triggers for two-way calendar sync

Phase 2, task 1. Deliberately inert: it adds columns and changes trigger
behaviour, and unlocks nothing. No calendar becomes writable, nothing syncs
to Google, no behaviour a household can see changes.

It ships on its own because there is no database rollback — the box's
post-update watchdog reverts the code symlink, not the schema — and because
the risk that matters is not a migration that fails loudly but the trigger
rewrite succeeding while subtly wrong. Those triggers fire on every write to
calendar_events for every household, and CalDAV clients depend on them for
sync tokens and ETags.

• calendar_events.remote_updated, the provider's own timestamp
• calendar_changes.external_id, captured on journal rows and load-bearing on
  deletes, where the event row is already gone
• calendars.outbound_cursor and calendars.last_outbound_at
• both trigger functions rewritten so a write touching only remote_updated is
  invisible: no revision bump, no sync_token bump, no ctag reroll, no journal
  row — otherwise every future outbound push would make every subscribed
  CalDAV client re-download the event

What to watch after deploying is an absence, not a feature: CalDAV keeps
syncing, devices do not re-download everything, calendar_changes does not
grow.

Install

curl -fL https://github.com/Springdale-Robotics/basis/releases/download/v0.1.37-alpha/basis-0.1.37-alpha.tar.gz | tar -xz
sudo bash basis-0.1.37-alpha/backend/deploy/native/install.sh --source basis-0.1.37-alpha

Basis installs natively (Node/Postgres/Redis + systemd); there
is no Docker image. Local development still uses Docker for
Postgres/Redis/Ollama via backend/docker-compose.dev.yml.