Ticket lifecycle screenshots and configuration

A visual walkthrough of one LoopTroop ticket, from project setup to completion.

Each section shows the status as it appears in the app, its available actions, and a screenshot. For state transitions and implementation details, see Ticket Flow.

---

Quick Reference

Phase	Status	Available Actions
Setup	Project Creation	Create project, attach repository, select attachment mode
Setup	Configuration	Select main implementer, council members, effort levels, and Advanced project defaults
To Do	Backlog	Edit ticket details, configure model overrides, start the workflow, or cancel the ticket
Discovery	Scanning Relevant Files	Review scanned codebase files and rationales
Interview	Council Drafting Questions	Monitor parallel council question drafting
Interview	Voting on Questions	View anonymized questionnaire scores and voting breakdown
Interview	Refining Interview	Watch the selected draft become the interactive interview
Interview	Interviewing	Answer questions in adaptive batches, skip items with an optional reason, or skip all remaining questions
Interview	Coverage Check (Interview)	Monitor the coverage audit and follow-up questions
Interview	Approving Interview	Review the interview, edit answers or YAML, approve, or cancel
Specs (PRD)	Council Drafting Specs	Monitor Full Answers generation and parallel PRD drafting
Specs (PRD)	Voting on Specs	View anonymized PRD rubric scores and voting breakdown
Specs (PRD)	Refining Specs	Watch candidate v1 take shape from the competing drafts
Specs (PRD)	Coverage Check (PRD)	Monitor PRD coverage checks and candidate revisions
Specs (PRD)	Approving Specs	Review the PRD, inspect Full Answers, fix gaps with AI, approve, or cancel
Blueprint (Beads)	Council Drafting Blueprint	Monitor parallel blueprint drafting
Blueprint (Beads)	Voting on Blueprint	View anonymized architecture scores and voting breakdown
Blueprint (Beads)	Refining Blueprint	Watch semantic blueprint refinement
Blueprint (Beads)	Coverage Check (Beads)	Monitor the blueprint audit against the PRD
Blueprint (Beads)	Expanding Blueprint	Watch the blueprint become execution-ready bead records
Blueprint (Beads)	Approving Blueprint	Review the execution plan, inspect dependencies and file targets, fix gaps with AI, approve, or cancel
Pre-Implementation	Checking Readiness	Monitor workspace, worktree, agent connectivity, and graph checks
Pre-Implementation	Drafting Workspace Setup Plan	Watch setup-plan generation, live logs, artifacts, diagnostics, and version history
Pre-Implementation	Approving Workspace Setup	Review and edit the setup plan, regenerate it with commentary, approve, or cancel
Pre-Implementation	Preparing Workspace Runtime	Watch environment preparation, tool provisioning, and probe checks
Implementation	Implementing	Monitor bead-by-bead execution, live logs, progress counters, and ETA range
Post-Implementation	Testing Implementation	Watch whole-ticket tests and the file-effects audit
Post-Implementation	Preparing Manual QA	Watch Manual QA checklist generation and PRD coverage calculation
Post-Implementation	Manual QA	Run manual verification, record results, attach evidence, submit, or skip
Post-Implementation	Preparing Final Commit	Watch Git-hook validation and candidate commit squashing
Post-Implementation	Creating Pull Request	Watch the candidate file audit, branch push, and draft PR creation
Post-Implementation	Reviewing Pull Request	Review the draft PR and finish with or without merging it
Post-Implementation	Cleaning Up	Watch cleanup of temporary runtime files
Done	Done	Review final artifacts, logs, PR details, and cleanup report
Done	Canceled	Review preserved artifacts and logs from the canceled ticket
Errors	Error (reason)	Read error diagnostics, retry, continue an eligible session, edit the setup plan, or cancel

---

Setup ?

In Configuration, Project, New Ticket, and saved drafts, AI question wait sits directly below AI questions as a subitem indented to the right, without a separator. Both labels have ? help links, with controls aligned to the right. Tab focuses the selected choice in each group; arrow keys change the choice.

When effective questions are Off, including inherited Off, the disabled wait controls show the last valid duration. Turning questions off preserves the chosen mode and unfinished input; turning them back on restores the input and its validation. Inactive wait errors do not block saving.

