Bricklogger 0.3.1

Bricklogger 0.3.1

0.3.0 was tagged but never released: its release run found the fault fixed
below. These are its changes, with that fix.

A one-stop init

• bricklogger init sets a machine up in one go and can be run again: the
  directories, the plugins, the sources and destinations, the database, the
  remaining files and the services, in that order. A file that exists is
  asked about, replace or skip, skip by default; a replaced file is copied
  first to <file>.<time>.bak, and the env file is only ever added to. On a
  machine where the daemon runs, it ends by asking whether to restart it.
• Its plugin step shows the catalogue, installs the chosen plugins and any
  other package typed in, and goes on with the types installed when an
  install fails.
• It prepares TimescaleDB: on localhost, on Debian and Ubuntu, it offers to
  install PostgreSQL 18 with TimescaleDB from Timescale's repository, run
  timescaledb-tune (copying postgresql.conf first) and enable the
  service, through sudo in the terminal; it creates the database, the role
  and the extension, as postgres locally or with an admin login asked for
  on another host and never kept. The role's password is generated and
  written to the env file. Nothing is ever deleted, and where it cannot act
  it prints the remaining commands and goes on. init --db runs the step
  alone.
• init --non-interactive writes the missing files and never replaces;
  --plugin PACKAGE installs plugins, and with BRICKLOGGER_DB_PASSWORD set
  (and optionally BRICKLOGGER_DB_HOST, _PORT, _NAME, _USER) it writes
  a working tsdb destination instead of the example.

The catalogue

• Bricklogger ships a catalogue of approved plugins, kept in
  github.com/CX1-ApS/bricklogger-marketplace, where a plugin is proposed with
  a pull request. It is shown by bricklogger plugins catalogue,
  GET /v1/plugins/catalogue, the Plugins screen's new Catalogue part with an
  Install per entry, and the MCP server's bricklogger://catalogue and
  list_catalogue. The MCP server still installs nothing.
• Every installed plugin has an origin, built-in, catalogue or custom,
  shown by bricklogger plugins, the Plugins screen and GET /v1/plugins.
  Custom plugins are installed exactly as before.
• catalogue joins the words no type may be named.

The compose file brings its database

• docker-compose.yml now has a db service, timescale/timescaledb-ha:pg18
  with a volume of its own, and every service, the web interface and the MCP
  server included, starts with docker compose up -d; there are no profiles.
  All four run on the host's network, and the database listens on
  127.0.0.1 alone and asks for a password there.
• .env beside the compose file must set POSTGRES_PASSWORD (the database's
  admin) and BRICKLOGGER_DB_PASSWORD (the role Bricklogger logs in as). At
  its first start the database creates the role, its database and the
  extension, and the daemon container writes a working TimescaleDB
  destination and installs the packages in BRICKLOGGER_PLUGINS, once each.
• The TimescaleDB destination updates the extension at start when the server
  offers a newer one than the database has, and logs a warning with the
  command where its role may not.

Configuration writes and reload run as jobs

• PUT /v1/config/{file} and POST /v1/daemon/reload answer 202 with a
  config or reload job instead of answering when they are done. Their
  steps are validating, writing, and stopping <instance> and
  starting <instance>; a configuration that does not hold fails the job
  with the 422 problem and its errors. They queue with model uploads and
  activations, one job at a time.
• GET /v1/jobs lists the jobs, newest first, with ?state=. The Model,
  Configuration and Daemon screens show a queued or running job again when
  they open, and every web button that waits says so, with the seconds
  counting.
• The CLI follows the job and shows its steps; the MCP write tools wait for
  it and answer as before. A stop finishes the configuration jobs it has
  accepted.

Speed and reliability

• Validation parses each SPARQL query once: a 9.3k-triple model validated in
  8.7 s instead of 37.5 s.
• A re-plan reads the points' locations with one query per kind of anchor: on
  a model of 6,000 entities, about a second instead of minutes, which every
  activation and reload waited for.
• A source's status reports never wait for the daemon, so a source reporting
  during an activation or a reload no longer blocks it and gets abandoned
  with stop_timeout. That warning is withdrawn once the abandoned thread
  ends.

Fixes

• What an activation inferred could differ between two starts of the daemon:
  Brick's SHACL rules were applied once, in an order that varied, so a rule
  that needs another's result sometimes ran too early. An entity typed
  brick:AHU, say, got the tags of brick:Air_Handling_Unit only in some runs.
  The rules are now applied until a pass adds nothing. Validation is
  unchanged; an activation takes about 40 % longer. 0.2 has the same fault.

Breaking changes

• An API client that writes the configuration or reloads must follow the job
  it gets with 202, through GET /v1/jobs/{id}, as for a model upload. The
  CLI, the web interface and the MCP server do this already.

For plugin authors

• The SDK contract is unchanged. A plugin is released again for 0.3 with
  bricklogger>=0.3,<0.4 — or >=0.2.5,<0.4 when it should go on working
  with 0.2 — since one bound to <0.3 holds update core at 0.2 and is left
  out when a container's image moves to 0.3.

Upgrading

• bricklogger update all, once every installed plugin has a release that
  allows 0.3; update status names any plugin that holds it back.
• In a container, compare your compose file with the new one: name
  ghcr.io/cx1-aps/bricklogger:0.3.1, and either take the db service and set
  both passwords in .env, or leave it out when the logger writes to a
  database of its own. The web interface and the MCP server now start without
  --profile.