chore: set up linting and formatting infrastructure

[Pinkish-Warrior]

• Add ESLint with TypeScript support and strict rules
• Add Prettier for consistent code formatting (80 char, double quotes, LF)
• Add Husky git hooks (pre-commit: lint-staged, pre-push: type-check)
• Add lint-staged for efficient staged file checking
• Add markdownlint for documentation consistency
• Add EditorConfig for cross-OS/IDE consistency
• Create comprehensive LINTS.md developer guide
• Update package.json with lint, format, type-check, and validate scripts

This ensures code quality and consistency across the team of 4 developers working on different operating systems.

Note: Pre-push hook temporarily excludes tests until Vitest setup is complete.

[MariShopen]

I have a big question about using Husky. I don’t think it’s necessary, and I’m worried it will actually make our work more complicated. It’s much more convenient to make intermediate commits without thinking about the linter every time, and then run one general check before pushing. So I suggest we remove .husky/pre-commit.

[Pinkish-Warrior]

Hi Marina,Thank you for input on this. What is exactly the complication you see on this  - Could you explain further? Husky handles the task for you automatically, ensuring nothing is forgotten and preventing issues from being pushed to the CI/CD pipeline, which could slow down development. Looking forward on hearing your thoughts, Tania Rosa SantanaShe/herOn 12 Dec 2025, at 19:42, Marina Shopina ***@***.***> wrote: @MariShopen commented on this pull request. In .husky/pre-commit:

@@ -0,0 +1,5 @@

+#!/usr/bin/env sh +. "$(dirname -- "$0")/_/husky.sh" + +# Run lint-staged for backend +cd backend && npx lint-staged I have a big question about using Husky. I don’t think it’s necessary, and I’m worried it will actually make our work more complicated. It’s much more convenient to make intermediate commits without thinking about the linter every time, and then run one general check before pushing. So I suggest we remove .husky/pre-commit. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>