API & Service Communication Contracts

Analyze the project to document all services, API endpoints, communication patterns (sync/async), DTOs, and retry/circuit-breaker policies. Generate a Mermaid sequence diagram showing the primary request flow across services. Save to .github/modernize/assessment/engines/facts/api-service-contracts.md.

Input Parameters

workspace-path (optional): Path to the project to analyze (defaults to current directory)

Scope Boundaries — Avoid Redundancy with Other Skills

This skill is part of a set of four complementary assessment skills. To avoid content duplication across their output documents, observe these scope rules:

Introduction: Write a 1-2 sentence intro focused on the API surface (number of endpoints, communication style). Do NOT restate the application's technology stack, database options, or architecture type — those are covered by other skills.
Entity fields and persistence details are owned by the data-architecture skill. In the DTOs & Contracts section, list entity/DTO class names and their role in the API contract (request type, response type, immutability). Do NOT reproduce full field lists, ORM annotations (cascade, fetch strategy), or table names — reference data-architecture.md instead.
Validation rules (e.g., @NotBlank, custom validators) are owned by the business-workflows skill. Mention validation only when it affects the API contract (e.g., "returns 400 if validation fails"). Do NOT enumerate individual field constraints.
Caching implementation details (provider, TTL, configuration class) are owned by the data-architecture skill. In the sequence diagram, you may show cache hit/miss behavior, but do NOT repeat the cache provider name, configuration details, or rationale.
Configuration properties and profiles (e.g., spring.jpa.*, database profiles) are owned by the configuration-inventory skill. Do NOT list property keys/values.
Startup dependency chain details (readiness probes, K8s manifests, dockerize) are owned by the configuration-inventory skill. Mention startup order only if it directly affects API availability. Do NOT repeat probe paths or wait mechanisms.