1.5 KiB
1.5 KiB
| name | description | user-invocable | model-invocable | side-effects | permission-profile | triggers | |
|---|---|---|---|---|---|---|---|
| forge-autonomous-runtime | Explains SF autonomous loop, UOK gates, installed-runtime drift, and recovery paths. | false | true | none | restricted |
|
forge-autonomous-runtime
Context
SF's autonomous mode is governed by the Unified Operation Kernel (UOK):
- State reading — UOK reads canonical project state from
.sf/sf.db - Ledger recording — Each run is recorded in the DB-backed ledger
- Projection — Runtime files under
.sf/runtime/are generated projections - Dispatch — UOK determines the next unit of work and creates a fresh agent session
- Execution — LLM executes with focused prompt and pre-inlined context
- Reconciliation — UOK reconciles ledger and projections before next dispatch
Recovery Paths
- Crash recovery — Lock file tracks current unit; next
/autonomousreads surviving state - Stuck detection — Loop detects stuck iterations and emits
stuck-detectedjournal events - Health gates — Pre-dispatch gates check state integrity before execution
- Parity reports — Ledger parity ensures no orphaned or missing unit records
Rules
- Never modify
.sf/sf.dbdirectly — use UOK APIs - Never trust
.sf/runtime/files as authoritative — they are projections - Always check
runControlandpermissionProfilebefore tool invocation - Journal events are best-effort; absence is a failure signal