reasoning: use structured semantic fidelity contract

lib/graph/prompt-builder.js

@@ -1,5 +1,7 @@
 import {
   ConfidenceLevel,
+  answerResolutionGuidance,
+  answerSupportCategory,
   SituationKind,
   SituationRelationship,
   SituationStatus,
@@ -33,6 +35,8 @@ export function buildGraphUpdatePrompt({
   const nodeStatuses = formatEnumValues(SituationStatus);
   const edgeRelationships = formatEnumValues(SituationRelationship);
   const confidenceLevels = formatEnumValues(ConfidenceLevel);
+  const supportCategories = formatEnumValues(answerSupportCategory);
+  const resolutionGuidanceValues = formatEnumValues(answerResolutionGuidance);
 
   return `You are proposing a graph update for Confidence Engine ${promptVersion}.
 
@@ -60,6 +64,12 @@ ${edgeRelationships}
 ## Allowed Confidence Values
 ${confidenceLevels}
 
+## Allowed answerMeaning.supportCategory Values
+${supportCategories}
+
+## Allowed answerMeaning.resolutionGuidance Values
+${resolutionGuidanceValues}
+
 ## Required JSON Field Names
 The JSON object must contain exactly these top-level fields:
 - addedNodes
@@ -116,10 +126,11 @@ The JSON object must contain exactly these top-level fields:
 25. Do not replace the whole graph, and do not restate unchanged graph content inside the proposal.
 26. answerMeaning.userSupportedMeaning must state only what the user's answer directly supports.
 27. Put any stronger interpretation in answerMeaning.possibleInference, not in userSupportedMeaning.
-28. supportCategory and resolutionGuidance are optional descriptive hints only; if you are unsure of the exact wording, leave them null rather than inventing rigid category labels.
+28. When answerMeaning is present, populate supportCategory with one of the allowed values whenever the user's meaning fits an existing category. Use other when none of the protected categories applies. Do not leave supportCategory null merely because the wording is uncertain.
 29. If the answer is conditional or qualified, preserve that qualification explicitly in userSupportedMeaning.
 30. If the answer says the user is unsure or does not resolve the distinction, state that uncertainty directly in userSupportedMeaning.
 31. If the answer explicitly states a hard constraint, state that directly in userSupportedMeaning.
+32. Populate resolutionGuidance when the user's meaning genuinely implies must_remain_unresolved, may_resolve, or must_resolve. Keep it null only when no existing resolution state actually applies.
 
 ## Additional Guidance
 - If the answer only clarifies an existing unknown, prefer updatedNodes and resolvedUnknownNodeIds over creating duplicate nodes.
@@ -132,6 +143,8 @@ The JSON object must contain exactly these top-level fields:
 - If rule #6 does not apply (the answer contains no user-supported meaning that requires graph progress) and there is no other justification for change, return empty arrays for every category.
 - If rule #6 applies but you choose an update/refinement of existing structure, resolve an existing unknown, or add justified new structure, your structural proposal plus answerMeaning together represent the complete response — answerMeaning preserves semantic fidelity while structural mutation handles graph progress; neither replaces the other.
 - If you add a new unknown with addedNodes, connect it with at least one addedEdge to an existing updated/resolved node or to a newly added non-unknown node from the answer.
+- For answerMeaning.supportCategory, use only these exact values: ${supportCategories}. Use other when none of the protected categories applies.
+- For answerMeaning.resolutionGuidance, use only these exact values: ${resolutionGuidanceValues}. Keep it null only when none of those existing resolution states genuinely applies.
 
 ## Example Constraint Reminder
 ${formatExampleAnswerBlock()}