Browse Source

docs: add out-of-scope entry for preset fallback / preset-scoped mode

Records the maintainer's wontfix decision on #638 so future identical
requests can be deduplicated during triage.
Michael Henke 4 weeks ago
parent
commit
95dbe58656
1 changed files with 30 additions and 0 deletions
  1. 30 0
      .out-of-scope/preset-fallback.md

+ 30 - 0
.out-of-scope/preset-fallback.md

@@ -0,0 +1,30 @@
+# Preset Fallback & Preset-Scoped Mode
+
+This project does not support preset-to-preset fallback or preset-scoped mode.
+
+## Why this is out of scope
+
+Model-level fallback already exists in the plugin: when an agent's `model` is
+configured as an array, the entries form a fallback chain resolved at runtime by
+`ForegroundFallbackManager` (abort the failed session, re-prompt with the next
+untried model). Subagents not listed in the active preset also inherit the
+preset's primary model. So the runtime "if my model is unavailable, try another"
+surface is already covered.
+
+What was requested goes further and is a different shape:
+
+- **Preset-to-preset fallback** — a preset declaring it falls back to another
+  preset (e.g. `PresetSchema` gaining a `fallback`/`extends` field). This needs
+  schema changes plus resolution wiring in the preset manager and config hook,
+  and raises questions about which agents/settings the fallback preset supplies.
+- **Preset-scoped mode** — restricting a preset to certain agents, directories,
+  tasks, or conversation modes (a `scope` field on `PresetSchema`). This is a
+  meaningful design surface with no current implementation (zero matches in the
+  codebase) and no agreed semantics.
+
+The maintainer chose not to take on that design/implementation as `wontfix`
+(issue #638). If the need recurs with a concrete design, revisit.
+
+## Prior requests
+
+- #638 — "Support preset fallback and document preset-scoped mode"