Collapsing Advanced preserves unfinished input and validation. An invalid active Custom wait blocks saving or starting, with a short error still visible while the section is closed. Choose a valid whole number, Default, or Inherit to clear it. A saved fractional value appears exactly in the Custom input; choosing Custom from Inherit starts from the nearest whole minute.

Project Creation ?

Screenshot

Create a project and attach a local Git repository to LoopTroop.

What you can do:

• Set the project name, description, and appearance.
• Attach a local Git repository that has a GitHub remote.
• Choose how to attach a repository that LoopTroop has used before: restore its tickets, clear its tickets, or start fresh.
• Open Project Advanced to choose concrete Manual QA, Git-hook, and folder-ignore settings seeded from Configuration.
• Set AI questions to Inherit / On / Off and AI question wait to Inherit / Custom in Project Advanced. The rows show the effective values and their sources; custom waits accept 1 to 60 whole minutes. ? ?
• Choose whether /.looptroop/ and /.ticket/ rules go to the repository .gitignore, this clone's Git exclude (the default), or nowhere. ?

---

Configuration ?

Screenshot

Configure the main implementer, council members, effort levels, and project settings.

What you can do:

• Select the main implementer. This model is also a council member and handles implementation and other single-model steps. ?
• Select models for multi-model planning phases. ?
• Set supported effort levels for each council member and, where available, an OpenRouter routing variant such as :floor or :nitro. ?
• In collapsed Advanced, set future-project defaults for Git-hook policy and LoopTroop folder ignores. ? ?
• In Advanced, turn AI questions on or off and choose Default (5 minutes) or Custom (1 to 60 whole minutes) for AI question wait. Default removes the custom override. Changing the wait mode counts as an unsaved edit even when both modes use 5 minutes. ? ?
• Set the future-project Manual QA default. ?
• Set the log preview length for model tool calls. This limits only the text shown in the AI Model logs, not the content sent to the tool. ?

OpenCode provider recovery ?

1. OpenCode Retry Limit: Number of failed requests OpenCode can retry before the phase fails. ?
2. OpenCode Retry Grace Window: Time OpenCode may remain in a retrying state before LoopTroop treats the request as failed. ?
3. OpenCode Max Steps: Maximum steps OpenCode may take before its session closes. 0 allows unlimited steps. ?

AI thinking ?

1. AI Response Timeout: Time allowed for a planning-phase model request to complete. The default is 20 minutes. ?
2. Minimum Council Quorum: Minimum number of council members that must return a valid draft or vote for a drafting or voting phase to succeed. ?
3. Maximum Interview Questions: Maximum questions generated during the interview. ?
4. Structured Output Retries: Number of fresh attempts allowed when a model returns invalid structured output. ?

Coverage ?

1. Coverage Follow-Up Budget: Maximum follow-up questions generated during interview coverage checks. ?
2. Interview Coverage Passes: Number of coverage checks that can return the ticket to the interview when gaps remain. ?
3. PRD Coverage Passes: Number of PRD coverage checks when gaps remain. ?
4. Beads Coverage Passes: Number of blueprint coverage checks when gaps remain. ?

Implementation and workspace setup ?

1. Max Bead Retries: Number of times a bead can retry before the phase fails. ?
2. Per-Iteration Timeout: Time allowed for a bead iteration before it fails. The default is 20 minutes. ?
3. Execution Setup Timeout: Time allowed for workspace setup before it fails. The default is 20 minutes. ?

---

To Do ?

Backlog ?

Screenshot

Edit the ticket before starting the workflow.

What you can do:

• Edit the ticket title, description, priority, and ticket-level options.
• In Advanced, choose Manual QA, AI questions (Inherit / On / Off), and AI question wait (Inherit / Custom). AI question rows show the effective values and their sources, with ? help links beside both labels. Custom waits accept 1 to 60 whole minutes. Git-hook and folder-ignore policies are project settings. ? ?
• In a saved Draft ticket, leave the custom wait input, press Enter, or close the view to save a valid value. Mode changes save immediately; Inherit removes the custom override.
• In a saved Draft ticket, later edits and Start wait for earlier saves to succeed. A failed save stops queued actions and shows an error, even with Advanced closed. Controls stay usable during saves and lock during Start or while inherited settings load.
• Click Create Ticket to keep the ticket in the Backlog until you are ready to start it.
• Click Create & Start to start it immediately.
• When the workflow starts, LoopTroop runs initial checks and moves the ticket to Scanning Relevant Files. The ticket is then locked for editing. To change it, cancel the ticket and create a new one.
• You can cancel the ticket at any later point. It then moves to the Done column.

