DSH plugin rule set priority in DeepSeek Harness

Rule sets look like a convenience until two of them disagree and the bot follows the one nobody expected. A DSH plugin resolves that disagreement by scope, so understanding priority matters more than memorizing fields. The DSH Plugin Hub lists current entries, while the behavior below depends on the installed release.

Where dsh-purge rule sets come from in DeepSeek Harness

A rule set is a unit of intent, not a folder of unrelated switches.

It groups prompts and policies that are meant to travel together, which is why it can be applied or reverted as one decision. That grouping is what makes an experiment safe, because the previous state is a named set rather than a memory of several edits. The plugin entry for dsh-purge describes the fields, while the installed version defines which of them are actually honored.

Rule sets arrive from more than one place. Bundled defaults provide a fallback, global configuration supplies the team baseline, and a model binding or session override adds a narrower claim. Each source writes to a different scope, so the practical question is never which set is best in isolation. The question is which scope is active for this conversation and this model.

Keeping the number of sets small is a design choice with real consequences. Every additional set is another possible active state, and every rename is another chance to lose the mapping between intent and configuration. A readable name, a baseline set and a short note about what each set changes will save more time than any clever naming convention. Saving a set is also not the same as applying it, which is the first place a silent mismatch appears.

The priority order of a DSH plugin rule set

Specificity wins, and the narrowest scope is the current session.

A session override outranks a model binding, a model binding outranks global rules, and global rules outrank plugin defaults. This order is predictable when each scope is used for the purpose it was designed for. It becomes confusing when a broad scope is edited to fix a narrow symptom.

Priority does not mean that all four layers merge into one blended prompt. In most setups one effective set wins for a given session and model, and the others remain stored but inactive. That distinction matters during debugging, because editing a losing set produces no visible change no matter how correct the edit is. The apply state, not the file contents, tells you what the runtime is actually using.

There can be explicit exceptions in a particular plugin release, especially when a configuration flag changes precedence. Those exceptions should be read from the entry and the release notes rather than inferred from a single test. When documentation and observed behavior disagree, trust the behavior you can reproduce and record the version. A priority model is useful only if it predicts what the next session will do.

Session overrides inside the DeepSeek Harness plugin runtime

A session override is a temporary claim on behavior, and it should expire with the session.

It exists so a single conversation can test a rule without rewriting the baseline for everyone else. That makes it ideal for verification, incident response and comparing two prompts on the same input. It is a poor place to store a decision that the whole team should inherit.

A DeepSeek Harness plugin usually keeps the override attached to the conversation rather than to the model. The current session therefore behaves differently from a new one, which is exactly what surprises people. When a rule appears to work in one window and fail in another, the difference is often an override that was left behind. The fix is to close the test session or remove the override, not to edit the global set again.

Verification is straightforward when the scope is known. Reproduce the case in the overridden session, then open a fresh session and reproduce it again. If the results differ, the override is doing something, and the next question is whether that difference is still wanted. Removing it should restore the baseline without any other edit.

Binding a DSH plugins rule set to a model

Model binding prevents one prompt set from being judged against the wrong model.

Different models respond differently to the same instructions, so a set tuned for one may be misleading on another. Binding attaches the set to a model and lets unbound models fall back to global rules. That keeps comparisons honest, because the prompt and the model change together by design.

The common failure is assuming a switch re-applies everything. After changing models, the new model may need to load its binding before the rules take effect. A fresh session is the cheapest way to confirm which set is active, and it also removes cached conversation state from the test. If behavior still looks wrong, compare the binding and the apply state before rewriting the prompt.

Bindings should be recorded somewhere a human can read. A list of model names next to set names is enough, and it should be reviewed whenever a model is added or retired. Without that record, an unbound model silently inherits the global baseline and looks like it ignored its intended rules. The record also makes rollback possible when a binding turns out to be a mistake.

Resolving conflicts before they reach a DeepSeek Harness session

Most rule conflicts are scope conflicts wearing a content disguise.

The visible symptom is usually a rule that seems ignored, a behavior that changes after a model switch or a session that behaves unlike its neighbors. Before rewriting any prompt, identify which layer is active and whether the set was applied at all. The sequence below keeps that investigation from turning into random edits.

1. Identify the active layer for the current session and model.
2. Confirm the rule set was applied, not merely saved.
3. Compare timestamps to see which rule was written last.
4. Check whether a model binding redirects the set.
5. Reproduce the conflict in a fresh session with the same model.
6. Record the winning layer, then remove or narrow the losing rule.

The record from the last step is the part teams skip. Without it, the same conflict returns after the next model change and is diagnosed from scratch. A short note that names the scope, the set and the version is enough to prevent that repetition. Fewer sets and clearer scopes are the real fix, because a priority order only helps when the layers are used as intended.