feat: normalize candidate application lifecycle - #66
Conversation
📝 WalkthroughWalkthrough후보자 지원을 불변 앵커, bitemporal 범위 버전, 단계 이력으로 분리했다. 테넌트 격리와 변경·삭제·TRUNCATE 보호를 적용했다. PostgreSQL 계약 테스트와 CI 저장소 검증을 갱신했다. Changes후보자 지원 핵심
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: 🔵 Low · up to The PR normalizes candidate application identity and lifecycle history. Current checks are green, but adding a uniqueness constraint to existing position data during deployment may briefly block reads and writes, so merge is low risk with owner awareness of the acceptable migration lock duration; the remaining documentation and test-maintenance issues are non-blocking. Sequence Diagram(s)sequenceDiagram
participant PullRequest
participant GitHubActions
participant PostgreSQL
participant ContractTests
PullRequest->>GitHubActions: trigger workflow
GitHubActions->>PostgreSQL: start PostgreSQL 16.14
GitHubActions->>ContractTests: run ordered PostgreSQL contracts
ContractTests->>PostgreSQL: apply migration and validate protections
PostgreSQL-->>ContractTests: return contract results
ContractTests-->>GitHubActions: report tests and worktree status
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 6 files. (9 skipped: 9 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Buyer-visible gap
Orgmetra currently conflates candidate identity with opening-specific recruiting lifecycle through a candidate-level application status. This lane adds tenant-qualified durable application identity, bitemporal Job/optional-Position scope versions, and bitemporal application-stage history while keeping employer terminal outcomes in governed decision boundaries.
Current domain contract
candidate_application_recordis the immutable durable anchor;candidate_application_record_versioncarries bitemporal Job/optional-Position scope;candidate_application_stage_recordcarries non-terminal recruiting stages. Same-tenant Candidate/Job/Position integrity and Position→Job scope are enforced. Raw stages exclude genericclosed, barewithdrawn, andhiredso governed terminal-decision/withdrawal evidence cannot be bypassed. Forced RLS is exercised with NOBYPASSRLS regressions. No dedicated-writer dependency repository or cross-service application-table SQL is introduced.Repair lineage
A CodeRabbit finding correctly identified that
docs/ERD.mdused the too-strongcandidate_application_record ||--|{ candidate_application_record_versioncardinality although the authoritative schema permits a durable application anchor with zero scope versions. Regression10335192ec910c1daa23ce88fd475f18cba81253pinned the optional||--o{edge;29691f265d100361e2d5a70024e02672384c2da9repaired the ERD;f27136f5febea21fb9b3cc7f22d4b564484a52beresealed the exact changed workflow/ERD artifacts. Those valid deltas remain preserved.Live authority
04c60a6d485c1af32973959c37c9133ae928f59bdevelop@9e3e4847510e1e612b48474ba42b177b8ed824dfdevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4fThe older body text that called this PR non-draft/mergeable is superseded. Its prior exact-source hosted snapshot included broad technical success but terminal OpenCode/Strix failures. Protected
develophas also advanced materially, so neither that old check rollup nor mechanical mergeability can authorize integration now.Stack discipline
PR #67 is a dependency-first child and remains on this parent's old branch snapshot. Process #66 first: non-force adopt the then-current protected
develop, preserve the normalized-application delta, reconcile migrations/ERD/provenance with protected truth, reseal exact changed artifacts, and rerun every applicable exact-current-head local/central gate. Only after normal protected integration should #67 adopt protected truth and reacquire its own withdrawal evidence. The separate unresolved ADR-manifest provenance dependency owned by #51 must likewise be revalidated from protected truth rather than copied from a mutable branch.Do not force-push, destructively rebase, self-approve, use routine administrator bypass, weaken a gate, transfer parent/predecessor evidence, or mutate a dedicated-writer dependency.