用途：在 SQLAlchemy 2.x 上构建可嵌入的、单机运行的数据库驱动就绪集任务队列。就绪性由依赖驱动（DAG 中每个任务在其上游完成后才可运行），关系数据库是唯一持久化底座，不需要消息代理或第二数据源。适用于长时运行、有状态、并发受外部资源或速率限制的任务，且需在 SQLite、PostgreSQL、MySQL 间可移植。
主要能力：核心是分方言的原子租约——PostgreSQL 与 MySQL 8+ 使用 SELECT ... FOR UPDATE SKIP LOCKED，SQLite 使用 BEGIN IMMEDIATE 写锁认领，防止同一任务被重复派发。在其上叠加崩溃恢复（心跳、租约过期、陈旧租约回收）、挂起任务超时、加权公平分配（按 group_key 与 weight 分配稀缺槽位），以及完整的 tick 循环（扫描→排序→认领→派发→持久化→回收）。数据模型为通用 jobs 行加 job_deps 边表，用部分索引使扫描保持 O(就绪集) 而非全表。整体以同步为优先，异步仅作简要说明。
使用方式：先确认任务形态符合上述场景，再定义 jobs 与 job_deps 模型，编写就绪集查询，按数据库方言分支实现原子认领，最后组合心跳续约、回收清扫与 tick 循环。需要 SQLAlchemy 数据层与 with_for_update(skip_locked=...) 原语时参见 sqlalchemy 技能；需要模式迁移时参见 alembic。
限制：MySQL 需 8.0+ 与 InnoDB，5.7 下 SKIP LOCKED 为语法错误；MySQL 需将认领事务设为 READ COMMITTED，因默认 REPEATABLE READ 可能读到旧快照；SQLite 无行级锁，with_for_update 静默无效，必须改用 BEGIN IMMEDIATE。不适合短时即发即弃任务、静态入队的多机扇出（更适合 Celery、Dramatiq、RabbitMQ）、cron 风格定时调度（APScheduler）或重型编排平台（Airflow、Prefect、Dagster）。具体 TTL 取值与超时后的升级策略由使用方决定。