---

Discovery ?

Scanning Relevant Files ?

Screenshot

The main implementer scans the codebase and records relevant files.

What you can do:

• View live logs, along with artifacts and logs from earlier phases.
• Review the generated index containing file paths, excerpts, relevance ratings, and rationales
• Wait for automatic transition to council drafting upon completion
• From this point onward, LoopTroop moves tickets between Needs input and In progress automatically. You cannot move them between Kanban columns manually.

---

Interview ?

Council Drafting Questions ?

Screenshot

Council members draft interview strategies in parallel.

What you can do:

• Monitor multi-model logs while council members independently generate candidate question lists
• View each model's progress and completed draft.
• Stop or retry one model while the others keep drafting: open its chip and use the small Stop or Retry button in the top-right corner of its window. Both ask for confirmation. A stopped model does not count toward Min Council Quorum and still votes in the next step; a retried model starts over with a full AI response timeout of its own. ?

Screenshot

An interview draft proposed by a council member.

---

Voting on Questions ?

Screenshot

Council members vote independently and anonymously.

What you can do:

• Watch voting progress across council members
• View anonymized candidate questionnaires and rubric scores (evaluating question relevance and coverage)
• Inspect the score breakdown and winning draft selection
• Stop or retry one voter while the others keep scoring: open Voting Details and use the small Stop or Retry icon on its badge in the Voter Status row. Both ask for confirmation. A stopped voter does not count toward Min Council Quorum; a retried voter scores again with a full AI response timeout of its own. ?

Screenshot

Example anonymized voting results.

---

Refining Interview ?

Screenshot

The winning model reviews the other drafts and incorporates useful ideas.

What you can do:

• Monitor interview compilation progress

Screenshot

Example of a question revised using an idea from another draft.

---

Interviewing ?

Screenshot

Answer focused planning questions in adaptive batches of 1 to 3.

What you can do:

• Type responses to free-text questions, select options for choice-based questions, or edit earlier answers.
• Skip individual questions or restore a previously skipped question. A skipped question takes an optional reason, which the model that later fills the answer in gets to read. Restoring the question discards the reason.
• Click Submit to process the current batch and receive the next questions or advance to coverage.
• Click Skip All to mark all remaining questions as skipped and move directly to Approving Interview, with one optional reason for the whole action that applies only to questions you have not already explained. The PRD phase later fills skipped questions with AI-generated answers.

---

Coverage Check (Interview) ?

Screenshot

Winning model checks answers for gaps and spawns follow-up rounds if budget permits.

What you can do:

• Monitor coverage audit progress as the winning model checks collected answers against the ticket description
• Return automatically to Interviewing with follow-up questions if gaps exist and budget remains.

---

Approving Interview ?

Screenshot

Review and approve the structured interview artifact.

What you can do:

• Review questions, answers, skipped items, and the reasons given for skipping them in the structured view or raw YAML editor. Marking an answer skipped here also takes a reason; answering the question clears it.
• Edit answers with draft autosave. The same protection is available on editable approval screens.
• Click Save to update the authoritative interview artifact, then Approve to start Council Drafting Specs.
• Before Checking Readiness begins, you can return to Approving Interview or Approving Specs and edit the artifact. Saving an edit restarts downstream planning.

---

Specs (PRD) ?

Council Drafting Specs ?

Screenshot

Each model first resolves skipped questions, then drafts its own PRD (Product Requirements Document).

What you can do:

• Monitor Part 1 progress: council members fill skipped interview questions to create per-model Full Answers artifacts
• Monitor Part 2 progress: council members draft complete PRD specifications from relevant files and Full Answers
• Stop or retry one model from its Part 1 or Part 2 chip, using the small Stop or Retry button in the top-right corner of the window. Both ask for confirmation. Retry from Part 1 redoes both parts; Retry from Part 2 keeps Part 1 answers that passed validation and redoes only the PRD draft. Stop from either chip stops the model and throws away both parts, so it does not count toward Min Council Quorum. ?

