@ainyc/canonry 4.47.0 → 4.50.0

package/assets/agent-workspace/skills/aero/SKILL.md

@@ -34,6 +34,17 @@ When a project has GA4 connected, traffic is a first-class signal alongside cita
 - Don't edit client's code without showing diffs and getting approval
 - Don't conflate "not cited" with "page doesn't exist" — check first
 
+### When to use `--probe` runs
+When you need to **verify** something on your own initiative — "did the OpenAI provider migration land cleanly?", "is the regression still reproducible after the WP fix?", "does this query actually surface us when I think it should?" — use `cnry run <project> --probe --provider <p> --query "..."`. Probe runs:
+- Still cost provider API quota (same wire call)
+- Write a snapshot you can inspect via `cnry runs get <id>`
+- Are EXCLUDED from dashboard, analytics, intelligence, insights, and notifications
+- Won't wake you up again via the post-run hook (no recursive analysis loops)
+
+Use probes whenever the run is for **your** investigation, not for the user's metrics. The two May-17 ainyc probes that broke the dashboard before this convention existed are the canonical example of why this matters — a 1-snapshot test masqueraded as "the latest sweep" and zeroed the headline.
+
+A real (non-probe) sweep is appropriate when the user explicitly asks to refresh data ("run it again", "get the latest", "trigger a sweep").
+
 ### How to Communicate
 - Data first: show the numbers before the interpretation
 - Be specific: "You lost the ChatGPT citation for 'roof repair phoenix' between March 28-April 2" not "your visibility decreased"

package/assets/agent-workspace/skills/aero/references/orchestration.md

@@ -32,6 +32,14 @@ Steps:
 8. If content fix: generate diff (schema, llms.txt, or content changes)
 9. Update memory with regression event + diagnosis
 
+**Want to verify the regression is real / reproducible before reporting?** Use a probe run instead of a real sweep:
+
+```
+cnry run <project> --probe --provider <p> --query "<regressed-query>"
+```
+
+Then `cnry runs get <id>` to inspect the snapshot. The probe's snapshot won't displace the latest scheduled sweep on the dashboard, won't generate insights, and won't fire notifications — so you can re-test as many times as needed without polluting metrics. Promote to a real sweep (drop `--probe`) only if the operator explicitly wants the data to feed the dashboard.
+
 ## Workflow 3: Weekly Review
 
 Trigger: Scheduled (weekly, or on-demand)

package/assets/agent-workspace/skills/aero/soul.md

@@ -12,7 +12,7 @@ You are **Aero** — an AEO analyst. You help operators understand how AI answer
 - **Evidence over opinion.** Numbers before interpretation. "You lost the ChatGPT citation for 'roof repair phoenix' between March 28 and April 2" beats "your visibility decreased."
 - **Proactive, not passive.** Regressions don't wait to be asked about. Surface them when you spot them. Flag emerging competitors the moment they appear in citations you own.
 - **Honest about uncertainty.** When the data is ambiguous, say so. Don't manufacture confidence. Don't promise fixes will appear in the next sweep — AEO changes take weeks.
-- **Cautious with writes.** Sweeps cost quota. Schedules shape downstream notifications. Queries define what gets tracked. Confirm intent before mutating state the operator will notice.
+- **Cautious with writes.** Sweeps cost quota. Schedules shape downstream notifications. Queries define what gets tracked. Confirm intent before mutating state the operator will notice. When *you* need to test something (verify a fix, reproduce a regression), use `cnry run --probe` — same wire call, no dashboard/analytics/notification pollution.
 - **Canonry is the source of truth.** Read state back; never maintain a parallel copy in your head. Conclusions age, the data doesn't.
 
 ## Voice

package/assets/agent-workspace/skills/canonry/SKILL.md

@@ -77,6 +77,8 @@ A canonry engagement follows the same loop regardless of project size:
 4. **Monitor** — Re-run sweeps weekly (`cnry run --all --wait` fans out across every project). Correlate visibility shifts with deployments and competitor moves.
 5. **Report** — Lead with data, not interpretation: "Lost the mention for `<query>` on Gemini between <date> and <date> — two competitors moved in. Here's what to fix." For a one-command client-facing summary, run `cnry report <project>` to generate a self-contained HTML bundle (mention + citation hero, competitor landscape, GSC + GA4 performance, insights, suggested next queries). Same payload is available via `--format json` and the `canonry_report` MCP tool.
 
+**Verifying without polluting metrics**: when you need to test something on your own initiative — "did the latest provider deploy work?", "is this regression reproducible?", "would this query actually surface us?" — use `cnry run <project> --probe --provider <p> --query "..."`. Probe runs write a snapshot you can inspect via `cnry runs get <id>` but are excluded from the dashboard, analytics, intelligence, report, and notifications. Use probes for *your* investigation; use real sweeps when the operator wants the data to feed metrics.
+
 ## Surgical Reads
 
 When you need a specific value rather than a full payload, use the dot-path getter:

package/assets/agent-workspace/skills/canonry/references/canonry-cli.md

@@ -78,9 +78,10 @@ cnry run <project> --wait                      # block until complete
 cnry run <project> --location <label>          # run with specific location context
 cnry run <project> --all-locations             # run for every configured location
 cnry run <project> --no-location               # explicitly skip location context
+cnry run <project> --probe --provider openai --query "..."  # operator/agent test run — snapshot is inspectable but EXCLUDED from dashboard, analytics, intelligence, report, and notifications. Use for verification / "did this fix work?" / regression hypothesis testing.
 cnry run --all --wait                          # all projects
 cnry run cancel <project> [run-id]             # force-cancel stuck runs
-cnry runs <project> --limit 10                 # list recent runs
+cnry runs <project> --limit 10                 # list recent runs (includes both real and probe runs; filter on `trigger` if you only want one)
 cnry run show <id>                             # show run details
 ```
 
@@ -88,6 +89,18 @@ Run statuses: `queued` → `running` → `completed` / `failed` / `partial`
 
 `partial` = some providers failed (usually rate limits) — successful snapshots are still saved.
 
+### Probe vs real runs
+
+| Trigger | Source | Feeds dashboard/analytics | Runs intelligence | Fires notifications | Wakes Aero |
+|---|---|---|---|---|---|
+| `manual` | `cnry run <project>` | ✅ | ✅ | ✅ | ✅ |
+| `scheduled` | cron schedule | ✅ | ✅ | ✅ | ✅ |
+| `config-apply` | `cnry apply` after queries change | ✅ | ✅ | ✅ | ✅ |
+| `backfill` | `cnry backfill ...` | partial (historical) | ✅ | — | — |
+| **`probe`** | `cnry run --probe ...` | ❌ | ❌ | ❌ | ❌ |
+
+Use `--probe` whenever you're testing on your own initiative — verifying a fix landed, reproducing a regression, sanity-checking a query — rather than producing data the user/dashboard will consume.
+
 `snapshot` does not create a project or write to the DB. It generates category queries, runs providers, and produces a report for prospecting.
 
 ## Citation Data