<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Learn Cloche on Cloche</title>
    <link>http://192.168.2.122:1313/learn/index.html</link>
    <description>Recent content in Learn Cloche on Cloche</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language><atom:link href="http://192.168.2.122:1313/learn/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Communicating Between Steps</title>
      <link>http://192.168.2.122:1313/learn/communicating-between-steps/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/communicating-between-steps/index.html</guid>
      <description>Cloche offers three mechanisms for passing data between steps: environment variables injected by the daemon, a KV store accessible from both host and container steps, and a shared run folder for large files. Which one to use depends on what you&amp;rsquo;re passing and where it needs to go.
Environment Variables The daemon injects a set of CLOCHE_* environment variables into every step. These provide context about the current run — IDs, paths, and output locations — rather than user data.</description>
    </item>
    <item>
      <title>Tutorial: Automating GitHub Issues</title>
      <link>http://192.168.2.122:1313/learn/tutorial-github-workflow/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/tutorial-github-workflow/index.html</guid>
      <description>By the end of this tutorial you will have a Cloche pipeline that watches a GitHub repository for Issues, implements them autonomously inside a Docker container, and opens a pull request — all without manual intervention.
What We&amp;rsquo;re Building The pipeline has four workflows. list-tasks queries GitHub for open issues. main orchestrates the full run from claiming the task through to the PR. Inside main, develop does the coding work in a container, and merge extracts those changes, rebases on main, and opens the PR.</description>
    </item>
    <item>
      <title>Configuration Reference</title>
      <link>http://192.168.2.122:1313/learn/configuration/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/configuration/index.html</guid>
      <description>Cloche uses two configuration files: a per-project config and a global user config.
Project Configuration (.cloche/config.toml) Created by cloche init. Controls orchestration behavior, evolution, and per-agent settings for a single project.
Top-level Key Default Description active true Set to true to auto-start the orchestration loop when the daemon starts. [orchestration] Key Default Description concurrency 1 Maximum concurrent container runs. stagger_seconds 1.0 Delay (seconds) between consecutive run launches. dedup_seconds 300 Window (seconds) to suppress re-assigning the same task ID.</description>
    </item>
    <item>
      <title>Safety Guide</title>
      <link>http://192.168.2.122:1313/learn/safety/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/safety/index.html</guid>
      <description>This guide covers good practices for using Cloche securely. The central concern is the Lethal Trifecta of LLM-powered agent usage: when a system simultaneously has (1) access to private data, (2) exposure to untrusted content, and (3) the ability to communicate externally, it becomes vulnerable to prompt injection attacks that can exfiltrate sensitive information. Cloche&amp;rsquo;s architecture is designed to let you break this trifecta, but only if you configure it correctly.</description>
    </item>
    <item>
      <title>Project Layout</title>
      <link>http://192.168.2.122:1313/learn/project-layout/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/project-layout/index.html</guid>
      <description>After running cloche init --new, a project has the following structure:
my-project/ +-- .cloche/ | +-- develop.cloche # Container workflow | +-- host.cloche # Host orchestration workflows (list-tasks, main, release-task) | +-- Dockerfile # Container image definition | +-- config.toml # Project configuration | +-- version # Schema version marker (used for upgrade checks) | +-- prompts/ # Prompt templates | | +-- implement.md | | +-- fix-tests.md | | +-- fix-merge.</description>
    </item>
    <item>
      <title>Dockerfile Requirements</title>
      <link>http://192.168.2.122:1313/learn/dockerfile-requirements/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/dockerfile-requirements/index.html</guid>
      <description>The container image used by Cloche workflows must meet the following requirements:
Required Components Component Location Purpose cloche-agent /usr/local/bin/cloche-agent In-container orchestrator that receives step instructions from the daemon over gRPC. clo /usr/local/bin/clo Lightweight KV store CLI for reading and writing run data from inside the container. git On $PATH Required for result extraction (the daemon uses git worktrees to extract changes). agent user System user Cloche wraps commands with chown + su agent.</description>
    </item>
    <item>
      <title>Web Dashboard</title>
      <link>http://192.168.2.122:1313/learn/web-dashboard/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/web-dashboard/index.html</guid>
      <description>The web dashboard is a browser UI for monitoring and managing Cloche runs. It gives you live log streaming, workflow visualization, token usage metrics, task management, and container controls &amp;mdash; all without needing the CLI.
Enabling the Dashboard cloche init creates ~/.config/cloche/config with the dashboard enabled on localhost:8080 by default. Start the daemon and open http://localhost:8080.
To enable it manually, set http in ~/.config/cloche/config:
[daemon] http = &amp;#34;localhost:8080&amp;#34; Or pass it as an environment variable:</description>
    </item>
    <item>
      <title>Agent Setup</title>
      <link>http://192.168.2.122:1313/learn/agent-setup/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/agent-setup/index.html</guid>
      <description>Cloche supports any agent that can read a prompt from stdin and print CLOCHE_RESULT:&amp;lt;name&amp;gt; to stdout.
Built-in Agents Cloche has a concept of known agents — agent commands it understands natively. Known agents receive default arguments automatically, and some arguments are required and will always be injected regardless of agent_args. Unknown agents (e.g. codex) receive no default arguments; the prompt is passed on stdin and the command is invoked as-is.</description>
    </item>
    <item>
      <title>CLI Reference</title>
      <link>http://192.168.2.122:1313/learn/cli-reference/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/cli-reference/index.html</guid>
      <description>Every subcommand supports --help (or -h). Use cloche help &amp;lt;command&amp;gt; for detailed usage.
cloche init Set up or refresh a Cloche project. Safe to run on any existing project — existing files are not overwritten.
cloche init [-n | --new] [--install-shell-helpers] [--workflow &amp;lt;name&amp;gt;] [--base-image &amp;lt;image&amp;gt;] [--agent-command &amp;lt;cmd&amp;gt;] [--no-llm] Core behavior (always, no flags needed): Creates the .cloche/ directory structure if missing, creates or updates .cloche/config.toml (setting active = true), adds .</description>
    </item>
    <item>
      <title>DSL Reference</title>
      <link>http://192.168.2.122:1313/learn/dsl-reference/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>http://192.168.2.122:1313/learn/dsl-reference/index.html</guid>
      <description>Workflow files use the .cloche extension and live in .cloche/. The first step declared is the entry point. Graphs are validated at parse time: all results must be wired, no orphaned steps, and an entry point must exist.
Basic Structure workflow &amp;#34;develop&amp;#34; { container { image = &amp;#34;my-project:latest&amp;#34; agent_command = &amp;#34;claude&amp;#34; } step implement { prompt = file(&amp;#34;.cloche/prompts/implement.md&amp;#34;) results = [success, fail] } step test { run = &amp;#34;make test &amp;amp;&amp;amp; make lint&amp;#34; results = [success, fail] } step fix { prompt = file(&amp;#34;.</description>
    </item>
  </channel>
</rss>