@zibby/skills 0.2.22 → 0.2.24

package/docs/recipes/bug-autofix.md

@@ -1,85 +0,0 @@
----
-sidebar_position: 4
-title: Bug-autofix agent
----
-
-# `bug-autofix` — ticket → fix PR → tracker writeback
-
-The flagship orchestrator agent. It polls a tracker for new bugs, classifies each one, opens a fix PR for the autofixable ones, and writes the result back to the tracker — chaining three reusable building-block agents via **sub-graph dispatch**.
-
-```
-poll (this graph)
-  ↓ found a ticket?
-triage     → sub-graph: ticket-triage      → { severity, shouldAutofix, summary }
-  ↓ severity ≥ AUTOFIX_MIN_SEVERITY AND shouldAutofix AND repo configured?
-  ├─ yes → code_fix → sub-graph: code-fix  → { pr_url, branch }
-  │            ↓
-  └─ no ───────────────────────────────────────────┐
-                                                     ↓
-writeback  → sub-graph: tracker-writeback   (runs on BOTH branches)
-  ↓
- END
-```
-
-High-severity, concrete, autofixable bugs get a fix PR opened and the Jira ticket moved to *In Review*. Everything else (noise, vague, too-big, below threshold, or no repo configured) is triaged and a human is notified — no PR.
-
-## The three building-block agents
-
-`bug-autofix` is an orchestrator: each step is a separate, independently deployable agent it dispatches as a sub-graph. Deploy all four in the same project.
-
-| Step | Building block | Input | Output |
-|---|---|---|---|
-| `triage` | `ticket-triage` | `{ ticket }` | severity (`CRITICAL…NOISE`), `shouldAutofix`, summary |
-| `code_fix` | `code-fix` | `{ ticket, repo }` | `{ pr_url, branch }` — clones, fixes with an inline test-gate, opens a PR |
-| `writeback` | `tracker-writeback` | `{ ticket, pr_url?, branch?, result }` | transitions the issue, comments the PR link, posts to Slack/Lark |
-
-Each block is usable on its own — `ticket-triage` is a fine standalone classifier; `code-fix` is a standalone clone→fix→PR agent.
-
-## Sub-graph dispatch
-
-A child step is declared with `{ workflow }` on the node:
-
-```js
-graph.addNode('triage', {
-  workflow: 'ticket-triage',                  // child deploy slug
-  input:  (state) => ({ ticket: state.poll.ticket }),
-  output: 'classify',                         // dot-path on the child's final state
-});
-```
-
-The engine spawns the child as a **separate execution** (its own run row + Fargate task, or in-process when runtime tags match), links it to the parent for the Activity-tab tree and cancellation cascade, polls until terminal, and extracts `output` back into the parent state under the node name.
-
-## Trigger
-
-Cron poll (default) or per-ticket webhook. Each run processes ONE ticket; the next tick/webhook handles the next.
-
-```json
-{ "jql": "issuetype = Bug AND statusCategory != Done ORDER BY updated DESC" }   // cron
-{ "ticketKey": "PROJ-123" }                                                      // webhook
-```
-
-## Config (ENV tab)
-
-| Var | Meaning |
-|---|---|
-| `REPO_URL` | Repo the fix targets. Unset → no autofix, notify-only. |
-| `REPO_NAME` | Short repo name (default: derived from `REPO_URL`). |
-| `REPO_BRANCH` | Base branch (default `main`). |
-| `AUTOFIX_MIN_SEVERITY` | Routing floor for code-fix (default `MEDIUM`). |
-
-Plus the children's own config: Jira connected (triage/poll/writeback), GitHub connected (code-fix), and `SLACK_CHANNEL` / `LARK_RECEIVE_ID` (writeback).
-
-## Scope (v1)
-
-- **In:** poll → triage → (autofix?) → code-fix → writeback, end-to-end to "PR opened + Jira written back".
-- **Out:** deploy / verify / rollback; an auto re-dispatch loop; in-engine approval. The open PR is the human gate.
-- **Tracker seam:** Jira is implemented; GitHub / Linear are extension points in the child templates.
-
-## Deploy
-
-```bash
-zibby agent templates                         # browse the marketplace
-zibby agent new bug-autofix -t bug-autofix    # scaffold the orchestrator
-# ...also scaffold + deploy ticket-triage, code-fix, tracker-writeback in the same project
-zibby agent deploy bug-autofix
-```

