Context
The tests added in #41 for uppercase name normalization (bundles.test.ts and skills.test.ts) assert that the response does NOT contain "Invalid package/skill name" — confirming the name passes validation. However, they don't assert what actually happens next (the request proceeds to a downstream step that fails for a different reason due to mocking boundaries).
A tighter test would assert the specific downstream error (e.g., a GitHub fetch failure or DB lookup), making the test less fragile if error messages are reworded later.
Fix
In apps/registry/tests/bundles.test.ts and apps/registry/tests/skills.test.ts, update the normalization tests to assert the expected downstream error rather than just the absence of the validation error.
Context
The tests added in #41 for uppercase name normalization (
bundles.test.tsandskills.test.ts) assert that the response does NOT contain "Invalid package/skill name" — confirming the name passes validation. However, they don't assert what actually happens next (the request proceeds to a downstream step that fails for a different reason due to mocking boundaries).A tighter test would assert the specific downstream error (e.g., a GitHub fetch failure or DB lookup), making the test less fragile if error messages are reworded later.
Fix
In
apps/registry/tests/bundles.test.tsandapps/registry/tests/skills.test.ts, update the normalization tests to assert the expected downstream error rather than just the absence of the validation error.