Implement strict backend CV template placeholder endpoints and replacement flow with TDD coverage

[Copilot]

This issue requires backend support for strict {{PLACEHOLDER}} template CV generation while keeping the base resume flow unchanged and API-compatible.
This PR includes the backend endpoint exposure, strict replacement implementation, and focused TDD coverage for placeholder detection/replacement in template mode, with backend scope kept explicit and deterministic.

• Template placeholder detection endpoint contract

  • Exposed and validated POST /api/v1/google-drive/resume-placeholders.
  • Added dedicated request/response DTOs for detection:
    • Request: { "baseResumeId": "uuid" }
    • Response: { "baseResumeId": "uuid", "placeholders": ["SUMMARY", "SKILLS"] }
  • Verifies placeholders are extracted from Google Doc template text and returned without braces.

• Template generation endpoint contract

  • Exposed and validated POST /api/v1/google-drive/applications/{applicationId}/generated-resumes.
  • Response contract is explicit for template generation:
    • applicationId, baseResumeId, copiedFileId, pdfFileId, documentUrl, pdfUrl, values, placeholders, generatedAt.
  • Verifies provided values are applied and unresolved placeholders remain detectable.

• Template generation implementation

  • Simplified replacement flow so generation uses request values keys directly.
  • Replacement is strict and deterministic for official placeholder format {{PLACEHOLDER}} (key-based input like SUMMARY becomes {{SUMMARY}} during replacement).
  • Removed dynamic placeholder inference and compatibility branching from generation flow.
  • Keeps base resume generation flow unchanged.

• Service structure clarity

  • ResumeGenerationService exposes explicit methods for:
    • placeholder detection from template text
    • template resume generation from provided values
  • Controller wiring now calls these explicit service methods directly.

• Google Drive API behavior

  • SdkGoogleDriveApiClient replacement remains strict token replacement using {{KEY}}.
  • No alternate placeholder syntax compatibility behavior was introduced.

• Google Drive test double behavior

  • FakeGoogleDriveApiClient simulates stateful document text and strict placeholder replacement.
  • Includes resettable default template state to prevent cross-test leakage.

{
  "baseResumeId": "<resume-id>",
  "values": {
    "SUMMARY": "Senior Java Engineer",
    "SKILLS": "Spring Boot, PostgreSQL"
  }
}

[vitorhugo-java]

Implement features specificed on Issue. Using TDD. @copilot

[Copilot]

Implement features specificed on Issue. Using TDD. @copilot

Implemented the issue feature with TDD in commit c717153: template generation now replaces placeholders based on detected document tokens (including {{ PLACEHOLDER }} with internal whitespace), keeps base flow unchanged, and includes focused unit/integration coverage for detection and generation behavior.

[vitorhugo-java]

@copilot Act as a senior Java/Spring backend engineer.

You are working on the backend-only implementation for CV template placeholders.

Current PR problem:

The implementation expanded the backend scope too much and started handling behaviors that belong to the frontend flow.

This PR must ONLY provide the backend capabilities required for the future frontend implementation.

Do NOT implement frontend logic assumptions inside the backend.

Requirements to fix:

1. Keep backend responsibility limited to:

• detecting placeholders from template documents
• generating final CV documents with placeholder replacement
• preserving the current base CV generation flow

2. Do NOT introduce flexible placeholder parsing behavior that changes the contract unnecessarily.

The official placeholder format is STRICTLY:

{{PLACEHOLDER}}

Examples:

{{SUMMARY}}
{{SKILLS}}
{{PROJECT_HIGHLIGHT}}

Do not support additional syntaxes beyond whitespace normalization if truly necessary.

3. Simplify replacement logic.

Current implementation:

• reads document
• detects placeholders dynamically
• rebuilds replacement maps
• wraps tokens conditionally
• supports multiple token formats

This is over-engineered for the intended feature.

Expected behavior:

• frontend will already know the placeholder names
• backend receives:
  {
  "values": {
  "SUMMARY":"...",
  "SKILLS":"..."
  }
  }
• backend simply replaces:
  {{SUMMARY}}
  {{SKILLS}}

Keep the implementation simple and deterministic.

4. Remove backend assumptions that belong to frontend UX.

Backend should NOT:

• infer placeholder names dynamically during generation flow
• implement UI-oriented compatibility behavior
• try to support multiple user input styles
• contain frontend-oriented normalization logic

5. Keep placeholder detection endpoint only for template configuration support.

This endpoint is valid:
POST /api/v1/google-drive/resume-placeholders

Purpose:

• detect placeholders from template document
• allow frontend configuration UI later

Do not mix detection responsibilities with replacement flow.

6. Preserve backward compatibility:

• existing base resume generation must continue working exactly as before
• non-template CV flow must remain untouched

7. Refactor implementation for clarity.

Expected structure:

ResumeGenerationService

• detectPlaceholders()
• generateTemplateResume()

SdkGoogleDriveApiClient

• replaceGoogleDocPlaceholders()

Keep methods small and explicit.

8. Remove unnecessary complexity from:

• buildReplacementValues()
• resolvePlaceholderToken()
• token compatibility branching

