fix(prompts): name every type in suggest_entities, not just the JVM ones

[johnsonr]

The bug

suggest_entities.jinja rendered the list of permitted types with domainType.clazz.simpleName. clazz exists only on JvmType — a DynamicType has name/ownLabel and no clazz.

So every schema-declared type (in a configured world, most of them) rendered as an empty name directly under:

Entity types must only come from the following list:

    - : A calendar event surfaced as a signal — typically an upcoming meeting…
    - : An email thread surfaced when something in it warrants attention…

The model is then told "You must be sure that every entity is of one of the types above" and "Use the most specific domain type possible" against a list that names nothing. Jinjava logged one warning per type per chunk — 396 in one appliance's log:

WARN JinjavaTemplateRenderer : Template warning: Line 9: [clazz] Cannot resolve property 'clazz'
in 'DynamicType(name=calendar.meeting, description=A calendar event surfaced as a signal…'

A second, separate defect in the same file: context.directions (198 more warnings). SourceAnalysisContext has no directions — its fields are schema, entityResolver, contextId, knownEntities, relations, promptVariables, sourceLocator, perspective, mintNewEntities, mintedEntityProperties. It is a vestige of the field SourceAnalysisConfig carried in the predecessor project; the conditional has been permanently false, so that instruction never reached a prompt. (KnowledgeGraphBuilder's KDoc still promises the context holds "schema and directions for analysis".)

Together these were every template warning in that log.

The change

• domainType.clazz.simpleName → domainType.ownLabel, and the parents chain map(attribute='clazz') | map(attribute='simpleName') → map(attribute='ownLabel').

  ownLabel is the correct key in both directions: for a JvmType it is the simple name, so JVM types render byte-for-byte as before; and it is what extracted labels are matched against on the write side — DrivineNamedEntityDataRepository.save matches entity.labels() against dataDictionary.jvmTypes.map { it.ownLabel }.

• context.directions → directions. promptVariables are spread at the top level of the template model (LlmEntityExtractor: mapOf("context" to context, "chunk" to chunk) + context.promptVariables), so this renders whatever a caller supplied via withPromptVariables and stays silent otherwise — turning dead markup into a working extension point. Deleting the block outright is the alternative if you'd rather not keep it.

Tests

New SuggestEntitiesTemplateTest renders the template through JinjavaTemplateRenderer against a DynamicType schema and asserts the label, description and properties all appear, plus that directions render when supplied and are absent when not.

Verified it bites: reverted to the old template → both tests fail; restored → both pass. Existing PropositionExtractionTemplateTest (24 tests) still green.

Note

embabel-object-graph carries a copy of this template with the same clazz defect (plus propose_facts.jinja) — fixed there separately. Its directions reference is correct, because its SourceAnalysisConfig really does have that field; that is where this one was inherited from.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CdQPAxBM1m7CG645DKeMYa