captchakraken 3.0.0 → 3.1.0

package/dist/solver.d.ts

@@ -44,7 +44,10 @@ export declare class CaptchaKrakenSolver {
     /** Answers keyed by screenshot hash; a hit means the answer already ran and changed nothing. */
     private solutionCache;
     private repeatedAnswerSeen;
-    /** The one recording and one answer for the animated board on screen. */
+    private retriedUnusableAnswer;
+    private knownAnimated;
+    private animatedProbeDone;
+    /** The one recording for the animated board on screen, and its answer until the widget refuses it. */
     private animatedPlan;
     private keyframeMode;
     private keyframeSteadyScreens;
@@ -54,6 +57,14 @@ export declare class CaptchaKrakenSolver {
     private resampleLevel;
     /** The recording `classifyByRecording` started and left running for the branch below to finish or drop. */
     private pendingBurst;
+    /**
+     * The camera on the animated board in front of us, running across rounds until that board is gone.
+     *
+     * Distinct from `pendingBurst`, which is the speculative film one round starts and the same round spends.
+     * This one outlives a rejected answer on purpose: it is the only thing that can give the next ask a
+     * different question to answer, since the answer itself is deterministic at temperature 0.
+     */
+    private animatedFilm;
     private lastBurstFps;
     private actedOnBoard;
     private lastSubmitFrameHash;
@@ -110,6 +121,13 @@ export declare class CaptchaKrakenSolver {
     /** The `--model` argv, or nothing: without VLLM_BASE_URL the CLI can see a credentials file this process cannot. */
     private modelName;
     private resolveCli;
+    /** What is LEFT of the solve, as a bound on one ask.
+     *
+     * The CLI is a child process and the solve deadline is only read between steps, so nothing stops an
+     * ask already in flight — measured against the hosted endpoint, one hung for ~124s inside a 45s
+     * budget and the attempt ran 143s. Never below the floor: a keyframe ask carries six images, and a
+     * timeout shorter than the work turns a busy endpoint into a guaranteed failure. */
+    private askTimeoutMs;
     /** One-shot CLI tool call; `{}` on any failure so polling callers keep going. */
     private runCliTool;
     /** Start the persistent CV worker once; false when it cannot start, so callers fall back to one-shot spawns. */
@@ -142,12 +160,22 @@ export declare class CaptchaKrakenSolver {
     private waitForAnyClickedTileLoaded;
     /** Click, watch the clicked tiles, re-solve while they swap, submit on `done` or a chipped board. */
     private solveRecaptchaGrid;
-    private recordKeyframeBurst;
     /**
      * Start filming now and decide later what it was for: the classifier, the speculative film, or the
      * recording an animated answer is sliced from. Every window is wall-clock. A cycle is a screen that
      * comes back; a board that shows nothing new for a floor window has settled. There is deliberately no
      * "enough screens, stop" exit: measured on number_with_highest_value_video it failed every seed either way.
+     *
+     * `continuous` keeps the camera rolling past the first answer, for the whole solve. A one-shot burst can
+     * only ever show the model the screens that happened to fall inside its window — measured, a 4s burst
+     * against a 5.3s cycle showed two screens of three, and when the answer lived on the third there was no
+     * second chance, because the reused answer is identical by construction. Filming on means every later
+     * round slices a STRICTLY LONGER film: more repetitions for `_detect_cycle` to confirm against, and, on a
+     * board that never repeats, six evenly-spread picks across the whole solve instead of across four seconds.
+     *
+     * Longer, but never of TWO boards. A vendor that deals a fresh puzzle on a miss has replaced everything
+     * filmed so far, and keyframes cut across both states describe neither. `resume` cuts the film where our
+     * answer landed; a screen from before the cut coming back is what un-cuts it. See `snapshot`.
      */
     private startKeyframeBurst;
     /** Slice a burst into keyframes and solve them in one model request. The frame number is the guard. */
@@ -163,15 +191,28 @@ export declare class CaptchaKrakenSolver {
     private resetSolveState;
     /** Keyed on the retry mode too: the missed-tiles answer legitimately overlaps the previous one. */
     private static answerSignature;
+    /** The recording still stands; dropping only the refused answer makes the retry an inference, not a burst. */
+    private invalidateAnimatedAnswer;
     /** True when this answer already ran and changed nothing: resample, and let the recording path have a go. */
     private noteAnswer;
     /** A cache hit costs no inference, and means the answer already ran: the board cycles. */
     private answerFor;
+    /**
+     * Drop the ANSWER, keep the camera.
+     *
+     * The two are deliberately separable. An answer the widget refused is spent — reusing it just presses the
+     * same wrong thing until the no-progress fence trips, three rounds in, with half the budget unspent. The
+     * film is the opposite: every second it keeps running makes the next slice a better question. So a
+     * refusal discards this and leaves `animatedFilm` alone; only a board that is GONE stops the camera.
+     */
     private discardAnimatedPlan;
+    /** The board is gone: its film can never describe the next one, so end it and free the frames. */
+    private stopAnimatedFilm;
     /** Static or animated, decided by filming once. The film stays running for the branch that uses it. */
     private classifyByRecording;
     private releasePendingBurst;
     private shouldSpeculate;
+    /** One second look per solve: a repeated answer arms it, and the recording it takes spends it. */
     private shouldRetryAsAnimated;
     private getSolution;
     /** One inference through the CLI. */