The Himmel Adoption Trail

Eight levels from a fresh machine to a fleet that ships while you sleep. Climb as far as suits you — every level is optional, honest about what it changes, and reversible. Click any chip for its detail.

LEVEL 0

Install & stay current

Clone github.com/yotamleo/himmel, then run the installer from inside the clonehimmelctl only lands on your PATH once the install has run, so the first invocation is node scripts/himmelctl/bin.js install. It reads your machine first, asks — Enter always takes the safe default — and shows the full plan with --dry-run before touching anything. Later, /himmel-update keeps everything current, including the pinned tools it manages for you. One manifest covers the whole install: dependencies, wiring, schedulers, lanes, plugins, vault and hooks.

Before you clone: install git, node and npm (or bun), jq, python3, gh, pre-commit and the claude CLI. The installer hard-stops on the ones it cannot work without (bash, git, jq, python3, and npm or bun) and lists the rest in its plan. On an interactive terminal it will offer to install a missing hard requirement, but only after you say yes; with --dry-run or no terminal it just tells you what is missing. On Debian/Ubuntu note that the nodejs package ships without npm. Exact per-platform commands, and a verified end-to-end Linux walkthrough, are in setup/new-machine.md; the narrative version is getting-started.md.

This page ships in docs/ in the public himmel repo and is published from there at yotamleo.github.io/Himmel/adoption-trail.html; you can also open the file straight from your clone.

himmel brings
installs from elsewhere
coming

Impact: from minute one, himmelctl status reads your real machine — what is actually installed, armed and working, never what a config file merely claims.

Answers are cached; himmelctl ensure replays them.
LEVEL 1

Ship with guardrails

Turn on the development overlay: commit gates, ticket discipline, attested pushes and a review loop that runs before anything merges — on GitHub via the required gh CLI, or Bitbucket via the bundled Bitbucket CLI (the himmel-gh plugin routes to whichever your repo uses).

  • Worktree isolation — feature work never edits your main branch directly
  • Dangerous-command blocking — destructive shell operations are refused, not regretted
  • Secret egress fences — credentials and private data are stopped before they reach any outside service
  • Corpus routing — a ratified matrix decides which body of data may reach which backend at all; health data fails closed
  • Attested pushes — a push carries proof of testing and review, or it doesn't leave
  • Review gates — a merge needs a clean review verdict at the exact commit being merged, not at some earlier one
  • Git-flow discipline — conventional commits with ticket refs, feature work only in worktrees, and a runbook that drives execute → review → PR → ticket → merge → handover end-to-end
  • Spend guards — unattended runs draw the same subscription bank as you do; they are gated, never silent
  • Scheduler safety — raw scheduled-task mutation is blocked; only vetted scripts arm or disarm

None of this is advice. Each guard above is wiring — hooks and gates that fire whether or not anyone remembers them.

The Claude-session guards (worktree isolation, dangerous-command blocking, the egress fences) and the git gates (pre-commit, commit-msg, pre-push) are both wired by the install — the opt-out, --skip-hooks (-SkipHooks on Windows), is a flag of scripts/adopt.sh / adopt.ps1, not of himmelctl install, so use it if you manage git hooks yourself. Ticket discipline is on by default once they are placed: the commit-msg gate wants a PROJECT-123 reference when you set JIRA_PROJECT_KEY (or your own TICKET_ID_PATTERN), and himmel's own #123 numbering when you have no Jira at all. TICKET_ID_REQUIRED=0 opts out of the ticket half; the conventional-commit shape check stays on either way. See setup/new-machine.md.

Today the git flow is structurally PR-only: no direct push to main, one sanctioned merge path, auto-merge only when you opt in.

Impact: nothing lands unreviewed or unattested. The workflow enforces itself, so discipline stops depending on memory at 2am.

LEVEL 2

Second brain

Connect a vault — start from the bundled or point at the notes you already have — and pick which of the eight cadences to arm: the content pipeline (harvest, synthesize, health), the search reindex, the knowledge-graph refresh, a cleanup sweep (if you took the codex lane), the upstream drift-fix and upstream watch, and — only where they apply — a Windows repo sync and a Google Health pull. The search reindex is its own cadence with its own arming — arm only the pipeline and your search goes stale.

himmel brings
you provide

Impact: knowledge compounds while you sleep. A link you toss in at midnight is a connected, summarized note by morning.

The vault-dependent cadences are asked once a vault exists. Anything you decline is recorded as declined — never switched on behind your back.
LEVEL 3

Reach: your phone joins

Wire the Telegram bridge. The installer also asks — explicitly, by name — whether the bridge should survive reboots, on the platforms where it has an installer for that (Windows and Linux).

Impact: ideas and alerts meet you where you are. The vault fills itself from your phone; the system can tap your shoulder when something needs you.

Needs a bot token; the wizard walks you through it and never echoes secrets.
LEVEL 4

Review depth

Add the optional review lanes — codex and hermes — beside Claude's built-in review. They are offered as review lanes: a second opinion on your diff before it merges. Each is its own explicit opt-in, with its own login.

Impact: two model families argue over your diff before it merges. The trade, plainly: without these lanes, review runs Claude-only — one reviewer, however good.

Skippable forever — and the wizard tells you at the question itself what skipping costs you.
LEVEL 5

Spend & context, under control

See and steer what agent work costs — tokens, quota windows, context — before it surprises you.

himmel brings
coming

Impact: quota exhaustion stops being a 3pm surprise. Heavy work checks the bank first; every session can read its own context fill instead of guessing.

LEVEL 6

Always-on operations

Harden for unattended work: always-on hardening, handover state so work survives any single session, overnight runs, and a real monitoring stack — Grafana, Prometheus and himmel's own exporters, installed on your machine — feeding alerts to your bridge.

Impact: work continues while you're away. Instead of reconstructing the night, you read one morning report and make the decisions only you can make.

Partly guided-manual today: the installer wires the monitoring stack up on Windows, but reports it as not yet runnable elsewhere, and a few schedules are still armed by hand.
LEVEL 7

Command a fleet

Two words first, because the rest of this level uses them (both are defined in the glossary). A leg is one work session that owns exactly one ticket, in its own worktree. The console is the one session you keep in front of you: it reviews legs at their stop points, holds the sole authority to release a merge, and escalates to you only what genuinely needs you.

The summit is many legs running at once under one console. They coordinate through a written layer — mission briefs plus handover and roadmap documents every leg reads and appends — and by direct messages to the console when something is urgent.

A read-only console for watching it happen ships today: a local web UI showing fleet state, escalations and a live event stream. Dispatch and adjudication are not built yet — the console's own UI says so.

Impact: you stop being the bottleneck of one session. A night's work is many tickets shipped in parallel — and the morning report stays your single human surface.

OFF-TRAIL

Self-evolving — testing in progress

The experimental tier: capabilities that run daily here but are not proven enough to promise. Listed as work in progress, not as features.