AppConfig at boot. Useful for syncing settings across machines, sharing a team setup, or pinning a known-good config to a repo.
Three ways to load
Presets resolve in this order — later wins:- Global —
~/.soulforge/config.json→presets[] - Project —
<cwd>/.soulforge/config.json→presets[] - CLI —
--plugin <spec>(stackable) orSOULFORGE_PRESETS=spec1,spec2
Spec formats
| Form | Example |
|---|---|
| Registry id | team/standard |
| Absolute path | /etc/forge/preset.json |
| Relative path | ./presets/local.json, ../shared.json |
| Home path | ~/forge/preset.json |
| URL | https://example.com/preset.json |
^(https?:\/\/|\.\/|\.\.\/|\/|~\/)|^[a-zA-Z0-9][a-zA-Z0-9._/-]{1,}$. Invalid specs are logged and skipped.
Wizard
Boot output
By default preset resolution is silent on success. Failures print one short line to stderr (one bad preset never blocks boot — fail-open). For full traces:ok or fail) with the resolved source.
How merging works
Presets are resolved to plainAppConfig patches, then merged on top of DEFAULT_CONFIG in load order. The diff against defaults becomes the presetOverlay — applied before loadConfig() returns, so every consumer sees the merged shape transparently.
Your ~/.soulforge/config.json is never rewritten. Removing the preset entry restores the prior behaviour on next launch.
Authoring
A preset is a JSON file (or registry-hosted JSON) with any subset ofAppConfig fields:
~/.soulforge/presets/<name>.json to make it discoverable, or host anywhere reachable by HTTPS.
Environment
| Variable | Purpose |
|---|---|
SOULFORGE_PRESETS | Comma-separated specs (set automatically by --plugin flags). |
See also
- Configuration — the AppConfig shape presets layer onto.
- Task router — the most-changed slot in shared presets.

