chore: dependencies and coverage

[jamesacres]

No description provided.

[claude]

Code review

Reviewed dependency bumps (NestJS 10→11, ESLint flat config, Jest 30, TS 5.9, AWS SDK v3), the new CI workflow/husky hooks/coverage thresholds, and the hand-written logic changes (MCP client capabilities, Lambda handler for Node 24, CDK runtime bump, new enum values). No CLAUDE.md violations or significant bugs found in most of the diff. Two issues below survived independent verification.

1. CLAUDE.md / AGENTS.md — inaccurate "do not commit" rule

bubblyclouds-api/CLAUDE.md

Lines 28 to 31 in 13ae1f7

	adminUsers, codes or the RevenueCat key.
	- Do not commit generated/vendored output: `dist/`, `coverage/`, `wasm/`,
	`sudoku-seeds/` and `src/lib/qqwing/` are build artifacts / vendored code.
	- Co-locate a `*.spec.ts` with every new source file; unit coverage thresholds

The new agent instructions state:

Do not commit generated/vendored output: dist/, coverage/, wasm/, sudoku-seeds/ and src/lib/qqwing/ are build artifacts / vendored code.

wasm/, sudoku-seeds/, and src/lib/qqwing/ are actually tracked in git and not in .gitignore (only dist/ and coverage/ are). src/lib/qqwing/index.ts is imported directly by production code in src/sudoku/sudoku.service.ts. Since these files are auto-loaded standing instructions for future agents, this could lead an agent to delete or gitignore files the build/runtime depends on. The same text is duplicated in AGENTS.md:

bubblyclouds-api/AGENTS.md

Lines 28 to 31 in 13ae1f7

	adminUsers, codes or the RevenueCat key.
	- Do not commit generated/vendored output: `dist/`, `coverage/`, `wasm/`,
	`sudoku-seeds/` and `src/lib/qqwing/` are build artifacts / vendored code.
	- Co-locate a `*.spec.ts` with every new source file; unit coverage thresholds

2. scripts/local-dynamodb-setup.ts — dotenv used but not a declared dependency

bubblyclouds-api/scripts/local-dynamodb-setup.ts

Lines 11 to 13 in 13ae1f7

	*/
	import 'dotenv/config';

import 'dotenv/config';

dotenv is not in root package.json's dependencies or devDependencies — it only resolves today because it's hoisted as a transitive dependency of @nestjs/config (pinned to an exact 17.4.1 there). Under a strict-hoisting installer, or if that transitive pin changes, npm run dynamodb:setup would fail with MODULE_NOT_FOUND. deploy/package.json declares dotenv explicitly as a direct dependency, suggesting this root omission is an oversight — the fix is a one-line addition to root devDependencies.

---

🤖 Generated with Claude Code