pullfrog 0.1.33 → 0.1.35

package/dist/utils/autoMerge.d.ts

@@ -1,37 +1,28 @@
 import type { ToolContext } from "../mcp/server.ts";
 /**
- * Run-end lifecycle action: merge ANY open PR that this run mechanically
- * approved on its current head — Pullfrog acting as a full repo maintainer,
- * contributor PRs included, not just merging its own work. There is deliberately
- * NO agent-callable merge tool — the merge is a pure, deterministic consequence
- * of the runtime observing a clean approved state, so a prompt-injected agent has
- * no merge surface to reach for. Every clause is fail-closed and re-verified
- * against GitHub's own state at merge time; any failure logs why and returns
- * without merging. Best-effort — the caller wraps this in a `.catch`, and a
- * merge/comment failure can never flip the run's outcome.
+ * Run-end lifecycle action: hand any PR this run mechanically approved on its
+ * current head to GitHub's NATIVE auto-merge — Pullfrog acting as a full repo
+ * maintainer, contributor PRs included. There is deliberately NO agent-callable
+ * merge tool — the merge is a deterministic consequence of the recorded approval
+ * verdict, so a prompt-injected agent has no merge surface to reach for.
  *
- * There is NO self-authorship restriction: the approval verdict IS the trust
- * decision (Pullfrog reviewed it and would approve), exactly like a human
- * maintainer merging a contributor PR. The population of mergeable PRs is bounded
- * upstream by the review triggers (`prCreated` / `prCreatedAllowNonCollaborator`)
- * — Pullfrog can only merge what it was configured to review + approve — and the
- * whole capability is opt-in per repo (clause 1). The remaining clauses are the
- * maintainer's controls.
+ * Native auto-merge waits for all REQUIRED checks + reviews (un-fakeable by a
+ * fork), respects the human veto via branch protection, and requires branch
+ * protection to exist. We keep only the Pullfrog-specific pre-gates GitHub can't
+ * express: armed toggles, approved-THIS-head, zero outstanding Pullfrog threads,
+ * no human CHANGES_REQUESTED. Best-effort — the caller wraps this in `.catch`,
+ * and a merge/comment failure can never flip the run's outcome.
  *
  * The invariant (all must hold):
  *   1. `ctx.autoMergeEnabled` — the per-repo toggle ANDed with the global
  *      `isAutonomousMaintenanceEnabled()` kill switch, server-side (run-context).
  *   2. `ctx.prApproveEnabled` — cannot auto-merge what it may not approve.
- *   3. this run recorded an APPROVE verdict (`toolState.approval.wouldApprove`) —
- *      Pullfrog's review is the merge decision.
+ *   3. this run recorded an APPROVE verdict (`toolState.approval.wouldApprove`).
  *   4. the PR is open and not a draft.
- *   5. `toolState.approval.sha === <current head sha>` — approved THIS head, so a
- *      commit pushed after the review can't ride the approval in (409-safe below).
+ *   5. `toolState.approval.sha === <current head sha>` — approved THIS head.
  *   6. `countOutstandingPullfrogThreads === 0` — re-queried at merge time.
- *   7. no un-dismissed human CHANGES_REQUESTED — the human veto always wins.
- *   8. GitHub reports the PR mergeable and not blocked/dirty/behind.
- *   9. every external check-run/commit-status on the head is complete and
- *      non-failing (`checkRunsGate`) — red or in-flight CI never auto-merges,
- *      even on a repo without branch protection.
+ *   7. no un-dismissed human CHANGES_REQUESTED at handoff.
+ * The remaining wait-for-required-checks + wait-for-required-reviews semantics
+ * are GitHub's, via native auto-merge and branch protection.
  */
 export declare function autoMergeAfterApprove(ctx: ToolContext): Promise<void>;

package/dist/utils/proxy.d.ts

@@ -16,6 +16,7 @@
  *
  *   - 402 → `BillingError` (card declined, balance empty, 3DS, etc.)
  *   - 503 → `TransientError` (transient sync issue — retry next dispatch)
+ *   - 404 → `TransientError` (stale repo↔account link — re-homes on next webhook)
  */
 import type { ToolState } from "../toolState.ts";
 import { type OidcCredentials } from "./github.ts";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pullfrog",
-  "version": "0.1.33",
+  "version": "0.1.35",
   "type": "module",
   "bin": {
     "pullfrog": "dist/cli.mjs",

package/dist/utils/checksGate.d.ts

@@ -1,45 +0,0 @@
-/**
- * Shared, dependency-free CI green/red predicate — the single source of truth for
- * "given these check-runs, is this PR head safe to merge?". Consumed by the
- * auto-merge path: `autoMerge.ts` gates the PR head at merge time, and the
- * `pr-merge-completion` webhook re-checks it before dispatching a slow-CI re-wake.
- * A red or in-flight sha never merges, and a sha with no confirmable green
- * check-run is treated as unverified (refused, not merged blind).
- *
- * Gates on the Checks API only. The Pullfrog App deliberately holds no `statuses`
- * permission (requesting it would force re-approval on every install — see
- * wiki/app-permissions.md), so the legacy Commit Statuses API is unreadable
- * (`listCommitStatusesForRef` 403s). Modern CI (GitHub Actions, etc.) reports via
- * check-runs; a repo relying on the legacy Statuses API is covered by branch
- * protection instead — a failing required status makes `mergeable_state` `blocked`,
- * which the merge invariant already refuses (`NON_MERGEABLE_STATES`).
- */
-export type CheckRun = {
-    name: string;
-    status: string;
-    conclusion: string | null;
-};
-/**
- * Refuse if any external check-run is incomplete (queued/in_progress) or concluded
- * anything other than success/neutral/skipped. Fail-closed on unknown/absent
- * conclusions. Pure so the pass/fail logic is inspectable directly.
- */
-export declare function checkRunsGate(params: {
-    checkRuns: CheckRun[];
-}): {
-    ok: boolean;
-    reason: string;
-};
-/**
- * true when the head has ≥1 CONCLUDED non-failing EXTERNAL check-run — CI
- * positively ran, not merely "no red was seen". paired with `checkRunsGate.ok`
- * (any completed check is non-failing), this == "≥1 concluded non-failing check".
- * the merge requires it: a head with ZERO check-runs passes
- * `checkRunsGate` (nothing red) but has no verification, and since the app can't
- * read legacy commit statuses, "zero check-runs" is indistinguishable from "green
- * Actions but a red CircleCI status" — so we only act on a head we can positively
- * confirm is green. Pullfrog's own verdict checks don't count as external CI.
- */
-export declare function hasVerifiedCheck(params: {
-    checkRuns: CheckRun[];
-}): boolean;