package/docs/recipes/github-ai-scout.md

@@ -1,61 +0,0 @@
----
-sidebar_position: 5
-title: GitHub AI scout
----
-
-# `github-ai-scout` — daily AI-project radar
-
-A daily scout agent that finds **new/trending AI projects on GitHub**, scores them against **your** rubric with an LLM, and posts a shortlist to Slack for a human to review. It proposes — it never stars, forks, or adds anything.
-
-```
-scan   (this graph) → GitHub search REST API: your query + created:> + stars:>=
-  ↓
-score  (LLM)        → rank + filter candidates against your rubric → shortlist
-  ↓
-digest (this graph) → render a report-object → sub-graph: notify-slack
-  ↓
- END
-```
-
-Everything that defines *what* it scouts is a deploy-time input — the search query, the recency/star thresholds, and the scoring rubric. Point it at a different topic and a different rubric and it scouts that domain instead.
-
-## Inputs
-
-| Input | Default | What it does |
-|---|---|---|
-| `query` | `topic:ai topic:llm topic:agents topic:rag` | GitHub search query, WITHOUT date/stars filters (scan appends those). |
-| `daysBack` | `30` | Only repos created within this many days. |
-| `minStars` | `30` | Minimum stars. |
-| `maxCandidates` | `30` | How many repos to fetch (max 100). |
-| `shortlistSize` | `8` | How many to surface in Slack. |
-| `rubric` | generic quality rubric | Plain-English scoring instruction — describe *your* taste. |
-| `excludeRepos` | `[]` | `owner/repo` names to skip — dedup against repos you already track. |
-| `slackChannel` | **required** | Channel id (`C012345`) or `#name` where the shortlist lands. |
-
-## GitHub auth (optional)
-
-The scan works **unauthenticated** for public search. To raise the rate limit, set a `GITHUB_TOKEN` env var on the project — the scan sends it as a Bearer token. No scopes needed; public read is enough.
-
-## Slack setup
-
-The digest dispatches to the **notify-slack** building-block agent (in-process sub-graph), which renders the shortlist as a native Block-Kit card. Deploy `notify-slack` in the same project, connect Slack, and set `slackChannel`.
-
-## Trigger
-
-Cron — typically **daily**. Each run is a fresh scan over the trailing `daysBack` window; use `excludeRepos` to keep the shortlist to NEW finds.
-
-```json
-{ "slackChannel": "#ai-radar" }
-```
-
-## What it does NOT do
-
-It **proposes a shortlist for human review — never auto-adds.** No starring, no forking, no writing anywhere except the Slack post. A person decides what to do with each find.
-
-## Deploy
-
-```bash
-zibby agent templates                                 # browse the marketplace
-zibby agent new github-ai-scout -t github-ai-scout    # scaffold (also deploy notify-slack)
-zibby agent deploy github-ai-scout
-```

package/docs/recipes/index.md

