mirror of
https://github.com/hanzoai/insights.git
synced 2026-11-02 14:32:45 +00:00
zeekay
1b367e2b62
The tree was a debranded snapshot of upstream taken around 2026-02-20, and upstream has moved about five months since. This replaces it with upstream master, mechanically re-derived: bin/debrand does the rename, and the pipeline and squashed migrations are restored from the shipped tree. Not a merge. The previous import replaced the tree wholesale in a single commit, so there is no shared content history to merge against. Reproducing the rename on the new tree is what actually converges. What survives: .hanzo/workflows, the Dockerfiles and bin/docker* entrypoints, compose files, LLM.md, and insights/migrations. The squashed initial migration is load-bearing — the live database records it by name, so upstream's ~918 individual migrations cannot come back. Nine products are dropped as unreferenced. Twenty-one more that we do not run are kept anyway because the core app still imports them; unpicking those is a refactor and does not belong in a rebase. This base does not build yet, and the reasons are not in the rename: upstream now wants Python 3.13.13 against our 3.12.12 and Django 5.2 against our 4.2, and the dependency manifests still name upstream packages that we republish under our own names. Those are decisions, not renames.
91 lines
6.4 KiB
JSON
91 lines
6.4 KiB
JSON
{
|
|
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
|
"properties": {
|
|
"category": {
|
|
"description": "For MCP feedback (`feedback_type: \"mcp\"`) only: the single category that best describes the dominant theme. Pick \"missing_tool\" if a capability was absent, \"tool_description\" if the tool docs were unclear, \"tool_input_schema\" if input args were confusing, \"tool_output_format\" if the response was hard to consume, \"instructions_clarity\" if these MCP instructions were unclear, \"tool_correctness\" if a tool returned wrong data, \"error_message\" if an error was unhelpful, \"performance\" if latency was the issue. Omit for product, docs, or other feedback.",
|
|
"enum": [
|
|
"tool_correctness",
|
|
"tool_description",
|
|
"tool_input_schema",
|
|
"tool_output_format",
|
|
"missing_tool",
|
|
"instructions_clarity",
|
|
"performance",
|
|
"error_message",
|
|
"other"
|
|
],
|
|
"type": "string"
|
|
},
|
|
"details": {
|
|
"description": "Any additional context that doesn't fit the other fields. Keep it to clear, concise bullet points.",
|
|
"type": "string"
|
|
},
|
|
"feedback_type": {
|
|
"description": "What this feedback is about. \"product\" = any Insights product or feature (insights, session replay, feature flags, the data warehouse, web analytics, error tracking, etc.). \"mcp\" = this MCP server itself — a tool, its input schema, response format, an error, or these instructions. \"docs\" = Insights documentation. \"scout\" = a canonical Insights scout skill's content — reserved for scheduled scout runs reporting an improvement opportunity in their own Insights-authored skill (set `scout_skill_name`, `scout_skill_version`, and `scout_category`). \"other\" = anything that doesn't fit the above.",
|
|
"enum": ["product", "mcp", "docs", "scout", "other"],
|
|
"type": "string"
|
|
},
|
|
"friction_points": {
|
|
"description": "Clear, concise bullet points describing the friction — what was confusing, broken, slow, or missing. Quote the exact product surface, tool name, parameter, or error text where you can. Omit for purely positive feedback.",
|
|
"type": "string"
|
|
},
|
|
"product_area": {
|
|
"description": "The Insights product or area this is about, in free text (e.g. \"session replay\", \"insights\", \"data warehouse\", \"feature flags\", \"docs\"). Most useful for product feedback; for MCP feedback the tool name belongs in `details`/`friction_points` instead.",
|
|
"type": "string"
|
|
},
|
|
"scout_category": {
|
|
"description": "For scout feedback (`feedback_type: \"scout\"`) only: the single category that best describes the skill gap. \"false_positive\" = the skill's detection rules surfaced something that wasn't real; \"missed_detection\" = a real issue the skill's instructions steered you past; \"discriminator_gap\" = the skill's signal-vs-baseline discriminator doesn't hold for a class of projects; \"wasted_investigation\" = an investigation pattern the skill mandates burned budget without payoff; \"instruction_ambiguity\" = an instruction that is ambiguous in practice. Omit for non-scout feedback.",
|
|
"enum": [
|
|
"false_positive",
|
|
"missed_detection",
|
|
"discriminator_gap",
|
|
"wasted_investigation",
|
|
"instruction_ambiguity",
|
|
"other"
|
|
],
|
|
"type": "string"
|
|
},
|
|
"scout_skill_name": {
|
|
"description": "For scout feedback (`feedback_type: \"scout\"`) only: the canonical scout skill the feedback is about (e.g. \"signals-scout-web-analytics\"), exactly as named in the run identity. Required for scout feedback — without it the feedback cannot be aggregated per skill.",
|
|
"type": "string"
|
|
},
|
|
"scout_skill_version": {
|
|
"description": "For scout feedback (`feedback_type: \"scout\"`) only: the skill version the run executed (from the run identity). Feedback is only actionable against the version that produced it — the skill may have moved since.",
|
|
"maximum": 9007199254740991,
|
|
"minimum": -9007199254740991,
|
|
"type": "integer"
|
|
},
|
|
"sentiment": {
|
|
"description": "The overall tone. Use \"negative\" for something broken or blocking, \"mixed\" for mostly-fine-but-with-a-concrete-problem, \"neutral\" for a suggestion or feature request with no strong sentiment, and \"positive\" for praise or something that worked well. All sentiments are welcome — positive feedback is encouraged, not just problems.",
|
|
"enum": ["positive", "neutral", "negative", "mixed"],
|
|
"type": "string"
|
|
},
|
|
"suggested_improvement": {
|
|
"description": "The single most impactful, concrete change that would address this feedback, if you can name one (e.g. \"add a `filters` example to query-funnel's description\", or \"let the replay scrubber snap to the nearest event\"). Optional — praise or an observation doesn't need one.",
|
|
"type": "string"
|
|
},
|
|
"summary": {
|
|
"description": "A one-sentence headline capturing the feedback (e.g. \"session replay scrubber jumps backwards when you click the timeline\", \"query-trends descriptions made it hard to choose between trends and funnels\", or \"the new SQL editor autocomplete is excellent\").",
|
|
"minLength": 1,
|
|
"type": "string"
|
|
},
|
|
"task_completed": {
|
|
"description": "Were you able to complete the user's task? Be honest — \"false\" is just as useful as \"true\". Most relevant when `feedback_type` is \"mcp\".",
|
|
"type": "boolean"
|
|
},
|
|
"tools_used": {
|
|
"description": "The MCP tool names you called while working on the user's task (e.g. [\"read-data-schema\", \"query-trends\"]). Helps us correlate feedback to specific tools.",
|
|
"items": {
|
|
"type": "string"
|
|
},
|
|
"type": "array"
|
|
},
|
|
"user_request": {
|
|
"description": "A short, anonymised paraphrase of what the user originally asked you to do. Do not include PII, customer names, or sensitive query content.",
|
|
"type": "string"
|
|
}
|
|
},
|
|
"required": ["summary", "feedback_type", "sentiment"],
|
|
"type": "object"
|
|
}
|