Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[DEL-B3] Policy-based Agent Routing, Selective Activation and Durable Resource Accounting

Aperta
  • Qualcosa non va?
#321 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python
Ambito
ai, backend

Direzione di ricerca

Start from EPIC #315 and hard dependencies #316, #318, #319 to ground the baseline. Locate the controller and LLM Manager modules owning done acceptance and provider routing, and review ADR 0004 for effect ownership. Use deterministic fake provider with existing CLI integration tests to validate per-round and per-run bounds, keeping opt-in config backward compatible.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Parent: EPIC #315 · Stage M3 (adaptive coordination) · Size M · Reconciled 2026-10-25 (UTC) against main at f04db5f (state protocol 12). "Current scope" is authoritative. The earlier planning text follows verbatim and still applies where it does not conflict.

Current scope (reconciled 2026-10-25)

Policy-based agent routing, selective activation and durable resource accounting:

  • an explicit role-to-provider policy;
  • capability-aware provider selection;
  • deterministic routing from recorded policy inputs;
  • alternative providers only where they are configured;
  • no unapproved API or model fallback;
  • task-level and run-level budgets;
  • aggregate physical-launch counting;
  • runtime and storage bounds;
  • token and cost provenance;
  • explicit handling of unknown usage, which is never zero;
  • crash-safe accounting;
  • safe stop or pause outcomes;
  • candidate preservation.

Enforceable ceilings versus estimates. Launch counts, runtime and storage are enforceable. Token and cost figures are observational. A monetary ceiling that cannot be guaranteed is reported as an estimate, never enforced as if it were exact.

Ownership. #154 owns normalized usage semantics (cumulative versus delta, unknown usage). #126 owns durable operator interaction and pause/resume; until it lands, the outcome of exhaustion is the existing safe stop. This issue consumes both and creates no competing usage or interaction protocol. Minimum aggregate limits already ship with #319; this issue adds policy and adaptivity on top.

Dependencies
  • Hard (native): #316, #318, #319.
  • Blocks (native): #322, #323.
  • Coordination: #154, #126, #147.
Acceptance criteria (added 2026-10-25)
  • Routing is a deterministic function of recorded policy inputs and capability observations; replay reproduces it.
  • No provider, model or API change happens that the policy does not name.
  • Physical launches are counted across correction relaunches, transient retries and resumes, and the count survives a crash.
  • Unknown usage is recorded as unknown. A strict monetary ceiling with unknown usage stops or asks; it never assumes zero.
  • Reports separate enforced ceilings from estimates.

Earlier planning text (verbatim)

Superseded where it conflicts with "Current scope" above. In particular, minimum aggregate caps now ship with #319; this issue adds policy-based routing and adaptive activation.

Parent: EPIC #315 · Wave B · Size M · Planning baseline f4fd5ef (2026-10-25 UTC). Research: GVS5H, not an implementation dependency.

Objective / deliverable

Implement feature-off-by-default admission for low/medium/high complexity or explicit operator opt-in. Cap manager/worker/verification rounds, total cost/token/time, request count and storage; derive trusted usage from normalized summaries where available (#154), distinguish cumulative vs delta, unknown cost and subscription plans. No unsupported assumptions about dollar cost or unlimited subscriptions; no silent API/provider fallback. Kill or pause with preserved state/candidate on exhaustion. Route optional roles only among configured Claude/OpenCode/Pi adapters after capability probe; heterogeneous model routing remains experiment not default.

Dependencies

  • Hard: #316 (DEL-A1)
  • Hard: #318 (DEL-A3)
  • Hard: #319 (DEL-B1)
  • Coordination only: #147 SDK providers / #126 interactions, #154 usage, #176 scheduler and #266 sandbox. Do not add blanket cross-EPIC hard blockers without evidence.

Acceptance criteria

  • Default one-agent behavior and existing config remain unchanged, strict config validation for opt-in options
  • Deterministic stop on per-round and per-run bounds, including crash resume and unknown usage
  • No unapproved provider change, no rate-card hallucination, no bypass of step/review budgets
  • Metrics include overhead and cost-per-validated-success with explicit unknown/estimated provenance
  • Token-cost/success tradeoff thresholds and activation policy tied to baseline evidence from #318 (DEL-A3)
  • Regression tests preserve original single-agent path, ADR 0004 controller-owned effects, exact candidate validation, ReviewCertificate and merge safety; provider credentials remain isolated.
  • Docs/doctor/config compatibility updated where behavior changes; skipped real-runtime evidence never reported as pass.

Invariants / exclusions

The LLM Manager is advisory. Controller exclusively owns done acceptance, typed GitHub effects, state transitions, candidate identities and merge. Inner tasks are not GitHub native sub-issues and do not modify EPIC graph. Neither Agent nor verifier may execute repository-controlled commands outside the existing sandbox. No unbounded raw transcript/reasoning recording or ambient credentials. Feature remains opt-in; no Public Alpha #255 gate. Coordinate persisted schema on #23 before migration. Do not copy GVS5H's arbitrary subprocess verifier or its text-hash scratchpad and call it production recovery.

Verification hints

Use deterministic fake provider plus real existing CLI integration where available; include redacted bounded evidence, attack cases, failure/cancel/resume, explicit run/issue/candidate SHA. No new orchestration daemon or scheduler.

Lingua principale
Python
Stelle
0
Fork
0
Merge medio
5h 51m
PR unite (30g)
73

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di iceboundrock/AutoForge

Tutte le issue di iceboundrock/AutoForge

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.