Self-hosting

Что это значит без мистики

Self-hosting звучит магически: harness развивает сам harness. На практике это не магия, а maturity step. Сначала нужен controlled loop, который умеет менять собственные bounded части, проходить checks и оставлять audit trail.

Путь bootstrap

1. Ручной agent run.
2. Minimal runner.
3. Task contracts и context packs.
4. Verification gates.
5. Logs и run summaries.
6. Task graph и ready queue.
7. Bounded задачи по улучшению самого harness.
8. Review и release policy для изменений harness.

Это уже есть в labs

Lab-цепочка хендбука — работающий self-hosting в миниатюре, с evidence на каждый шаг:

Шаг	Кто строил	Что построено	Evidence
1	Человек	harness v01 (~90 строк)	код в 01-manual-runner/
2	v01	harness v02 + JSONL observability	run log v01, py_compile check
3	v02	ALGI pain diary slice	runs/*.jsonl, unit tests
4	v02	harness v03 + policy gate	run log v02
5	v03	ALGI clinician report — через собственный policy gate	policy_check events в log

Каждое «harness строит harness» здесь bounded (одна задача, один fixture), checked (py_compile, unit tests) и logged. Ровно это отличает self-hosting как maturity step от self-hosting как магического мышления: улучшение самого себя проходит через тот же contract → checks → evidence цикл, что и продуктовая задача.

Два loop, не один

Для production self-hosting важно разделить execution и evolution:

online loop:
  выполнить bounded task -> записать immutable trajectory -> классифицировать result

offline loop:
  собрать похожие trajectories -> поставить diagnosis -> предложить candidate change
  -> прогнать eval/regression -> release/canary/rollback

Online loop не должен напрямую переписывать stable prompt, policy, tests, validators или release thresholds. Он только выполняет работу и пишет evidence. Persistent изменения появляются как candidate artifacts: knowledge document, skill, prompt patch, tool change, harness patch. Каждый candidate проходит review и eval suite.

Практическое правило: agent может улучшать рабочие инструкции и bounded harness code, но не должен сам менять систему, которая утверждает его изменения.

С чего начинать self-hosting

Хорошие первые задачи:

• улучшить templates;
• добавить parser для logs;
• расширить run summary;
• добавить non-destructive check;
• улучшить docs;
• добавить тест на существующее поведение.

Плохие первые задачи:

• менять permissions model;
• менять secret handling;
• переписывать scheduler;
• включать production execution;
• удалять review gates.

Maturity model

Stage	Возможность
Script	Один bounded run, ручной запуск.
Runner	Воспроизводимый цикл task -> prompt -> checks.
Harness	Logs, retry, review, sandbox, result classification.
Orchestrator	Task graph, dependencies, ready queue, concurrency.
Self-hosted	Harness берет bounded задачи по улучшению самого себя.

Что считать learning signal

Не каждый successful run должен становиться новым правилом. Хороший learning signal имеет:

• external evidence, а не self-report агента;
• diagnosis: outcome, process или quality failure;
• несколько похожих случаев либо явно high-impact incident;
• provenance: source run IDs, logs, checks, reviewer notes;
• held-out eval, на котором candidate change улучшает результат;
• retention set, где старые сценарии не ломаются.

Если сигнал основан на web page, email, issue text или tool output, считайте его untrusted evidence. Его можно анализировать, но нельзя напрямую превращать в instruction без schema/provenance/review.

На что не соглашаться

• Называть self-hosting любой agent-generated diff в harness repo.
• Увеличивать autonomy до observability.
• Разрешать self-modification без stronger checks.
• Не отделять course-stable layer от production-grade ambition.
• Позволять agent менять validators, eval thresholds, audit logs или stable backups.

Что сделать руками

Спроектируйте roadmap от одного agent script к yolo-runner-like self-hosted harness. Для каждого шага укажите, какая часть harness может менять саму себя, какие checks защищают изменение и где остаётся human review.