@dreb/coding-agent 2.59.2 → 2.60.1

package/docs/mach6.md

@@ -77,9 +77,9 @@ Run a durable, explicit, round-aware review. It always posts two comments: an **
 /skill:mach6-review 53 tests
 ```
 
-Rounds 1–2 run the applicable code-reviewer, error-auditor, test-reviewer, completeness-checker, and simplifier together in phase one. The independent assessor then applies factual, scope, and practical gates. Practical assessment requires a credible actor, exact reachable trigger, concrete consequence, existing safeguards, and material value from fixing the problem; missing tests are not blockers without an important uncovered regression.
+Every round runs the applicable code-reviewer, error-auditor, test-reviewer, completeness-checker, and simplifier together in phase one. A specialist is retried rather than omitted if dispatch arbitration or the agent fails. In rounds 1–2, the independent assessor then applies factual, scope, and practical gates. Practical assessment requires a credible actor, exact reachable trigger, concrete consequence, existing safeguards, and material value from fixing the problem; missing tests are not blockers without an important uncovered regression.
 
-Round 3+ reviews only changes since the latest recorded reviewed SHA and verifies prior blockers. The four core specialists remain; simplifier runs only when explicitly requested. Phase two runs independent-assessor, developers-advocate, and devils-advocate in parallel. The developer's advocate attacks the practical value of proposed work; the devil's advocate attacks evidence that the original acceptance promises hold and supplements rather than replaces test-reviewer. A later-round item blocks merge only when the assessor and developer's advocate agree on material practical impact, with parent adjudication based on a concrete trigger-and-outcome sequence.
+Round 3+ continues to review the full PR and all interactions among its changes while using changes since the latest recorded reviewed SHA as supplemental context for verifying prior blockers and identifying new work. Reviews narrow only when the user explicitly requests a targeted scope. Phase two runs independent-assessor, developers-advocate, and devils-advocate in parallel. The developer's advocate attacks the practical value of proposed work; the devil's advocate attacks evidence that the original acceptance promises hold and supplements rather than replaces test-reviewer. A later-round item blocks merge only when the assessor and developer's advocate agree on material practical impact, with parent adjudication based on a concrete trigger-and-outcome sequence.
 
 See [Review Agents](#review-agents) below.
 
@@ -132,7 +132,7 @@ Phase one uses specialists with orthogonal incentives and confidence-scored cand
 | **error-auditor** | What can fail silently at runtime? | All applicable rounds |
 | **test-reviewer** | What important behavior lacks coverage? | All applicable rounds; never replaced |
 | **completeness-checker** | Does the PR fulfill authoritative scope? | All applicable rounds |
-| **simplifier** | Can changed code be clearer without behavior changes? | Rounds 1–2 in parallel; round 3+ only when requested |
+| **simplifier** | Can changed code be clearer without behavior changes? | Every round; retry on dispatch or agent failure |
 
 Phase two assessment agents:
 
@@ -150,7 +150,7 @@ The two advocates intentionally pull in different directions: one challenges the
 
 - **GitHub as shared memory** — Plans, reviews, assessments, and progress are posted as PR/issue comments with HTML markers (`<!-- mach6-plan -->`, `<!-- mach6-review -->`, etc.) so any future session can pick up context.
 - **Three-gate independent assessment** — Findings must be factual, authorized, and materially practical before becoming merge blockers.
-- **Deliberate counter-pressure** — Later rounds focus on the delta and pair practical-value skepticism with adversarial acceptance evidence to resist ceremonial review work.
+- **Deliberate counter-pressure** — Every round reviews the full PR; later-round deltas supplement that view for fix verification while practical-value skepticism and adversarial acceptance evidence resist ceremonial review work.
 - **Durable accountability checkpoint** — Implementation and fixes are committed, pushed, and recorded before formal review so work cannot be lost or repeatedly rewritten while still local.
 - **User-controlled review cycles** — Only the user starts each formal review or re-review. Agents stop at the checkpoint and suggest the next command rather than autonomously chaining review and fix cycles.
 - **Focused checks remain available** — One-off reviewer/checker subagents may answer narrow correctness questions without becoming a formal mach6 review cycle.

package/docs/models.md

@@ -81,7 +81,8 @@ Override defaults when you need specific values:
           "input": ["text"],
           "contextWindow": 128000,
           "maxTokens": 32000,
-          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }
+          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
+          "appendSystemPrompt": "Prefer solutions that fit this local model's context and tool capabilities."
         }
       ]
     }
@@ -89,7 +90,7 @@ Override defaults when you need specific values:
 }
 ```
 
