file based ticketing system for agents, resides under the tickets folder
Install
Recommended for product/application repos: install MuonTickets as a git submodule.
curl -fsSL https://raw.githubusercontent.com/muonium-ai/muontickets/main/install.sh | bashIf you need a custom source repo for the submodule:
curl -fsSL https://raw.githubusercontent.com/muonium-ai/muontickets/main/install.sh | bash -s -- --repo https://github.com/muonium-ai/muontickets.gitTemplate form for your own fork:
curl -fsSL https://raw.githubusercontent.com/<org>/<repo>/main/install.sh | bash -s -- --repo https://github.com/<org>/<repo>.git
Use direct checkout (this repository itself) only when developing MuonTickets core.
Install MuonTickets as a git submodule in a new project
From your new project's root:
git init git submodule add https://github.com/muonium-ai/muontickets.git tickets/mt/muontickets git submodule update --init --recursive uv sync uv run python3 tickets/mt/muontickets/muontickets/mt.py init
Commit submodule onboarding files:
git add .gitmodules tickets/mt/muontickets tickets/
git commit -m "Add MuonTickets submodule and initialize board"Quickstart (uv)
For repos where MuonTickets is installed as submodule:
uv sync uv run python3 tickets/mt/muontickets/muontickets/mt.py init uv run python3 tickets/mt/muontickets/muontickets/mt.py validate
Common path mistake (submodule mode)
Wrong (installs/runs from the wrong location):
uv run python3 muontickets/mt.py init
Right (submodule under tickets/mt):
uv run python3 tickets/mt/muontickets/muontickets/mt.py init
If you are in a direct MuonTickets checkout, use the root entrypoint:
uv run python3 mt.py --help uv run python3 mt.py report --summary
Copy-paste: submodule + agent template workflow
Use this path when onboarding a fresh project and creating agent-ready tickets from template defaults:
# 1) Install as submodule git submodule add https://github.com/muonium-ai/muontickets.git tickets/mt/muontickets git submodule update --init --recursive # 2) Initialize board and template uv sync uv run python3 tickets/mt/muontickets/muontickets/mt.py init # 3) Optional: seed team playbook from shipped snippets cp tickets/mt/muontickets/muontickets/ticket.template tickets/ticket.template cp tickets/mt/muontickets/muontickets/agents.snippet docs/AGENTS.md # 4) Create and assign agent tickets from template defaults uv run python3 tickets/mt/muontickets/muontickets/mt.py new "Implement feature X" --label backend uv run python3 tickets/mt/muontickets/muontickets/mt.py claim T-000001 --owner agent-a
Version and Build Info (Bug Reports)
MuonTickets now uses the project-root VERSION file (major.minor) as the source of CLI version output.
Use these commands when filing bug reports from the field:
# Python reference CLI uv run python3 mt.py version --json # Rust port (build from source) ports/rust-mt/target/release/mt-port version --json # Zig port (build from source) ports/zig-mt/zig-out/bin/mt-zig version --json
Conventional global shortcuts are also supported:
uv run python3 mt.py uv run python3 mt.py -v uv run python3 mt.py --version ports/rust-mt/target/release/mt-port ports/rust-mt/target/release/mt-port -v ports/rust-mt/target/release/mt-port --version ports/zig-mt/zig-out/bin/mt-zig ports/zig-mt/zig-out/bin/mt-zig -v ports/zig-mt/zig-out/bin/mt-zig --version
Each command emits parseable build info (implementation + semantic version + toolchain versions) to make reports reproducible.
For Agents: Ticket Workflow
Agent quick-reference guide: see skills.md for install modes, command workflows, and best practices.
Developer utility scripts (benchmarks, conformance compare, ticket seeders): see tools/USAGE.md.
Troubleshooting rule: do not edit files under tickets/ directly for normal workflow actions (claim/status/comments/archive). Always use mt.py commands so transition checks, dependency checks, and metadata updates are applied consistently.
Execution guidance:
- Prefer one ticket fix per git commit and one pull request per ticket to keep reviews, rollback, and traceability clean.
- When tickets are isolated (no shared files, no dependency coupling, no system-wide side effects), run multiple agents in parallel. Parallel independent execution is a core MuonTickets use case.
- Prefer git worktrees for parallel agent isolation where available (one worktree per agent) to avoid clobbering local state.
- Use a branch-per-agent workflow and avoid direct development on
main/master. - Integrate via pull requests instead of direct commits to protected/default branches.
Sandbox-safe multi-agent workspace
- Keep transient artifacts under project-local
tmp/(not/tmp) to reduce sandbox/path permission issues. - Use per-agent subfolders such as
tmp/agent-a/,tmp/agent-b/for generated scratch files. tmp/is ignored in git excepttmp/.gitkeep, so the convention is available without polluting commits.- Prefer Makefile targets for build/test workflows where available, and include
make cleanas standard cleanup for project temp state. - Run a basic smoke test first (before full test suites) to catch breakage early and shorten feedback loops.
Run these from the project root where MuonTickets is installed.
# 1) Pull latest board state git pull # 2) Pick the best ready ticket and claim it uv run python3 tickets/mt/muontickets/muontickets/mt.py pick --owner agent-1 # 3) Inspect your claimed ticket(s) uv run python3 tickets/mt/muontickets/muontickets/mt.py ls --status claimed --owner agent-1 # 4) Add progress updates while implementing uv run python3 tickets/mt/muontickets/muontickets/mt.py comment T-000001 "Implemented parser and added tests" # 5) Move ticket to review when done coding uv run python3 tickets/mt/muontickets/muontickets/mt.py set-status T-000001 needs_review # 6) Validate board consistency before commit/push uv run python3 tickets/mt/muontickets/muontickets/mt.py validate
After merge, mark the ticket complete:
uv run python3 tickets/mt/muontickets/muontickets/mt.py done T-000001Archive, Backlogs, and Ticket IDs
- Active tickets live in
tickets/. - Completed tickets can be moved to
tickets/archive/usingmt archive. mt archiverefuses to move a ticket if active tickets still reference it independs_on(unless--force).mt validatereportsdepends_on archived ticket ...when an active ticket depends on an archived ticket.- Future/planned work can live in
tickets/backlogs/. - Ticket numbering is tracked in
tickets/last_ticket_id. - If
tickets/last_ticket_idis missing,mtautomatically rebuilds the next number by scanning ticket IDs acrosstickets/,tickets/archive/, andtickets/backlogs/.
Ticket Template (tickets/ticket.template)
- On first install and on
mt init, MuonTickets createstickets/ticket.templateif it does not already exist. - Users can edit this file to set default ticket metadata/body preferences.
mt new "Title"uses template defaults when available.- CLI args override template values when provided (for example:
--priority,--type,--effort,--label,--tag,--depends-on,--goal). - Existing
tickets/ticket.templatefiles are never overwritten by installer/init. createdandupdatedmetadata are timestamp-based (YYYY-MM-DDTHH:MM:SSZ).- Queue/runtime fields are supported in template defaults:
retry_count,retry_limit,allocated_to,allocated_at,lease_expires_at,last_error,last_attempted_at.
Examples:
# Edit defaults in tickets/ticket.template (for example: priority: p2, type: docs, effort: xs) # Create ticket with sequence from tickets/last_ticket_id uv run python3 tickets/mt/muontickets/muontickets/mt.py new "Implement feature X" # Override template defaults for one ticket uv run python3 tickets/mt/muontickets/muontickets/mt.py new "Hotfix auth" --priority p0 --type code --effort xs --label urgent --goal "Fix login regression" # Archive a completed ticket uv run python3 tickets/mt/muontickets/muontickets/mt.py archive T-000001
Agent setup using ticket templates
Use the shipped snippets to standardize agent onboarding in your project:
# optional: start from MuonTickets defaults cp tickets/mt/muontickets/muontickets/ticket.template tickets/ticket.template # optional: copy agent playbook snippet into your team docs cp tickets/mt/muontickets/muontickets/agents.snippet docs/AGENTS.md
Create tickets from template defaults, then assign to agents:
# create tickets with template defaults uv run python3 tickets/mt/muontickets/muontickets/mt.py new "Implement auth middleware" --label backend --tag sprint-1 uv run python3 tickets/mt/muontickets/muontickets/mt.py new "Add API contract tests" --type tests --label qa --depends-on T-000001 # claim tickets for specific agents uv run python3 tickets/mt/muontickets/muontickets/mt.py claim T-000001 --owner agent-a uv run python3 tickets/mt/muontickets/muontickets/mt.py claim T-000002 --owner agent-b # validate board before agents start work uv run python3 tickets/mt/muontickets/muontickets/mt.py validate
Autonomous Maintenance (mt maintain)
MuonTickets includes a built-in maintenance taxonomy of 150 rules across 9 categories (security, deps, code-health, performance, database, infrastructure, observability, testing, docs). The maintain command provides a scan-first, create-later workflow: verify issues exist before creating tickets that trigger CI/CD cycles.
Reference taxonomy: docs/muonium_autonomous_maintenance_rules.md. External tools setup: docs/maintenance_tools_setup.md.
Subcommands: init-config, doctor, list, scan, create.
Setup (mt maintain init-config / doctor)
# Generate default config (all tools disabled) uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain init-config # Auto-detect project stack and pre-enable matching tools uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain init-config --detect # Verify all enabled tools are installed and on PATH uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain doctor
init-config --detect scans for pyproject.toml, package.json, Cargo.toml, go.mod, Dockerfile, etc. and generates a tickets/maintain.yaml with the right tools pre-enabled for your stack.
doctor checks that every tool enabled in maintain.yaml is reachable on $PATH, reporting [OK] or [MISS] per tool.
Browse the taxonomy (mt maintain list)
# List all 150 maintenance rules with detection heuristics uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain list # Filter by category uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain list --category security # Filter by specific rule numbers uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain list --rule 2 --rule 48
Scan for issues (mt maintain scan)
Scan the codebase against maintenance rules. Reports PASS/FAIL/SKIP per rule. No tickets created. Invokes both built-in scanners and external tools configured in tickets/maintain.yaml.
# Scan security rules uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --category security # Scan all categories at once uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --all # Use a profile preset (ci: security+code-health+testing, nightly: all) uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --profile ci # Scan specific rules uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --rule 2 --rule 42 --rule 48 # JSON output for agent/LLM consumption uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --category code-health --format json # Show only new findings since last scan uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --all --diff # Auto-fix issues where tools support it (e.g. cargo fmt, black) uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --category code-health --fix
Built-in scanners detect: exposed secrets, hardcoded passwords, .env tracked in git, large files (>1000 lines), excessive TODOs, container running as root, broken doc links, stale README. Rules without built-in scanners use configured external tools from maintain.yaml, or report SKIP if unconfigured.
Exit codes: 0 = all pass, 1 = findings detected, 2 = config/argument error.
Create tickets for verified issues (mt maintain create)
Scans first, then creates tickets only for rules with findings. Rules that pass scanning are skipped. Ticket bodies include actual findings (file paths, line numbers) so fixing agents have full context.
# Scan + create tickets for failures and suggestions uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain create --category security # Create for all categories uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain create --all # Preview without creating uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain create --category docs --dry-run # Override priority, pre-assign to maintenance agent uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain create --category deps --priority p0 --owner agent-maint # Skip scanning -- create suggestion tickets for all rules (legacy behavior) uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain create --category testing --skip-scan
Configuration (tickets/maintain.yaml)
External tools are configured in tickets/maintain.yaml. Each tool can have:
enabled: true/false— whether to invoke during scancommand:— the shell command to run ({repo}is replaced with repo root)timeout:— per-tool timeout in seconds (overrides the globalsettings.timeout)fix_command:— auto-fix command used withmt maintain scan --fix
Deduplication
Running mt maintain create multiple times is safe. Each ticket is tagged maint-rule-{id}. Rules with existing open tickets are skipped.
Scan profiles
| Profile | Categories | Use case |
|---|---|---|
ci |
security, code-health, testing | Fast checks for CI pipelines |
nightly |
all 9 categories | Comprehensive nightly scans |
Scan diffing
--diff compares the current scan against tickets/maintain.last.json and shows only new findings. This is stored automatically after each scan.
Agent maintenance loop
# 1) Setup: generate config matching your stack uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain init-config --detect # 2) Verify tools are installed uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain doctor # 3) Scan for issues (CI cron or lightweight agent) uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --all --format json # 4) Create tickets only for verified failures uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain create --all # 5) Agents pick up maintenance work uv run python3 tickets/mt/muontickets/muontickets/mt.py pick --owner agent-maint-1 --label auto-maintenance # 6) After fix + merge uv run python3 tickets/mt/muontickets/muontickets/mt.py done T-000042 # 7) Next scan shows only new findings (dedup + diff) uv run python3 tickets/mt/muontickets/muontickets/mt.py maintain scan --all --diff
Generated tickets carry:
- Label:
auto-maintenance(filterable viamt ls --label auto-maintenance) - Tags:
maint-rule-{id},maint-cat-{category} - Title prefix:
[MAINT-NNN] - Body includes actual findings (file paths, line numbers) when scanner detected the issue
- Logging: all tool invocations are logged to
tickets/maintain.log
Reporting (SQLite)
Generate a local SQLite report database (not committed):
uv run python3 tickets/mt/muontickets/muontickets/mt.py report --summary
Run with search:
uv run python3 tickets/mt/muontickets/muontickets/mt.py report --search auth --limit 20
By default this creates tickets/tickets_report.sqlite3 and indexes ticket data from tickets/, tickets/archive/, tickets/errors/, and tickets/backlogs/.
Binary Releases (Preview)
Unified multi-platform release (Rust + Zig + C together):
# Push a tag like v0.9.0 to build Linux/macOS/Windows native artifacts
git tag v0.9.0
git push origin v0.9.0This triggers .github/workflows/combined-release.yml and publishes release assets for all implementations:
mt-rust-<arch>-<os>.tar.gz(Linux/macOS)mt-rust-<arch>-windows.zip(Windows)mt-zig-<arch>-<os>.tar.gz(Linux/macOS)mt-zig-<arch>-windows.zip(Windows)mt-c-<arch>-<os>.tar.gz(Linux/macOS)mt-c-<arch>-windows.zip(Windows)SHA256SUMS,SHA256SUMS.sig,SHA256SUMS.pem
Detailed operator runbook: see RELEASE_CHECKLIST.md.
Package-manager path (Cargo):
# install from source checkout cd ports/rust-mt cargo install --path .
Direct binary download path (GitHub Releases):
# macOS/Linux example (replace tag and artifact name as needed) curl -L -o mt-rust.tar.gz https://github.com/muonium-ai/muontickets/releases/download/vX.Y.Z/mt-rust-<arch>-<os>.tar.gz tar -xzf mt-rust.tar.gz
# Windows PowerShell example Invoke-WebRequest -Uri "https://github.com/muonium-ai/muontickets/releases/download/vX.Y.Z/mt-rust-<arch>-windows.zip" -OutFile "mt-rust.zip" Expand-Archive -Path "mt-rust.zip" -DestinationPath "."
Release integrity verification:
shasum -a 256 -c SHA256SUMS
cosign verify-blob --signature SHA256SUMS.sig --certificate SHA256SUMS.pem --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp '^https://github.com/muonium-ai/muontickets/.github/workflows/(combined-release|rust-release|zig-release).yml@refs/(tags/(v.*|rust-v.*|zig-v.*)|heads/main)$' SHA256SUMSChangelog Process
- User-visible changes must include an entry in
CHANGELOG.md. - Use this format per entry:
YYYY-MM-DD | Type | Summary. - Keep entries descriptive enough to trace feature/fix intent without internal ticket IDs.
- Add changelog updates in the same PR/commit as the code/docs change.