This repository contains the dpg-scoring microservice.
Current focus:
- Fastify + TypeScript service
- HMAC-authenticated internal APIs
- AI-backed
match-scorecompatibility scoring - Gemini-first provider setup with future OpenAI support
- OpenAPI docs via Swagger UI
- Redis-backed nonce storage and match-score caching
- public routes:
GET /GET /healthGET /ready
- protected routes:
POST /api/v1/scores/match
All /api/v1 routes are protected through the shared auth hook.
- OpenAPI docs are served from
/docs - raw OpenAPI JSON is served from
/docs/json - keep route schema metadata accurate because docs are generated from route definitions
- prefer OpenAPI as the source of truth even if the UI layer changes later
match-score is no longer rule-based.
Use this flow:
- validate raw DPG items
- normalize and redact sensitive fields from
item_state - resolve prompt version
- resolve provider
- call AI provider
- validate structured AI response
- return stable API response
- API version and prompt version are separate
- request
versiondefaults tov1 - request
promptVersionis optional - API
v1can later run with newer prompt versions - always preserve backward compatibility of the API response when changing prompts only
- keep provider-specific logic inside
src/modules/match-score/providers/ - keep prompt-specific logic inside
src/modules/match-score/prompts/ - do not mix Gemini/OpenAI request formatting into route or service files
- prefer provider abstraction over branching in route/controller code
- prompts must be versioned
- prompts should return JSON only
- prompts should score compatibility from
0to10 - prompts should avoid hallucination and use only provided fields
- prompt changes should be additive and traceable
- auth secrets are file-based under
config/auth.keys.json - AI provider secrets are file-based under
config/ai.providers.json - do not commit real secret values
- keep example files updated when secret file shapes change
- Redis is the shared store for auth nonce replay protection
- Redis is also used for match-score response caching
- prefer Redis-backed behavior when
REDIS_ENABLED=true - in local fallback mode, auth can use in-memory nonce storage and cache can be skipped
- local Redis is started with
docker compose up -d redis
- prefer small focused changes
- keep route handlers thin
- keep route summaries, descriptions, tags, and security metadata accurate for docs
- keep orchestration in services
- validate AI input/output with Zod
- cache only validated final match-score responses
- avoid hardcoding domain-specific matching logic into
v1 - preserve the generic compatibility prompt approach unless requirements change
After non-trivial changes, run:
pnpm check
pnpm buildUseful helpers:
docker compose up -d redis
pnpm call:match-score
pnpm auth:headers -- --format curl