Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/onenot8/issueLoop/llms.txt

Use this file to discover all available pages before exploring further.

The issueloop Python package exposes a flat public API — every function is available directly on the top-level module. Import issueloop once and call issueloop.use(...) at startup to configure the database, LLM provider, and notification settings. After that, every other function is ready to call without additional imports or setup.
import issueloop

issueloop.use(
    database="local",
    llm={
        "providers": [
            {"provider": "anthropic", "model": "claude-sonnet-4-6", "api_key": "sk-..."},
            {"provider": "ollama", "model": "qwen2.5-coder:7b"},
        ]
    },
    notify={"webhook": "https://your-endpoint"},
)

API categories

Scan & Test

scan_repo, run_tests, run_single_test, create_tickets, and get_file_inventory — the pipeline entry points that discover files, run your test suite, and convert failures into tickets.

Ticket Lifecycle

get_top_error, resolve, fail, escalate, reassign, retry_bug, bulk_resolve, and get_bug_attempts — claim, advance, and close tickets.

Bug Query

get_all_bugs, get_unresolved_bugs, search_bugs, get_bugs_by_status, get_bugs_by_priority, and more — read-only inspection of the ticket database.

Fix-Apply

propose_fix, apply_fix, check_permission, and get_permission_audit_log — permission-gated shell command execution with automatic test re-verification.

Live Monitoring

watch_process, watch_log_file, stop_watch, and list_active_watchers — real-time error detection from running processes and log files.

LLM & Tokens

get_token_consumption, get_token_consumption_by_provider, get_llm_call_history, and get_llm_provider_status — audit LLM spend and debug provider configuration.

Database

cleanup, purge_repo, get_database_stats, export_bugs, reap_stale_bugs, and rotate_logs — long-term ticket store maintenance.

Config & Utils

use, get_config, list_repos, health_check, get_crash_log, and get_notification_config — setup and system diagnostics.

Ticket object shape

Every function that returns a ticket — get_top_error, get_all_bugs, propose_fix, retry_bug, and so on — returns a dict with the following fields. Status and priority values are always lowercase strings.
{
    "id": "uuid",
    "repo": "myrepo",
    "priority": "blocking" | "high" | "normal" | "low",
    "status": "pending" | "in_progress" | "blocked" | "done" | "failed" | "needs_human",
    "error_summary": "...",
    "raw_log_ref": "...",
    "command": "...",
    "test_id": "...",
    "attempts": 0,
    "escalation_summary": None,
    "proposed_fix": None,
    "created_at": "2024-01-01T00:00:00+00:00",
    "resolved_at": None,
    "dispensed_at": None,
}
FieldTypeDescription
idstrUUID assigned at creation
repostrRepository name from the manifest
prioritystrOne of blocking, high, normal, low — set by LLM triage
statusstrCurrent lifecycle status
error_summarystrHuman-readable summary produced by LLM triage
raw_log_refstrReference to the source JSONL log entry
commandstrThe test command that produced this failure
test_idstrThe test identifier from test_manifest.json
attemptsintNumber of fix attempts made so far
escalation_summarystr | NoneReason stored when the ticket is escalated
proposed_fixstr | NoneShell command stored by propose_fix()
created_atstrISO 8601 UTC timestamp
resolved_atstr | NoneISO 8601 UTC timestamp, set on resolution
dispensed_atstr | NoneISO 8601 UTC timestamp, set when claimed via get_top_error()

Build docs developers (and LLMs) love