Screenshot

Each model provides answers only for the interview questions the user skipped.

Screenshot

Each model then creates its own PRD draft.

---

Voting on Specs ?

Screenshot

Each model independently and anonymously votes on all PRD drafts.

What you can do:

• Watch voting progress across council members
• View anonymized PRD drafts and weighted rubric scores (evaluating requirement completeness, acceptance criteria quality, edge cases, test intent, and coherence)
• Inspect vote resolution and winning draft selection
• Stop or retry one voter while the others keep scoring: open Voting Details and use the small Stop or Retry icon on its badge in the Voter Status row. Both ask for confirmation. A stopped voter does not count toward Min Council Quorum; a retried voter scores again with a full AI response timeout of its own. ?

---

Refining Specs ?

Screenshot

Winning model incorporates strong elements from competing drafts into PRD Candidate v1.

What you can do:

• Monitor refinement progress as the winning model merges missing requirements and edge cases into its winning structure
• Inspect diff metadata showing what was added from losing drafts

Screenshot

Example of an addition from another draft.

---

Coverage Check (PRD) ?

Screenshot

The candidate PRD is checked against the winning Full Answers and revised until it is clean or reaches the pass cap.

What you can do:

• Monitor coverage audit progress as the candidate PRD is checked against the winning model's Full Answers
• Watch in-phase revisions (producing candidate v1, v2, and so on) when gaps are identified
• Observe live version progress.

Screenshot

Example coverage gap identified during PRD verification.

---

Approving Specs ?

Screenshot

Review the PRD requirements specification.

What you can do:

• Review requirements, acceptance criteria, edge cases, and test intent in structured view or raw YAML editor
• Open the read-only Full Answers chip to view the complete interview answer set used by the winning PRD model
• Review prominent coverage warnings if approval was reached after hitting the coverage pass cap
• Click Fix gaps with AI to run a targeted PRD revision and fresh coverage audit for unresolved gaps

---

Blueprint (Beads) ?

Council Drafting Blueprint ?

Screenshot

Council members divide the specification into small beads with executable tasks and verification criteria.

What you can do:

• Monitor parallel blueprint generation as council members split the PRD into semantic task units
• View task counts, dependency graph structures, and beads structure for each council member's draft
• Stop or retry one model while the others keep drafting: open its chip and use the small Stop or Retry button in the top-right corner of its window. Both ask for confirmation. A stopped model does not count toward Min Council Quorum and still votes in the next step; a retried model starts over with a full AI response timeout of its own. ?

Screenshot

Example bead blueprint. During implementation, each bead is the model's primary task context.

---

Voting on Blueprint ?

Screenshot

Beads drafts rated on graph logic, file target isolation, and testing strategy.

What you can do:

• Watch voting progress across council members
• View anonymized blueprints and architecture rubric scores (evaluating task decomposition, feasibility, dependency acyclicity, and testability)
• Inspect vote resolution and winning blueprint selection
• Stop or retry one voter while the others keep scoring: open Voting Details and use the small Stop or Retry icon on its badge in the Voter Status row. Both ask for confirmation. A stopped voter does not count toward Min Council Quorum; a retried voter scores again with a full AI response timeout of its own. ?

---

Refining Blueprint ?

Screenshot

Winning blueprint merges strong verification steps from alternative drafts.

What you can do:

• Monitor refinement progress as the winning model incorporates extra tasks, edge cases, and verification steps from losing blueprints
• Inspect blueprint diff metadata

Screenshot

Example changes to a bead after incorporating ideas from another draft.

---

Coverage Check (Beads) ?

Screenshot

The blueprint is checked against the PRD and revised when criteria are missing. The screenshot shows version 2 because the first model response was malformed and could not be repaired safely. Multiple attempts may appear when a phase encounters an error.

What you can do:

• Monitor semantic blueprint auditing against the approved PRD
• Watch in-phase revisions when required PRD outcomes lack corresponding beads
• Observe live version progress

Screenshot

Example of a clean coverage report.

---

Expanding Blueprint ?

Screenshot

LoopTroop adds the execution fields that are not needed while the council is drafting the semantic blueprint.

