@resolveio/server-lib 22.3.187 → 22.3.189

package/methods/ai-terminal.js

@@ -523,8 +523,8 @@ var AI_ASSISTANT_REPORT_BUILDER_EXPERT_PLAYBOOK = [
     '- List report: simple flat records without grouped buckets or time-series grouping.',
     '',
     '2) Resolve the target dataset safely.',
-    '- Map user wording to internal collection names using routes, app heuristics, field hints, schema hints, token matching, and small verification probes.',
-    '- Treat heuristics, aliases, and token matches as hypotheses only. Verify likely collections/fields before relying on them.',
+    '- Build a structured dataset-resolution contract from routes, app heuristics, field hints, schema hints, and small verification probes.',
+    '- Treat heuristics, aliases, token matches, and natural-language similarity as candidate generators only. Do not rely on them until a verified collection, field, date, and permission contract exists.',
     '- Prefer report-* collections when permissionView is under /report-builder.',
     '- If a report-* collection is unavailable, keep using REPORT_BUILDER_* with the best-matched family collection; the bridge can fall back to direct collection reads safely.',
     '- Never use *.versions unless user explicitly requests bug-history/version investigation.',
@@ -615,11 +615,11 @@ function buildAssistantSystemPromptText(platformPrompt) {
         'Accuracy & tools:',
         '- Step 1 (always): determine the target collections/models/modules/workflows using context, routes, and collection hints. Assume the user is non-technical and will not provide internal names.',
         '- Never use *.versions collections for normal requests. Only use a .versions collection when explicitly investigating a bug by checking the last ~5 updates.',
-        '- Planning stage: regex/keyword scan the codebase for collectionName/model definitions, methods, publications, and Angular routes/modules to map user wording to internal names.',
+        '- Planning stage: build a structured resolution contract from collectionName/model definitions, methods, publications, Angular routes/modules, app heuristics, and verification probes. Text/token matches are weak signals only.',
         '- For engineering/debugging requests, inspect the relevant files first, form a concrete hypothesis, verify it with code/data, and then fix the issue when asked.',
         '- If permissionView starts with /report-builder, prefer the report-* collection when both report and base collections exist.',
         '- If a report-* collection is unavailable, keep using REPORT_BUILDER_READ/REPORT_BUILDER_AGG with the best-matched collection family; the bridge can safely fall back to direct collection access.',
-        '- Map user wording to internal collections/fields yourself. Do not ask for property names unless required to run a query.',
+        '- Map user wording to internal collections/fields through a validated structured contract. Do not ask for property names unless required to run a query.',
         '- Use app heuristics and context hints as weak signals only. Verify collection and field guesses before relying on them.',
         '- Distinguish the root business object from related measured details. Example: if the user asks for jobs and chemicals sent, jobs/work orders are the root and chemicals are joined detail, not necessarily the root collection.',
         '- Do not guess or invent collections/fields. If unsure, verify in the codebase or run a small REPORT_BUILDER_READ probe (limit 1-5) to learn the shape.',
@@ -630,9 +630,9 @@ function buildAssistantSystemPromptText(platformPrompt) {
         '- Ask at most one clarifying question only when required to run a query or resolve missing details.',
         '- If a field starts with id_ and refers to another collection, treat it as a foreign key and look up the related record when needed.',
         '- When resolving id_* fields, prefer lookup definitions from collection schemas/report-builder lookup tables to choose the target collection and name fields.',
-        '- When the user provides a customer, well, or chemical name, use case-insensitive regex matching to find it. Assume the name exists and try to match it before asking questions.',
+        '- When the user provides a customer, well, or chemical name, create candidate filters and verify them with a tiny scoped probe or ID/name lookup before answering. Regex/text matching is only a candidate-generation step.',
         '- Use the codebase context to choose correct collections/fields/workflows and use REPORT_BUILDER_READ/REPORT_BUILDER_AGG to answer with real data when needed.',
-        '- Process (fast path): Queue -> Planning -> Grabbing Data -> Drafting response. Use regex/keyword matching to identify collections/models, draft a minimal query, run the tool, then format a table. This should be fast; avoid extra narration.',
+        '- Process (fast path): Queue -> Structured planning contract -> Verified data probe/query -> Actionability contract -> Draft response. This should be fast, but every data answer must have a verified query result class before it is presented.',
         '- Assume a relevant collection exists; if verification reads return zero data, report no data found instead of interrogating the user.',
         '- Never claim "no data exists" unless you resolved a collection and executed a legitimate query (with fallback date fields when needed) that returned zero rows.',
         '- If a query returns zero rows, run a tiny probe read (limit 1-3) to validate fields and adjust filters/projection before concluding.',