@beryl-so/cli 0.45.0 → 0.46.1

package/README.md

@@ -175,6 +175,7 @@ Create and manage projects: a site Beryl explores, authors tests for, and runs.
 | `beryl projects get` | Show one project, including its current exploration state | `projects_get` |
 | `beryl projects create [url]` | Create a project. With a URL the agent starts exploring; with just --name an empty one | `projects_create` |
 | `beryl projects rename <name>` | Rename a project | `projects_rename` |
+| `beryl projects quarantine [state]` | Turn auto quarantine on or off and tune when it mutes and releases a test | `projects_quarantine` |
 | `beryl projects delete` | Delete a project and all its tests and runs | `projects_delete` |
 | `beryl projects re-explore` | Send the agent back in to run/heal existing tests and discover new flows | none |
 | `beryl projects report` | Aggregate quality report across recent runs (pass rates, flaky tests, trend) | `projects_report` |

package/dist/beryl-test-skill.js

@@ -159,7 +159,17 @@ An empty \`accounts list\` means nothing is set up. In order of preference:
 1. **The user has a dedicated test account** → bank it:
    \`beryl accounts create --email <email> --password <password>\`. A DEDICATED test
    account only — never a real user's.
-2. **No credentials, but the app has a signup form** → let Beryl make one.
+2. **Only Google (or another SSO) sign-in, no email+password form** → the same path:
+   ask for a DEDICATED Google test account and bank it with \`accounts create --email
+   --password\`. Its sign-in plan runs through Google's own pages — click the app's
+   Google button, fill \`#identifierId\` with \`{{login_email}}\`, click
+   \`#identifierNext\`, fill \`input[name=Passwd]\` with \`{{login_password}}\`, click
+   \`#passwordNext\`, then assert the app's signed-in shell. Store it with \`accounts
+   set-login\`, prove it with \`accounts check\`. Author its tests with \`auth_mode:
+   "session"\` only, so Google is signed in once per run, never per test. Google may
+   still challenge a scripted sign-in now and then ("Verify it's you"); the captured
+   session (end of §1) is the fallback for that, not the default.
+3. **No credentials, but the app has a signup form** → let Beryl make one.
    \`beryl accounts create --type beryl\`, then sign it up with
    \`beryl accounts signup <id> --file <signup-plan.json>\`. The plan is the app's own
    signup form as an ActionPlan, ending LOGGED IN, filling \`{{mailbox_address}}\` and
@@ -168,7 +178,7 @@ An empty \`accounts list\` means nothing is set up. In order of preference:
    or the record was lost) skips signup: store its sign-in with \`accounts set-login\`.
    No password sign-in? Pass \`--login-method otp\` (or \`magic_link\`) and let the plan
    \`await_email\` through; later sign-ins read the same mailbox.
-3. **Neither** → the flow is not testable authenticated. Say so rather than guessing.
+4. **Neither** → the flow is not testable authenticated. Say so rather than guessing.
 
 A project with no accounts falls back to the \`LOGIN_EMAIL\` variable +
 \`LOGIN_PASSWORD\` secret with the same handle resolution, so existing tests are
@@ -222,11 +232,13 @@ pending", "the share link is issued") — a real, strong outcome. While AUTHORIN
 drive the full handshake live: a second account (\`accounts create --label member\`), or
 a second mailbox (\`mailbox create --label invitee\`, read with \`mailbox read\`).
 
-SSO-only sites (no email+password form at all) ride a captured session instead: a human
-signs in once through a live browser view in the Beryl webapp, Beryl stores the session
-encrypted server-side and injects it into cloud runs — \`tests create\` verifies such
-plans server-side, \`runs trigger\` runs them, \`runs local\` skips them (the session
-never leaves Beryl's cloud).
+SSO-only sites are not a dead end: with a dedicated Google test account they follow §1
+item 2 like any password account. The captured session is the FALLBACK — no test account
+can be provided, or Google challenges the scripted sign-in: a human signs in once
+through a live browser view in the Beryl webapp, Beryl stores the session encrypted
+server-side and injects it into cloud runs — \`tests create\` verifies such plans
+server-side, \`runs trigger\` runs them, \`runs local\` skips them (the session never
+leaves Beryl's cloud).
 
 ## 2. Author locally over the Playwright MCP
 
@@ -349,14 +361,19 @@ Every one of these has produced a wrong plan or a red \`tests create\`. Check th
    \`text=X\` to a case-insensitive SUBSTRING — \`text=Continue\` is ambiguous. Use
    something unique (\`button[type=submit]\`, \`input[name=email]\`,
    \`input[autocomplete=one-time-code]\`).
-4. **A single-page app can redirect after the first \`goto\`.** If \`/dashboard\`
+4. **Google's sign-in pages carry decoys.** The identifier page already holds a hidden
+   \`input[type=password]\`, so a \`wait_for\` on it fires before the real field exists —
+   target \`input[name=Passwd]\`. Responsive layouts often render the app's "Continue
+   with Google" button twice (mobile + desktop); add \`:visible\` or use a structural
+   selector so the click is not ambiguous.
+5. **A single-page app can redirect after the first \`goto\`.** If \`/dashboard\`
    client-side redirects to \`/dashboard/<id>\`, a click fired straight after the goto
    lands on the pre-redirect render and is discarded on re-render. Put a \`wait_for\`
    on something that exists only AFTER the redirect, then act.
-5. **Never bake an id into a URL.** \`goto /projects/8ab46d63-.../settings\` breaks for
+6. **Never bake an id into a URL.** \`goto /projects/8ab46d63-.../settings\` breaks for
    any other account. Navigate to the stable entry point and click through
    (\`a[href$='/settings']\`) — the plan is about the app, not your row.
-6. **Assert durable content, not the empty state.** "No tests yet" is true today and
+7. **Assert durable content, not the empty state.** "No tests yet" is true today and
    false the moment anything exists. Prefer what is structural — a section heading, a
    permanent explainer, an always-present control.
 

package/dist/commands/accounts.js

@@ -65,6 +65,8 @@ export const testAccountCommands = [
             "the site: pass --email and --password, and it is usable immediately. `--type beryl` " +
             "reserves one Beryl will sign up itself, addressed at the project mailbox. It starts " +
             "`pending` and becomes usable after `beryl accounts signup`. " +
+            "Works for Google-only apps too: bank a dedicated Google test account as user_provided " +
+            "and author its sign-in plan through Google's form. " +
             "The first account an environment gets is its default whatever you pass.",
         scope: "project",
         flags: [
@@ -98,6 +100,7 @@ export const testAccountCommands = [
             "beryl accounts create --email qa@acme.test --password 'hunter2'",
             "beryl accounts create --type beryl --login-method otp",
             "beryl accounts create --email admin@acme.test --password 'hunter2' --label admin",
+            "beryl accounts create --email qa@gmail.com --password 'hunter2'  # Google-only app",
         ],
         async run(ctx, input) {
             const { workspaceId, projectId } = await ctx.requireProject(input);

package/dist/commands/projects.js

@@ -176,6 +176,53 @@ export const projectCommands = [
             };
         },
     },
+    {
+        name: "projects quarantine",
+        summary: "Turn auto quarantine on or off and tune when it mutes and releases a test",
+        description: "With auto quarantine on, the end of every run checks the tests that ran: a test that " +
+            "failed --failures times in the last --days days with a pass in between is " +
+            "quarantined (straight failures are a regression and never are), and a quarantined " +
+            "test, manual or auto, is released after --passes first-attempt passes in a row. " +
+            "Pass on|off and/or any of the numbers; `projects get` shows the current values.",
+        scope: "project",
+        args: [{ name: "state", description: "on | off; omit to only tune the numbers" }],
+        flags: [
+            { name: "failures", type: "number", description: "Failures in the window that quarantine a test (1-50, default 3)" },
+            { name: "days", type: "number", description: "Window in days (1-90, default 7)" },
+            { name: "passes", type: "number", description: "Passes in a row that release a test (1-50, default 5)" },
+        ],
+        examples: [
+            "beryl projects quarantine on",
+            "beryl projects quarantine on --failures 3 --days 7 --passes 5",
+            "beryl projects quarantine --passes 3",
+            "beryl projects quarantine off",
+        ],
+        async run(ctx, input) {
+            const { workspaceId, projectId } = await ctx.requireProject(input);
+            const body = {};
+            const state = input.args.state;
+            if (typeof state === "string" && state) {
+                const lower = state.toLowerCase();
+                if (lower !== "on" && lower !== "off") {
+                    throw new UsageError(`Expected "on" or "off", got "${state}"`);
+                }
+                body.auto_quarantine = lower === "on";
+            }
+            const failures = flagNum(input, "failures");
+            const days = flagNum(input, "days");
+            const passes = flagNum(input, "passes");
+            if (failures !== undefined)
+                body.quarantine_failures = failures;
+            if (days !== undefined)
+                body.quarantine_days = days;
+            if (passes !== undefined)
+                body.quarantine_release_passes = passes;
+            if (Object.keys(body).length === 0) {
+                throw new UsageError("Pass on|off or at least one of --failures, --days, --passes");
+            }
+            return { data: await ctx.client.patch(projectPath(workspaceId, projectId), body) };
+        },
+    },
     {
         name: "projects delete",
         summary: "Delete a project and all its tests and runs",

package/dist/commands/tests.js

@@ -587,9 +587,10 @@ export const testCommands = [
             "red lands in the run's quarantined_count and gates neither the run's verdict nor exit " +
             "codes, so it can't red-light a deploy. Use " +
             "it on a persistently flaky test instead of deleting it (which destroys the history) or " +
-            "asking support to deactivate it (which stops it running at all). After 5 consecutive " +
-            "clean passes the test reports rehab_ready (advisory only, nothing un-quarantines " +
-            "itself). `off` un-quarantines.",
+            "asking support to deactivate it (which stops it running at all). After the project's " +
+            "release threshold of consecutive clean passes (default 5) the test reports " +
+            "rehab_ready: a suggestion while auto quarantine is off, the actual release once " +
+            "`projects quarantine on` has turned it on. `off` un-quarantines.",
         scope: "project",
         args: [
             { name: "test-id", description: "Test id", required: true },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@beryl-so/cli",
-  "version": "0.45.0",
+  "version": "0.46.1",
   "description": "Beryl on the command line — projects, runs, the exploring agent, and an MCP server over the same commands.",
   "license": "MIT",
   "type": "module",
@@ -40,9 +40,11 @@
     "@types/node": "^26.1.1",
     "tsx": "^4.23.1",
     "typescript": "^7.0.2",
-    "vitest": "^4.1.10"
+    "vitest": "^4.1.11"
   },
   "overrides": {
-    "@hono/node-server": "2.0.11"
+    "@hono/node-server": "2.0.11",
+    "hono": "^4.13.5",
+    "@vitest/mocker": "^4.1.11"
   }
 }