feat(agent): curb concept/entity sprawl (strict entity types, name-length gate, pending buffer) #247

Problem

The concept/entity plan step (_CONCEPTS_PLAN_USER) creates a dedicated wiki page for almost
anything the LLM proposes on its very first mention — including document-own identifiers (a
ticket/case key, a page ID) and overly specific one-off names (e.g. "person name + their role in
this one case"). For ingest workloads with many short, similar documents (e.g. one Markdown file
per support ticket), this produces a large number of low-value entity/concept pages that are
never referenced again and don't represent generalizable knowledge.

Additionally, entity_types: (configurable per-KB vocabulary for the entity type field) is
currently only used to label entities, not to gate whether they get created at all: an entity
whose LLM-returned type doesn't match the configured list silently falls back to "other" instead
of being rejected.

Reproduction

Configure a KB with a narrow entity_types: list (e.g. business unit, role, IT system) and
run openkb add on short, structured documents that each center on a unique identifier (support
tickets, case records). Inspect wiki/entities/: pages appear for the ticket/case key itself and
for personal names combined with a case-specific detail, none of which fit the configured
entity_types and none of which are useful cross-document knowledge.

Context

• openkb --version: current main / fork integration (as of 2026-09-07)
• Affects both concept_update_mode values (rewrite and append)

Vorschlag (Skizze)

1. Make entity_types gate-able: add an opt-in strict_entity_types: false config key. When
   true, an entity whose type doesn't match the configured vocabulary is dropped instead of
   coerced to "other".
2. Add a hard, name-quality filter: reject any brand-new concept/entity name longer than 3 words
   (after splitting on -/_/whitespace) — a lightweight, deterministic proxy for "too specific
   to be reusable knowledge" (unique keys, hashes, ticket numbers, and multi-part combinations all
   tend to produce long names).
3. Soften first-mention creation: introduce a small pending buffer (.openkb/pending_topics.json)
   that collects up to two lightweight notes per new concept/entity candidate before a dedicated
   page is created on the third mention. This keeps genuinely-recurring topics while avoiding an
   instant page for something mentioned exactly once. Works for both concept_update_mode values
   (in "append" mode, promotion reuses the existing note-append writers with no extra LLM call).
4. Add soft prompt guidance (reuse-first framing, a concrete per-document "how many brand-new
   items" suggestion computed from the document's actual token count, and a name-generality rule)
   — non-enforced, complementary to (1)-(3).

Happy to open a PR implementing this.

_{This issue was drafted with the assistance of an AI assistant.}