feat(#29): add sample ticket templates for different issue types

[santhosh-7777]

Description

This PR adds 5 sample ticket templates in the tickets/ directory to support testing different issue scenarios.
The templates include:

• A bug fix request
• A new feature request
• An enhancement request
• A refactor request
• A test addition request

Each template follows the expected YAML frontmatter format and includes realistic CHT use cases with clear descriptions and acceptance criteria. These can be used for testing agent workflows and as documentation examples.

Closes #29

Code review checklist

• Readable: Concise, well named, follows the style guide, documented where necessary.
• Documented: No changes required in cht-docs.
• Tested: Not applicable (markdown templates only).
• Backwards compatible: No impact on existing functionality.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[santhosh-7777]

Hi @sugat009, just checking in — let me know if any changes are needed from my side. Happy to update quickly. Thanks!

[sugat009]

Thanks for the ping and for your patience, @santhosh-7777! I've got a couple of PRs ahead of this one in my review queue and ran out of time today. Aiming to take a proper look tomorrow. Really appreciate the contribution 🙏

[sugat009]

Review: PR #100 (commit 6ad5ad9)

Thanks for the contribution, and sorry for the wait on this one. Realistic CHT use cases (CHWs, deployments, low-connectivity context) and clean structure across all five files.

I ran each template through parseTicketFile to confirm they validate, and 3 of the 5 fail because their type value isn't in the project's allowed list (feature, bug, improvement):

sample-bug-fix:        PARSE OK
sample-new-feature:    PARSE OK
sample-enhancement:    FAILS (Invalid type: "enhancement". Must be one of: feature, bug, improvement)
sample-refactor:       FAILS (Invalid type: "refactor". Must be one of: feature, bug, improvement)
sample-test-addition:  FAILS (Invalid type: "test". Must be one of: feature, bug, improvement)

Context, in case it's useful: the type system here is narrower than GitHub's general issue categories. enhancement was renamed to improvement in PR #84, and improvement is intentionally broad. It covers refactors too (along with anything that improves existing functionality without being a new feature or a bug fix). refactor and test aren't separate types. The source of truth is tickets/README.md (lines 62-65, 165-169).

Two possible paths:

1. Map all 5 to valid types, keeping the file count and the variety of scenarios:

   • sample-enhancement.md → type: improvement (and rename file to sample-improvement.md for consistency)
   • sample-refactor.md → type: improvement (a refactor improves maintainability; fits the spirit)
   • sample-test-addition.md → type: improvement (improving test coverage is also an improvement)

   You'd end up with 1 bug + 1 feature + 3 improvements, which still demonstrates breadth across realistic scenarios.

2. Reduce to 3 samples, one per valid type: sample-bug.md, sample-feature.md, sample-improvement.md. Cleaner mapping but loses the refactor/test scenarios.

I'd lean toward option 1 if the goal is to show common CHT scenarios across multiple types. Up to you.

Minor (non-blocking)

• The samples use ## Description (h2), which matches the README's documented format. Existing tickets like contact-search-feature.md use # Description (h1), which works via parser fallback but is technically inconsistent. Your samples actually align with the docs better than some older examples. No change needed; just flagging in case it surprises you.
• Acceptance criteria use - [ ] checkboxes while existing tickets use plain - bullets. The parser keeps [ ] as part of the item text. Minor stylistic inconsistency; either way works for samples.

Summary

• Fix the 3 invalid type values so all 5 samples parse cleanly

Once that's in, this is good to go. Thanks again for the patience!

[santhosh-7777]

@sugat009 ,Thanks for the detailed review!
I’ve updated the invalid type values to improvement and renamed the enhancement template to sample-improvement.md for consistency.
All templates now pass validation. Please take another look when you get a chance.

[sugat009]

Re-review: PR #100 (commit 6e7e336)

The blocker is resolved cleanly. All 5 templates now parse:

sample-bug-fix:        OK (type=bug)
sample-improvement:    OK (type=improvement, renamed from sample-enhancement)
sample-new-feature:    OK (type=feature)
sample-refactor:       OK (type=improvement)
sample-test-addition:  OK (type=improvement)

Distribution is 1 bug + 1 feature + 3 improvements, which still demonstrates breadth across realistic CHT scenarios.

Approving. Thanks for the careful turnaround!

Note for future reference: the "Build, lint, and test" CI is currently red, but it's a project-wide ESLint failure on src/mcp/client.ts (unrelated to this PR; lint runs across all .ts files). PR #99 fixes it by bumping engines.node to >=22.0.0. Once #99 merges this clears on its own.