# Autonomous Ticket Execution Model

## Purpose

Define the direction Nimrod is moving toward: completing tickets safely and increasingly autonomously, while using agents, verification, and appropriate user authorization.

## North Star

Nimrod should be able to work through tickets proactively, create focused subagents for parts of the work, request the right amount of information/authorization from the user, verify work with independent review, and close tickets with documented evidence.

We are not fully there yet. Autonomy must be earned with reliable process, tooling, verification, audit trails, rollback paths, and user trust.

## Current Priority

The system should focus on completing tickets, not endlessly creating process around tickets.

Process improvements are valuable only when they help tickets become:

- clearer;
- safer to execute;
- easier to verify;
- easier to close;
- less likely to create repeated mistakes.

## Intertwined Tickets

Tickets often depend on each other. For example, Vaultwarden TLS/bootstrap may require Nginx, while a broader Nginx reverse-proxy standard is also an active ticket.

When tickets intertwine:

1. Do not ignore the dependency.
2. Do not silently create a conflicting architecture.
3. Document whether the dependent work is:
   - temporary/bootstrap;
   - permanent local-to-service design;
   - part of the broader shared platform ticket;
   - a blocker requiring user decision.
4. Link the related tickets both ways where practical.
5. Complete the smallest safe slice without pretending the wider platform is complete.

## Agent Roles for Ticket Completion

For non-trivial tickets, prefer multiple context-isolated passes:

1. **Ticket triager** — selects/summarizes priority work without loading everything.
2. **Locator/researcher** — finds relevant docs, live state, constraints, and existing work.
3. **Planner** — creates a small executable plan with verification and rollback.
4. **Implementer** — executes only the approved slice.
5. **Reviewer/verifier** — independently checks the diff/live state against the ticket/spec.
6. **Closer** — updates ticket status, docs, runbooks, change logs, and follow-up tickets.

The implementer and reviewer should not be the same context when risk is meaningful.

## Authorization Standard

Ask the user for the right amount of authorization:

- **No approval needed:** read-only discovery, local documentation drafts, non-risky planning.
- **Brief approval or assumption okay:** low-risk repo docs/code changes in a scoped branch/worktree.
- **Explicit approval required:** infrastructure mutation, destructive actions, public exposure, credential/security changes, backup deletion, firewall changes, migration of critical data/secrets.
- **Questionnaire preferred:** when several bounded decisions are needed.

Avoid both extremes:

- too much autonomy without verification;
- too many low-value questions that documented defaults already answer.

## Definition of Done

A ticket is not done merely because code or infrastructure was changed.

A ticket is done when:

- acceptance criteria are satisfied or explicitly revised;
- verification evidence is recorded;
- related docs/runbooks/status files are updated;
- related tickets/dependencies are linked;
- server-side changes are logged when applicable;
- risks/blockers/follow-ups are recorded;
- an independent review/verifier pass has checked meaningful work;
- rollback/restore path is known for risky changes.

Use `docs/verification-and-definition-of-done.md` as the detailed standard for ticket closeout.

## Scheduled Agents — Future Direction

Some agents should eventually run on schedules, but only after safe execution controls exist.

Candidate scheduled agents:

- security posture/audit reviewer;
- backup verification/restore-test reminder;
- stale ticket/backlog cleaner;
- dependency/update best-practices reviewer;
- infrastructure inventory verifier;
- documentation/index health checker;
- service dashboard/update compliance checker.

Initial scheduled agents should be read-only and produce reports/tickets. Mutation-capable scheduled agents require stronger approval, logging, and rollback controls.

## Immediate Practical Model

Until full scheduling/orchestration exists:

1. Use `nimrod-ticket-triager` to pick the next ticket/slice.
2. Use subagents for context-heavy research/review.
3. Keep implementation slices small.
4. Require reviewer/verification before marking tickets done.
5. Close or move tickets instead of letting `tickets/active/` grow endlessly.