@phnx-labs/agents-cli 1.22.119 → 1.22.121

package/dist/lib/accounting/account-pool-collect.js

@@ -3,19 +3,7 @@ import { hasKeychainTokenSync, isSecretsTransportError } from '../secrets-client
 import { getGlobalDefault, listInstalledVersions } from '../installations/versions.js';
 import { collectRunCandidates } from './rotate.js';
 import { registryPoolCandidates } from './account-pool.js';
-/**
- * Provider accounts whose credential is present on THIS device, as capability
- * records. A registry entry with no local secret is skipped: including it would
- * let `--strategy balanced` pick an account that then fails at spawn and exits the
- * whole run (`resolveSpawnAccount` throws on a missing credential) instead of
- * rotating to a healthy one.
- */
 function localRegistryRecords() {
-    // Read-only launch input: an unreachable standalone `secrets` (missing binary,
-    // timeout, non-JSON) must not abort the run — it just means no provider
-    // accounts are foldable here, so the run proceeds on the native login rather
-    // than hanging or crashing (PHNX-3989, honoring the ≤3s sync bound). A genuine
-    // non-transport error still throws. DIST-1 holds: no embedded-engine fallback.
     try {
         return Object.values(readAccountRegistry().accounts)
             .filter((a) => hasKeychainTokenSync(a.secretRef))
@@ -27,17 +15,6 @@ function localRegistryRecords() {
         throw err;
     }
 }
-/**
- * PURE: fold provider-account candidates into the native version-home list.
- *
- * A registry account runs in `runVersion` (the agent's default installed home);
- * the token/key overrides that home's own login at exec, so any home works. It
- * carries `providerAccount` so the run path routes it through the existing
- * `--account` injection (`resolveSpawnAccount` → `accountEnv`). An account already
- * covered by a native login is skipped by accountKey. With no installed version
- * there is nowhere to execute a registry account, so the native list passes
- * through unchanged.
- */
 export function foldRegistryCandidates(agent, inputs) {
     const { native, records, runVersion } = inputs;
     if (!runVersion)
@@ -57,11 +34,6 @@ export function foldRegistryCandidates(agent, inputs) {
         usageError: null,
         usageMinutesToLimit: null,
         plan: null,
-        // Derive from the record's real secret-presence field rather than a bare
-        // `true` literal (PHNX-3502). Inert on today's only producer
-        // (`localRegistryRecords` already filters token-less accounts before the
-        // map), but keeps the field honest for any injected record that carries
-        // `secretPresent: false`.
         signedIn: r.secretPresent,
         authVerdict: null,
         lastActive: null,
@@ -70,20 +42,6 @@ export function foldRegistryCandidates(agent, inputs) {
     }));
     return [...native, ...extra];
 }
