fix(seed): 응웬반A Golden Flow 시작 상태와 PostgreSQL 호환성 보강

[krestar]

왜 필요한가요?

대표 시연은 HR이 응웬반A에 대한 자연어 요청을 입력하는 시점부터 시작하지만,
기존 Demo Seed에는 응웬반A의 Case, Task, 문서, 승인과 Audit 등 흐름이 이미 진행된 상태가 포함되어 있었고,
여권 정상·외국인등록증 사본 누락이라는 시연 전제도 Server가 재현 가능한 형태로 구분되지 않았습니다.
이 때문에 Golden Flow를 처음부터 재현하기 어렵고, 실제 시연 중 생성되는 데이터와 기존 Seed가 충돌할 수 있었습니다.

또한 PostgreSQL 17에서 Demo Seed를 활성화하면 DemoCaseSeeder가 Instant를 직접 SQL 파라미터로 전달하면서
다음 오류로 서버 기동이 중단됐습니다.

PSQLException: Can't infer the SQL type to use for an instance of java.time.Instant

이 PR은 현재 구현된 모델 범위에서 응웬반A를 Golden Flow 시작 상태로 정리하고,
PostgreSQL에서도 빈 DB 기동과 동일 DB 재기동을 안정적으로 수행할 수 있게 합니다.

• Closes [Demo Seed][P1] 시나리오(응웬반A) 시작 데이터 정합성 보강 #94

무엇이 바뀌나요?

Demo Seed

• 응웬반A Worker 92000000-0000-0000-0000-000000000006와 Demo Company·HR·Workflow 참조는 유지합니다.
• 응웬반A와 직접 연결된 기존 Case 1건, Task 3건, 계약서 WorkerDocument 1건 및 관련
  Checklist·Approval·Transition·Document Request Draft·Audit를 생성 대상에서 제외합니다.
• 여권은 PASSPORT_COPY/VERIFIED와 유효한 미래 만료일, 외국인등록증 사본은
  ARC/MISSING과 만료일 없음으로 명시합니다. 두 row에는 Task·StoredFile·OCR 결과를
  연결하지 않습니다.
• 응웬반A의 AiRun, AiAttempt, Question, Candidate, Candidate Decision,
  WorkerLink, WorkerResponse, Submission, Evidence가 없는 시작 상태를 검증합니다.
• 다른 27명 근로자의 Showcase 값·고정 ID·상태·관계는 유지합니다. 순번 기반 파생 ID가
  이동하지 않도록 기존 전체 Catalog를 구성한 뒤 Golden Flow 관련 closure만 제외합니다.
• 구버전 응웬반A 예약 ID가 남아 있는 DB는 사용자 데이터를 자동 삭제하지 않고 fail-fast합니다.
  개인 Demo DB 또는 전용 volume 초기화가 필요합니다.

주요 Demo Company 수량 변화:

데이터	변경 전	변경 후
Case	22	21
Task	24	21
WorkerDocument	84	83
Checklist	68	60
Approval	13	12
Transition	52	48
Document Request Draft	5	4
Audit Event	96	88

Worker 28명, StoredFile 3건, ExternalSubmission 6건, Evidence 10건과
응웬반A 외 Showcase fixture의 고정 식별자는 유지됩니다.

PostgreSQL JDBC 호환성

• DemoCaseSeeder의 timestamp 파라미터를 JDBC 경계에서
  Timestamp.from(instant)로 명시적으로 변환합니다.
• Domain의 Instant 타입과 PostgreSQL 스키마는 변경하지 않습니다.
• PostgreSQL 17에서 Demo Seed를 활성화한 dev profile Application Context를 두 번
  기동하는 회귀 테스트를 추가합니다.

API·도메인·권한·AI

• 운영 API, DTO, Domain Model과 DB 스키마 변경은 없습니다.
• Role·Permission과 tenant 접근 규칙 변경은 없습니다.
• AI Runtime이 요청한 경우 Server가 같은 tenant의 WorkerDocument를 조회해
  passport_copy_status, passport_copy_expiry_date, arc_status, arc_expiry_date를
  구조화된 Context로 제공합니다.
• 문서 상태·만료일은 Server 소유 값으로 검증하며 AI Runtime이 다른 값으로 변경하면
  CORE_VALUE_MISMATCH로 거부합니다.
• Prompt, Agent/Model routing과 외부 연동 변경은 없습니다.
• Issue #84의 E-9 날짜·비자정보, 별도 Workplace·연락처, Agent/Prompt Version Seed를
  선행 구현하지 않습니다.

문서·배포

• docs/demo-seed.md와 docs/demo-seed-fixture-manifest.md를 실제 Seed 수량과 Golden
  Flow 시작 상태에 맞게 갱신합니다.
• PostgreSQL 17 첫 기동·동일 volume 재기동 절차와 구버전 개인 DB 초기화 정책을
  docs/deployment-runbook.md에 추가합니다.
• Compose의 DEMO_SEED_ENABLED 기본값은 계속 false입니다.

어떻게 검증했나요?

자동 테스트

• ./gradlew clean test
• POSTGRES_TEST_ENABLED=true 환경의 ./gradlew clean test
• H2 Demo Seed 전체 실행·재실행과 snapshot 불변 검증
• 응웬반A 단일성 및 Golden Flow 후속 데이터 미생성 검증
• 응웬반A 여권 VERIFIED·미래 만료일과 ARC MISSING 상태 검증
• WorkerDocument의 tenant 격리 AI Context 해석과 Server 소유 값 변조 차단 검증
• 다른 Showcase fixture의 수량·고정 ID·관계 보존 검증
• PostgreSQL timestamp 저장·재조회와 DemoCaseSeeder 재실행 검증
• PostgreSQL 17 Demo Application Context 첫 기동·동일 DB 재기동 검증
• ./gradlew build

