geo/findings.brand-description-prompt.md

Findings: Brand Description Prompt Context

User Requirement

• The brand edit UI has a required 品牌描述 field.
• The current brand description should influence every generated article.
• Very long descriptions must not make prompts unbounded.
• Numeric/basic facts in a description must survive any compaction unchanged.

Screenshot Evidence

• Example brand: 辽宁木格创意家居有限公司.
• The description contains founding year, company positioning, location, production-area data, and production capabilities.

Research Findings

• brands.description is already required by BrandService and is submitted/displayed by the admin-web brand editor.
• Question-expansion code already loads brand name/website/description into a dedicated brand context, providing a local query pattern to reuse.
• Article generation does not expose an obvious shared brand_description prompt field in the initial search; each generation path currently needs tracing.
• BrandRequest normalizes description with whitespace trim and enforces non-empty input, but the inspected CRUD path has no generation-specific length budget.
• Brand identity is tenant-scoped and has name, optional website, and description; a small read-only prompt context can load these fields directly without coupling generation to the full CRUD response/cache.
• Queue-time snapshotting is preferable to worker-time-only lookup: it makes a queued generation reproducible if the brand description is edited before the worker runs.
• The persisted article-body paths are template, custom prompt-rule, imitation, and KOL generation.
• Failed article regeneration copies the previous generation task's input_params_json, so a brand-context snapshot on the original task is automatically stable across retries/regeneration.
• Template analyze/title/outline assists are separate LLM calls and require a separate scope decision; they do not persist article bodies directly.
• The LLM layer estimates prompt tokens for rate limiting but does not enforce an input-context budget for article prompts.
• Brand description is PostgreSQL TEXT; the brand editor, shell modal, and onboarding modal do not set maxlength, so descriptions are effectively unbounded from the generation perspective.
• Existing code has rune-safe truncation helpers, but blind head truncation would drop later numeric facts and is not suitable here.

Proposed Compaction Direction

• Short descriptions pass through verbatim.
• Long descriptions use deterministic extractive compaction rather than another LLM call: keep the opening identity sentence, sentences with numeric/date/contact facts, and high-value business/capability sentences, then restore source order within a hard rune budget.
• Extraction must not rewrite text, ensuring retained years, quantities, areas, certifications, and names remain byte-for-byte/rune-for-rune faithful.
• Snapshot the compacted context, original rune count, and compaction flag at queue time.
• Production read-only length distribution on 2026-07-10: 7 active descriptions, min 54, median 277, average 478, P90 1167.4, max 1195; none exceed 1200 or 2400 runes.
• Production prompt accounting currently estimates roughly one character per token and allows a large article output budget. A 2000-rune brand-description cap is material but bounded and preserves every current description verbatim.
• Brand description must be treated as the authoritative source for the focal brand's base facts. This matters because the current screenshot says 2019 while previously inspected RAG items contained both 2020 and 2019.
• The existing KnowledgeFactConstraint model and generate/repair/reject guard can protect facts extracted from the brand description too.
• Constraint merge order must be brand first, RAG second; equivalent conflicting RAG constraints must be discarded before validation.
• The existing generation payload helper file is the correct place for a structured __snapshot_brand_prompt_context key and JSON round-trip helpers.
• Existing prompt tests cover template generation only; custom, imitation, and KOL prompt placement need new focused coverage.
• Review follow-up: Chinese numeral detection must require a nearby unit/date marker; treating any 一/两 as numeric would over-prioritize ordinary prose.
• Review follow-up: oversized-segment splitting should track rune count incrementally rather than rebuild the builder string per rune.
• The existing fact-repair prompt wording should mention both brand-profile and knowledge-base canonical facts after constraint merging.
• Direct regression cases for Chinese numerals should distinguish factual counts/dates (二〇一九年, 两项, 三百户) from ordinary wording (一体化, 两全其美).
• Length review found a second growth channel: FactConstraints are extracted from the full description and rendered after the 2000-rune excerpt. They must be restricted to the focal brand and bounded fact kinds so unrelated company dates cannot bypass the prompt budget.
• Priority review found that enough numeric segments can outrank and evict the opening identity segment; opening retention needs an explicit invariant rather than a lower numeric weight.
• brands.name is database-bounded at 200 characters, but website and description are TEXT; prompt assembly needs its own field/section budgets.
• Brand descriptions often use generic self-reference (公司成立于..., 品牌创立于...) instead of repeating the legal name. Those facts should bind to the current brand, while an explicitly named different company must remain excluded.
• Template and imitation generation both resolve the current brand_id before task JSON is marshaled, so they can load and attach a brand snapshot without changing request DTOs.
• Custom prompt-rule and KOL enqueue paths likewise have tenant and brand IDs before task JSON serialization; all four can call one shared snapshot loader.
• Scheduled custom/KOL generation flows through the same enqueue functions, so no scheduler-specific brand-description branch is required.
• Prompt placement can remain consistent without appending after output rules:
  • Template: after request context, before knowledge and writing requirements.
  • Custom rule: after task supplements, before knowledge and output requirements.
  • Imitation: after imitation settings, before knowledge and source article.
  • KOL: after rendered task instructions, before knowledge context.
• Final scope is persisted article-body generation. Template analyze/title/outline assists remain separate non-body calls and were not changed.
• Final budgets are 200 runes for name, 320 for website, 2000 for the extractive description excerpt, 4 canonical fact constraints, and 4096 runes for the complete rendered brand section.

Security Note

• Brand descriptions are user-authored prompt data and must be delimited as reference context, not treated as instructions that can override system/output rules.