afv-library/skills/investigating-agentforce-d360/assets/dc/gateway_responses.sql

44 lines
1.7 KiB
MySQL
Raw Normal View History

@W-22707610 feat: add investigating-agentforce-d360 skill Data Cloud 360° view of a single Agentforce session — DC-only, zero Splunk dependency. Pulls 24 STDM + GenAI DMOs via the Data Cloud Query REST API, assembles a hierarchical session tree (Interaction → Step → Generation → GatewayRequest), and renders a human-readable markdown summary with transcript + per-turn topic/action invocations + LLM generations + tool calls + audit chain. Migrated as a standalone Apache-2.0 skill from an internal hub plugin — self-contained, no sibling-skill or plugin dependencies. What this skill answers: - "Trace session <uuid>" / "Summarize what happened in <0Mw…>" - "Find escalated sessions today on Messaging in <org>" - Session discovery by time / agent / channel / outcome / conversation text when the user has no session id What it does NOT answer (use a different surface): - Design-time architecture — use investigating-agentforce-architecture - Runtime planner availability — DC alone can't tell you which topic/action was eligible for the classifier on a given turn Skill layout: - 8 Python pipeline modules (fetch_dc, assemble_dc, render_dc, discover_sessions, resolve_session, dc, storage, config) - 4 _shared helpers (paths, fs_guard, sql, __init__) with skill-scoped DATA_ROOT (~/.claude/data/investigating-agentforce-d360/) - 26 SQL templates under assets/dc/ - 27 test files (367 tests + 18 subtests, 100% passing) - 3 reference docs (artifacts.md, dc_dmo_fields.md, dc_pipeline_contract.md) - SKILL.md (sf-skills frontmatter, license: Apache-2.0, metadata.version: "1.0") - README.md (external-facing quick-start) - tools/grant_allowlist.py (idempotent first-run permission grant) - tools/archive_data_dir.sh (opt-in stop-hook tarballer) Quality gates: - pytest scripts/tests/: 367 passed + 18 subtests, 0 failures - npm run validate:skills: 62 of 62 skill(s) checked, 0 errors - Live end-to-end runs against 3 real Salesforce sessions exercising both the full-tree and STDM-lag gateway-direct render branches - 4 independent code-review rounds (correctness, security, markdown, architecture-critic) — all findings addressed Customer-data hygiene: no live tenant ids, no internal sprint markers, no hub/sibling-skill references. Synthetic fixtures look obviously synthetic (`019dface-…` UUIDs, `0MwTESTMSG…` MessagingSession ids, `00DTESTORG…` org ids, `MyAgent` placeholder agent name). Sibling skill: investigating-agentforce-architecture (PR #278) — same migration pattern, design-time metadata; complementary scope.
2026-05-28 18:57:52 +08:00
-- Gateway responses — one row per LLM call response at the GenAI Gateway.
-- DMO: GenAIGatewayResponse__dlm
--
-- Placeholders (substituted by scripts/dc.py.load_sql):
-- WHERE_CLAUSE — the filter expression, no "WHERE" keyword
-- ORDER_BY — full "ORDER BY <col>" or empty string
--
-- FK shape (small table; documented for reference only):
-- generationRequestId__c = GatewayRequest.gatewayRequestId__c
-- generationResponseId__c = Step.ssot__GenAiGatewayResponseId__c
-- = Generation.generationResponseId__c
--
-- Forward join path from a session:
-- Session → GatewayRequest (sessionId__c LIKE)
-- → GatewayResponse (generationRequestId__c IN {gw_req_ids})
-- This is the canonical and only supported direction. 1:1 invariant holds
-- in live data — every GatewayRequest for a session produces one Response
-- row (modulo in-flight calls at fetch time).
--
-- NOTE: No `ssot__` prefix — fields end in `__c` directly.
SELECT
generationResponseId__c,
generationRequestId__c,
parameters__c,
timestamp__c,
orgId__c,
cloud__c
FROM GenAIGatewayResponse__dlm
WHERE {{WHERE_CLAUSE}}
{{ORDER_BY}};
-- ============================================================================
-- EXAMPLE WHERE clauses (pass via where_clause=)
-- ============================================================================
-- Forward: Responses for the session's gateway requests (primary use case)
-- WHERE → generationRequestId__c IN ('<req_id1>','<req_id2>',...)
-- ORDER BY → ORDER BY timestamp__c
-- Ad-hoc lookup by specific response ids (not used by the waterfall)
-- WHERE → generationResponseId__c IN ('<resp_id1>','<resp_id2>',...)