@@ -1,68 +0,0 @@
----
-sidebar_position: 1
-title: Agent Marketplace
----
-
-# Agent Marketplace
-
-Zibby ships a set of **ready-made agents** — production-ready automations you can deploy today. Each one is a real Zibby agent, eating its own dog food. Browse them, deploy with one command, and tune them to your project.
-
-> An **Agent** is a deployed automation built on coding-agent CLIs. Build and ship one with the `zibby agent` CLI.
-
-```
-                       ┌──────────────────┐
-   ┌──────────────────►│  zibby agent new │  ◄── Build your own
-   │                   │  zibby agent ... │
-   │                   └──────────────────┘
-   │                              ▲
-   │                              │ uses the same primitives
-   │                              │
-   │                   ┌──────────────────────┐
-   │  Marketplace ────►│  bug-autofix         │  ◄── Ticket → fix PR → writeback
-   │  agents built     │  github-ai-scout     │  ◄── Daily AI-project radar
-   │  on top of the    │  pipeline-supervisor │  ◄── Zibby managing Zibby
-   │  same platform    │  sentry-triage       │  ◄── Incident routing
-   │                   │  zibby test          │  ◄── Browser testing
-   │                   └──────────────────────┘
-```
-
-You don't have to use the marketplace. You can build whatever agent you want with `zibby agent new`. The marketplace just saves you from writing the obvious starter graphs for common cases.
-
-## Available agents
-
-| Agent | What it does | Best for |
-|---|---|---|
-| [Bug-autofix](./bug-autofix) | Polls a tracker, triages each bug, opens a fix PR for autofixable ones, writes the result back. Chains three reusable building-block agents (`ticket-triage` → `code-fix` → `tracker-writeback`). | End-to-end bug SDLC, automated remediation |
-| [GitHub AI scout](./github-ai-scout) | Daily scan of new/trending AI projects on GitHub, LLM-scored against your rubric, shortlist posted to Slack | Tracking a fast-moving space without manual triage |
-| [Pipeline supervisor](./pipeline-supervisor) | Watches the project's *other* agents, flags failing/slow ones, posts an improvement proposal to Slack/Lark | Zibby managing Zibby — agent fleet health |
-| [Sentry triage](./sentry-triage) | Hourly: fetch unresolved Sentry issues, classify by severity, route via Slack/Lark (author DM + usergroup mention) | Automated incident routing without a human triager |
-| [`zibby test`](./test) | Drives a browser via Cursor or Claude, runs assertions, generates a Playwright script + verification video | E2E test generation from plain-English specs |
-
-Plus reusable **building-block agents** that the orchestrators compose via sub-graph dispatch — `ticket-triage`, `code-fix`, `tracker-writeback`, `notify-slack`, `notify-lark`, `notify-notion`. Each is independently deployable and usable on its own.
-
-## Why a marketplace
-
-Three reasons we ship ready-made agents alongside the platform:
-
-1. **Proof of concept** — every marketplace agent IS a Zibby agent. If `bug-autofix` works, the platform works. You can see the actual graph definition and adapt it.
-2. **Faster onboarding** — you don't need to design a full graph on day one. Deploy an agent, see the output, then build your own.
-3. **Composable** — the orchestrators (`bug-autofix`) are built from smaller building-block agents dispatched as sub-graphs, so you can reuse the pieces in your own agents.
-
-## Building your own agent
-
-If you have an agent you'd want shipped as a built-in:
-
-```bash
-zibby agent new my-agent          # scaffold
-# ... build it out ...
-zibby agent run my-agent          # test locally
-zibby agent deploy my-agent       # ship to your cloud account
-```
-
-If it's broadly useful, we may pull it into the official marketplace. Open an issue or PR.
-
-## Next
-
-- **[Bug-autofix agent](./bug-autofix)** — the flagship orchestrator, walked through end-to-end
-- **[Build your own agent](../get-started/your-first-workflow)** — scaffold and customize
-- **[Concepts: graph](../concepts/graph)** — the primitives every agent is built on

package/docs/recipes/pipeline-supervisor.md

@@ -1,57 +0,0 @@
----
-sidebar_position: 6
-title: Pipeline supervisor
----
-
-# `pipeline-supervisor` — Zibby managing Zibby
-
-A scheduled supervisor agent that watches the project's *other* agents, finds the ones that are failing or slow, and posts a human-reviewable improvement proposal to Slack or Lark.
-
-v1 is strictly **READ → PROPOSE → NOTIFY**. It never edits another agent's graph — that's the safe starting point. The auto-PATCH step is a deliberate TODO, not implemented.
-
-```
-scan_pipelines        (deterministic + Zibby REST API, PAT-authed)
-   → propose_improvements (LLM — one proposal per flagged agent)
-   → notify               (LLM + SKILLS.CHAT_NOTIFY — one review card)
-```
-
-If `scan_pipelines` flags nothing, the graph short-circuits straight to `notify` (which posts/skips without an LLM call on the proposer).
-
-## How it reads other agents
-
-A direct authed `GET /executions?projectId=<id>&limit=200` against the Zibby REST API (the same route the dashboard and remote MCP server use), carrying a **user personal access token** in `Authorization: Bearer`.
-
-It must be a USER PAT (`zby_pat_…`), **not** the Fargate-injected `PROJECT_API_TOKEN`: every cross-agent read route requires a `userId` from the authorizer, and a project token carries none — so it 401s.
-
-## Config (ENV tab)
-
-Required:
-
-- `ZIBBY_PAT` — user personal access token the supervisor reads executions with.
-- `SLACK_CHANNEL` **or** `LARK_RECEIVE_ID` — where the review card goes.
-
-Optional:
-
-- `SUPERVISOR_PROJECT_ID` — project to supervise (defaults to the running project).
-- `SLACK_MENTIONS` / `LARK_MENTIONS` — JSON array of mentions on the card.
-
-## Input (per-run dials)
-
-| Field | Default | Meaning |
-|---|---|---|
-| `lookbackHours` | 24 | Hours of execution history to scan |
-| `minFailRate` | 0.4 | Flag an agent failing ≥ this fraction of recent runs |
-| `targetWorkflowTypes` | — | Optional name filter (case-insensitive substring) |
-| `maxPipelines` | 25 | Cap on distinct agents analyzed per run |
-
-## Trigger
-
-Cron — typically daily or hourly, depending on how active the supervised project is.
-
-## Deploy
-
-```bash
-zibby agent templates                                       # browse the marketplace
-zibby agent new pipeline-supervisor -t pipeline-supervisor  # scaffold
-zibby agent deploy pipeline-supervisor
-```