What you can do:

• Monitor expansion progress as the semantic blueprint is converted into execution-ready bead records
• Verify added file targets, dependency ordering, labels, and runtime metadata

---

Approving Blueprint ?

Screenshot

Review the dependency graph and executable plan before coding starts.

What you can do:

• Review task descriptions, acceptance criteria, dependency graphs, file targets, and planned commands or no-command reasons
• Review coverage warnings if approval was reached after hitting the coverage pass cap
• Click Fix gaps with AI to revise the semantic blueprint and re-run expansion for remaining gaps
• Edit the plan in structured or raw editor with draft autosave, then click Save to update the authoritative plan

---

Pre-Implementation ?

Checking Readiness ?

Screenshot

Checks workspace cleanliness, Git worktree hygiene, OpenCode reachability, and execution locks.

What you can do:

• Monitor pre-flight validation checks: workspace directory existence, required artifacts, Git worktree cleanliness, OpenCode connectivity, execution capability probe prompt, and bead graph acyclicity
• Review generated pre-flight report detailing pass, warning, and failure entries
• If readiness fails, read the failed doctor check and its reason in the error. A model can appear available while its actual probe request fails authentication; Technical details keeps the available request and debug evidence.

Screenshot

Example of a successful readiness check.

---

Drafting Workspace Setup Plan ?

This active status keeps its generation log expanded and shows an artifact placeholder immediately, followed by the complete generated setup plan and generation report. Use the version selector to inspect archived generations. If structured retries cannot repair a malformed response, the rejected output and diagnostics remain available before LoopTroop hands the result to the approval gate with only Regenerate enabled.

There is no new screenshot for this status yet; this guide intentionally documents the new lifecycle step without capturing an end-to-end run.

---

Approving Workspace Setup ?

Screenshot

Review the setup plan before implementation: readiness assessment, workspace inputs, setup steps, Git hooks, and the locked project policy.

What you can do:

• Review readiness assessment, temporary setup steps, workspace probes, command families, read-only detected Git hooks and project policy, and editable validation commands
• Edit setup steps or validation commands
• Click Regenerate with commentary to preserve the current draft and input durably, archive the current generation/approval attempts, and enter Drafting Workspace Setup Plan for a fresh version

---

Preparing Workspace Runtime ?

Screenshot

Materializes approved workspace inputs, runs setup, verifies probes, and validates hooks.

What you can do:

• Monitor workspace input materialization, temporary tool provisioning and setup execution

• Watch validation of the runtime wrapper and workspace probes

• Review the Error (reason) screen when setup finishes blocked or fails validation.

  • Click Retry with extra note... from the live blocked view to restart setup in a fresh session with your unchanged guidance

  • Click Edit setup plan... from live blocked view to rewind to setup approval

---

Implementation ?

Implementing ?

Screenshot

LoopTroop implements one bead at a time in dependency order, using the bead details as task context.

What you can do:

• Monitor bead-by-bead execution in real time
• Track progress with the bead completion counter and ETA range in the workspace header. The displayed time is the remaining time for the current iteration. If it expires, LoopTroop starts a fresh iteration with the bead details and a note about the failure. The project configuration sets the timeout and retry budget; the defaults are 20 minutes and five iterations.
• View live execution logs, visible agent responses, file modification events, and command outputs for the active bead
• Inspect each bead's status (pending, in progress, done, or error) and code-only diff.
• Watch automatic Ralph-style bead recovery after a failed iteration. It appends a structured note, abandons the degraded session, resets the worktree, increments the iteration, and retries within the configured budget.
• Review Error (reason) if a bead exhausts its retry budget or local commit finalization fails.

Screenshot

Open a bead to view its details, logs, diff, and input/output in separate tabs.

Screenshot

Changes made by a bead.

Screenshot

Example of a Ralph-style retry loop from another ticket. The second iteration succeeds after receiving the appended note.

Screenshot

All changes made during implementation, shown at the end of the phase.

---

Post-Implementation ?

Testing Implementation ?

Screenshot

The main implementer creates a whole-ticket test plan and runs it with the approved runtime profile.

What you can do:

