Add Copilot setup workflow

[rezwana-karim]

This pull request adds a new GitHub Actions workflow for setting up the Copilot development environment. The workflow automates environment setup, dependency installation, database preparation, type checking, and caching to streamline local and CI development.

New Copilot setup workflow:

• Introduces .github/workflows/copilot-setup-steps.yml, a comprehensive workflow that:
  • Checks out the code and sets up Node.js 22 with npm 11.
  • Installs required OS packages for Playwright and Next.js image processing.
  • Installs npm dependencies, generates the Prisma client, applies migrations, and seeds the SQLite database if needed.
  • Runs type checking and saves errors to JSON using a PowerShell script.
  • Installs and caches Playwright browsers conditionally based on project configuration.
  • Optionally warms up the Next.js dev server and caches Next.js build artifacts and npm cache.This workflow sets up the environment for Copilot, including Node.js, dependencies, Prisma client generation, database seeding, type checking, and caching for Playwright and Next.js.

Description

Why

Fixes #
Related to #

What

Type of Change

Please check the relevant option(s):

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• 🎨 Style/UI change
• ♻️ Code refactoring (no functional changes)
• ⚡ Performance improvement
• ✅ Test addition or update
• 🔧 Configuration change
• 🏗️ Infrastructure change

Checklist

Please ensure your PR meets the following requirements:

Code Quality

• Code follows the project's TypeScript and code style guidelines
• Code is properly formatted (ran npm run format)
• Code passes linting (ran npm run lint)
• TypeScript compiles without errors (ran npm run type-check)
• No any types used (except for documented third-party library interfaces)
• File size limits respected (max 300 lines per file, 50 lines per function)

Testing

• All existing tests pass (ran npm run test)
• New tests have been added for new features or bug fixes
• Test coverage meets requirements:
  • Business logic: minimum 80% coverage
  • Utility functions: 100% coverage
  • API routes: integration tests added
  • Critical paths: E2E tests added (if applicable)
• Tests follow AAA pattern (Arrange, Act, Assert)

Security & Best Practices

• Authentication checks are in place for protected routes
• Multi-tenant isolation is enforced (storeId filtering)
• Input validation is implemented using Zod schemas
• No secrets or sensitive data in code (using environment variables)
• SQL injection prevention (using Prisma, no raw SQL)
• XSS prevention (proper input sanitization)

Documentation

• Documentation has been updated (if applicable)
• JSDoc comments added for complex functions
• API documentation updated (if API changes were made)
• README.md updated (if needed)
• Specification documents updated (if architectural changes were made)

Database (if applicable)

• Database migration created (if schema changes were made)
• Migration tested on local database
• Seed data updated (if needed)
• Indexes added for new query patterns
• Soft delete pattern followed for user-facing data

Accessibility (if UI changes were made)

• Meets WCAG 2.1 Level AA standards
• Keyboard navigation works properly
• ARIA labels added where necessary
• Color contrast ratios meet requirements (≥ 4.5:1)
• Focus indicators are visible
• Alt text provided for images
• Tested with screen reader (if major UI changes)

Performance (if applicable)

• Page load time within budget (< 2.0s LCP desktop, < 2.5s mobile)
• API response time within budget (< 500ms p95)
• Database queries optimized (no N+1 queries)
• Images optimized (using Next.js Image component)
• Bundle size within limits (< 200KB initial load)

Build & Deployment

• Build succeeds locally (ran npm run build)
• No console errors or warnings
• Environment variables documented (if new ones added)
• Works in both development and production modes

Screenshots (if applicable)

Before

After

Additional Context

Reviewer Notes

---

By submitting this pull request, I confirm that:

• I have read and agree to follow the Code of Conduct
• I have read the Contributing Guidelines
• My contribution is original work or properly attributed
• I agree to license my contribution under the project's MIT License

[github-actions]

👋 Thanks for opening your first pull request in StormCom!

A maintainer will review your PR soon. Please make sure:

• Your PR follows our
  Contributing Guidelines
• All CI checks pass
• You've added appropriate tests
• Documentation has been updated (if needed)

We appreciate your contribution to making StormCom better! 🚀

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[Copilot]

According to the coding guidelines, Node.js version should be 18.x or higher, but the project specifically targets 18.x. The workflow uses Node 20, which may introduce compatibility issues. Consider using Node 18 to match the documented tech stack requirement.

Suggested change

	# Engines: Node >=20, npm >=10
	- name: Set up Node 20
	uses: actions/setup-node@v4
	with:
	node-version: "20"
	# Engines: Node >=18, npm >=10
	- name: Set up Node 18
	uses: actions/setup-node@v4
	with:
	node-version: "18"

[Copilot]

The comment indicates PowerShell with Linux fallback, but the implementation shows the opposite: it attempts npm script first, then falls back to PowerShell. On ubuntu-latest, PowerShell may not be available by default. The logic should either be corrected or the comment updated to accurately reflect 'npm script with PowerShell fallback'.

Suggested change

	- name: Save type-check errors to JSON (PowerShell script with Linux fallback)
	- name: Save type-check errors to JSON (npm script with PowerShell fallback)

[Copilot]

The PID capture logic is flawed. If 'npm run dev' fails immediately, the shell will still execute 'echo $! > /tmp/next_pid' with the PID of the failed subshell. The kill command on line 105 should verify the process exists before attempting to kill it, or use 'kill -0' to check process existence first.

Suggested change

	kill $(cat /tmp/next_pid) || true
	NEXT_PID=$(cat /tmp/next_pid)
	if kill -0 "$NEXT_PID" 2>/dev/null; then
	kill "$NEXT_PID" || true
	fi