-The file reloads each time you open `/model`. Edit during session; no restart needed.
+The file reloads each time you open `/model`. `/reload` also refreshes model-specific prompt metadata for the active model, so prompt edits do not require a restart.
 
 ## Supported APIs
 
@@ -202,11 +203,29 @@ Leave `authHeader` unset or `false` for endpoints that expect `x-api-key`.
 | `maxTokens` | No | `16384` | Maximum output tokens |
 | `cost` | No | all zeros | `{"input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0}` (per million tokens) |
 | `compat` | No | provider `compat` | OpenAI compatibility overrides. Merged with provider-level `compat` when both are set. |
+| `systemPrompt` | No | — | Replace dreb's built-in prompt whenever this exact custom model is active. Mutually exclusive with `appendSystemPrompt`. |
+| `appendSystemPrompt` | No | — | Preserve the selected base prompt and append model-specific instructions. Mutually exclusive with `systemPrompt`. |
 
 Current behavior:
 - `/model` and `--list-models` list entries by model `id`.
 - The configured `name` is used for model matching and detail/status text.
 
+A custom model can keep its behavioral prompt beside its transport and capability metadata:
+set exactly one of `systemPrompt` and `appendSystemPrompt` on that model object. Values must
+be non-empty strings. Model IDs may contain `/`; dreb retains the provider and complete model
+ID as an exact identity.
+
+The same behavior is also configurable through an exact `provider/model` entry under
+[`modelSettings`](settings.md#modelsettings) in `settings.json`. Configure prompt behavior for
+a canonical model in only one file. If both `models.json` and `settings.json` declare either
+prompt field for that model, dreb fails loudly instead of selecting a source.
+
+An explicit session replacement from `--system-prompt`, `SYSTEM.md`, or an SDK resource
+loader remains stronger than a model's `systemPrompt`. `appendSystemPrompt` follows the
+selected base and existing session append sources. Switching, cycling, or restoring a model
+rebuilds the prompt immediately; `/reload` picks up prompt edits and removals from either
+configuration file.
+
 ## Overriding Built-in Providers
 
 Route a built-in provider through a proxy without redefining models:
@@ -255,6 +274,7 @@ Use `modelOverrides` to customize specific built-in models without replacing the
       "modelOverrides": {
         "anthropic/claude-sonnet-4": {
           "name": "Claude Sonnet 4 (Bedrock Route)",
+          "appendSystemPrompt": "Use APIs and capabilities available through the Bedrock route.",
           "compat": {
             "openRouterRouting": {
               "only": ["amazon-bedrock"]
@@ -267,7 +287,11 @@ Use `modelOverrides` to customize specific built-in models without replacing the
 }
 ```
 
-`modelOverrides` supports these fields per model: `name`, `reasoning`, `input`, `cost` (partial), `contextWindow`, `maxTokens`, `headers`, `compat`.
+`modelOverrides` supports these fields per model: `name`, `reasoning`, `input`, `cost` (partial), `contextWindow`, `maxTokens`, `headers`, `compat`, `systemPrompt`, `appendSystemPrompt`.
+
+Prompt fields follow the same rules as custom model entries: choose replacement or append,
+not both; use a non-empty string; and do not also configure prompt behavior for the canonical
+provider/model in `settings.json`.
 
 Behavior notes:
 - `modelOverrides` are applied to built-in provider models.

package/docs/settings.md

@@ -21,7 +21,7 @@ Edit directly or use `/settings` for common options.
 | `hideThinkingBlock` | boolean | `false` | Hide thinking blocks in output |
 | `thinkingBudgets` | object | - | Custom token budgets per thinking level |
 | `agentModels.models` | object | - | Per-agent model fallback lists for subagents (map of agent name → ordered model IDs). See [agent-models.md](agent-models.md) |
-| `modelSettings` | object | - | Per-model overrides keyed by model ID (e.g. thinking display). See [modelSettings](#modelsettings) |
+| `modelSettings` | object | - | Per-model thinking-display and provider/model system-prompt overrides. See [modelSettings](#modelsettings) |
 
 #### agentModels.models
 
@@ -55,9 +55,12 @@ Configurable in the TUI via `/settings` → **Agent Models**. See [agent-models.
 
 #### modelSettings
 
-Per-model overrides keyed by model ID. Currently supports `thinkingDisplay`, which controls
-whether adaptive-thinking Claude models (Opus and Sonnet 4.6–4.x, plus Claude 5 families)
-return thinking summaries.
+`modelSettings` supports thinking-display preferences and persistent model-specific system
+prompts.
+
+`thinkingDisplay` remains keyed by bare model ID for compatibility. It controls whether
+adaptive-thinking Claude models (Opus and Sonnet 4.6–4.x, plus Claude 5 families) return
+thinking summaries:
 
 ```json
 {
@@ -73,12 +76,58 @@ return thinking summaries.
 
 Anthropic's API defaults Opus 4.7+ to `"omitted"`, so dreb sends `"summarized"` by default
 on adaptive models to keep thinking visible. Set `"omitted"` here to opt into the
-lower-latency behavior. The setting is **keyed by model ID**, so it is honored identically
-by the main session and by any subagent that uses the same model. Non-adaptive models
-ignore the setting.
+lower-latency behavior. The setting is honored identically by the main session and by any
+subagent that uses the same model. Non-adaptive models ignore it. It is configurable in the
+TUI via `/settings` → **Show thinking summaries** (shown only when the current model supports
+adaptive thinking).
+
+System-prompt settings require an exact canonical `provider/model` key. Use `systemPrompt`
+to replace dreb's built-in prompt, or `appendSystemPrompt` to preserve the selected base
+prompt and append model-specific instructions:
+
+```json
+{
+  "modelSettings": {
+    "openai-codex/gpt-5.6-sol": {
+      "appendSystemPrompt": "When implementing a mach6 plan, stop when the work is ready to commit and push."
+    },
+    "ollama/qwen2.5-coder:7b": {
+      "systemPrompt": "You are a coding assistant for this local model. Verify external facts against authoritative sources before answering."
+    }
+  }
+}
+```
 
-Configurable in the TUI via `/settings` → **Show thinking summaries** (shown only when the
-current model supports adaptive thinking).
+For a model defined or overridden in `~/.dreb/agent/models.json`, the same two fields may
+instead live directly on its custom `models[]` object or built-in `modelOverrides` object.
+This keeps a custom model and its behavior together. Do not use both surfaces for one
+canonical model: any prompt declaration in both files is rejected, even if both declarations
+use the same mode.
+
+Prompt behavior:
+
+- The key is matched as one exact string. Model IDs may themselves contain `/`, so
+  `openrouter/anthropic/claude-sonnet-4` means provider `openrouter` and model ID
+  `anthropic/claude-sonnet-4`.
+- Bare model-ID keys never apply prompt instructions; this prevents instructions from
+  leaking to another provider exposing the same ID.
+- Configure exactly one of `systemPrompt` and `appendSystemPrompt` for a canonical model.
+  Defining both, or using an empty/non-string value, fails loudly when dreb builds that
+  model's prompt.
+- An explicit session replacement from `--system-prompt`, `SYSTEM.md`, or an SDK resource
+  loader takes precedence over `systemPrompt`. `appendSystemPrompt` still appends after
+  existing session append sources such as `--append-system-prompt`, `APPEND_SYSTEM.md`, and
+  subagent-definition instructions.
+- Switching or cycling models rebuilds the prompt immediately: instructions from the old
+  model are removed and instructions for the new model are applied. `/reload` picks up
+  external prompt edits and removals from both `settings.json` and `models.json`.
+- Global and project entries follow the existing per-property merge. A project value wins
+  for the same field; a merged entry that supplies both prompt modes is rejected rather
+  than choosing one silently.
+- Built-in and custom models use the same exact identity. A `models.json` custom model or
+  built-in override can own the prompt directly; otherwise use its exact `provider/id` here.
+- A canonical model with prompt behavior in both files is invalid. There is no source
+  precedence between `models.json` and `settings.json`.
 
 ### UI & Display
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@dreb/coding-agent",
-	"version": "2.59.2",
+	"version": "2.60.1",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"drebConfig": {

package/skills/mach6-review/SKILL.md

@@ -26,7 +26,7 @@ Track prepare, phase-one review, findings comment, phase-two assessment, assessm
 
 Extract the required PR number and optional aspects: `code`, `errors`, `tests`, `completeness`, `simplify`.
 
-## Step 3: Prepare, determine the round, and establish the delta
+## Step 3: Prepare, determine the round, and establish the review context
 
 Before checkout, run `git status --porcelain`. If non-empty, stop and use `suggest_next` to offer `/skill:mach6-push`.
 
@@ -51,21 +51,23 @@ PRIOR_ROUNDS="$(printf '%s' "$PR_CONTEXT" | jq '[.comments[] | select(.body | st
 REVIEW_ROUND="$((PRIOR_ROUNDS + 1))"
 ```
 
-For round 3+, extract the most recent parseable full SHA after `Reviewed commit:` in the latest review comment. If found, use `git log <sha>..HEAD` and `git diff <sha>..HEAD`; this delta and its interactions are the review target. Also extract previous merge blockers and verify that each is fixed. Reject unchanged-code findings unless a delta change makes the issue newly reachable. If no legacy SHA is parseable, review the full PR diff but retain all round-3+ rules.
+Use `gh pr diff <pr-number>` in every round. The full PR and the interactions among all of its changes are the review target unless the user explicitly requests a narrower review.
 
-For rounds 1–2, use `gh pr diff <pr-number>`. Mark the PR ready only after all checks pass: `gh pr ready <pr-number>`.
+For round 3+, also extract the most recent parseable full SHA after `Reviewed commit:` in the latest review comment. If found, use `git log <sha>..HEAD` and `git diff <sha>..HEAD` as supplemental context for identifying new changes and verifying prior fixes, never as a replacement for the full PR diff. Extract previous merge blockers and verify that each is fixed. Do not reject a finding merely because the relevant lines are unchanged since the previous round.
+
+Mark the PR ready only after all checks pass: `gh pr ready <pr-number>`.
 
 ## Step 4: Phase one — specialist candidates
 
 Agent mapping: `code` → `code-reviewer`; `errors` → `error-auditor`; `tests` → `test-reviewer`; `completeness` → `completeness-checker`; `simplify` → `simplifier`.
 
-Without targeted aspects:
-- Rounds 1–2: run `code-reviewer`, applicable `error-auditor`, applicable `test-reviewer`, applicable `completeness-checker`, and `simplifier` together in one parallel `subagent` `tasks` call.
-- Round 3+: run the same four core specialists together on the delta. `test-reviewer` remains present when testable code changed. Skip `simplifier` unless `simplify` was explicitly requested.
+Without targeted aspects, run `code-reviewer`, applicable `error-auditor`, applicable `test-reviewer`, applicable `completeness-checker`, and `simplifier` together in one parallel `subagent` `tasks` call in every round. `test-reviewer` remains present whenever the PR contains testable code changes.
+
+With targeted aspects, run only mapped agents while still reviewing the full PR unless the user explicitly requests a narrower target.
 
-With targeted aspects, run only mapped agents, while preserving round-3+ delta constraints. Never run simplifier serially after the others.
+If dispatch arbitration or a specialist agent fails, retry that specialist. A retry may run separately after the original parallel batch; do not omit a required or requested specialist because its first attempt failed.
 
-Give every agent changed paths, full PR context, authoritative scope, actual files, and confidence scoring (0–100; report only candidates at least 80). In round 3+, explicitly provide the base SHA, delta, previous blockers, and unchanged-code rejection rule. Verify previous blockers independently even if no agent reports them.
+Give every agent changed paths, the full PR diff and context, authoritative scope, actual files, and confidence scoring (0–100; report only candidates at least 80). In round 3+, also provide the prior reviewed SHA, supplemental delta, and previous blockers so agents can verify fixes without narrowing the review target. Verify previous blockers independently even if no agent reports them.
 
 ## Step 5: Post unverified candidates
 
@@ -99,7 +101,7 @@ Post with a unique temp file and `gh pr comment <pr-number> --body-file "$GH_BOD
 
 ## Step 6: Phase two — assess with counter-pressure
 
-All assessors receive identical candidate findings, actual code, full PR/issue context, verbatim original quoted requests, acceptance criteria, approved scope changes, review round, and delta context.
+All assessors receive identical candidate findings, actual code, the full PR diff and PR/issue context, verbatim original quoted requests, acceptance criteria, approved scope changes, and the review round. For round 3+, also provide the latest delta as supplemental fix-verification context without narrowing assessment of the full PR.
 
 Apply three gates:
 1. **Factual:** current code contains the problem.