-/**
- * Candidate list for the `agents run` strategy pick, account-centric: the usual
- * native version-home candidates PLUS one candidate per provider account whose
- * provider can authenticate `agent` and whose credential is present locally
- * (RUSH-3182). This is what makes a setup-token / API-key account balance-eligible.
- *
- * Passed as the `collect` argument to {@link resolveRunVersion} on the RUN path,
- * and used by session recovery (`resolveSessionRecovery`, PHNX-3626) so an
- * origin-account limit can rotate to a healthy provider account and stay NATIVE.
- * The other consumers of {@link collectRunCandidates} (watchdog, teams
- * placement) keep calling it directly and are unaffected. The existing
- * {@link pickBalancedCandidate} selects over the combined list, so the
- * revoked / rate-limit / exhausted logic is unchanged.
- */
 export async function collectRunCandidatesForRun(agent) {
     const native = await collectRunCandidates(agent);
     const runVersion = getGlobalDefault(agent) ?? listInstalledVersions(agent)[0];

package/dist/lib/accounting/account-pool.d.ts

@@ -1,61 +1,20 @@
 import type { AgentId } from '../types.js';
 import type { AccountAuthKind } from '../account-provider-registry.js';
-/**
- * The provider-account side of the run-candidate pool (RUSH-3182).
- *
- * `--strategy balanced` used to enumerate only version-home native logins, so a
- * setup-token / API-key account added via `agents accounts add` never balanced.
- * This module turns the account registry into the extra candidates the run path
- * folds in — see `collectRunCandidatesForRun` in `account-pool-collect.ts`.
- *
- * Pure + dependency-light so the harness-capability filter is unit-tested in
- * isolation with fixtures.
- */
-/** A provider account record as stored in the registry (identity captured separately). */
 export interface RegistryAccountRecord {
     id?: string;
     name: string;
     provider: string;
     auth: AccountAuthKind;
-    /**
-     * Whether this account's secret is actually present on THIS device
-     * (`hasKeychainToken(secretRef)`, checked by the record's builder). Carried
-     * through rather than assumed, so a candidate's `signedIn` reflects a real
-     * check instead of a literal disconnected from it (PHNX-3502) — a registry
-     * entry can exist with no local secret (added on another device, or
-     * revoked), and folding it in as unconditionally signed-in would let
-     * `--strategy balanced` pick an account that fails at spawn.
-     */
     secretPresent: boolean;
 }
-/** A registry account eligible to run one harness, ready to map to a candidate. */
 interface RegistryAccountInput {
     id?: string;
-    /** Agent-scoped key so `(claude, X)` and `(codex, X)` stay distinct. */
     accountKey: string;
     email: string | null;
     name: string;
     provider: string;
     auth: AccountAuthKind;
-    /** See {@link RegistryAccountRecord.secretPresent}. */
     secretPresent: boolean;
 }
-/**
- * Which provider accounts can authenticate `agent`. An account is a candidate for
- * harness H only when its provider adapter has an `envFor(H, kind)` mapping
- * (`providerAuthenticatesHarness`, the same check the account UI uses) — so a
- * Cursor key never enters Claude's pool and a Claude setup-token never enters
- * Codex's. This is registry-driven, no per-harness `else if`: a harness gets a
- * provider-account pool exactly when the adapter table maps a provider to it —
- * today claude, codex, grok, cursor, opencode (plus gemini/antigravity). A harness
- * with only a native OAuth login and no provider adapter — kimi — returns `[]`
- * here and keeps balancing its native logins only.
- *
- * `accountKey` is synthetic here (`${agent}:name=${name}`) — a stable per-account
- * key so balancing can include it immediately; the real agent-scoped identity
- * (email / org uuid) is backfilled by identity capture and replaces it. `email`
- * is null until then, which routes the account as usage-unverified but still a
- * candidate, never excluded.
- */
 export declare function registryPoolCandidates(records: RegistryAccountRecord[], agent: AgentId): RegistryAccountInput[];
 export {};

package/dist/lib/accounting/account-pool.js

@@ -1,21 +1,4 @@
 import { providerAuthenticatesHarness } from '../account-provider-registry.js';
-/**
- * Which provider accounts can authenticate `agent`. An account is a candidate for
- * harness H only when its provider adapter has an `envFor(H, kind)` mapping
- * (`providerAuthenticatesHarness`, the same check the account UI uses) — so a
- * Cursor key never enters Claude's pool and a Claude setup-token never enters
- * Codex's. This is registry-driven, no per-harness `else if`: a harness gets a
- * provider-account pool exactly when the adapter table maps a provider to it —
- * today claude, codex, grok, cursor, opencode (plus gemini/antigravity). A harness
- * with only a native OAuth login and no provider adapter — kimi — returns `[]`
- * here and keeps balancing its native logins only.
- *
- * `accountKey` is synthetic here (`${agent}:name=${name}`) — a stable per-account
- * key so balancing can include it immediately; the real agent-scoped identity
- * (email / org uuid) is backfilled by identity capture and replaces it. `email`
- * is null until then, which routes the account as usage-unverified but still a
- * candidate, never excluded.
- */
 export function registryPoolCandidates(records, agent) {
     const out = [];
     for (const r of records) {

package/dist/lib/accounting/capacity.d.ts

@@ -1,35 +1,3 @@
-/**
- * Remaining-capacity weighting for account selection — a pure, dependency-free
- * primitive shared by the version-home router (`rotate.ts`) and the account pool
- * (`account-pool.ts`). Kept in its own module so either can import it without
- * dragging in the heavy usage/secrets graph.
- */
-/**
- * How far from its projected cap an account must be to keep its FULL headroom
- * weight. Inside this horizon the weight is scaled down linearly toward the
- * floor, so an account racing toward its 5h cap loses priority before it maxes.
- */
 export declare const PROJECTION_HORIZON_MIN = 30;
-/**
- * The weight an account with NO usage snapshot draws. Absence of a usage signal
- * is NOT capacity (specifications.md GWT-E5c, SING-1a): a null snapshot means
- * "unverifiable", not "empty" — on a worker box every account reads null
- * (setup-token lacks the `user:profile` scope, RUSH-2392), so scoring null as
- * full capacity made the blind pool's top pick an account that was actually
- * weekly-exhausted (PHNX-3392). Floored at 1, never 0: an all-unverified pool
- * must still draw a pick rather than strand the launch.
- */
 export declare const UNVERIFIED_WEIGHT = 1;
-/**
- * Weight one candidate by remaining routing capacity, deprioritized by how soon
- * it is projected to cap. The base is weekly headroom (`max(1, 100 - used)`);
- * an account with no live snapshot is NOT full-capacity — absence of a usage
- * signal is not evidence of headroom, so it draws `UNVERIFIED_WEIGHT` and any
- * verified-healthy account outranks it (GWT-E5c). `minutesToLimit` (the daemon's
- * burn-rate projection on the 5h session window) then scales that base: >=
- * horizon (or unknown) keeps full weight, and closer-to-cap scales toward the
- * floor of 1 — so a launch avoids an account projected to cap soon, not just a
- * 100%-maxed one. Pure + exported so the deprioritization is unit-tested
- * directly (a weighted-random draw is not).
- */
 export declare function capacityWeight(usedPercent: number | null, minutesToLimit: number | null): number;

package/dist/lib/accounting/capacity.js

@@ -1,37 +1,5 @@
-/**
- * Remaining-capacity weighting for account selection — a pure, dependency-free
- * primitive shared by the version-home router (`rotate.ts`) and the account pool
- * (`account-pool.ts`). Kept in its own module so either can import it without
- * dragging in the heavy usage/secrets graph.
- */
-/**
- * How far from its projected cap an account must be to keep its FULL headroom
- * weight. Inside this horizon the weight is scaled down linearly toward the
- * floor, so an account racing toward its 5h cap loses priority before it maxes.
- */
 export const PROJECTION_HORIZON_MIN = 30;
-/**
- * The weight an account with NO usage snapshot draws. Absence of a usage signal
- * is NOT capacity (specifications.md GWT-E5c, SING-1a): a null snapshot means
- * "unverifiable", not "empty" — on a worker box every account reads null
- * (setup-token lacks the `user:profile` scope, RUSH-2392), so scoring null as
- * full capacity made the blind pool's top pick an account that was actually
- * weekly-exhausted (PHNX-3392). Floored at 1, never 0: an all-unverified pool
- * must still draw a pick rather than strand the launch.
- */
 export const UNVERIFIED_WEIGHT = 1;
-/**
- * Weight one candidate by remaining routing capacity, deprioritized by how soon
- * it is projected to cap. The base is weekly headroom (`max(1, 100 - used)`);
- * an account with no live snapshot is NOT full-capacity — absence of a usage
- * signal is not evidence of headroom, so it draws `UNVERIFIED_WEIGHT` and any
- * verified-healthy account outranks it (GWT-E5c). `minutesToLimit` (the daemon's
- * burn-rate projection on the 5h session window) then scales that base: >=
- * horizon (or unknown) keeps full weight, and closer-to-cap scales toward the
- * floor of 1 — so a launch avoids an account projected to cap soon, not just a
- * 100%-maxed one. Pure + exported so the deprioritization is unit-tested
- * directly (a weighted-random draw is not).
- */
 export function capacityWeight(usedPercent, minutesToLimit) {
     const base = usedPercent === null ? UNVERIFIED_WEIGHT : Math.max(1, 100 - usedPercent);
     if (minutesToLimit === null || !Number.isFinite(minutesToLimit))