Browse Source

Merge pull request #712 from mhenke/triage/preset-fallback-out-of-scope

docs: out-of-scope entry for preset fallback / preset-scoped mode
Mike Henke 3 weeks ago
parent
commit
4889dffb06
2 changed files with 58 additions and 0 deletions
  1. 28 0
      .out-of-scope/hashline.md
  2. 30 0
      .out-of-scope/preset-fallback.md

+ 28 - 0
.out-of-scope/hashline.md

@@ -0,0 +1,28 @@
+# Hashline (content-hash line anchors for LLM edits)
+
+This project does not implement hashline / content-hash line anchoring for LLM edits.
+
+## Why this is out of scope
+
+Hashline is a technique where each line returned by the `read` tool is prefixed
+with a short content-hash anchor (e.g. `9#KT:  console.log(...)`), and the LLM
+references edits by `LINE#HASH` anchor instead of quoting raw text. The system
+validates the hash before applying an edit, so if the file changed between read
+and edit the hash mismatches and the edit is rejected before it can corrupt
+anything. Hashes are context-based (`xxh32(prev + curr + next)` over a 16-char
+alphabet), so editing line N only invalidates N-1/N/N+1.
+
+Implementing it requires wrapping OpenCode's core `read` and `edit` tools to
+inject and validate anchors and track file snapshots for stale-anchor recovery.
+That is a deep, behavior-changing modification to the fundamental edit loop —
+fragile to bolt onto a slim plugin that intentionally avoids reimplementing tool
+plumbing. It belongs in OpenCode core itself or a dedicated standalone plugin,
+not in oh-my-opencode-slim.
+
+Token savings are real (reported ~61% fewer output tokens on Grok 4 Fast, ~8%
+better on Gemini), but the integration cost and architectural fit put it
+outside this project's scope.
+
+## Prior requests
+
+- #141 — "Discussion about hashline" (feature proposal / discussion; closed as wontfix)

+ 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"