3 Commits

Include renames

Author	SHA1	Message	Date
steveandClaude Opus 4.8	3f3a5b057c	Agent runtime: majordomo in-process, Ollama Cloud config, chat endpoint (#56) ... 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	2026-07-21 02:15:22 -04:00
steveandClaude Opus 4.8	653f381c4b	Document the agent env vars; make keeping docs true a standing rule ... README's config table gained OLLAMA_CLOUD_API_KEY and PANSY_AGENT_MODEL, marked as read once the assistant lands (#56) so the table describes what the binary does rather than what it will do. Both are already set in Komodo. Also fixed the Compose example, which still said "# PANSY_OIDC_ISSUER: ... once auth (#5) lands" — auth landed a long time ago. That is exactly the kind of rot this commit is trying to prevent, so it seemed worth fixing in the same breath: the snippet now shows the OIDC vars people actually need to set. CLAUDE.md now carries the rule explicitly. README updates go in the SAME commit as the change that needs them — the env var table and the compose snippet are the two things people copy, so they hurt most when stale. DESIGN.md tracks real architecture changes. Examples must run. And when you touch a file, check the comments around your change are still true, because a stale comment is worse than none: the next reader believes it. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ	2026-07-21 00:55:06 -04:00
steveandClaude Opus 4.8	1716362981	Add CLAUDE.md and a prominent vibe-coded disclosure in the README ... pansy is written by an LLM with a human directing. That belongs near the top of the README, not in a footnote — someone deciding whether to self-host this and point it at their own data should know before they decide, not after. The disclosure says what it actually means in practice (less scrutiny than a hand-written project, read the code, back up the database) rather than a vague "AI-assisted" hedge. CLAUDE.md collects the operational details that otherwise get rediscovered every session: GOWORK=off, the store/service/api seam and why rules go in the middle layer, the two unit scales, version-guarded writes, ErrNotFound-as-existence-mask, the branch/Gadfly/merge/deploy loop, and the env var names that aren't guessable. It also makes the disclosure a standing rule: if the README is ever rewritten, that section survives the rewrite, and the only acceptable edit is a clearer one. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ	2026-07-21 00:50:37 -04:00