# Updates API

Small public update feed for W-Make Batchmaker and Batchmaker Standalone.

## Local

```bash
npm test
UPDATES_ADMIN_TOKEN='use-a-local-token' npm start
```

The service listens on `PORT` (default `8080`) and stores SQLite data at `UPDATES_DB_PATH` (default `./data/updates.sqlite`).

## API

Public:

- `GET /healthz`
- `GET /v1/updates?product=batchmaker|standalone&limit=3`
- `GET /v1/updates/:slug`
- `GET /feed.xml?product=batchmaker|standalone`

Admin requests require `Authorization: Bearer <token>`:

```bash
curl -X POST http://127.0.0.1:8080/v1/admin/updates \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{"product":"standalone","title":"Studio update","summary":"A new calculation workflow is available."}'

curl -X POST http://127.0.0.1:8080/v1/admin/updates/1/publish \
  -H 'Authorization: Bearer <token>'
```

Never commit the token or production data. In Docker, `/data` must be a persistent volume and `UPDATES_ADMIN_TOKEN` must be injected by the host secret/environment.

## Operations

Before deployment, back up the SQLite database. A restart must preserve published updates. Test restore by copying the backup to a temporary SQLite path and opening it with Node's `node:sqlite`.

The service intentionally has no CMS, user system, comments, or direct access to Batchmaker databases in v1.

ponytail: Keep the API contract stable; migrate to PostgreSQL/OIDC only when measured write volume or multi-author editing justifies the additional operational surface.

## Current integration boundary

The portfolio is wired as the first client. Batchmaker and Standalone still need their own UI client changes in their canonical repositories after the runtime/deployment URLs are confirmed.

No production deployment is performed by this change.

## License

Private project.