The backend contract should be predictable and strict.

9. Tests:

Keep only tests that validate:

• placeholder detection
• placeholder replacement
• unresolved placeholders remain detectable
• base flow still works

Remove tests validating unnecessary compatibility behavior.

10. Follow:

• SOLID
• clean architecture
• avoid overengineering
• backend-only scope
• production-ready code

[Copilot]

@copilot Act as a senior Java/Spring backend engineer.

You are working on the backend-only implementation for CV template placeholders.
...

Updated in commit 2d3a6b7.

Changes now keep backend scope strict and deterministic: template generation directly replaces only {{PLACEHOLDER}} tokens from values keys, placeholder detection remains isolated to /resume-placeholders, base resume flow remains unchanged, and over-engineered compatibility/dynamic token inference paths were removed. Tests were simplified to cover only detection, strict replacement, unresolved placeholders, and base-flow preservation.

[vitorhugo-java]

@copilot Act as a senior Java 21 + Spring Boot backend engineer.

The current PR is wrong because it only changed service/client/test layers and did NOT expose the feature through API endpoints.

Your task is to implement the backend endpoints for CV template placeholders, keeping the frontend for a later issue.

STRICT SCOPE:

• Backend only
• No frontend code
• No UI assumptions
• No extra placeholder syntax beyond the official contract
• Keep the base resume flow unchanged

OFFICIAL PLACEHOLDER CONTRACT:
Use ONLY this format in template documents:
{{PLACEHOLDER}}

Examples:
{{SUMMARY}}
{{SKILLS}}
{{PROJECT_HIGHLIGHT}}

REQUIRED ENDPOINTS:

1. Detect placeholders from a template resume
   POST /api/v1/google-drive/resume-placeholders

Request:
{
"baseResumeId": "uuid"
}

Response:
{
"baseResumeId": "uuid",
"placeholders": ["SUMMARY", "SKILLS", "PROJECT_HIGHLIGHT"]
}

Purpose:

• Read the Google Docs template content
• Detect placeholders from the document text
• Return only the placeholder names without braces

2. Generate a resume using template placeholders
   POST /api/v1/google-drive/applications/{applicationId}/generated-resumes

Request:
{
"baseResumeId": "uuid",
"values": {
"SUMMARY": "Senior Java Engineer",
"SKILLS": "Spring Boot, PostgreSQL"
}
}

Response:
{
"applicationId": "uuid",
"baseResumeId": "uuid",
"copiedFileId": "string",
"pdfFileId": "string",
"documentUrl": "string",
"pdfUrl": "string",
"values": {
"SUMMARY": "Senior Java Engineer",
"SKILLS": "Spring Boot, PostgreSQL"
},
"placeholders": [],
"generatedAt": "date-time"
}

IMPLEMENTATION REQUIREMENTS:

• Create a controller under the Google Drive API namespace
• Add DTOs for request and response
• Wire the controller to the existing ResumeGenerationService
• Keep placeholder detection and generation in the service layer
• Keep base resume generation behavior unchanged
• Do NOT add flexible token compatibility logic
• Do NOT change the frontend flow here
• Do NOT change existing API contracts unrelated to CV generation

SERVICE REQUIREMENTS:

• ResumeGenerationService must expose methods for:
  • detecting placeholders from document text
  • generating a resume from provided values
• The service must replace only placeholders matching the exact keys from the request
• The service must preserve unresolved placeholders if no value is provided
• The service must return metadata needed by the controller response

GOOGLE DRIVE CLIENT REQUIREMENTS:

• Keep replacement deterministic
• Replace only exact placeholder tokens using the official contract
• Avoid overengineering
• Keep methods small and explicit

TESTS:

Add integration tests for:

• POST /api/v1/google-drive/resume-placeholders
• POST /api/v1/google-drive/applications/{applicationId}/generated-resumes

Add unit tests for:

• placeholder detection
• placeholder replacement
• unresolved placeholders behavior

ACCEPTANCE CRITERIA:

• The feature is reachable through real endpoints
• The backend exposes placeholder detection
• The backend exposes template resume generation
• Base resume flow remains unchanged
• No frontend code is introduced
• No controller means the task is incomplete

[Copilot]

@copilot Act as a senior Java 21 + Spring Boot backend engineer.

The current PR is wrong because it only changed service/client/test layers and did NOT expose the feature through API endpoints.
...

Addressed in commit b12932e.

Implemented and exposed the backend endpoints with explicit contracts:

• POST /api/v1/google-drive/resume-placeholders now uses dedicated detection request/response DTOs (baseResumeId, placeholders).
• POST /api/v1/google-drive/applications/{applicationId}/generated-resumes is wired to template generation with strict {{PLACEHOLDER}} replacement and response fields aligned to the requested backend contract (applicationId, baseResumeId, copiedFileId, pdfFileId, documentUrl, pdfUrl, values, placeholders, generatedAt).

Also refactored service wiring to explicit methods (detectPlaceholders, generateTemplateResume) and updated unit/integration coverage accordingly, while keeping base resume flow untouched.