Skip to main content

Caloron-Noether

Caloron reimplemented as Noether composition graphs. Same orchestration capabilities, ~6x less code.

Architecture

noether-scheduler (cron: sprint_tick.json every 60s)
        │
        ▼
Noether Engine (runs composition graphs)
  ├── DAG stages (Pure Python) — evaluate, is_complete, validate
  ├── GitHub stages (Network Python) — poll, create_issue, comment, merge
  ├── Supervisor stages (Pure Python) — health check, intervention, messaging
  ├── Retro stages (Pure/Network Python) — feedback, KPIs, report
  └── Kickoff stages (Network/LLM Python) — repo context, DAG generation
        │
        ▼
caloron-shell (~200 lines Rust, axum)
  ├── POST /heartbeat — record agent heartbeats
  ├── POST /spawn — create worktree + start harness
  └── GET /status — list live agents

All business logic is in Noether stages (Python). The shell only manages processes and HTTP.

Prerequisites

Caloron-Noether is a set of stages and compositions that run on top of Noether (v0.3.0+). You need both the noether CLI and noether-scheduler on your PATH.

cargo install noether-cli noether-scheduler
# or grab prebuilt binaries: https://github.com/alpibrusl/noether/releases/latest

See the Noether docs for deeper configuration, and the Scheduler guide for cron-driven compositions.

Setup

# 1. Verify noether is installed
noether --version
noether-scheduler --version

# 2. (Optional) Point at the hosted stage registry
export NOETHER_REGISTRY=https://registry.alpibru.com

# 3. Register custom stages
./register_stages.sh

# 4. Build the shell
cargo build -p caloron-shell

# 5. Start the shell (heartbeat + spawn server)
CALORON_SHELL_PORT=7710 ./target/debug/caloron-shell

# 6. Start the scheduler (drives sprint ticks + weekly retro)
noether-scheduler --config scheduler.json

Documentation

Full docs: docs/ — build locally with mkdocs serve.

Stage Promotion Path

All stages start as Python. When a stage meets all four criteria (generality, hot path, stable schema, worth the lines), it can be promoted to Rust via InlineRegistry — zero graph changes needed. See context/inline-stages.md.

CLI

Installing the package (pip install caloron-noether) exposes a caloron ACLI-compliant command:

caloron init my-project --backend noether            # create a project
caloron sprint "Build a hotel rate anomaly detector" # run an autonomous sprint
caloron status                                       # active project + last sprint
caloron history --limit 10                           # past sprints
caloron show 5                                       # full retro for sprint #5
caloron metrics --output json                        # aggregated KPIs
caloron agents                                       # agent profiles in this project
caloron projects list | switch | delete              # multi-project management
caloron config get|set <key> [value]                 # per-project settings

All commands accept --output text|json|table. The framework selected at caloron init --framework is propagated to the PO, HR, and reviewer agents. Supported frameworks: claude-code, cursor-cli, gemini-cli, codex-cli, open-code, aider. Non-claude frameworks use their agentic / auto-approval mode (-y for Gemini, --yes-always for Aider, exec --full-auto for Codex, -p for cursor-agent); make sure the corresponding CLI is authenticated and on $PATH.

Organisation conventions

Teams with a standard way of laying out projects, naming packages, or licensing files can declare those rules once and have every caloron sprint apply them. caloron org init scaffolds the file; edit it with your conventions:

caloron org init              # writes ~/.caloron/organisation.yml
# edit ~/.caloron/organisation.yml
caloron org show              # preview the block every agent will see
caloron org validate          # sanity-check the YAML

Per-project overrides go in <project>/caloron.yml (right-wins merge). Conventions are injected into the PO, agent, reviewer, and fix prompts — they're not enforced at tool level (no ruff config generation, no CI gate) today; the reviewer is the backstop.

Runtime dependency — Gitea

Caloron uses Gitea as the version-control backend for sprints — issues, PRs, merges, review comments all go through its API. A running Gitea container is required; without it, caloron sprint aborts with instructions. Start one with:

docker run -d --name gitea -p 3000:3000 -p 222:22 gitea/gitea:1.22

Set GITEA_TOKEN (or accept the dev-mode default) and configure your project with caloron config set repo <owner>/<repo> pointing at a repo you've created in that Gitea instance.

Bypass the preflight with caloron sprint --skip-gitea-check if you intentionally want to run without version control (agent still runs; all git/issue/PR calls become no-ops).

Sandbox

On Linux, caloron sprint runs each agent inside a bwrap (bubblewrap) sandbox. On macOS and other systems where bwrap is unavailable, it falls back to a no-op passthrough script so pip install caloron-alpibru works out of the box. Override with SANDBOX=/path/to/your-sandbox.sh if you need custom isolation.

Project Structure

orchestrator/         Sprint runtime (Python)
  orchestrator.py     Main loop: PO → agents → PRs → reviews → retro
  skill_store.py      Registry of skills/MCPs (18 built-in, user-extensible)
  hr_agent.py         Assigns skills + model + framework per task
  agent_configurator.py  Writes CLAUDE.md/.cursorrules/GEMINI.md + MCP configs
  agent_versioning.py    Tracks agent evolution across sprints
  template_store.py      Project scaffolds (YAML templates + LLM generation)
templates/            Project templates (user-extensible YAML)
  fastapi.yaml        FastAPI + ruff + pytest + Dockerfile
  fastapi-postgres.yaml  + SQLAlchemy + Alembic + docker-compose
  python-data.yaml    pandas + data dir + fixtures
  nextjs.yaml         Next.js 14 + TypeScript + Tailwind
  rust-cli.yaml       clap + clippy + fmt CI
stages/               Noether Python stages (stdin JSON → stdout JSON)
  dag/                DAG evaluation, completion, validation
  github/             GitHub/Gitea API operations
  supervisor/         Health checks, interventions, messaging
  retro/              Feedback, KPIs, report generation
  kickoff/            Repo context, DAG generation
compositions/         Noether composition graphs (JSON)
shell/                Thin Rust binary (axum HTTP server)
scripts/              Sandbox (bubblewrap on Linux, passthrough on macOS/other)
deploy/               Docker Compose + Kubernetes Helm chart
demo/                 Asciinema recording script

Metadata

Release files for caloron-alpibru 0.4.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for caloron-alpibru 0.4.2
File Size Uploaded
caloron_alpibru-0.4.2.tar.gz 120.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for caloron-alpibru 0.4.2
File Interpreter ABI Platform
caloron_alpibru-0.4.2-py3-none-any.whl Python 3 none any Details

Total release size: 209.1 kB

Release files / caloron_alpibru-0.4.2.tar.gz

Download URL caloron_alpibru-0.4.2.tar.gz
Size 120.6 kB
Tags Source
SHA-256 checksum
How to use checksums
c8a0a9c75fb64fa174eba8a53c92a05cf11af1c87f7a90a7c3119a7bc5aab6af
BLAKE2b-256 checksum
How to use checksums
89d85864448c0de388b23e284e6741711b16d53b8f70c543052e826c17b27a9d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Apr 16, 2026.

Transparency log

Release files / caloron_alpibru-0.4.2-py3-none-any.whl

Download URL caloron_alpibru-0.4.2-py3-none-any.whl
Size 88.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
8b619ffbcf334a44d706e33e1223e99430f7b314a82649c05acab14d5305b171
BLAKE2b-256 checksum
How to use checksums
2f6641b77fd5f7add582027288fbdce9996e7a704dc929fbcbcc0adc26773ade
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Apr 16, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.4.2 This release

2 release files

0.4.1

2 release files

0.4.0

2 release files

0.3.3

2 release files

0.3.2

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page