disinto/AGENTS.md

Disinto — Agent Instructions

What this repo is

Disinto is an autonomous code factory. It manages ten agents (dev, review, gardener, supervisor, planner, predictor, architect, reproduce, triage, edge dispatcher) that pick up issues from forge, implement them, review PRs, plan from the vision, and keep the system healthy — all via a polling loop (docker/agents/entrypoint.sh) and claude -p. The dispatcher executes formula-based operational tasks.

Each agent has a .profile repository on Forgejo that stores lessons learned from prior sessions, providing continuous improvement across runs.

Note: The vault is being redesigned as a PR-based approval workflow on the ops repo (see issues #73-#77). See docs/VAULT.md for details. Old vault scripts are being removed.

See README.md for the full architecture and disinto-factory/SKILL.md for setup.

Directory layout

disinto/                 (code repo)
├── dev/           dev-poll.sh, dev-agent.sh, phase-test.sh — issue implementation
├── review/        review-poll.sh, review-pr.sh — PR review
├── gardener/      gardener-run.sh — polling-loop executor for run-gardener formula
│                  best-practices.md — gardener best-practice reference
│                  pending-actions.json — queued gardener actions
├── predictor/     predictor-run.sh — polling-loop executor for run-predictor formula
├── planner/       planner-run.sh — polling-loop executor for run-planner formula
├── supervisor/    supervisor-run.sh — formula-driven health monitoring (polling-loop executor)
│                  preflight.sh — pre-flight data collection for supervisor formula
├── architect/     architect-run.sh — strategic decomposition of vision into sprints
├── vault/         vault-env.sh — shared env setup (vault redesign in progress, see #73-#77)
│                  SCHEMA.md — vault item schema documentation
│                  validate.sh — vault item validator
│                  examples/ — example vault action TOMLs (promote, publish, release, webhook-call)
├── lib/           env.sh, agent-sdk.sh, ci-helpers.sh, ci-debug.sh, load-project.sh, parse-deps.sh, guard.sh, mirrors.sh, pr-lifecycle.sh, issue-lifecycle.sh, worktree.sh, formula-session.sh, stack-lock.sh, forge-setup.sh, forge-push.sh, ops-setup.sh, ci-setup.sh, generators.sh, hire-agent.sh, release.sh, build-graph.py,
│                  branch-protection.sh, secret-scan.sh, tea-helpers.sh, vault.sh, ci-log-reader.py
│                  hooks/ — Claude Code session hooks (on-compact-reinject, on-idle-stop, on-phase-change, on-pretooluse-guard, on-session-end, on-stop-failure)
├── projects/      *.toml.example — templates; *.toml — local per-box config (gitignored)
├── formulas/      Issue templates (TOML specs for multi-step agent tasks)
├── docker/        Dockerfiles and entrypoints for reproduce, triage, and edge dispatcher agents
├── docs/          Protocol docs (PHASE-PROTOCOL.md, EVIDENCE-ARCHITECTURE.md)
├── site/          disinto.ai website content
├── tests/         Test files (mock-forgejo.py, smoke-init.sh)
├── templates/     Issue templates
├── bin/           The `disinto` CLI script
├── disinto-factory/  Setup documentation and skill
├── state/         Runtime state
├── .woodpecker/   Woodpecker CI pipeline configs
├── VISION.md      High-level project vision
└── CLAUDE.md      Claude Code project instructions

disinto-ops/             (ops repo — {project}-ops)
├── vault/
│   ├── actions/   where vault action TOMLs land (core of vault workflow)
│   ├── pending/   vault items awaiting approval
│   ├── approved/  approved vault items
│   ├── fired/     executed vault items
│   └── rejected/  rejected vault items
├── sprints/       sprint planning artifacts
├── knowledge/     shared agent knowledge + best practices
├── evidence/      engagement data, experiment results
├── portfolio.md   addressables + observables
├── prerequisites.md  dependency graph
└── RESOURCES.md   accounts, tokens (refs), infra inventory

Agent .profile Model

Each agent has a .profile repository on Forgejo storing knowledge/lessons-learned.md (injected into each session prompt) and journal/ reflection entries (digested into lessons). Pre-session: formula_prepare_profile_context() loads lessons. Post-session: profile_write_journal records reflections. See lib/formula-session.sh.

Terminology note: "Formulas" are TOML issue templates in formulas/ that orchestrate multi-step agent tasks. Distinct from "processes" in docs/EVIDENCE-ARCHITECTURE.md.

Tech stack

• Shell: bash (all agents are bash scripts)
• AI: claude -p (one-shot) or claude (interactive/tmux sessions)
• CI: Woodpecker CI (queried via REST API + Postgres)
• VCS: Forgejo (git + Gitea-compatible REST API)
• Notifications: Forge activity (PR/issue comments), OpenClaw heartbeats

Coding conventions

• All scripts start with #!/usr/bin/env bash and set -euo pipefail
• Source shared environment: source "$(dirname "$0")/../lib/env.sh"
• Log to $LOGFILE using the log() function from env.sh or defined locally
• Never hardcode secrets — agent secrets come from .env.enc, vault secrets from .env.vault.enc (or .env/.env.vault fallback)
• Never embed secrets in issue bodies, PR descriptions, or comments — use env var references (e.g. $BASE_RPC_URL)
• ShellCheck must pass (CI runs shellcheck on all .sh files)
• Avoid duplicate code — shared helpers go in lib/

How to lint and test

# ShellCheck all scripts
git ls-files '*.sh' | xargs shellcheck

# Run phase protocol test
bash dev/phase-test.sh

---

Agents

Agent	Directory	Role	Guide
Dev	dev/	Issue implementation	dev/AGENTS.md
Review	review/	PR review	review/AGENTS.md
Gardener	gardener/	Backlog grooming	gardener/AGENTS.md
Supervisor	supervisor/	Health monitoring	supervisor/AGENTS.md
Planner	planner/	Strategic planning	planner/AGENTS.md
Predictor	predictor/	Infrastructure pattern detection	predictor/AGENTS.md
Architect	architect/	Strategic decomposition	architect/AGENTS.md
Reproduce	docker/reproduce/	Bug reproduction using Playwright MCP	formulas/reproduce.toml
Triage	docker/reproduce/	Deep root cause analysis	formulas/triage.toml
Edge dispatcher	docker/edge/	Polls ops repo for vault actions, executes via Claude sessions	docker/edge/dispatcher.sh

Vault: Being redesigned as a PR-based approval workflow (issues #73-#77). See docs/VAULT.md for the vault PR workflow details.

See lib/AGENTS.md for the full shared helper reference.

---

Issue lifecycle and label conventions

Issues flow: backlog → in-progress → PR → CI → review → merge → closed.

Labels

Label	Meaning	Set by
backlog	Issue is queued for implementation. Dev-poll picks the first ready one.	Planner, gardener, humans
priority	Queue tier above plain backlog. Issues with both priority and backlog are picked before plain backlog issues. FIFO within each tier.	Planner, humans
in-progress	Dev-agent is actively working on this issue. Only one issue per project is in-progress at a time.	dev-agent.sh (claims issue)
blocked	Issue is stuck — agent session failed, crashed, timed out, or CI exhausted. Diagnostic comment on the issue has details. Also used for unmet dependencies.	dev-agent.sh, dev-poll.sh (on failure)
tech-debt	Pre-existing issue flagged by AI reviewer, not introduced by a PR.	review-pr.sh (auto-created follow-ups)
underspecified	Dev-agent refused the issue as too large or vague.	dev-poll.sh (on preflight too_large), dev-agent.sh (on mid-run too_large refusal)
bug-report	Issue describes user-facing broken behavior with reproduction steps. Separate triage track for reproduction automation.	Gardener (bug-report detection in grooming)
in-triage	Bug reproduced but root cause not obvious — triage agent investigates. Set alongside bug-report.	reproduce-agent (when reproduction succeeds but cause unclear)
rejected	Issue formally rejected — cannot reproduce, out of scope, or invalid.	reproduce-agent, humans
vision	Goal anchors — high-level objectives from VISION.md.	Planner, humans
prediction/unreviewed	Unprocessed prediction filed by predictor.	predictor-run.sh
prediction/dismissed	Prediction triaged as DISMISS — planner disagrees, closed with reason.	Planner (triage-predictions step)
prediction/actioned	Prediction promoted or dismissed by planner.	Planner (triage-predictions step)
formula	Issue is a formula-based operational task. Dev-poll skips these; dispatcher handles them.	Dispatcher (when dispatching formula tasks)

Dependency conventions

Issues declare dependencies via ## Dependencies / ## Depends on sections listing #N refs. lib/parse-deps.sh extracts these; dev-poll only picks issues whose deps are all closed. See AD-002 for concurrency bounds per LLM backend.

---

Addressables and Observables

Concrete artifacts the factory has produced or is building. Observables have measurement wired — the gardener promotes addressables once an evidence process is connected.

Artifact	Location	Observable?
Website	disinto.ai	No
Repo	codeberg.org/johba/disinto	Partial
Skill	ClawHub (in progress)	No
GitHub org	github.com/Disinto	No

---

Architecture Decisions

Humans write these. Agents read and enforce them.

ID	Decision	Rationale
AD-001	Nervous system runs from a polling loop (docker/agents/entrypoint.sh), not PR-based actions.	Planner, predictor, gardener, supervisor run directly via *-run.sh. They create work, they don't become work. (See PR #474 revert.)
AD-002	Concurrency is bounded per LLM backend, not per project. One concurrent Claude session per OAuth credential pool; one concurrent session per llama-server instance. Containers with disjoint backends may run in parallel.	The single-thread invariant is about backends, not pipelines. (a) Anthropic OAuth credentials race on token refresh — two sessions sharing one mounted ~/.claude will trip over each other during rotation and 401. All agents inside an OAuth-mounted container serialize on flock session.lock. (b) llama-server has finite VRAM and one KV cache — parallel inference thrashes the cache and risks OOM. All llama-backed agents serialize on the same lock. (c) Disjoint backends are free to parallelize. Today disinto-agents (Anthropic OAuth, runs review,gardener) runs concurrently with disinto-agents-llama (llama, runs dev) on the same project — they share neither OAuth state nor llama VRAM. (d) Per-project work-conflict safety (no duplicate dev work, no merge conflicts on the same branch) is enforced by issue_claim (assignee + in-progress label) and per-issue worktrees — that's a separate guard that does NOT depend on this AD.
AD-003	The runtime creates and destroys, the formula preserves.	Runtime manages worktrees/sessions/temp. Formulas commit knowledge to git before signaling done.
AD-004	Event-driven > polling > fixed delays.	Never waitForTimeout or hardcoded sleep. Use phase files, webhooks, or poll loops with backoff.
AD-005	Secrets via env var indirection, never in issue bodies.	Issue bodies become code. Agent secrets go in .env.enc, vault secrets in .env.vault.enc (SOPS-encrypted when available; plaintext .env/.env.vault fallback supported). Referenced as $VAR_NAME. Runner gets only vault secrets; agents get only agent secrets.
AD-006	External actions go through vault dispatch, never direct.	Agents build addressables; only the vault exercises them (publishes, deploys, posts). Tokens for external systems (GITHUB_TOKEN, CLAWHUB_TOKEN, deploy keys) live only in .env.vault.enc and are injected into the ephemeral runner container. lib/env.sh unsets them so agents never hold them. PRs with direct external actions without vault dispatch get REQUEST_CHANGES. (Vault redesign in progress: PR-based approval on ops repo, see #73-#77)

Who enforces what:

• Gardener checks open backlog issues against ADs during grooming; closes violations with a comment referencing the AD number.
• Planner plans within the architecture; does not create issues that violate ADs.
• Dev-agent reads AGENTS.md before implementing; refuses work that violates ADs.
• AD-002 is a runtime invariant; nothing for the gardener to check at issue-groom time. Concurrency is enforced by flock session.lock within each container and by issue_claim for per-issue work. A violation manifests as a 401 or VRAM OOM in agent logs, not as a malformed issue.

---

Phase-Signaling Protocol

When running as a persistent tmux session, Claude must signal the orchestrator at each phase boundary by writing to a phase file (e.g. /tmp/dev-session-{project}-{issue}.phase).

Key phases: PHASE:awaiting_ci → PHASE:awaiting_review → PHASE:done. Also: PHASE:escalate (needs human input), PHASE:failed.

See docs/PHASE-PROTOCOL.md for the complete spec including the orchestrator reaction matrix, sequence diagram, and crash recovery.