# popiartServer

Local development backend for `popiartcli`.

This is a thin single-server backend for local integration. It keeps the CLI
contract stable while pushing model-heavy responsibilities back to
`PopiNewAPI`.

It is meant to validate these product-facing APIs first:

- `auth`
- `skills`
- `run`
- `jobs`
- `artifacts`
- basic `budget`, `project`, and `models` stubs

## Project Relationship

See [docs/project-relationship.md](./docs/project-relationship.md).

Persistence details for the current local backend are documented in
[docs/persistence.md](./docs/persistence.md).

This note explains how `popiartcli`, `popiartServer`, and `PopiNewAPI` split responsibilities, and why routing, billing attribution, and provider access belong in the backend layers rather than the CLI.

## Run

```sh
make run
```

Default address:

```text
http://127.0.0.1:8080
```

Health check:

```sh
curl http://127.0.0.1:8080/health
```

Use it from `popiartcli`:

```sh
cd /Users/jiajia/popiartcli
go run ./cmd/popiart --endpoint http://127.0.0.1:8080/v1 auth login --key <your-popinewapi-key>
go run ./cmd/popiart --endpoint http://127.0.0.1:8080/v1 skills list
```

Optional skillhub source:

```sh
export POPIART_SKILLHUB_DIR=/tmp/Popiart_skillhub
```

In local development, `/tmp/Popiart_skillhub` is used automatically when it exists.

## Notes

- Local persistence is intentionally thin: `sessions`, `job refs`, and project route overrides live in SQLite.
- `artifact` no longer has a local blob store. For sync image results, the server stores `result_refs_json` in the job row and derives artifact metadata on demand.
- `job logs` are synthesized from job state transitions instead of being stored as a separate table.
- The local development backend verifies your login key against the local `PopiNewAPI`.
- This server is a development backend, not the final production architecture.