steveandClaude Opus 4.8
3f3a5b057c
Everything below the run loop already existed. This is the thing that runs a model. The build tag is gone, deliberately. internal/agent's doc comment promised two separations — cmd/pansy not importing the package, and the tool wiring behind //go:build majordomo — and both have been rewritten rather than left as a stale aspiration. A tag that keeps the agent out of the binary only earns its keep if you would ever ship a build without the agent, and the agent is the point; keeping it meant an untagged CI that never compiled the code that matters. majordomo is a real dependency now, resolved from the Gitea instance as a pseudo-version with no replace directive, so the Docker build (which has no sibling checkout) resolves it the same way this machine does. It is stdlib-first and pure Go, so CGO_ENABLED=0 and the single static binary survive. A TURN IS ONE CHANGE SET. That is the whole reason acting without a confirmation prompt is defensible: "empty the garlic bed and plant cucumbers" is one object edit and a dozen planting inserts, and it has to undo as one action rather than thirteen. The scope is opened even for a turn that turns out to be a question, because a change set with no revisions is never written — so asking costs nothing and history isn't littered with empty entries. The model spec goes to majordomo.Parse verbatim. That grammar, including comma-separated failover chains, is majordomo's; re-implementing any of it here would only mean two places to update when it grows. The key needs a bridge though: majordomo's ollama-cloud preset reads OLLAMA_API_KEY while pansy (like gadfly) is configured with OLLAMA_CLOUD_API_KEY, so the provider is registered explicitly on a private registry rather than depending on ambient environment. Runs are bounded by a step cap, a timeout and majordomo's loop guards. This is loop safety, not cost control — pansy is a personal tool and spend caps are explicitly not a v2 concern. A capped run does NOT fail: it kept whatever it managed to do, that work is recorded and undoable, and the reply says it stopped early rather than going silent. The chat endpoint streams. A turn that clears a bed and replants it makes a dozen tool calls over tens of seconds, and without streaming that is a long silence followed by everything at once — which reads as a hang, and defeats a design that rests on watching the canvas change as it happens. Conversations persist per (user, garden). Client-held history would be lost on a refresh, which is exactly when someone reloads to check whether the agent's change landed. Only the user/assistant TEXT is stored, not the model's full transcript: continuity needs what was said and what came back, and replaying a stored tool call would replay a decision made against a garden that has since moved on. It also keeps majordomo's message shape out of the schema. An instance with no key starts, serves the app, and doesn't advertise the agent — the routes aren't registered at all, the same shape as OIDC 404ing when unconfigured. A configured-but-unresolvable model logs and disables the assistant rather than refusing to boot: a garden planner that won't start because of a chat feature is worse than one without chat. Tool refusals reach the model as tool results it can explain, not 500s. The ACL story only works if it can narrate the refusal. Closes #56 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
pansy
Self-hostable garden planner: drag beds, bags, and containers onto a real-scale field, click into them to place freeform plops of plants, and zoom out to see what's planted where. Go backend + React frontend, one static binary.
🤖 This is a vibe-coded project
Essentially all of the code in pansy was written by an LLM (Claude), with a human directing the work, reviewing it, and deciding what ships. Every pull request also gets an automated adversarial review before it lands.
That's said up front because you deserve to know it before you trust pansy with anything: it hasn't been through the kind of scrutiny a hand-written, widely-used project has. Read the code before you self-host it. Back up your database. Bugs here are the ordinary kind of bugs, not a scandal — but so is the fact that nobody hand-wrote the thing.
See DESIGN.md for the architecture. Work is tracked in this repo's issues — start from the tracking epic.
Quickstart
Prerequisites: Go 1.26+, Node 20+.
Develop
Run the Go API and the Vite dev server together (Vite proxies /api → the API):
make dev
Then open http://localhost:5173. Or run the two halves in separate terminals for independent restarts:
make dev-api # Go API on :8080
make dev-web # Vite dev server on :5173
Build & run
Produce the single static binary with the web build embedded, then run it:
make build
./pansy
Open http://localhost:8080 — one process serves both the JSON API and the app.
Test
make test
Configuration
All configuration is via environment variables; every value has a default, so ./pansy runs with none set.
| Variable | Default | Description |
|---|---|---|
PANSY_PORT |
8080 |
TCP port the HTTP server listens on. |
PANSY_DB |
./pansy.db |
SQLite database file path (created if absent). |
PANSY_BASE_URL |
(empty) | Externally-visible base URL; used to derive the OIDC redirect URI. |
PANSY_REGISTRATION |
open |
open or closed — gates local self-service signup. |
PANSY_LOCAL_AUTH |
true |
Enable local password auth. Set false for pure-OIDC. |
PANSY_OIDC_ISSUER |
(empty) | OIDC issuer/discovery URL (Authentik). Enables SSO when set. |
PANSY_OIDC_CLIENT_ID |
(empty) | OIDC client ID. |
PANSY_OIDC_CLIENT_SECRET |
(empty) | OIDC client secret. |
PANSY_OIDC_BUTTON_LABEL |
Sign in with Authentik |
Label for the OIDC button on the login page. |
PANSY_TRUSTED_PROXIES |
(none) | Comma-separated proxy CIDRs/IPs to trust for client-IP resolution. |
The garden assistant reads three more. Setting none of them leaves the assistant off; the app runs exactly as it does without it.
| Variable | Default | Description |
|---|---|---|
OLLAMA_CLOUD_API_KEY |
(empty) | Ollama Cloud API key. Without it the assistant is disabled, not broken — the chat routes simply aren't registered. |
PANSY_AGENT_MODEL |
ollama-cloud/glm-5.2:cloud |
Model spec, passed verbatim to majordomo.Parse — a comma-separated list is a failover chain, e.g. ollama-cloud/glm-5.2:cloud,ollama-cloud/kimi-k2.6:cloud. |
PANSY_AGENT_ENABLED |
on when a key is present | Turns the assistant off without removing the key. |
The assistant acts without asking first, which is only reasonable because every turn is one undoable change set — see the History panel in the editor.
Local email/password auth is live (POST /api/v1/auth/register, /auth/login, /auth/logout, GET /auth/me, GET /auth/providers); the session is an HttpOnly cookie (Secure when PANSY_BASE_URL is https). The first account registered becomes admin, and it may register even when PANSY_REGISTRATION=closed to bootstrap the instance.
OIDC (Authentik-first) is live too: set PANSY_OIDC_ISSUER, PANSY_OIDC_CLIENT_ID, PANSY_OIDC_CLIENT_SECRET, and PANSY_BASE_URL (needed for the redirect URI). Register PANSY_BASE_URL + /api/v1/auth/oidc/callback as the redirect URI in your IdP. GET /auth/oidc/login starts an authorization-code + PKCE flow; first login provisions a user just-in-time (a matching verified email links to an existing local account instead of duplicating it). Provider discovery is lazy, so a briefly-unreachable IdP never blocks startup or local auth. Set PANSY_LOCAL_AUTH=false for pure-Authentik deployments (local register/login are then rejected and hidden from /auth/providers).
Docker & deployment
CI (.gitea/workflows/build-image.yml) builds the single-binary image and pushes it to the Gitea registry on every branch push:
| Ref | Tag |
|---|---|
main |
gitea.stevedudenhoeffer.com/steve/pansy:latest |
| any other branch | gitea.stevedudenhoeffer.com/steve/pansy:<branch-name> |
| every build | gitea.stevedudenhoeffer.com/steve/pansy:sha-<short> (immutable; use to pin) |
The image runs as a non-root user, serves on :8080, and stores the SQLite database on the /data volume. Run it directly:
docker run -d --name pansy \
-p 8080:8080 \
-v pansy-data:/data \
gitea.stevedudenhoeffer.com/steve/pansy:latest
Or as a Komodo/Compose stack:
services:
pansy:
image: gitea.stevedudenhoeffer.com/steve/pansy:${PANSY_TAG:-latest}
ports:
- "8080:8080"
volumes:
- pansy-data:/data
environment:
PANSY_BASE_URL: https://pansy.example.com
# PANSY_OIDC_ISSUER: https://auth.example.com/application/o/pansy/
# PANSY_OIDC_CLIENT_ID: ...
# PANSY_OIDC_CLIENT_SECRET: ...
# OLLAMA_CLOUD_API_KEY: ... # enables the garden assistant
restart: unless-stopped
volumes:
pansy-data:
Pin PANSY_TAG to a sha-<short> tag for reproducible deploys, or leave it at latest to track main.