custom-first-control-prompt

@wm-coders/dsh-custom-first-control-prompt

English | 中文

Deployment-configured prompt prefix. Ordered system-prompt sections render ahead of the deployment persona, and configured reference user/assistant exchanges are injected into every ordinary conversation request — as real alternating messages prepended on the request path (llm/stream interception, zero session-log writes). Static content renders byte-identically on every request, preserving prefix-cache reuse. Installation

After installation, restart the web app (dsh --profile web or run restart-web.ps1 / restart-web.sh).

To uninstall: Install / deployment / debugging obstacles and test methods: DEBUG-NOTES.zh.md (in Chinese; web fail-loud root causes, duplicate-id inserts, API verification chains — all paths scrubbed). One-command install: INSTALL.md. Full cross-machine walkthrough: INSTALL-FULL.zh.md (Chinese). Configuration Invalid configuration fails plugin load naming the offending entry: empty text, duplicate section names, or a non-finite order. Per-entry section problems (blank/duplicate name, bad order, empty text) and per-pair history problems (empty text, embedded reserved tags) degrade to skipping that entry with a warning instead of failing the plugin tree. Injection mechanism

The reference exchanges are built once at plugin activation into alternating real Message objects (deep-frozen, shared by reference across requests), then prepended onto every ordinary conversation request by an llm/stream waterfall listener: Clone and redispatch: loop-built requests are deep-frozen and marker-tagged (markAgentLoopRequest(deepFreeze(...))) and never mutated; the listener clones the request, prepends the seed messages, and redispatches through ctx.llm.stream. The clone carries no loop marker, the agent-loop log-reconstruction invariant does not apply to it, and the discarded original is a pure deriveMessages() projection. Zero log writes: seed messages live only on the request path — real turn numbering starts at 1 with no collisions, forks are ordinary copies, and compaction cannot shadow the reference history (every request re-injects it). Scope filtering: auxiliary calls (purpose-stamped, e.g. session-title, compaction) and hand-built requests (no sessionId) pass straight through; subagent-origin sessions are skipped by default (includeSubagents: true opts in). Panel verification: not seeing the seed messages in the chat transcript is expected; use the panel'

Verifying the injection works: in a fresh session ask a question only the injected history can answer (e.g. "repeat our earliest user message") — the model quoting the configured content proves it. session.history shows no seed messages (a clean log is a feature, not a failure).

Panel save semantics: the panel's config editor writes an id-targeted override into the profile cordis.patch.yml (never an insert, so it cannot collide with the bundle layer's row), updating only this plugin's core row (custom-first-control-prompt) and preserving everything else — other entries, comments, and legacy rows. While the profile patch carries no row, the editor shows the composed config (bundle-layer defaults); saving then creates the override. System sections

Each enabled entry registers via ctx.systemPrompt.section() at plugin load, so it participates in every assembly exactly like the factory sections: variable interpolation, scope shadowing, and the assembly waterfall all apply. Static configured text renders identically in every assembly, which is what keeps the request prefix reusable. Model experience Deployment system sections What the model sees

Configured section text renders at its configured order position — by default ahead of the persona — alongside the factory sections from dsh-system-prompt. Token impact

Every section repeats on every