@hasna/loops 0.4.11 → 0.4.13

package/CHANGELOG.md

@@ -5,6 +5,86 @@ documented in this file. Version entries are generated from the
 conventional-commit git history; one commit maps to one released patch version
 unless noted.
 
+## 0.4.13 (2026-07-05)
+
+`--pr-handoff` workflows whose worker pushes its own branch and opens the PR
+directly (no handoff artifact — the cursor pattern) now complete instead of
+failing the pr-handoff step and skipping the verifier.
+
+### Fixed
+
+- **pr-handoff — no-artifact/direct-PR path exited 1 instead of 0:** the step
+  runs as `bash -lc` (a login shell). The no-artifact guard ended with an
+  explicit `exit 0` while `set -e` was active; under systemd (`SHLVL` unset →
+  bash sets 1) an explicit exit sources `~/.bash_logout`, whose `clear_console`
+  fails without a controlling TTY, and errexit handed that failure back as the
+  step's exit code. The workflow failed, the verifier (which depends on
+  pr-handoff) was skipped, and the source task was stranded `in_progress`.
+  Both guard branches now route through bun heredocs and fall through the `if`'s
+  natural end — no top-level shell `exit` — so the intended status is preserved
+  on the local and remote execution paths alike (gate steps already ended
+  naturally, which is why only pr-handoff failed). (#34)
+
+### Added
+
+- **Worker-opened PR detection on the no-artifact path:** when no handoff
+  artifact exists, pr-handoff now looks up the worker's own open PR for the
+  workflow branch (`gh pr list --head <branch> --state open`), records the same
+  `openloops:pr-handoff=done task=… pr=… commit=… branch=…` comment the
+  artifact path records, and exits 0 — so direct-PR (cursor-style) completions
+  carry PR evidence into the verifier and merge lane. Best-effort and
+  fail-open on lookup: a missing PR or a `gh`/`git`/`todos` error is logged,
+  writes no done-evidence, and never fails the step. The artifact (codewith)
+  handoff path is unchanged. (#34)
+
+## 0.4.12 (2026-07-05)
+
+Drain throughput: `--max-active` is now a per-route ceiling instead of a
+store-wide one, drain dispatch spreads across subscription accounts by live load,
+and every step records the account it ran on.
+
+### Fixed
+
+- **Route admission — per-route `--max-active`:** the global admission count was
+  store-wide, so the busiest router's `--max-active` became a shared ceiling that
+  throttled every other router (average concurrency ~1.9 while the agent lane
+  allowed 12; ~253 items/24h deferred as `global active workflow limit reached`).
+  The global count is now scoped to the route/drain that set the limit; scope
+  precedence is an explicit `--max-active-scope <key>` first, then the running
+  loop's `LOOPS_LOOP_NAME`, then the route key as the final fallback — so each
+  router's `--max-active` is its own ceiling.
+  Existing routers get correct scoping with no config change. `project` and
+  `project_group` counts are unchanged: they remain cross-route anti-hog caps.
+- **Per-account attribution:** Codewith agent steps carry their subscription
+  account in `authProfile`, not an `AccountRef`, so `workflow_step_runs.account_profile`
+  was NULL for every drain worker and per-account burn could not be attributed.
+  The resolved auth profile (and provider as `account_tool`) is now recorded on
+  each step at run creation, and the per-role assignment is surfaced in drain
+  reports.
+
+### Added
+
+- **Least-loaded auth-profile pool selection + `--max-per-profile`:** pooled
+  Codewith dispatch picked a member by a pure hash of the work item, which stacked
+  several concurrent workers on one account at high concurrency and tripped
+  provider-side 429/stream-drop limits. Live drains now count running steps per
+  account and place each route on the least-loaded pool member (verifier/planner
+  still land on a different account than the worker; the hash is the deterministic
+  tie-break, so a cold store reproduces the prior assignment). New
+  `--max-per-profile <K>` (default 2 for pools of two or more, `0` disables) defers
+  a route when every pool account already has `K` running steps.
+
+Schema: additive sqlite migration `0008_work_item_route_scope` (nullable
+`workflow_work_items.route_scope`; its index is created only by the migration —
+never in the baseline DDL, which re-runs on every open and would crash pre-0008
+databases). `SCHEMA_USER_VERSION` is intentionally not bumped so an older binary
+can still open a database this migration touched (rollback-safe). Postgres gets
+the equivalent additive migration `0004_work_item_route_scope`; the released,
+checksummed `0002_workflows_goals` block is untouched so existing postgres
+ledgers keep verifying. Upgrade coverage: a real pre-0008 (0.4.11 schema)
+fixture database must open cleanly, gain the column + index, and keep its data;
+released postgres migration checksums are pinned in tests.
+
 ## 0.4.11 (2026-07-05)
 
 Scheduler fairness and PR-route hygiene: fast command loops no longer starve

package/README.md

@@ -38,6 +38,16 @@ package. Cloud mode is a public contract until a cloud-specific hosted URL and
 cloud token are configured through `LOOPS_CLOUD_API_URL` plus
 `LOOPS_CLOUD_TOKEN` or `HASNA_LOOPS_CLOUD_TOKEN`.
 
+Scheduler state is explicit in status JSON. `schedulerState.localStore` is
+SQLite plus local run artifact files: authoritative in `local`, cache/spool in
+non-local modes. `schedulerState.remoteStore` names the non-local contract
+(`api_control_plane_contract`, `postgres_contract`, or
+`hosted_control_plane_contract`) and reports `applySupported=false` because this
+public package does not directly mutate remote Postgres, S3/object storage, AWS
+resources, or hosted credentials. Route admission remains bounded by
+`max_dispatch`, `max_active`, `max_active_per_project`,
+`max_active_per_project_group`, `max_active_scope`, and `max_per_profile`.
+
 Useful status commands:
 
 ```bash
@@ -524,11 +534,12 @@ workflow unless the event data or metadata has `route_enabled=true`,
 `automation.allowed=true`, or a task tag containing `auto:route`. It also skips
 blocked, completed/done, cancelled/canceled, failed, archived, manual,
 approval-required, or `no-auto` tasks. Terminal route work items such as
-failed, dead-letter, cancelled, or succeeded history stay deduped until an
-operator runs `loops routes requeue <work-item-id> --reason "<cause fixed>"`.
-The next route-created output records `requeue` evidence with the previous work
-item id, previous attempts, operator reason, new attempt, workflow id, and loop
-id.
+failed, dead-letter, cancelled, or succeeded history are re-admitted only when
+the todos task is still actionable, the per-attempt backoff has elapsed, and the
+redispatch cap has not been reached. Operators can still force a retry with
+`loops routes requeue <work-item-id> --reason "<cause fixed>"`. The next
+route-created output records `requeue` evidence with the previous work item id,
+previous attempts, reason, new attempt, workflow id, and loop id.
 
 Task route drains can select providers from task metadata instead of running one
 fixed provider/account pool for the whole drain. Add one or more
@@ -594,8 +605,15 @@ This is the intended deterministic-to-agentic path: a producer creates a todos
 task, `@hasna/events` delivers `task.created`, OpenLoops records the invocation
 and admission item, OpenLoops creates a worker/verifier workflow when admitted,
 and the workflow updates todos with evidence. Use account pools so worker and
-verifier steps do not burn the same profile; OpenLoops picks deterministically
-and uses a different verifier profile when the pool has at least two entries.
+verifier steps do not burn the same profile. For live Codewith drains, OpenLoops
+spreads each route to the **least-loaded** pool account (counting running steps
+per account) and still keeps the verifier on a different profile than the worker;
+the deterministic hash is the tie-break, so a cold store reproduces the previous
+assignment exactly. `--max-per-profile <K>` (default 2 for pools of two or more,
+`0` to disable) defers a route when every pool account already has `K` running
+steps — the guardrail that keeps higher concurrency from stacking on one
+subscription and tripping provider-side rate limits. The chosen account per role
+is recorded on each step (`account_profile`) and surfaced in drain reports.
 Use `--dry-run` to inspect the rendered invocation, work item, workflow, and
 loop input without storing anything.
 
@@ -645,11 +663,21 @@ loops routes schedule todos-task oss-task-route-drain \
   --max-active-per-project 1 \
   --max-active-per-project-group 4 \
   --max-active 12 \
+  --max-per-profile 2 \
   --worktree-mode required \
   --evidence-dir "$HOME/.hasna/loops/reports/oss-task-route-drain" \
   --compact
 ```
 
+`--max-active` counts active routed workflows **per route**. Scope precedence:
+an explicit `--max-active-scope <key>` wins, else the running loop's
+`LOOPS_LOOP_NAME`, else the route key — so each router's limit is its own
+ceiling rather than a store-wide total shared by every router.
+`--max-active-per-project` and `--max-active-per-project-group` remain cross-route
+anti-hog caps counted over all routes. Raise a router's `--max-active`
+deliberately once counting is per-route; keep `--max-per-profile` set so the
+extra concurrency spreads across subscription accounts.
+
 Only route tasks that explicitly opt in with `auto:route`, `route_enabled=true`,
 or `automation.allowed=true`. Use Codewith account pools, required worktrees,
 max-active throttles, and bounded evidence directories. Do not dispatch or paste

package/dist/api/index.js

@@ -3,7 +3,7 @@
 // package.json
 var package_default = {
   name: "@hasna/loops",
-  version: "0.4.11",
+  version: "0.4.13",
   description: "Persistent local loop and workflow runner for deterministic commands and headless AI coding agents",
   type: "module",
   main: "dist/index.js",
@@ -194,6 +194,50 @@ function sourceOfTruthForMode(mode) {
     return "self_hosted_control_plane";
   return "cloud_control_plane";
 }
+var ROUTE_ADMISSION_GATES = [
+  "max_dispatch",
+  "max_active",
+  "max_active_per_project",
+  "max_active_per_project_group",
+  "max_active_scope",
+  "max_per_profile"
+];
+function remoteSchedulerBackendForMode(mode, config) {
+  if (mode === "local")
+    return "none";
+  if (mode === "cloud")
+    return config.cloudApiUrl ? "hosted_control_plane_contract" : "unconfigured";
+  if (config.databaseUrlPresent)
+    return "postgres_contract";
+  if (config.apiUrl)
+    return "api_control_plane_contract";
+  return "unconfigured";
+}
+function schedulerStateForMode(args) {
+  const nonLocal = args.deploymentMode !== "local";
+  return {
+    authority: args.sourceOfTruth,
+    localStore: {
+      backend: "sqlite",
+      role: args.localRole,
+      runArtifacts: "local_files",
+      routeAdmissionState: "workflow_work_items"
+    },
+    remoteStore: {
+      backend: remoteSchedulerBackendForMode(args.deploymentMode, args.config),
+      configured: nonLocal && args.controlPlaneConfigured,
+      applySupported: false,
+      objectArtifacts: nonLocal ? "object_store_contract" : "none",
+      mutatesAws: false
+    },
+    routeAdmission: {
+      stateStore: nonLocal ? "control_plane_contract" : "local_sqlite",
+      activeStatuses: ["admitted", "running"],
+      gates: ROUTE_ADMISSION_GATES,
+      dryRunEvaluatesLiveCounts: false
+    }
+  };
+}
 function displayControlPlaneUrl(value) {
   if (!value)
     return;
@@ -219,6 +263,9 @@ function buildDeploymentStatus(opts = {}) {
   if (deploymentMode === "self_hosted" && !controlPlaneConfigured) {
     warnings.push("self_hosted mode needs LOOPS_API_URL or LOOPS_DATABASE_URL before it can become authoritative");
   }
+  if (deploymentMode === "self_hosted" && config.databaseUrlPresent && !config.apiUrl) {
+    warnings.push("LOOPS_DATABASE_URL selects the self_hosted storage contract; loops-runner still needs LOOPS_API_URL to claim remote work");
+  }
   if (deploymentMode === "cloud" && config.apiUrl && !config.cloudApiUrl) {
     warnings.push("LOOPS_API_URL selects self_hosted; cloud mode uses LOOPS_CLOUD_API_URL");
   }
@@ -252,6 +299,13 @@ function buildDeploymentStatus(opts = {}) {
       required: deploymentMode !== "local",
       role: deploymentMode === "local" ? "daemon" : "control_plane_worker"
     },
+    schedulerState: schedulerStateForMode({
+      deploymentMode,
+      sourceOfTruth: sourceOfTruthForMode(deploymentMode),
+      localRole: deploymentMode === "local" ? "authoritative" : "cache_and_spool",
+      controlPlaneConfigured,
+      config
+    }),
     warnings
   };
 }
@@ -264,6 +318,7 @@ function deploymentStatusLine(status) {
     `source=${status.deploymentModeSource}`,
     `truth=${status.sourceOfTruth}`,
     `local=${status.localStore.role}`,
+    `scheduler=${status.schedulerState.routeAdmission.stateStore}`,
     `control_plane=${configured}`
   ].join(" ");
 }