• Monitor whole-ticket test plan generation based on ticket details, PRD, and beads
• Watch test command execution in the worktree through the setup wrapper
• Review test results, pass/fail status per test, and output logs
• Inspect the file-effects audit classifying dirty files as delivery candidates or local-only outputs

---

Preparing Manual QA ?

• Watch the main implementer generate the checklist from the PRD and bead context.

---

Manual QA ?

Screenshot

Run manual verification.

What you can do:

• Run and control the application independently outside LoopTroop
• Evaluate each checklist item as Pass, Waive, Fail, Pending, or Improvement.
  • Pass: The item meets its acceptance criteria. A note is optional.
  • Waive: The item does not apply or is skipped. A note is optional.
  • Fail: The item does not meet its acceptance criteria. A note is required. LoopTroop can create a QA bead for each failed item or combine failures into one QA bead, then return the ticket to Implementing.
  • Improvement: LoopTroop creates a separate Backlog ticket from the item result.
• Attach links or upload files as evidence for each item
• Click Skip Manual QA... to archive entered data read-only without creating fix work or child tickets, with an optional reason for the round

---

Preparing Final Commit ?

Screenshot

Runs Git-hook validation again, stages the changes, and squashes bead-level commits into a clean candidate commit.

---

Creating Pull Request ?

Screenshot

Performs the final candidate audit, pushes the branch, and drafts the pull request title and description.

---

Reviewing Pull Request ?

Screenshot

Review the pull request, then finish after merging it or leave it unmerged.

What you can do:

• Review the draft pull request directly on GitHub via provided URL
• Inspect Net Diff, By Bead, or By File diff views in the local workspace
• Review candidate file audit, final test summary, and integration report
• Click Merge PR & Finish to mark PR ready, merge on GitHub, verify remote base branch, and advance to cleanup
• Click Finish Without Merge to leave the PR open and unmerged and advance directly to cleanup. It asks for confirmation and takes an optional reason, which is stored on the merge report and is the only record of why the branch stopped

---

Cleaning Up ?

Screenshot

Deletes temporary lockfiles, wrapper hooks, and session directories while preserving planning files and audit trails.

• After this phase, the ticket is complete and moves to the Done column of the Kanban board.

---

Done ?

Done ?

What you can do:

• Review all ticket artifacts, logs, test reports, integration reports, PR details, and cleanup summary
• Inspect final net diff and full implementation history
• The ticket is read-only in this terminal state.

---

Canceled ?

What you can do:

• Review existing artifacts and execution logs created prior to cancellation
• The ticket is read-only in this terminal state.
• Create a new ticket if work needs to be restarted

---

Errors ?

Error (reason) ?

Screenshot

This example shows Technical details expanded for inspection. The section starts collapsed when opening a ticket error.

What you can do:

• Read the actual failure and any distinct underlying cause above the recovery controls. Each failure line keeps its failed-step and error-type prefixes and HTTP status in regular text, with only the actionable cause bold. Expand Technical details to inspect the ticket and occurrence identity, failed phase, exact timestamp, complete sanitized error, and available model, session, and other diagnostics. The last five matching debug records appear newest first, each collapsed by default; expand a record for its complete structured data. Technical details also starts collapsed, and missing evidence is stated explicitly. Use the separate phase log's Debug view for the full history.
• Follow the recovery guidance for the actions currently available on the live error.
• Click Retry to follow the failed phase's normal retry path: archive and rerun a non-coding phase attempt, or reset the failed bead during Implementing.
• Click Retry with extra note... for supported failed AI work to restart in a fresh session with your unchanged guidance. Coding also retains that guidance in User Retry Notes.
• Click Continue to resume an addressable preserved OpenCode session after transient provider, network, or rate-limit interruptions, or after repairing a known OpenCode-server login or permission rejection, without archiving phase attempts. Billing, quota, invalid-request, and policy denials do not qualify for that server-login exception. Failed session creation without an existing session stays Retry-only; provider-login failures remain ineligible for Continue.
• Click Edit setup plan... (when setup failed) to rewind to setup approval
• Click Cancel to move the ticket to Canceled.

---

Related Docs

• Ticket Flow: Detailed state machine documentation and transitions
• Beads & Execution: Bead structure, execution loops, and recovery mechanics
• System Architecture: Module map and storage ownership
• Getting Started: Installation and first run setup