# Issue and Feature Tracking

This directory is used to track issues and feature ideas for the Asset Processor Tool using Markdown files.

## Structure

All ticket files are stored directly within the `Tickets/` directory.

```mermaid
graph TD
    A[Asset_processor_tool] --> B(Tickets);
    A --> C(...other files/dirs...);
    B --> D(ISSUE-XXX-....md);
    B --> E(FEAT-XXX-....md);
    B --> F(_template.md);
```

## File Naming Convention

Ticket files should follow the convention: `TYPE-ID-short-description.md`

*   `TYPE`: `ISSUE` for bug reports or problems, `FEAT` for new features or enhancements.
*   `ID`: A sequential three-digit number (e.g., `001`, `002`).
*   `short-description`: A brief, hyphenated summary of the ticket's content.

Examples:
*   `ISSUE-001-gui-preview-bug.md`
*   `FEAT-002-add-dark-mode.md`

## Ticket Template (`_template.md`)

Use the `_template.md` file as a starting point for creating new tickets. It includes YAML front matter for structured metadata and standard Markdown headings for the ticket content.

```markdown
---
ID: TYPE-XXX          # e.g., FEAT-001, ISSUE-002
Type: Issue | Feature  # Choose one: Issue or Feature
Status: Backlog | Planned | In Progress | Blocked | Needs Review | Done | Won't Fix # Choose one
Priority: Low | Medium | High # Choose one
Labels: [gui, cli, core, blender, bug, feature, enhancement, docs, config] # Add relevant labels from the list or define new ones
Created: YYYY-MM-DD
Updated: YYYY-MM-DD
Related: # Links to other tickets (e.g., #ISSUE-YYY), relevant files, or external URLs
---

# [TYPE-XXX]: Brief Title of Issue/Feature

## Description
(Provide a detailed explanation of the issue or feature request. What is the problem you are trying to solve, or what is the new functionality you are proposing?)

## Current Behavior
(Describe what happens currently. If reporting a bug, explain the steps to reproduce it. If proposing a feature, describe the current state without the feature.)

## Desired Behavior / Goals
(Describe what *should* happen if the issue is resolved, or what the feature aims to achieve. Be specific about the desired outcome.)

## Implementation Notes (Optional)
(Add any thoughts on how this could be implemented, potential technical challenges, relevant code sections, or ideas for a solution.)

## Acceptance Criteria (Optional)
(Define clear, testable criteria that must be met for the ticket to be considered complete.)
*   [ ] Criterion 1: The first condition that must be satisfied.
*   [ ] Criterion 2: The second condition that must be satisfied.
*   [ ] Add more criteria as needed.

```

## How to Use

1.  Create a new Markdown file in the `Tickets/` directory following the naming convention (`TYPE-ID-short-description.md`).
2.  Copy the content from `_template.md` into your new file.
3.  Fill in the YAML front matter and the Markdown sections with details about the issue or feature.
4.  Update the `Status` and `Updated` fields as you work on the ticket.
5.  Use the `Related` field to link to other relevant tickets or project files.
```