package/docs/recipes/sentry-triage.md

@@ -1,93 +0,0 @@
----
-sidebar_position: 3
-title: Sentry triage recipe
----
-
-# `sentry-triage` — agent-driven Sentry triage
-
-An hourly Sentry triage agent that fetches unresolved issues, classifies them by severity, and **routes them to the right human**. Three nodes, end-to-end agent-driven, deployed from the marketplace in one click.
-
-```
-fetch_issues  →  classify  →  dispatch_alerts
-(deterministic    (LLM —      (LLM —
- + Sentry API)    severity)    Slack/Lark, agent-driven routing)
-```
-
-## What it does
-
-1. **fetch_issues** — calls Sentry's REST API for issues unresolved + unassigned + `lastSeen:-60m`. Hydrates each with `suspectCommits[]` (author email from Sentry's GitHub integration) for downstream routing.
-2. **classify** — labels each issue `NOISE | LOW | MEDIUM | HIGH | CRITICAL` based on a configurable rubric (impact metric, surface area, payment paths, security tags). Skips below-threshold issues.
-3. **dispatch_alerts** — the routing brain. Three layers of decisioning:
-   - **Free-form `DISPATCH_RULES`** in env (highest priority) — natural language like *"send to Sam for billing issues"*
-   - **Structured env vars** — `SLACK_CHANNEL`, `ROUTING_PREFER_AUTHOR`, `ROUTING_HIGH_SEVERITY_GROUP`
-   - **Defaults** — channel-only post, threshold `MEDIUM`
-
-The agent uses [`slack_lookup_user_by_email`](../skills/slack), [`slack_list_usergroups`](../skills/slack), [`slack_search_users`](../skills/slack) (or the Lark equivalents) to resolve names → IDs, then `slack_post_message` / `lark_send_message` to deliver. Channel post, user DM, usergroup mention — same agent decides per-issue based on what you wrote in the rules.
-
-## Deploy from the marketplace
-
-```bash
-zibby agent templates deploy sentry-triage --project <project-id>
-```
-
-Or via the dashboard: `/marketplace/workflows` → Sentry Triage → Deploy.
-
-After deploy, configure ENV (Apps → agent → ENV tab):
-
-| Env var | Required? | Default | What it does |
-|---|---|---|---|
-| `SLACK_CHANNEL` *or* `LARK_RECEIVE_ID` | Yes (one of) | — | Channel id (Slack `C…`) / chat id (Lark `oc_…`) for fallback posts |
-| `SEVERITY_THRESHOLD` | No | `MEDIUM` | Skip anything below: `NOISE` / `LOW` / `MEDIUM` / `HIGH` / `CRITICAL` |
-| `ROUTING_PREFER_AUTHOR` | No | `false` | If `true`, when a suspect commit author is known, DM them |
-| `ROUTING_HIGH_SEVERITY_GROUP` | No | — | Slack usergroup handle (`@oncall`) mentioned on CRITICAL/HIGH |
-| `SLACK_MENTIONS` *or* `LARK_MENTIONS` | No | `[]` | JSON array of mentions prepended on CRITICAL only |
-| `DISPATCH_RULES` | No | — | Free-form natural-language override (see below) |
-
-## DISPATCH_RULES — natural-language routing
-
-When you set `DISPATCH_RULES`, the agent treats it as **authoritative**; the structured env vars become fallbacks for things the rules don't cover.
-
-```
-DISPATCH_RULES="
-- CRITICAL bugs in /payment/ → DM Sam and post to #incidents
-- HIGH severity → DM the suspect commit author if known, else post to #engineering
-- Anything mentioning 'security' → also mention the @security usergroup
-- Frontend bugs (zibby-frontend project) → only Sarah, never page on-call
-- NOISE → skip entirely
-"
-```
-
-The agent reads issue metadata (severity, message, tags, suspectCommit author email, project name) and applies rules in order. **Same rule + same issue is deterministic** — temperature 0, schema-enforced output, every dispatch records who got it and why under `dispatched[].recipient.{kind,id,label}`.
-
-## Author-DM path
-
-When `ROUTING_PREFER_AUTHOR=true` and Sentry has a `suspectCommits[0].author.email`:
-
-```
-1. agent reads issue.suspectCommits[0].authorEmail
-2. → slack_lookup_user_by_email(email)
-3a. ✓ returns {id, name}  → slack_post_message(channel: <user-id>, text: …)
-3b. ✗ users_not_found     → channel fallback
-```
-
-Requires the [Sentry → GitHub integration](https://sentry.io/settings/integrations/github/) installed and Code Mappings configured. Without it, `suspectCommits[]` is empty and the agent falls back to channel-only routing automatically.
-
-If you deployed your backend with `RELEASE_SHA` Sentry release-tracking on, suspect commits populate within ~minutes of new issues being created. (The platform-side wiring — `Sentry.init({release})` + `sentry-cli releases set-commits --auto` at deploy time — is what makes per-issue blame work; without it, every issue lands with `suspectCommits: []`.)
-
-## Customize the prompts
-
-Each node's prompt lives in its own module — fork the template, edit, redeploy:
-
-```bash
-zibby agent download <uuid>
-# edit nodes/dispatch-node.js
-zibby agent deploy ./sentry-triage   # same UUID, new version
-```
-
-Or fork the whole template repo if you want long-term divergence — it's just a `@zibby/workflow-templates/sentry-triage/` directory in the published package.
-
-## Cadence
-
-Default: hourly cron, fires `sinceMinutes=60`. Change in the trigger config (Apps → agent → Triggers) — keep the SQL safe `since` between 5 and 1440 minutes (`inputSchema` enforces this).
-
-→ Next: [`zibby test`](./test) (the browser-testing recipe) or [Build your own agent](../get-started/your-first-workflow).

package/docs/recipes/test.md

@@ -1,190 +0,0 @@
----
-sidebar_position: 2
-title: Browser test recipe (zibby test)
----
-
-# `zibby test` — browser test recipe
-
-The browser-test recipe takes a plain-English spec, drives a real browser via a coding agent (Cursor / Claude / Codex / Gemini), runs the assertions, and produces a Playwright script + verification video.
-
-It's a worked example of what the Zibby platform does — every step is a regular agent node with Zod-validated handoff. You can read the source, fork it, or build your own variation.
-
-## Quick start
-
-```bash
-# Inline spec
-zibby test "Go to https://example.com and verify the title is 'Example Domain'"
-
-# Spec file
-zibby test test-specs/login.txt
-
-# With a specific agent
-zibby test test-specs/checkout.txt --agent claude
-```
-
-## What it produces
-
-```
-.zibby/output/sessions/<session-id>/
-├── execute_live/
-│   ├── result.json          ← Zod-validated assertions + agent reasoning
-│   └── browser-trace/       ← Playwright trace files
-├── generate_script/
-│   ├── result.json          ← parsed script + metadata
-│   └── generated.spec.js    ← reusable Playwright test
-└── video/
-    └── recording.webm       ← visual verification
-```
-
-Open the session in [Zibby Studio](https://zibby.app/studio) to scrub through the run, swap the prompt, re-execute any node.
-
-## The graph (this is just a Zibby agent)
-
-Under the hood, `zibby test` is a 3-node graph:
-
-```
-   ┌──────────────┐    ┌──────────────────┐    ┌─────────────────┐
-   │  preflight   │ →  │   execute_live   │ →  │ generate_script │
-   │              │    │                  │    │                 │
-   │ extract      │    │ agent drives     │    │ produce         │
-   │ assertions   │    │ browser via MCP, │    │ Playwright      │
-   │ from spec    │    │ records video    │    │ test file       │
-   └──────────────┘    └──────────────────┘    └─────────────────┘
-        │                     │                       │
-     Zod out               Zod out                 Zod out
-   (Assertions)         (BrowserResult)         (PlaywrightScript)
-```
-
-Each node is a real `WorkflowGraph` node. The agent in `execute_live` does its own tool loop (browser navigation, click, assertion checking) — Zibby just defines the contract.
-
-## Customizing
-
-**Use a different agent per run:**
-```bash
-zibby test test-specs/checkout.txt --agent claude    # Claude Code
-zibby test test-specs/checkout.txt --agent cursor    # Cursor (default)
-zibby test test-specs/checkout.txt --agent codex     # OpenAI Codex
-```
-
-**Run only one node** (e.g. just regenerate the script from an existing run):
-```bash
-zibby test --session 1768974629717 --node generate_script
-```
-
-**Headless vs headed:**
-```bash
-zibby test test-specs/login.txt              # headed (default — see the browser)
-zibby test test-specs/login.txt --headless   # headless mode (for CI)
-```
-
-**Cloud-stored test cases (run a saved execution):**
-```bash
-zibby test --sources <id1>,<id2> --execution <executionId>
-```
-
-## Test memory
-
-The recipe ships with a learning loop: every run reads from and writes to a local Dolt DB at `.zibby/memory/.dolt/` (cross-spec, **per-domain**). Selectors that worked, page-element fingerprints, navigation transitions, and free-form insights are all persisted — the agent's 100th run on a site is sharper and cheaper than its first.
-
-When `zibby test` runs and the DB exists, the agent gets 5 MCP tools auto-exposed:
-
-- `memory_get_test_history` — recent runs (pass/fail/timing)
-- `memory_get_selectors` — known selectors with stability metrics
-- `memory_get_page_model` — page elements / roles / accessible names
-- `memory_get_navigation` — known page-to-page transitions
-- `memory_save_insight` — save observations (categories: `selector_tip | timing | navigation | workaround | flaky | general`). **Required at least once per run.**
-
-```bash
-zibby memory stats        # what's in the DB
-zibby memory cost         # real LLM token spend per spec / per domain
-zibby memory compact      # prune old runs + GC
-```
-
-**Team sync.** Point the DB at a remote and teammates' learnings flow back to you on the next test run:
-
-```bash
-zibby memory remote add aws://my-bucket/team/proj/main   # BYO (S3 / GCS / DoltHub / file:///)
-zibby memory remote use --hosted                         # OR Zibby-managed S3 (signed-in only)
-```
-
-Or commit `memorySync.remote: 'hosted'` (or an `aws://` URL) into `.zibby.config.mjs` and `zibby init` auto-wires it for every teammate.
-
-Auto-pull on test start, auto-push on test pass. Failing runs don't pollute team memory.
-
-→ Full guide: [Test memory](../tests/memory). Schema and SDK: [`@zibby/ui-memory`](../packages/ui-memory).
-
-## Forking the recipe
-
-If the built-in recipe doesn't fit your case, scaffold a custom agent and copy the structure:
-
-```bash
-zibby agent new my-test-agent
-```
-
-Then in `graph.mjs`, define your own nodes:
-
-```js
-import { WorkflowGraph, z } from '@zibby/agent-workflow';
-
-const AssertionsSchema = z.object({
-  assertions: z.array(z.string()),
-  baseUrl: z.string().url(),
-});
-
-const BrowserResultSchema = z.object({
-  passed: z.boolean(),
-  details: z.array(z.object({ assertion: z.string(), passed: z.boolean() })),
-  videoPath: z.string().optional(),
-});
-
-const graph = new WorkflowGraph();
-
-graph.addNode('preflight', {
-  agent: 'claude',
-  prompt: ({ spec }) => `Extract assertions and base URL from: ${spec}`,
-  outputSchema: AssertionsSchema,
-});
-
-graph.addNode('execute_live', {
-  agent: 'cursor',
-  skills: ['browser'],
-  prompt: ({ preflight }) => `Navigate to ${preflight.baseUrl} and verify: ${preflight.assertions.join('; ')}`,
-  outputSchema: BrowserResultSchema,
-});
-
-graph.addEdge('preflight', 'execute_live');
-graph.setEntryPoint('preflight');
-
-export default graph;
-```
-
-That's the platform. The recipe is just a starter.
-
-## CI/CD
-
-```yaml
-- name: Run Zibby test
-  env:
-    ZIBBY_USER_TOKEN: ${{ secrets.ZIBBY_USER_TOKEN }}
-  run: |
-    npx @zibby/cli test test-specs/checkout.txt --headless
-```
-
-For agents triggered remotely (rather than per-CI-run), use [`agent trigger`](../cloud/triggering) on a deployed graph.
-
-## Why this is different from Playwright codegen / a basic LLM script
-
-| | Playwright codegen | LLM-only script | Zibby test recipe |
-|---|---|---|---|
-| Plain-English input | ❌ | ✅ | ✅ |
-| Real browser execution | ✅ | ❌ (just generates code) | ✅ |
-| Coding-agent driven | ❌ | partial | ✅ Cursor / Claude / Codex |
-| Multi-step verification | ❌ | ❌ | ✅ Zod-validated nodes |
-| Replayable + debuggable | ❌ | ❌ | ✅ Studio |
-| Vendor-neutral | N/A | locked to one LLM | swap agent per run |
-
-## See also
-
-- [Recipes overview](./)
-- [Concepts: graph](../concepts/graph) — the primitives this recipe uses
-- [Cloud triggering](../cloud/triggering) — fire agents from CI/CD

package/docs/reviewing-results.md

@@ -1,114 +0,0 @@
----
-sidebar_position: 7
-title: Reviewing Results
----
-
-# Reviewing Results
-
-After running tests with `--sync`, all results are available in the Zibby dashboard for review.
-
-## Test Runs
-
-Go to your project's **Test Runs** page to see all executions.
-
-Each run shows:
-- Run name and timestamp
-- Pass/fail status
-- Video thumbnail (hover to preview)
-- Source (local spec or cloud test case)
-
-## Video Replay
-
-Click on a test run to open the full replay view:
-
-### Video Player
-
-- Full video recording of the browser session
-- Playback controls (play, pause, seek)
-- Speed control (0.5x, 1x, 1.5x, 2x)
-- Cinematic mode for full-screen viewing
-
-### Action Timeline
-
-A timeline below the video shows every action the AI performed:
-
-- **Navigate** — page navigations
-- **Click** — button and link clicks
-- **Type** — keyboard input
-- **Assert** — verification checks
-- **Screenshot** — captured screenshots
-
-Click any action to jump to that point in the video.
-
-### Events Sidebar
-
-A detailed list of all events with:
-- Timestamps
-- Action descriptions
-- Element selectors
-- AI-generated captions explaining each action
-
-## Generated Scripts
-
-The **Scripts** tab shows the auto-generated Playwright test script:
-
-```javascript
-const { test, expect } = require('@playwright/test');
-
-test('User Login Flow', async ({ page }) => {
-  await page.goto('https://example.com/login');
-  await page.fill('[data-testid="email"]', 'test@example.com');
-  await page.fill('[data-testid="password"]', 'TestPass123');
-  await page.click('[data-testid="submit"]');
-  await expect(page).toHaveURL('/dashboard');
-});
-```
-
-Click **Copy** to copy the script to your clipboard and add it to your test suite.
-
-## Test Case Details
-
-The **Test Case** tab displays the original test specification that was executed, with syntax highlighting.
-
-## Analysis Results
-
-For ticket analyses, the analysis page provides:
-
-### Code Diff Viewer
-
-- Side-by-side diff of all code changes
-- File tree navigation
-- **Create Pull Request** button to push changes to GitHub
-
-### Test Cases
-
-- Structured test cases with steps, data, and expected outcomes
-- Editable — refine test cases before running them
-- Auto-saves changes
-
-### Pipeline View
-
-Live status of each analysis step:
-
-| Step | Description |
-|---|---|
-| Setup | Repository cloned and initialized |
-| Analyze Ticket | AI reads and understands the ticket |
-| Generate Code | Code changes produced |
-| Generate Test Cases | Test cases written |
-| Finalize | Report compiled and uploaded |
-
-Each step shows logs that can be expanded for debugging.
-
-## Collections
-
-Organize runs into collections for grouping related tests:
-
-- View collections in the **Collections** sidebar
-- Each collection can have subfolders
-- Drag runs between collections
-- Filter and search within collections
-
-## Sharing Results
-
-Share a test run with your team by copying the URL from the browser. Anyone with access to the project can view the results.