OctoCAT Supply Chain Management Code Review
Repository-wide code review assistant for the OctoCAT Supply Chain Management application, a TypeScript monorepo with Express REST API and React frontend.
Architecture Context
The codebase is structured as:
`api/` — Express REST API with SQLite persistence, repository pattern, Swagger docs`frontend/` — React + Vite + Tailwind UI`docs/` — Architecture documentation and demos`infra/` — Deployment scripts`.github/instructions/*.instructions.md` — Path-scoped guidance for specific areasRefer to `docs/architecture.md` and `docs/sqlite-integration.md` for deeper architectural details rather than restating them.
Review Instructions
When reviewing code or generating suggestions, follow this escalation order:
1. Security & Data Integrity (HIGHEST PRIORITY)
Flag SQL injection risks, authentication bypasses, or exposed secretsVerify input validation and sanitizationCheck authorization logic and access controlsEnsure sensitive data is not logged or exposed2. Logical & Functional Correctness
Verify business logic matches requirementsCheck edge cases and error pathsEnsure proper error handling using custom error types (NotFound, Validation, Conflict)Confirm consistent HTTP status codes via middleware3. Performance & Scalability
Highlight N+1 query patternsFlag unnecessary data loading or large bundle additionsIdentify performance bottlenecks in database queries or rendering4. Maintainability & Duplication
Flag duplicate logic that should be extracted to shared utilities or repository methodsSuggest refactoring when patterns emerge across filesEnsure DRY principles without over-abstraction5. Readability & Consistency
Enforce type safety (no `any` unless justified)Suggest adding or refining model/DTO types when gaps appearMaintain existing style and naming conventionsPrefer environment variable driven configuration over hard-coded paths/secrets6. Style & Minor Formatting (LOWEST PRIORITY)
Only flag if significantly impacting readabilitySummarize low-impact nits rather than listing each oneCode Generation Guidelines
When generating code:
1. **Minimal diffs** — Preserve existing style, naming, and structure. Make incremental changes only.
2. **Type safety** — Use TypeScript strictly. Add proper types instead of `any`.
3. **Error handling** — Use existing custom error types and ensure consistent HTTP status propagation.
4. **Testing** — Generate unit tests for repository logic and React Testing Library tests for critical UI paths.
5. **Environment config** — Use environment variables for configuration, never hard-code secrets or paths.
6. **Documentation** — Update related instruction files when introducing new architectural patterns or folders.
Monorepo Workflow
Build commands:
```bash
Build API only
npm run build --workspace=api
Build frontend only
npm run build --workspace=frontend
Build both (root command)
npm run build
```
Keep PRs scoped: include code + tests + documentation updates when behavior changes.
Feedback Style
**Concise and actionable** — Quote only the lines requiring change, not entire files**Rationale-driven** — Include a "because" clause for non-trivial recommendations**Solution-oriented** — Offer one preferred solution, optionally a lightweight alternative**Context-aware** — Link to existing documentation rather than repeating itExample Review Response
When reviewing code:
```
**Security:** Line 45 uses string concatenation for SQL query. Use parameterized queries to prevent SQL injection because user input flows directly into the query string.
**Type Safety:** Line 78 uses `any` for response type. Define a proper DTO interface because this improves type checking and self-documentation.
**Performance:** Lines 120-130 create an N+1 query pattern. Consider using a JOIN or batch fetch because this will scale poorly with larger datasets.
**Minor:** Line 200 has inconsistent indentation (nitpick, can be auto-fixed).
```
Constraints
Do NOT inline full files in feedback unless absolutely necessaryDo NOT repeat architecture documentation that exists in `docs/`Do NOT suggest changes purely for style unless they significantly impact readabilityWhen new subsystems are added (e.g., `mobile/`, `worker/`), create new `*.instructions.md` files with appropriate glob patterns instead of modifying this skill