README.md's Roadmap lists: "Add a scheduled job for BountiesService.expireOverdue() (deadline sweeps) and recurring MaintenancePool deposits." The expireOverdue half is already tracked (see the existing dead-code/no-scheduled-job issues for it). The maintenance-pool half is not separately tracked: MaintenancePoolService.deposit() is exclusively triggered by a sponsor calling POST /maintenance-pools/:id/deposit — there is no @Cron-scheduled (or any other automated) recurring deposit mechanism anywhere in the codebase, despite MaintenancePool.monthlyDeposit and the entity's own doc comment ("Sponsors can deposit into it repeatedly (recurring funding...)") both implying an expected regular cadence. Today, if a sponsor forgets to manually re-deposit, nothing notices or prompts them — the "recurring" nature of a maintenance pool is purely a naming convention on the monthlyDeposit field, not an enforced or automated behavior.
README.md's Roadmap lists: "Add a scheduled job for
BountiesService.expireOverdue()(deadline sweeps) and recurringMaintenancePooldeposits." TheexpireOverduehalf is already tracked (see the existing dead-code/no-scheduled-job issues for it). The maintenance-pool half is not separately tracked:MaintenancePoolService.deposit()is exclusively triggered by a sponsor callingPOST /maintenance-pools/:id/deposit— there is no@Cron-scheduled (or any other automated) recurring deposit mechanism anywhere in the codebase, despiteMaintenancePool.monthlyDepositand the entity's own doc comment ("Sponsors can deposit into it repeatedly (recurring funding...)") both implying an expected regular cadence. Today, if a sponsor forgets to manually re-deposit, nothing notices or prompts them — the "recurring" nature of a maintenance pool is purely a naming convention on themonthlyDepositfield, not an enforced or automated behavior.