g6-adapt-rq

# G6 RQ integration `g6.integrations.adapt_rq` exposes a bounded RQ client. Its best state is `qualified-draft`. ## When to use it Submit a function the operator registered before the call, inspect failed jobs or request a bounded requeue. Jobs run in the separately operated worker; G6 never imports or executes caller code. ## When not to use it Do not use it for arbitrary Python, shell commands, choosing a Redis address, bulk recovery, worker administration or deciding whether a job's answer is correct. Registration is a trust decision, not containment of a function. ## Ops - `enqueue`: submit `function` with JSON `args` and `kwargs`. - `enqueue_at`: submit at timezone-aware `scheduled_at`. - `enqueue_in`: submit after `delay_seconds` (0 to one year). - `job_status`: read `job_id`; only queue status `finished` sets `queue_reports_finished`. - `cancel_job`: ask RQ to cancel `job_id`; this does not stop a running function or undo its effects. - `list_workers`: list at most `limit` worker reports for `queue_name`. - `queue_snapshot`: registry cardinalities without registry cleanup. - `list_failed`: at most `limit` failed job IDs, with truncation stated. - `requeue_failed`: attempt each of at most 100 supplied `job_ids`, with a separate outcome for every unique ID. ## Alone and composed All nine ops are sensitive: even reads contact Redis. Over MCP the operator must allow the desired `adapt_rq.<op>` in the server's sensitive-op configuration. `dry_run` defaults to true and opens no connection. Set `dry_run=false` to request execution after the server operator enables the op. Caller approvals are refused. These operations do not consult `g6.action_gating`: the boundary is registry sensitivity, default dry-run and the operator's function allow-list. Registered functions run on the operator's own worker. The operator calls `register_function("size", len)` in trusted Python server startup, before blocks are constructed. Names are kept in G6's process registry; registration must be repeated after restarting. There is no registration MCP op. A block snapshots the operator registry. A caller supplies only the registered name, never an import path. Trusted Python setup may inject its Redis connection and function mapping. The default connection is loopback port 6379 with three-second socket timeouts; injected connections must have bounded timeouts too. Compose queue reports with `grounding` before using a returned claim. Job status is the queue's report; `return_value_claim` is the function's claim, even after the queue reports completion. Read `completion_state`, `warning_card`, `evidence`, `request_id` and `run_id`. Partial recovery is `blocked-escalated` and retains successes and failures; inspect it before retrying. A connection error may follow a queue change, so never blindly resubmit. ## Failure modes it catches `unseen_job_failure`: status, failure registry membership and queue counts expose failures without waiting for a function to finish in G6. The allow-list rejects unregistered names before contacting Redis. Requeue rechecks the stored function and its JSON arguments against the current operator registry, and refuses jobs from another queue. It refuses callbacks, webhooks, retry/repeat settings, dependencies, unknown execution fields and extra retention settings with `G6_E_RQ_METADATA_REFUSED` per job. Recovery requires a 1-300 second timeout and 0-3600 second result retention; missing or unlimited values are refused before the queue changes. ## Blind spots - `unsafe_autonomous_action`: a trusted registered function can still have harmful effects in its worker. An argument validator specific to the registered function is the operator's responsibility. - `prompt_injection`: job return values can contain hostile instructions; they remain data. - Redis and the worker must be trusted and isolated. Another Redis writer can alter jobs between checks. JSON prevents pickle loading; it does not authenticate job content. Hash lengths are checked before fetching values, and received values are checked before JSON/base64 decoding or bounded zlib expansion. A hostile server or a concurrent writer can still cause oversized protocol responses; these client checks do not bound Redis itself. - Worker heartbeats show recent presence, not competence, correct serializer settings or future availability. A worker must use the JSON serializer. The worker is POSIX-only and G6 never starts it. - There is no independent result checker, automatic retry, rollback, deduplication or exactly-once guarantee. - Counts can include expired registry entries until RQ performs its own maintenance. Worker reads count and enumerate the same per-queue membership key, then read heartbeat/state fields directly; no worker objects or cleanup writes. Stale IDs without heartbeats are omitted, left in Redis and still count towards the 100-ID membership cap. Enumeration fetches at most 101 distinct IDs and refuses overflow, including growth after the count. All worker reads share one three-second deadline, checked before and after each read. An in-flight read is still subject to the operator's existing socket timeout; no connection timeout is changed. - Limits: 100 returned IDs/workers, 256 registered functions, 64 KiB JSON input/result, 4,096 JSON nodes (keys included), cumulative strings/ASCII-escaped bytes within that byte budget, 4,096-bit integers, nesting 20, a 300-second worker job timeout and one-hour result retention. Stored job hashes are capped at 64 fields, 64 KiB per field and 256 KiB total; decompression stops at the 64 KiB cap plus one overflow byte. Its tests run against an in-memory Redis stand-in (fakeredis), never a real server or worker, and were run with rq 2.12; other RQ versions are untried. ## What it needs Install `g6[rq]` separately: rq is BSD-2-Clause and redis-py is MIT. Missing packages give `G6_E_RQ_NOT_INSTALLED`; there is no fallback. No model or API key is used. **Redis server** is a user-installed outside program, reached over its network protocol; nothing from the server is linked or distributed. Redis up to 7.2 is BSD-3-Clause; 7.4 is RSALv2 or SSPLv1; 8.0 and later also offer AGPLv3. Protocol-compatible Valkey is BSD-3-Clause and may be used instead. Install the chosen server separately and start `redis-server --bind 127.0.0.1 --port 6379` or `valkey-server --bind 127.0.0.1 --port 6379`. G6 detects availability through PING, without licence/version detection, and returns `G6_E_OUTSIDE_PROGRAM_MISSING` with start instructions if absent. The rq extra's dependency closure is checked at landing. **rq worker** is a separate POSIX-only program (BSD-2-Clause). In its environment, make registered functions importable and run `rq worker --serializer rq.serializers.JSONSerializer --with-scheduler default`. G6 checks for a queue worker heartbeat no older than ten minutes before enqueue or requeue. It never invokes a local worker command. Use a queue dedicated to these functions, with access restricted by the operator. ## Examples These requests are plans or honest missing-extra refusals; no extra or server is needed to explain them. Sensitive examples are not executed by the skill conformance runner. ```g6-example op=queue_snapshot {} ``` ```g6-example op=enqueue {"function": "size", "args": [[1, 2, 3]]} ``` ```g6-example op=list_failed {"limit": 10} ``` ```g6-example op=requeue_failed {"job_ids": ["job-from-list-failed"]} ``` This Python example runs with no extra and no server: ```python from g6.integrations.adapt_rq import AdaptRQBlock, RQInput block = AdaptRQBlock(functions={}) refused = block.infer(RQInput(op="enqueue", function="not-registered")).unwrap() assert refused["code"] == "G6_E_RQ_FUNCTION_REFUSED" assert block.infer(RQInput(op="ops")).unwrap()["completion_state"] == "qualified-draft" ``` ## The four open problems - **Learning signals**: queue reports and per-ID recovery failures are evidence. No adaptive recovery policy is learned. - **Evaluators the model cannot influence**: fixed name checks and queue states replace caller assurances. A compromised Redis writer can still influence the evidence. - **Transfer by failure mode**: the same guards apply to every registered job name; unseen-workload catch rates are unmeasured. - **Enough held-out cases**: fixed regressions are written; no held-out evaluation or executed mutation result is claimed.