일반 clean test와 PostgreSQL 환경 테스트가 모두 통과했습니다.

수동 Smoke

• 빈 PostgreSQL 17 Docker DB에서 DEMO_SEED_ENABLED=true로 서버 기동
• 서버 중지 후 같은 DB volume으로 Demo Seed 활성 서버 재기동
• 두 번째 기동에서도 Seed 오류가 없고 응웬반A Worker가 유지되는지 확인
• /health와 Swagger UI는 별도로 확인하지 않음

수동 Smoke는 서버 기동·재기동 성공과 응웬반A 관련 데이터(최하단 첨부)를 중심으로 확인했습니다.
세부 수량, 미생성 상태와 timestamp 불변은 자동 통합 테스트가 검증합니다.

보안·개인정보

• DTO·로그·AI 입력에 불필요한 개인정보를 추가하지 않았습니다.
• JWT, Worker Link 원본 토큰, API Key와 실제 비밀번호를 추가하지 않았습니다.
• Demo Company와 Test Company의 company_id 격리 검증을 유지합니다.
• AI 결과의 자동 승인·발송 동작을 추가하지 않았습니다.
• 기존 Accepted ADR의 저장소·보안·Workflow 경계를 변경하지 않았습니다.
• Server에 Prompt Builder·Provider SDK·모델 routing을 추가하지 않았습니다.

응웬반A의 AI Context에는 문서 종류·상태·만료일만 포함합니다. 여권번호, 외국인등록번호,
연락처, 주소, OCR 결과나 신분증 이미지는 Seed와 AI Context에 포함하지 않습니다.

API·DB·운영 영향

• API/OpenAPI/Notion 계약 변경: 없음
• DB 스키마 및 Flyway Migration: 없음
• 신규 환경변수: 없음
• Client 호환성: 응웬반A의 기존 Case·Task·계약서는 더 이상 Seed되지 않고, 여권
  VERIFIED와 ARC MISSING 문서가 Golden Flow 시작 상태로 조회됩니다. 전체 Demo
  목록·상태별 수량은 위 표와 같이 변경되며 다른 Worker의 고정 fixture는 유지됩니다.
• 기존 개인 Demo DB: 구버전 Golden Flow 예약 ID가 있으면 서버가 fail-fast하므로 해당
  개인 DB 또는 전용 volume을 초기화해야 합니다.
• Rollback: Migration이 없으므로 애플리케이션 변경을 revert할 수 있습니다. DB 데이터를
  되돌리기 위해 flyway repair나 schema history 조작을 하지 않습니다.
• Smoke 및 초기화 절차: docs/deployment-runbook.md에 반영했습니다.

화면 또는 응답 예시

API 응답 형식 변경은 없습니다.

Seed 직후 응웬반A의 실제값을 직접 확인.

[hywznn]

현재 #94에는 응웬반A의 WorkerDocument를 미리 만들지 않는다고 되어 있지만, 이 PR에서는 여권 VERIFIED와 외국인등록증 MISSING 문서를 생성하고 있습니다. => 하지만 만든다는점 확인했습니다

또한 현재 Agent는 worker_id, stay_expiry_date만 요청해서 새 문서 상태가 실제 분석에는 전달되지 않습니다.
-> DB에는 여권·외국인등록증 상태가 있지만 Agent에게 보내는 요청에는 그 값이 빠져있어요

1. Agent: worker_id와 stay_expiry_date를 알려주세요
2. Server: Agent가 요청한 두 값만 DB에서 조회
3. Server → Agent:
   worker_id
   stay_expiry_date
4. Agent가 이 두 값만 가지고 분석

agent한테 요청해달라고 이야기해보거나 해야할 것 같습니다
workflow/service.py 15줄

서버랑 다른 값

passport_copy_status
passport_copy_expiry_date
arc_status
arc_expiry_date

추가 참고
knowledge/required_slots.yaml 63줄

WF-STY-001:
  required: [worker_id, due_at]
  optional: [stay_expiry_date]
  resolvable_from_context:
    - worker_id
    - due_at
    - stay_expiry_date

Server PR #111에 여권·외국인등록증 상태를 조회하는 Resolver가 추가됐지만, 현재 WF-STY-001의 PLAN requiredFieldKeys에는 문서 상태가 없어 실제 ANALYZE 요청에 전달이 안될겁니다

=> Golden Flow에서 여권 VERIFIED, 외국인등록증 MISSING 상태를 활용하려면 Knowledge와 Agent에서 passport_copy_status, arc_status 등을 요청하도록 반영

단, arc_status=MISSING일 때 arc_expiry_date를 HR에게 입력하라고 묻지 않고 외국인등록증 사본 요청으로 이어지도록 처리

단순히 Agent 코드에 네 필드를 모두 추가하면, 외국인등록증이 없는데 만료일을 입력하라는 질문이 나올 수있음. 따라서 상태가 MISSING이면 만료일 질문 대신 서류 요청으로 처리하는 로직도 같이 필요

[hywznn]

이 부분에 대해서는 조금 고민해보시긴 해야할 것 같아요 데모용으로 생각하실건지 일단 풀패키지로 생각하면서 client agent 보완 요청을 할 것인지 제 생각은 후자이긴 합니다