From f782eea23e85201f16552aa54f1623a17311f1ea Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 16 Aug 2026 20:16:51 +0000 Subject: [PATCH] docs: note that "Sort detections" was checked against the fallback trap Brief aside in the fallback-pool section: the pre-existing left-to-right sort option doesn't affect [CLASS=...]-tagged classes and only slightly stabilizes the untagged fallback pool, so the existing guidance stands. --- DETAILER_CLASS_PROMPTS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/DETAILER_CLASS_PROMPTS.md b/DETAILER_CLASS_PROMPTS.md index d9bd911d7..5debdae9a 100644 --- a/DETAILER_CLASS_PROMPTS.md +++ b/DETAILER_CLASS_PROMPTS.md @@ -54,6 +54,8 @@ If detections come back as `[pussy, face, nipple]` this run, the untagged lines **This is expected behavior, not a bug.** Any class you actually want to distinguish must get its own explicit `[CLASS=name]` tag. Reserve untagged lines for text you're fine applying to *any* leftover detection regardless of which class it is (e.g. a generic quality boost) — not for a second or third class-specific template. +(SD.Next's pre-existing "Sort detections" option, which orders detections left-to-right before assignment, was checked too — it has zero effect on `[CLASS=...]`-tagged classes and only slightly stabilizes this fallback-pool ordering, so it doesn't change the guidance above.) + ### What an untagged/unmatched detection gets If a detection's class has no matching tag **and** there's no fallback line at all, it gets an **empty string**, not the main generation prompt. The "fall back to the main prompt when the Detailer field is empty" rule only fires when the *entire* field is empty before parsing — once you've typed anything (even just one `[CLASS=...]` line), that whole-field check no longer applies. If you want untagged classes to inherit the main prompt, add an explicit fallback line containing the literal token `[PROMPT]` (already substituted before parsing):