@oqtopus-team/pi-qdash 0.1.11-beta.22 → 0.1.11-beta.23

package/extensions/lib/write-gate.ts

@@ -5,7 +5,7 @@ const WRITE_TOOL_NAMES = new Set([
   "qdash_submit_agent_action",
   "qdash_commit_agent_candidate",
   "qdash_execute_agent_action",
-  "qdash_commit_agent_campaign_candidates",
+  "qdash_commit_agent_candidate_set",
   "qdash_apply_agent_candidate_commit",
   "qdash_create_forum_post",
   "qdash_update_forum_post",

package/extensions/qdash.ts

@@ -2378,30 +2378,30 @@ export default function qdashExtension(pi: ExtensionAPI) {
   });
 
   pi.registerTool({
-    name: "qdash_commit_agent_campaign_candidates",
-    label: "QDash Commit Agent Campaign Candidates",
-    description: "Commit multiple QDash agent campaign candidates. This is a write operation and requires confirmation.",
-    promptSnippet: "Commit multiple QDash agent candidates after explicit user confirmation",
-    promptGuidelines: ["Use qdash_commit_agent_campaign_candidates only after showing the candidate set and receiving explicit confirmation."],
+    name: "qdash_commit_agent_candidate_set",
+    label: "QDash Commit Agent Candidate Set",
+    description: "Commit a reviewed QDash agent candidate set (several candidates at once). This is a write operation and requires confirmation.",
+    promptSnippet: "Commit a QDash agent candidate set after explicit user confirmation",
+    promptGuidelines: ["Use qdash_commit_agent_candidate_set only after showing the candidate set and receiving explicit confirmation."],
     parameters: Type.Object({
       ...connectionParams,
       sessionId: Type.String(),
-      candidates: Type.Array(Type.Any({ description: "Agent campaign candidate references accepted by QDash." })),
+      candidates: Type.Array(Type.Any({ description: "Agent plan candidate references accepted by QDash." })),
       idempotencyKey: Type.Optional(Type.String()),
       expectedStateVersion: Type.Number(),
       confirmWrite: Type.Optional(Type.Boolean()),
     }),
     async execute(_toolCallId, params: ConfirmableParams & { profile?: string; configPath?: string; useEnv?: boolean; sessionId: string; candidates: unknown[]; idempotencyKey?: string; expectedStateVersion: number }, _signal, _onUpdate, ctx) {
       if (!params.confirmWrite) {
-        if (!ctx.hasUI || !(await ctx.ui.confirm("Commit QDash agent campaign candidates?", `Commit ${params.candidates.length} candidate(s)?`))) {
-          throw new Error("qdash_commit_agent_campaign_candidates requires explicit confirmation");
+        if (!ctx.hasUI || !(await ctx.ui.confirm("Commit QDash agent candidate set?", `Commit ${params.candidates.length} candidate(s)?`))) {
+          throw new Error("qdash_commit_agent_candidate_set requires explicit confirmation");
         }
       }
       const client = await makeClient(params);
-      return toToolResult(await client.commitAgentCampaignCandidates(params.sessionId, params.candidates as never, {
+      return toToolResult(await client.commitAgentCandidateSet(params.sessionId, params.candidates as never, {
         idempotencyKey: params.idempotencyKey ?? randomUUID(),
         expectedStateVersion: params.expectedStateVersion,
-      }), { tool: "qdash_commit_agent_campaign_candidates" });
+      }), { tool: "qdash_commit_agent_candidate_set" });
     },
   });
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oqtopus-team/pi-qdash",
-  "version": "0.1.11-beta.22",
+  "version": "0.1.11-beta.23",
   "description": "Pi extension for querying QDash via @oqtopus-team/qdash-client",
   "type": "module",
   "license": "Apache-2.0",
@@ -27,7 +27,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@oqtopus-team/qdash-client": "1.9.21-beta.203"
+    "@oqtopus-team/qdash-client": "1.9.21-beta.276"
   },
   "peerDependencies": {
     "@earendil-works/pi-coding-agent": "*",

package/skills/qdash/SKILL.md

@@ -36,7 +36,7 @@ Prefer the dedicated tool that matches the question. Use `qdash_query` only as a
    - `qdash_degradation_report`, `qdash_plan_calibration`, `qdash_validate_calibration` — inspect drift, plan work, and validate results
 3. Confirmation-gated write tools (the harness asks the user before running them):
    - `qdash_create_agent_session`, `qdash_submit_agent_action`, `qdash_execute_agent_action` — create or execute a scoped agent workflow
-   - `qdash_commit_agent_candidate`, `qdash_commit_agent_campaign_candidates` — commit reviewed candidate parameters
+   - `qdash_commit_agent_candidate`, `qdash_commit_agent_candidate_set` — commit reviewed candidate parameters
    - `qdash_apply_agent_candidate_commit` — apply a reviewed candidate commit
    - `qdash_create_forum_post`, `qdash_update_forum_post` — create or update Forum content
    - `qdash_create_forum_evidence_reply`, `qdash_create_forum_image_reply` — publish previously reviewed evidence replies

package/skills/qdash-calibration-agent/SKILL.md

@@ -13,7 +13,7 @@ metadata:
   preferred_qubit_recovery_recipe: CheckRabi -> CheckChevron -> Configure -> CheckRabi
   requires_confirmation_for:
     - agent session creation
-    - task execution
+    - task execution (per step unless the session policy sets autonomy: auto)
     - parameter commit
     - backend apply
   related_qdash_tasks:
@@ -114,6 +114,27 @@ For `ZX90InterleavedRandomizedBenchmarking` or two-qubit validation failures, do
 
 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.
 
+## Autonomous plan (autonomy: auto)
+
+A session created with `autonomy: auto` delegates the step-by-step confirmation once: the user
+approves the plan, the override bounds, the action budget, and `max_rounds_per_target`, and the
+plan then chooses each next node from the calibration evaluation of the last result. Treat
+the grant as the confirmation; do not ask again per node.
+
+- Build the plan only from nodes the user approved; every node's task must be in `allowed_tasks`.
+- The next step comes from the task knowledge's `next_actions` table (read it with
+  `qdash_get_task_knowledge`; the `next_actions` field lists what each evaluation status leads
+  to). Do not improvise a step for a status the table does not cover; the plan stops for the
+  user there, and that is correct.
+- The plan stops for the user when the same status returns three times, the fit is judged
+  unreliable twice in a row, an evaluation does not complete, a suggested range leaves the
+  session bounds, or a node's round budget is spent. Report the stop with the evaluations it
+  recorded (evaluation id, status, suggested range, chosen node) and the execution links.
+- Candidates are still committed only through the candidate gate with explicit confirmation,
+  unless the user asked for `commit_on_success` when approving the plan.
+- For CheckRabi recovery the plan is `rabi` → (`NO_SIGNAL`) `chevron` → `rabi-reconfigured`
+  with `reconfigure_before_task`; the session must allow reconfiguration.
+
 ## Session policy guidelines
 
 For diagnostic-only actions: