Replace Anthropic client with OpenAI-compatible client targeting https://api.riotpiao.com.
Configure models: reasoning (Planner/Judge), ornith:35b (Implementer).
Add health check on startup.
Add Pi provider support for skill preparation (--pi-provider=local-llm).
Files changed:
- action/llm/client.go: OpenAI-compatible HTTP client + HealthCheck()
- action/llm/client_test.go: Unit tests for model validation & health
- cmd/starter/main.go: Health check before workflow, local model defaults
- statemachine/types.go: PiProvider field for OrchestratorInput
Models:
- Planner: reasoning (smart decisions)
- Judge: reasoning (quality review)
- Implementer: ornith:35b (cheap execution)
Skills: pi clone-or-fetch --provider=local-llm with 504 timeout learning.
Verification: go build ./cmd/starter ./cmd/worker ./action/llm ✓
Tests: go test -v ./action/llm ✓ (all passing)
Unit tests for all git activities:
- TestGitCloneAndFetch ✓
- TestGitWorktreeAdd ✓
- TestGitCommit ✓
- TestGitDiff ✓
- TestGitSquashMerge ✓
Integration test framework for LLM and Temporal:
- TestTemporalConnection
- TestActivityExecution
- TestLLMActivityAvailability
- TestOrchestratorWorkflowIntegration
All unit tests passing (8/8).
Integration tests available with: go test -v ./tests/temporal_integration_test.go
(Requires TEMPORAL_HOSTPORT and ANTHROPIC_API_KEY set)
All ExecuteActivity calls were missing StartToCloseTimeout and
ScheduleToCloseTimeout, causing 'BadScheduleActivityAttributes' errors.
- Added 10min timeout for git operations (clone, worktree, push, merge)
- Added 30min timeout for LLM activities (implementer, which calls Claude)
- Git operations use shared ctxWithOptions context
- LLM activities get their own implCtx with longer timeout
- Added time import
Implements real activity-calling logic in OrchestratorWorkflow and
TaskUnitWorkflow (previously stubs), adds GitDiffActivity, and expands
PlanningActivity's I/O to carry repo path and prior task results.
Adds k8s/ deployment manifests (worker Deployment, orchestrator Job,
Kustomize base) for the poimen-workflows Temporal worker, using a
dedicated Kubernetes namespace `poimen` and Temporal namespace
`poimen-harness` rather than sharing the Temporal server's own
`temporal`/`production` namespaces.