@oqtopus-team/pi-qdash 0.1.6 → 0.1.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/extensions/qdash.ts +2 -0
- package/extensions/tools/task-knowledge.ts +144 -0
- package/package.json +1 -1
- package/skills/qdash/SKILL.md +38 -46
- package/skills/qdash-calibration-agent/SKILL.md +9 -52
- package/skills/qdash-timeseries-diagnosis/SKILL.md +2 -0
- package/skills/qdash-two-qubit-calibration-diagnosis/SKILL.md +4 -61
package/README.md
CHANGED
|
@@ -16,7 +16,7 @@ It uses [`@oqtopus-team/qdash-client`](https://www.npmjs.com/package/@oqtopus-te
|
|
|
16
16
|
|
|
17
17
|
## Key Features
|
|
18
18
|
|
|
19
|
-
- **Read-only investigation**: dedicated tools to inspect chips, qubits, couplings, calibration task results, executions, issues, and Forum posts. Secrets are redacted from tool output.
|
|
19
|
+
- **Read-only investigation**: dedicated tools to inspect chips, qubits, couplings, calibration task results, task knowledge (`qdash_get_task_knowledge`), executions, issues, and Forum posts. Secrets are redacted from tool output.
|
|
20
20
|
- **Dashboards and insights**: compact dashboards, triage overviews, target-level incident reports, degradation reports, and wiring insights.
|
|
21
21
|
- **Agent calibration workflow**: create agent sessions, submit and track agent actions, and commit/apply calibration candidates. Write operations are approval-gated.
|
|
22
22
|
- **Figures**: fetch calibration PNG/JSON figures and render them in the interactive TUI.
|
package/extensions/qdash.ts
CHANGED
|
@@ -25,6 +25,7 @@ import { toTextToolResult, toToolResult } from "./lib/results.js";
|
|
|
25
25
|
import { ansi, boxLinesToWidth, boxed, formatNumber, textComponent } from "./lib/render.js";
|
|
26
26
|
import { plotSeriesLines, timeseriesPlotComponent, timeseriesPoints } from "./lib/timeseries-plot.js";
|
|
27
27
|
import { installQDashWriteGate } from "./lib/write-gate.js";
|
|
28
|
+
import { registerTaskKnowledgeTool } from "./tools/task-knowledge.js";
|
|
28
29
|
import { registerTimeseriesComparisonTool } from "./tools/timeseries.js";
|
|
29
30
|
import { analyzeWiringMarkdown, wiringInsightLines, type WiringInsights } from "./lib/wiring-analysis.js";
|
|
30
31
|
|
|
@@ -1530,6 +1531,7 @@ async function executeQuery(params: QDashQueryParams) {
|
|
|
1530
1531
|
|
|
1531
1532
|
export default function qdashExtension(pi: ExtensionAPI) {
|
|
1532
1533
|
installQDashWriteGate(pi);
|
|
1534
|
+
registerTaskKnowledgeTool(pi, { makeClient });
|
|
1533
1535
|
|
|
1534
1536
|
pi.registerTool({
|
|
1535
1537
|
name: "qdash_config_info",
|
|
@@ -0,0 +1,144 @@
|
|
|
1
|
+
import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
|
|
2
|
+
import type { QDashClient } from "@oqtopus-team/qdash-client";
|
|
3
|
+
import { Type } from "typebox";
|
|
4
|
+
|
|
5
|
+
import { toTextToolResult } from "../lib/results.js";
|
|
6
|
+
|
|
7
|
+
type TaskKnowledgeParams = {
|
|
8
|
+
profile?: string;
|
|
9
|
+
configPath?: string;
|
|
10
|
+
useEnv?: boolean;
|
|
11
|
+
taskName: string;
|
|
12
|
+
format?: "markdown" | "summary";
|
|
13
|
+
};
|
|
14
|
+
|
|
15
|
+
type TaskKnowledge = {
|
|
16
|
+
name: string;
|
|
17
|
+
summary?: string;
|
|
18
|
+
what_it_measures?: string;
|
|
19
|
+
expected_result?: Record<string, unknown>;
|
|
20
|
+
failure_modes?: Array<Record<string, unknown>>;
|
|
21
|
+
check_questions?: string[];
|
|
22
|
+
};
|
|
23
|
+
|
|
24
|
+
type TaskKnowledgeList = { items?: Array<{ name?: string }> } | Array<{ name?: string }>;
|
|
25
|
+
|
|
26
|
+
export type TaskKnowledgeDependencies = {
|
|
27
|
+
makeClient(params: TaskKnowledgeParams): Promise<QDashClient>;
|
|
28
|
+
};
|
|
29
|
+
|
|
30
|
+
function text(value: unknown): string | undefined {
|
|
31
|
+
if (typeof value !== "string") return undefined;
|
|
32
|
+
const trimmed = value.trim();
|
|
33
|
+
return trimmed || undefined;
|
|
34
|
+
}
|
|
35
|
+
|
|
36
|
+
function bulletLines(items: string[]): string[] {
|
|
37
|
+
return items.length ? items.map((item) => `- ${item}`) : ["- Not documented."];
|
|
38
|
+
}
|
|
39
|
+
|
|
40
|
+
export function taskKnowledgeSummary(knowledge: TaskKnowledge): string {
|
|
41
|
+
const expected = knowledge.expected_result ?? {};
|
|
42
|
+
const expectedLines = [
|
|
43
|
+
text(expected.description),
|
|
44
|
+
text(expected.good_visual) && `Good visual: ${text(expected.good_visual)}`,
|
|
45
|
+
text(expected.typical_range) && `Typical range: ${text(expected.typical_range)}`,
|
|
46
|
+
].filter((value): value is string => Boolean(value));
|
|
47
|
+
const failureLines = (knowledge.failure_modes ?? []).map((mode) => {
|
|
48
|
+
const description = text(mode.description) ?? "Unspecified failure mode";
|
|
49
|
+
const cause = text(mode.cause);
|
|
50
|
+
const nextAction = text(mode.next_action);
|
|
51
|
+
return [description, cause && `Cause: ${cause}`, nextAction && `Next: ${nextAction}`].filter(Boolean).join(" — ");
|
|
52
|
+
});
|
|
53
|
+
|
|
54
|
+
return [
|
|
55
|
+
`# ${knowledge.name}`,
|
|
56
|
+
"",
|
|
57
|
+
...(text(knowledge.summary) ? [text(knowledge.summary)!, ""] : []),
|
|
58
|
+
"## What it measures",
|
|
59
|
+
"",
|
|
60
|
+
text(knowledge.what_it_measures) ?? "Not documented.",
|
|
61
|
+
"",
|
|
62
|
+
"## Expected result",
|
|
63
|
+
"",
|
|
64
|
+
...bulletLines(expectedLines),
|
|
65
|
+
"",
|
|
66
|
+
"## Failure modes",
|
|
67
|
+
"",
|
|
68
|
+
...bulletLines(failureLines),
|
|
69
|
+
"",
|
|
70
|
+
"## Check questions",
|
|
71
|
+
"",
|
|
72
|
+
...bulletLines((knowledge.check_questions ?? []).filter((item) => Boolean(text(item)))),
|
|
73
|
+
].join("\n");
|
|
74
|
+
}
|
|
75
|
+
|
|
76
|
+
function knownNames(payload: TaskKnowledgeList): string[] {
|
|
77
|
+
const items = Array.isArray(payload) ? payload : payload.items ?? [];
|
|
78
|
+
return items.map((item) => text(item.name)).filter((name): name is string => Boolean(name));
|
|
79
|
+
}
|
|
80
|
+
|
|
81
|
+
export function similarTaskNames(taskName: string, names: string[], limit = 5): string[] {
|
|
82
|
+
const needle = taskName.toLowerCase();
|
|
83
|
+
return names
|
|
84
|
+
.filter((name) => {
|
|
85
|
+
const candidate = name.toLowerCase();
|
|
86
|
+
return candidate.startsWith(needle) || needle.startsWith(candidate) || candidate.includes(needle) || needle.includes(candidate);
|
|
87
|
+
})
|
|
88
|
+
.sort((a, b) => {
|
|
89
|
+
const aPrefix = a.toLowerCase().startsWith(needle) ? 0 : 1;
|
|
90
|
+
const bPrefix = b.toLowerCase().startsWith(needle) ? 0 : 1;
|
|
91
|
+
return aPrefix - bPrefix || a.length - b.length || a.localeCompare(b);
|
|
92
|
+
})
|
|
93
|
+
.slice(0, limit);
|
|
94
|
+
}
|
|
95
|
+
|
|
96
|
+
function notFound(error: unknown): boolean {
|
|
97
|
+
if (!error || typeof error !== "object") return false;
|
|
98
|
+
const value = error as { status?: unknown; statusCode?: unknown; response?: { status?: unknown }; message?: unknown };
|
|
99
|
+
return value.status === 404 || value.statusCode === 404 || value.response?.status === 404 || /\b404\b|not found/i.test(String(value.message ?? ""));
|
|
100
|
+
}
|
|
101
|
+
|
|
102
|
+
export function registerTaskKnowledgeTool(pi: Pick<ExtensionAPI, "registerTool">, deps: TaskKnowledgeDependencies): void {
|
|
103
|
+
pi.registerTool({
|
|
104
|
+
name: "qdash_get_task_knowledge",
|
|
105
|
+
label: "QDash Task Knowledge",
|
|
106
|
+
description: "Get task knowledge when asked how to interpret a result, what curve or outcome is expected, which failure modes apply, or what to try next.",
|
|
107
|
+
promptSnippet: "Read QDash task knowledge before interpreting calibration results",
|
|
108
|
+
promptGuidelines: [
|
|
109
|
+
"Use qdash_get_task_knowledge before interpreting task-specific physics, expected curves, failure modes, or next diagnostic checks.",
|
|
110
|
+
"This tool is read-only and does not execute tasks or change parameters.",
|
|
111
|
+
],
|
|
112
|
+
parameters: Type.Object({
|
|
113
|
+
profile: Type.Optional(Type.String({ description: "QDash profile name. Defaults to env when QDASH_BASE_URL is set, otherwise 'default'." })),
|
|
114
|
+
configPath: Type.Optional(Type.String({ description: "Optional path to qdash config.ini." })),
|
|
115
|
+
useEnv: Type.Optional(Type.Boolean({ description: "Force QDASH_* environment variables instead of a profile." })),
|
|
116
|
+
taskName: Type.String({ description: "QDash task name, for example CheckRabi." }),
|
|
117
|
+
format: Type.Optional(Type.Union([Type.Literal("markdown"), Type.Literal("summary")], { description: "Output format. Defaults to markdown." })),
|
|
118
|
+
}),
|
|
119
|
+
async execute(_toolCallId, params: TaskKnowledgeParams) {
|
|
120
|
+
const client = await deps.makeClient(params);
|
|
121
|
+
const format = params.format ?? "markdown";
|
|
122
|
+
try {
|
|
123
|
+
const data = format === "summary"
|
|
124
|
+
? await client.getTaskKnowledge(params.taskName) as unknown as TaskKnowledge
|
|
125
|
+
: await client.getTaskKnowledgeMarkdown(params.taskName);
|
|
126
|
+
const markdown = format === "summary"
|
|
127
|
+
? taskKnowledgeSummary(data as TaskKnowledge)
|
|
128
|
+
: typeof data === "string"
|
|
129
|
+
? data
|
|
130
|
+
: text((data as { markdown?: unknown })?.markdown) ?? JSON.stringify(data, null, 2);
|
|
131
|
+
return toTextToolResult(markdown, data, { taskName: params.taskName, format, found: true });
|
|
132
|
+
} catch (error) {
|
|
133
|
+
if (!notFound(error)) throw error;
|
|
134
|
+
const listed = await client.listTaskKnowledge() as TaskKnowledgeList;
|
|
135
|
+
const suggestions = similarTaskNames(params.taskName, knownNames(listed));
|
|
136
|
+
const markdown = [
|
|
137
|
+
`No task knowledge found for \`${params.taskName}\`.`,
|
|
138
|
+
...(suggestions.length ? ["", "Similar known task names:", ...suggestions.map((name) => `- \`${name}\``)] : ["", "No similar known task names were found."]),
|
|
139
|
+
].join("\n");
|
|
140
|
+
return toTextToolResult(markdown, { taskName: params.taskName, found: false, suggestions }, { taskName: params.taskName, format, found: false });
|
|
141
|
+
}
|
|
142
|
+
},
|
|
143
|
+
});
|
|
144
|
+
}
|
package/package.json
CHANGED
package/skills/qdash/SKILL.md
CHANGED
|
@@ -3,61 +3,53 @@ name: qdash
|
|
|
3
3
|
description: Query a running QDash instance from pi via the pi-qdash extension and @oqtopus-team/qdash-client. Use when inspecting chips, metrics, task results, tasks, projects, files, flows, executions, forum posts, provenance, or QDash profile/configuration.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
<!-- Confirmation gates are implemented by the host harness. Skills should state that a gate exists, not instruct how or when to ask for confirmation. -->
|
|
7
|
+
|
|
6
8
|
# QDash
|
|
7
9
|
|
|
8
10
|
Use the pi-qdash tools instead of scraping the UI or hand-writing auth headers.
|
|
9
11
|
|
|
10
12
|
## Preferred tools
|
|
11
13
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
- `
|
|
16
|
-
- `
|
|
17
|
-
- `
|
|
18
|
-
- `
|
|
19
|
-
- `
|
|
20
|
-
- `
|
|
21
|
-
- `
|
|
22
|
-
- `
|
|
23
|
-
- `
|
|
24
|
-
- `
|
|
25
|
-
- `
|
|
26
|
-
- `
|
|
27
|
-
- `
|
|
28
|
-
|
|
29
|
-
- `
|
|
30
|
-
|
|
31
|
-
- `qdash_dashboard`
|
|
32
|
-
- `
|
|
33
|
-
- `qdash_recent_calibration_summary`
|
|
34
|
-
- `
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
- `
|
|
38
|
-
- `
|
|
39
|
-
- `
|
|
40
|
-
- `
|
|
41
|
-
|
|
42
|
-
- `
|
|
43
|
-
- `
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
- `chips`, `default_chip`, `metrics_config`, `chip_metrics`
|
|
47
|
-
- `chip_qubits`, `chip_qubit`, `chip_couplings`, `chip_coupling`
|
|
48
|
-
- `cryostats`, `cryostat`, `cooldowns`, `cooldown`, `cooldown_wiring_events`
|
|
49
|
-
- `timeseries`, `task_results`, `task_result`, `task_note`, `task_result_issues`
|
|
50
|
-
- `qubit_latest`, `qubit_history`, `coupling_latest`, `coupling_history`
|
|
51
|
-
- `tasks`, `task_knowledge`, `task_knowledge_markdown`
|
|
52
|
-
- `projects`, `project`, `files_tree`, `file_content`, `git_status`
|
|
53
|
-
- `issues`, `issue_knowledge`
|
|
54
|
-
- `flows`, `flow`, `flow_templates`, `flow_template`, `flow_helper_files`, `flow_helper_file`
|
|
55
|
-
- `executions`, `execution`, `ai_reviews`, `ai_review_runs`, `ai_review_run`
|
|
56
|
-
- `forum_posts`, `provenance_stats`, `provenance_history`, `provenance_changes`, `provenance_lineage`, `provenance_impact`
|
|
57
|
-
6. `qdash_raw_get` — read-only GET endpoints not covered by `qdash_query`.
|
|
14
|
+
Prefer the dedicated tool that matches the question. Use `qdash_query` only as a fallback when no dedicated tool covers the read-only operation.
|
|
15
|
+
|
|
16
|
+
1. Dedicated read-only tools:
|
|
17
|
+
- `qdash_list_chips`, `qdash_get_default_chip` — list chips or resolve the active chip
|
|
18
|
+
- `qdash_get_chip_metrics`, `qdash_list_chip_qubits`, `qdash_list_chip_couplings` — inspect chip metrics and topology targets
|
|
19
|
+
- `qdash_list_cryostats`, `qdash_list_cooldowns` — establish cryostat and cooldown context
|
|
20
|
+
- `qdash_get_cooldown_wiring`, `qdash_wiring_insights`, `qdash_list_cooldown_wiring_events` — inspect current wiring, attenuation, and changes
|
|
21
|
+
- `qdash_get_timeseries`, `qdash_plot_timeseries` — inspect one target metric over time
|
|
22
|
+
- `qdash_inspect_timeseries_csv`, `qdash_compare_timeseries` — validate and compare multiple QDash or CSV timeseries
|
|
23
|
+
- `qdash_list_task_results`, `qdash_get_task_result` — find and inspect calibration results
|
|
24
|
+
- `qdash_get_task_knowledge` — interpret a task's purpose, expected result, failure modes, and check questions
|
|
25
|
+
- `qdash_list_issues` — inspect tracked issues
|
|
26
|
+
- `qdash_list_flows`, `qdash_get_flow` — list or inspect calibration flows
|
|
27
|
+
- `qdash_list_executions`, `qdash_get_execution`, `qdash_wait_execution`, `qdash_compare_executions` — inspect, await, or compare executions
|
|
28
|
+
- `qdash_list_ai_reviews`, `qdash_get_provenance_stats` — inspect AI reviews or provenance status
|
|
29
|
+
- `qdash_list_forum_posts`, `qdash_get_forum_post`, `qdash_list_forum_replies` — inspect Forum context
|
|
30
|
+
- `qdash_preview_forum_evidence_reply`, `qdash_preview_forum_image_reply` — preview evidence or image replies without writing
|
|
31
|
+
- `qdash_get_figure`, `qdash_get_task_figures`, `qdash_recent_calibration_figure`, `qdash_analyze_figure_json`, `qdash_build_qcal_evidence` — inspect or package figure evidence
|
|
32
|
+
2. Read-only overview and planning tools:
|
|
33
|
+
- `qdash_dashboard`, `qdash_dashboard_insights`, `qdash_triage_overview` — summarize status, insights, and investigation priorities
|
|
34
|
+
- `qdash_investigate`, `qdash_target_report`, `qdash_compare_calibration` — investigate target history and compare calibrations
|
|
35
|
+
- `qdash_recent_calibration_summary`, `qdash_recommend_next_action` — summarize outcomes and recommend a safe next action
|
|
36
|
+
- `qdash_degradation_report`, `qdash_plan_calibration`, `qdash_validate_calibration` — inspect drift, plan work, and validate results
|
|
37
|
+
3. Confirmation-gated write tools (the harness asks the user before running them):
|
|
38
|
+
- `qdash_create_agent_session`, `qdash_submit_agent_action`, `qdash_execute_agent_action` — create or execute a scoped agent workflow
|
|
39
|
+
- `qdash_commit_agent_candidate`, `qdash_commit_agent_campaign_candidates` — commit reviewed candidate parameters
|
|
40
|
+
- `qdash_apply_agent_candidate_commit` — apply a reviewed candidate commit
|
|
41
|
+
- `qdash_create_forum_post`, `qdash_update_forum_post` — create or update Forum content
|
|
42
|
+
- `qdash_create_forum_evidence_reply`, `qdash_create_forum_image_reply` — publish previously reviewed evidence replies
|
|
43
|
+
4. Agent workflow state tools:
|
|
44
|
+
- `qdash_get_agent_session`, `qdash_get_agent_action`, `qdash_list_agent_actions`, `qdash_wait_agent_action` — inspect agent workflow state
|
|
45
|
+
- `qdash_list_agent_action_candidates`, `qdash_get_agent_candidate_commit`, `qdash_wait_agent_candidate_apply` — inspect candidates and apply status
|
|
46
|
+
5. `qdash_query` — fallback for read-only operations without a dedicated tool.
|
|
47
|
+
6. `qdash_raw_get` — last-resort read-only GET for an uncovered endpoint.
|
|
58
48
|
|
|
59
49
|
## Session context
|
|
60
50
|
|
|
51
|
+
When running in pi CLI, use `qdash_config_info` if the profile or non-secret connection settings are unclear.
|
|
52
|
+
|
|
61
53
|
Use these commands to make pi behave like a QDash-specific harness with persistent session-local context:
|
|
62
54
|
|
|
63
55
|
```text
|
|
@@ -9,7 +9,7 @@ metadata:
|
|
|
9
9
|
maturity: experimental
|
|
10
10
|
safety_level: operational-write-gated
|
|
11
11
|
default_mode: one-target-one-action
|
|
12
|
-
source_of_truth: pi-qdash skills
|
|
12
|
+
source_of_truth: procedures in pi-qdash skills; task physics and interpretation in qdash-task-knowledge
|
|
13
13
|
preferred_qubit_recovery_recipe: CheckRabi -> CheckChevron -> Configure -> CheckRabi
|
|
14
14
|
requires_confirmation_for:
|
|
15
15
|
- agent session creation
|
|
@@ -26,7 +26,7 @@ metadata:
|
|
|
26
26
|
|
|
27
27
|
# QDash Calibration Agent
|
|
28
28
|
|
|
29
|
-
This skill defines how pi should behave as a conservative, confirmation-gated calibration execution agent. It
|
|
29
|
+
This skill defines how pi should behave as a conservative, confirmation-gated calibration execution agent. It orchestrates safe operational steps after diagnosis. Task physics, expected results, and failure modes come from QDash task knowledge; this skill owns procedure and safety gates.
|
|
30
30
|
|
|
31
31
|
## Core principles
|
|
32
32
|
|
|
@@ -37,7 +37,7 @@ This skill defines how pi should behave as a conservative, confirmation-gated ca
|
|
|
37
37
|
- Use narrow agent session policies with the smallest allowed task/action/parameter scope.
|
|
38
38
|
- Do not commit or apply parameter candidates until a validation task succeeds and the user explicitly confirms.
|
|
39
39
|
- Avoid blind parameter sweeps. If two conservative probes fail, step back to a diagnostic task.
|
|
40
|
-
- Record
|
|
40
|
+
- Record task-specific lessons as task-knowledge cases; update this skill only for reusable procedure or safety guidance.
|
|
41
41
|
|
|
42
42
|
## Standard workflow
|
|
43
43
|
|
|
@@ -51,6 +51,7 @@ This skill defines how pi should behave as a conservative, confirmation-gated ca
|
|
|
51
51
|
2. Read evidence:
|
|
52
52
|
- `qdash_list_task_results`
|
|
53
53
|
- `qdash_get_task_result`
|
|
54
|
+
- `qdash_get_task_knowledge` for every task whose result will be interpreted
|
|
54
55
|
- `qdash_get_task_figures` when figures exist
|
|
55
56
|
- forum posts for the target when relevant
|
|
56
57
|
3. Make a one-step plan.
|
|
@@ -64,7 +65,7 @@ This skill defines how pi should behave as a conservative, confirmation-gated ca
|
|
|
64
65
|
|
|
65
66
|
### CheckRabi returns non-finite frequency, NaN, or low R²
|
|
66
67
|
|
|
67
|
-
|
|
68
|
+
Read `CheckRabi` and `CheckChevron` with `qdash_get_task_knowledge` before interpreting the failure or proposing recovery. Do not repeatedly perturb parameters without diagnosis.
|
|
68
69
|
|
|
69
70
|
Canonical recovery sequence:
|
|
70
71
|
|
|
@@ -81,26 +82,9 @@ Recommended sequence:
|
|
|
81
82
|
5. If successful, inspect candidates and only then consider committing/applying parameters with explicit user confirmation.
|
|
82
83
|
6. If still failing after `Configure`, request human review and inspect raw/figure data.
|
|
83
84
|
|
|
84
|
-
Known successful pattern:
|
|
85
|
-
|
|
86
|
-
- Q33 on mackerel / `144Qv1`, 2026-07-14:
|
|
87
|
-
- repeated `CheckRabi` failures with `non-finite frequency: nan`
|
|
88
|
-
- `CheckChevron` succeeded and estimated:
|
|
89
|
-
- `qubit_frequency = 4.186021437949582 GHz`
|
|
90
|
-
- `control_amplitude = 0.196626929963469 a.u.`
|
|
91
|
-
- `Configure` completed
|
|
92
|
-
- `CheckRabi` then completed with the CheckChevron estimates:
|
|
93
|
-
- `rabi_frequency = 12.664970037417886 MHz`
|
|
94
|
-
- `control_amplitude = 0.19406572753680693 a.u.`
|
|
95
|
-
|
|
96
85
|
### CheckChevron interpretation and suggestions
|
|
97
86
|
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
- Clear vertex/fringes: use estimated `qubit_frequency` and `control_amplitude`, then run `Configure -> CheckRabi` for validation.
|
|
101
|
-
- Faint fringes: suspect insufficient drive, readout fidelity, or initialization/readout contrast; suggest readout diagnostics before parameter commits.
|
|
102
|
-
- No visible chevron: inspect readout path first (`CheckReadoutFrequency`, `ReadoutClassification`) or request human review.
|
|
103
|
-
- Asymmetric/double chevron: suspect TLS, higher-level transitions, AC Stark shift, or frequency collision; avoid committing simple Rabi outputs without review.
|
|
87
|
+
Read `CheckChevron` with `qdash_get_task_knowledge` before judging its figure, estimates, expected curve, or failure mode.
|
|
104
88
|
|
|
105
89
|
If `CheckChevron` fails:
|
|
106
90
|
|
|
@@ -109,36 +93,11 @@ If `CheckChevron` fails:
|
|
|
109
93
|
3. Classify the failure message and input/output parameters.
|
|
110
94
|
4. Suggest the next diagnostic, but require user confirmation before another operational action.
|
|
111
95
|
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
- `Qubit frequency too low/high`, boundary hit, or fitted frequency outside normal operating range:
|
|
115
|
-
- Treat the Chevron estimate as unsafe.
|
|
116
|
-
- Do not commit/apply candidates.
|
|
117
|
-
- Do not run `Configure -> CheckRabi` from this estimate.
|
|
118
|
-
- Suggest `CheckQubitSpectroscopy`, coarse frequency search review, or human figure review.
|
|
119
|
-
- Abnormally large `coarse_control_amplitude`:
|
|
120
|
-
- Suspect the coarse search latched onto a wrong transition, poor readout contrast, or an invalid operating point.
|
|
121
|
-
- Suggest spectroscopy/readout diagnostics rather than stronger drive.
|
|
122
|
-
- Failed fit but visually plausible chevron:
|
|
123
|
-
- Ask the user to inspect figures.
|
|
124
|
-
- Consider adjusted scan bounds only with explicit user guidance.
|
|
125
|
-
- Faint/washed-out chevron:
|
|
126
|
-
- Suggest `ReadoutClassification`, `CheckReadoutFrequency`, and initialization/readout checks.
|
|
127
|
-
|
|
128
|
-
Known failed pattern:
|
|
129
|
-
|
|
130
|
-
- Q35 on mackerel / `144Qv1`, 2026-07-14:
|
|
131
|
-
- repeated `CheckRabi` failures with `non-finite frequency: nan`
|
|
132
|
-
- `CheckChevron` failed with `Qubit frequency too low for qid=35: 2.759894 GHz < 3.0 GHz`
|
|
133
|
-
- input `coarse_qubit_frequency = 2.894185298591617 GHz`
|
|
134
|
-
- input `coarse_control_amplitude = 0.5623413251903492 a.u.`
|
|
135
|
-
- Suggested action: stop, inspect figures, and investigate spectroscopy/coarse frequency/readout state before any Configure/Rabi retry.
|
|
96
|
+
Use the returned task knowledge to choose the next diagnostic. Treat unsafe estimates as non-committable, stop before `Configure -> CheckRabi`, and require confirmation for any additional task.
|
|
136
97
|
|
|
137
98
|
### CheckT2Echo failures
|
|
138
99
|
|
|
139
|
-
|
|
140
|
-
- If `T2_echo` is much shorter than `2*T1`, suspect noise/refocusing issues.
|
|
141
|
-
- Verify π/π/2 pulses before treating echo as a pure coherence problem.
|
|
100
|
+
Read `CheckT2Echo`, `CheckT1`, and `CheckRamsey` with `qdash_get_task_knowledge`, then compare their recent results before choosing a diagnostic.
|
|
142
101
|
|
|
143
102
|
## Coupling / two-qubit recovery rules
|
|
144
103
|
|
|
@@ -153,9 +112,7 @@ For `ZX90InterleavedRandomizedBenchmarking` or two-qubit validation failures, do
|
|
|
153
112
|
5. `CheckBellStateTomography`
|
|
154
113
|
6. then RB validation
|
|
155
114
|
|
|
156
|
-
Treat `completed` as execution status, not proof of quality.
|
|
157
|
-
|
|
158
|
-
If CR rotation is weak, inspect qubit detuning/frequency collisions and coupling history before increasing CR amplitude.
|
|
115
|
+
Treat `completed` as execution status, not proof of quality. Before interpreting Bell, tomography, coherence-limit, CR, ZX90, or IRB output, read each relevant task with `qdash_get_task_knowledge`; then correlate the returned criteria with figures and same-cooldown history.
|
|
159
116
|
|
|
160
117
|
## Session policy guidelines
|
|
161
118
|
|
|
@@ -26,6 +26,8 @@ checks.
|
|
|
26
26
|
|
|
27
27
|
## Workflow
|
|
28
28
|
|
|
29
|
+
When a compared QDash series comes from a task-specific output, call `qdash_get_task_knowledge` for that task before assigning physical meaning to its values, expected behavior, or failure modes.
|
|
30
|
+
|
|
29
31
|
### 1. Fix the investigation scope
|
|
30
32
|
|
|
31
33
|
Record the reusable scope with `/qdash-investigation-setup` when multiple
|
|
@@ -27,7 +27,7 @@ Use this skill when investigating coupling-level calibration quality, especially
|
|
|
27
27
|
For a coupling `cA-B`:
|
|
28
28
|
|
|
29
29
|
1. Build context with `qdash_list_cooldowns`, `qdash_target_report`, and recent task results for the coupling. Record the cooldown ID for each result and inspect wiring events when measurement conditions may have changed.
|
|
30
|
-
2. Inspect the latest same-cooldown tasks in this chain by default:
|
|
30
|
+
2. Inspect the latest same-cooldown tasks in this chain by default, and call `qdash_get_task_knowledge` for each task before interpreting its outputs or figures:
|
|
31
31
|
- `CheckCrossResonance`
|
|
32
32
|
- `CreateZX90`
|
|
33
33
|
- `CheckZX90`
|
|
@@ -46,51 +46,9 @@ For a coupling `cA-B`:
|
|
|
46
46
|
|
|
47
47
|
## Interpretation rules
|
|
48
48
|
|
|
49
|
-
|
|
49
|
+
Use `qdash_get_task_knowledge` for `CheckCrossResonance`, `CheckZX90`, `CheckBellState`, `CheckBellStateTomography`, `Check2QGateCoherenceLimit`, and `ZX90InterleavedRandomizedBenchmarking` as applicable. Apply the returned expected-result descriptions, criteria, failure modes, and check questions to the measured outputs.
|
|
50
50
|
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
- Bell-state tomography fidelity is below ~0.8.
|
|
54
|
-
- IRB fidelity has a large uncertainty/error bar, or `n_trials` is small.
|
|
55
|
-
- Coherence-limit fidelity is high but Bell/IRB fidelity is much lower.
|
|
56
|
-
- `CheckZX90` repeated-pulse traces do not show a stable/consistent response.
|
|
57
|
-
- CR parameter generation succeeds but `cr_amplitude` is near saturation or `zx_rotation_rate` is very small.
|
|
58
|
-
|
|
59
|
-
### Coherence limit gap
|
|
60
|
-
|
|
61
|
-
If `two_qubit_gate_coherence_limit` is high but measured Bell/IRB fidelity is low, do not attribute the issue primarily to T1/T2. Suspect control/calibration issues such as:
|
|
62
|
-
|
|
63
|
-
- ZX90 angle error
|
|
64
|
-
- CR phase error
|
|
65
|
-
- cancel-pulse amplitude/phase mismatch
|
|
66
|
-
- rotary compensation mismatch
|
|
67
|
-
- readout/classification contribution to validation figures
|
|
68
|
-
|
|
69
|
-
### Bell tomography signals
|
|
70
|
-
|
|
71
|
-
For a Bell target resembling `( |00> + |11> ) / sqrt(2)`:
|
|
72
|
-
|
|
73
|
-
- Large `|10>` or `|01>` population suggests population/conditional-rotation error, not just dephasing.
|
|
74
|
-
- Weak `|00><11|` coherence suggests phase, dephasing, or preparation error.
|
|
75
|
-
- Large imaginary coherence can indicate phase-compensation error.
|
|
76
|
-
|
|
77
|
-
Use the heatmap summaries from `qdash_analyze_figure_json` as numeric evidence. Do not overfit a single plot; correlate with `CheckZX90` and IRB.
|
|
78
|
-
|
|
79
|
-
### CheckZX90 repeated-pulse signals
|
|
80
|
-
|
|
81
|
-
Look for stable repeated-pulse behavior. Warnings include:
|
|
82
|
-
|
|
83
|
-
- Large scatter or non-decaying erratic points after the first few repetitions.
|
|
84
|
-
- Large first-step contrast followed by a non-zero offset.
|
|
85
|
-
- Different qualitative behavior between control and target qubit plots.
|
|
86
|
-
|
|
87
|
-
These symptoms point toward angle/phase/cancel/rotary issues and should be investigated before trusting IRB.
|
|
88
|
-
|
|
89
|
-
### IRB caveats
|
|
90
|
-
|
|
91
|
-
- A `completed` IRB with large error bar is weak evidence.
|
|
92
|
-
- Small `n_trials` should be reported explicitly.
|
|
93
|
-
- If Bell tomography is poor, do not use IRB alone as a pass signal.
|
|
51
|
+
Treat `completed` only as execution status. Correlate task knowledge with `qdash_analyze_figure_json`, same-cooldown history, and adjacent validation tasks; do not overfit one plot or use IRB alone as a pass signal.
|
|
94
52
|
|
|
95
53
|
## Recommended action sequence
|
|
96
54
|
|
|
@@ -108,19 +66,4 @@ Inspect figures/results
|
|
|
108
66
|
|
|
109
67
|
Each operational step requires explicit confirmation. Validate Bell/tomography before using IRB as the final quality signal.
|
|
110
68
|
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
Symptoms observed:
|
|
114
|
-
|
|
115
|
-
- `CheckCrossResonance` completed with `zx_rotation_rate ~ 1.69e-3`.
|
|
116
|
-
- `Check2QGateCoherenceLimit` reported ~0.978.
|
|
117
|
-
- `CheckBellStateTomography` reported `bell_state_fidelity ~ 0.60`.
|
|
118
|
-
- Bell tomography had high `|10>` component/population (~0.29) and non-ideal coherence.
|
|
119
|
-
- `ZX90InterleavedRandomizedBenchmarking` completed with `zx90_gate_fidelity ~0.94` but large error (~0.087) and `n_trials=10`.
|
|
120
|
-
- `CheckZX90` repeated-pulse traces were not clean/stable.
|
|
121
|
-
|
|
122
|
-
Interpretation:
|
|
123
|
-
|
|
124
|
-
- This is not primarily coherence-limited.
|
|
125
|
-
- Suspect ZX90 angle/phase/cancel/rotary calibration quality.
|
|
126
|
-
- Prefer walking back through `CheckCrossResonance -> CreateZX90 -> CheckZX90`, then validate with Bell tomography before trusting IRB.
|
|
69
|
+
Historical postmortem cases belong in QDash task knowledge. Retrieve them through `qdash_get_task_knowledge` rather than encoding device-specific values in this procedural skill.
|