feat: complete Tusk framework refactor, RBAC, Huma v2 integration, and documentation

- Refactor authorization models and fix PermissionRecord references
- Fix DefaultRegistry Find method integration in service_role.go
- Integrate Huma v2 OpenAPI 3.0 router and structured DTO response envelopes
- Remove obsolete cmd/genmodule scaffolding tool and Makefile target
- Add comprehensive documentation guides in docs/ (getting-started, architecture, routing, authorization, database, querying, responses)
- Add CHANGELOG.md, CONTRIBUTING.md, and update package placement guide for future features (Redis, Queues, Audit, Telemetry)
- Clean up .github/workflows and update .gitignore

Author: codetheuri

.agents/rules/architecture.md

@@ -0,0 +1,65 @@
+---
+trigger: always_on
+---
+
+Tusk Architecture Philosophy
+
+Tusk should feel like Go, not like Laravel, Spring Boot, or ASP.NET.
+
+Every package should have one clear responsibility.
+
+Every module should own its business domain.
+
+Avoid deep abstractions.
+
+Avoid framework magic.
+
+Avoid hidden behavior.
+
+Avoid reflection unless absolutely necessary.
+
+Avoid code generation unless it clearly improves developer experience.
+
+Every dependency should be visible in constructors.
+
+Use dependency injection through constructors.
+
+Keep APIs small.
+
+Keep exported APIs intentional.
+
+Write code that is obvious to read.
+
+If a design becomes difficult to explain, it is probably too complicated.
+
+Prefer standard library solutions over third-party packages unless the package provides significant value.
+
+The framework should teach good Go by example.
+
+Whenever you improve my code:
+
+Do not only rewrite it.
+
+Explain:
+
+- why the original design was less idiomatic
+- why the new design is preferred
+- what Go principle it follows
+- whether the change improves readability, simplicity, testing, or maintainability
+
+Assume I am learning advanced Go architecture.
+
+Prioritize helping me become a better Go engineer over simply producing code.
+
+Before introducing any abstraction, ask:
+
+- Does this abstraction reduce complexity?
+- Or does it merely hide complexity?
+
+Avoid abstractions that exist only for future possibilities.
+
+Follow the Go principle:
+
+"A little copying is better than a little dependency."
+
+Prefer duplication over premature abstraction when it leads to simpler, more readable code.

.agents/rules/documenation.md

@@ -0,0 +1,13 @@
+---
+trigger: always_on
+---
+
+Every exported type
+
+Every exported function
+
+Every package
+
+must contain documentation.
+
+Generated code should teach developers why something exists.

.agents/rules/gostyle.md

@@ -0,0 +1,19 @@
+---
+trigger: always_on
+---
+
+Always write idiomatic Go.
+
+Prefer the standard library.
+
+Keep functions focused.
+
+Return errors.
+
+Avoid panic except unrecoverable startup failures.
+
+Prefer composition over inheritance.
+
+Use dependency injection.
+
+Never use global mutable state.

.agents/rules/handlers.md

@@ -0,0 +1,11 @@
+---
+trigger: always_on
+---
+
+Handlers should
+
+- validate input
+- call service
+- return response
+
+Handlers should never contain business logic.

.agents/rules/identity.md

@@ -0,0 +1,9 @@
+---
+trigger: always_on
+---
+
+You are contributing to Tusk.
+
+Tusk is an opinionated Go backend framework focused on clarity, modularity, maintainability, and developer experience.
+
+Every suggestion should align with Tusk's architecture.

.agents/rules/performance.md

@@ -0,0 +1,15 @@
+---
+trigger: always_on
+---
+
+Prefer clarity.
+
+Avoid premature optimization.
+
+Avoid unnecessary allocations.
+
+Avoid reflection.
+
+Avoid goroutine leaks.
+
+Use benchmarks before optimization.

.agents/rules/repository.md

@@ -0,0 +1,13 @@
+---
+trigger: always_on
+---
+
+Repositories only access storage.
+
+No business logic.
+
+Use context.Context.
+
+Avoid N+1 queries.
+
+Prefer transactions when needed.

.agents/rules/responses.md

@@ -0,0 +1,16 @@
+---
+trigger: always_on
+---
+
+All API responses should be consistent.
+
+Prefer
+
+success
+message
+data
+errors
+
+Return meaningful HTTP status codes.
+
+Never expose internal errors.

.agents/rules/security.md

@@ -0,0 +1,17 @@
+---
+trigger: always_on
+---
+
+Validate all inputs.
+
+Never trust client data.
+
+Hash passwords using bcrypt or Argon2.
+
+Never log secrets.
+
+Protect against SQL injection.
+
+Use prepared queries.
+
+Use secure JWT practices.

.agents/rules/services.md

@@ -0,0 +1,11 @@
+---
+trigger: always_on
+---
+
+Services contain business rules.
+
+Services never know about HTTP.
+
+Services return domain errors.
+
+Services coordinate repositories.