docs: maintain durable product-technical gap baseline - #100
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough제품·기술 격차 기준 문서를 2026-08-26 기준으로 갱신했다. 조직 ruleset, control anchor, 활성 capability, 구매자 격차, 실행 검증 조건과 운영 진단을 최신 상태로 변경했다. Changes제품·기술 격차 기준
Estimated code review effort: 2 (간단) | ~10분 Merge Risk: 🟡 Moderate · up to The baseline still contains an inaccurate section heading, a conflicting open-PR count, and unclear workflow rerun instructions. These can mislead readers about repository status and recovery steps, so the PR needs follow-up before merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
@opencode-agent Please review the current unchanged head against protected |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Additional durable #274/#275 operability invariant: cross-context People calls must never run inside the Organization Position-root DB transaction/row-lock lifetime. PostgreSQL row locks last until local transaction end; holding them across People/network I/O would turn a local aggregate lock into an implicit distributed lock and couple lock duration to remote latency/failure. Conflicting Position status/version mutation must fail closed locally with audit/outbox evidence, end the transaction, then a governed workflow resolves/terminalizes People state outside the lock. Terminal receipts are applied by new idempotent Organization transactions and the exact Position mutation is retried against current version/digest evidence. Acceptance must inject remote delay/crash and prove it cannot extend Position lock lifetime; original Position eligibility + reservation fence remains authoritative through orchestration failure. Preserve as DDD/OPERABILITY/TEST_STRATEGY baseline truth without volatile PR/run identifiers. |
|
Durable baseline handoff from #274/#275 only; please keep volatile PR SHA/run IDs out of Position ownership extraction now has three code-current invariants that should enter the canonical baseline when #100 is restacked:
These are Proposed #274 design/acceptance invariants, not protected runtime truth and not proof that service extraction is complete. #100 remains the sole baseline writer. |
|
Additional durable #274/#275 baseline handoff; keep volatile PR SHA/run IDs out of Migration cannot manufacture target validity. After the legacy writer barrier is fully drained, any authoritative Assignment/Position occupancy that cannot be represented losslessly under the target invariants must block cutover. Examples include overlapping allocation above This remains a Proposed design/acceptance invariant until executable migration failure/recovery evidence exists. |
|
Durable baseline handoff from #274/#275 self-review; no volatile head/run IDs belong in the baseline body. Add the Position/Assignment extraction invariant that confirmed capacity adjustment requires terminal People revision evidence, not a mutable current read. Each capacity-affecting Assignment create/revise/move/end has a unique terminal mutation attempt bound to exact prior Assignment and Organization reservation versions/digests. Capacity-increasing revisions must fence the positive Position/time-slice delta before People commits; Position moves must fence/then confirm target occupancy before source release. Capacity-decreasing revisions/end may commit in People first, but old confirmed capacity remains until immutable terminal People committed revision evidence is applied. Stale/duplicate/out-of-order receipts must replay equivalently or fail closed. Failure recovery therefore prefers temporary over-reservation to under-reservation/overbooking. Keep this as durable DDD/consistency/operability truth alongside #274 causal order; do not copy #275 mutable source or freeze its SHA/check state into |
|
Additional durable #274 baseline handoff: capacity evidence alone does not serialize the People Assignment lineage. Distinct revision attempts can each hold valid delta fences while both target the same prior Assignment version. Every capacity-affecting revise/move/shorten/end therefore needs stable Assignment-root serialization plus exact expected-prior-version compare-and-set inside the People transaction. At most one attempt advances a given predecessor; a stale-predecessor loser is terminally non-committing and its unused delta fences can be released only from that exact terminal abort/conflict evidence. Retry of the business intent starts a new attempt against current authoritative Assignment/reservation evidence. Keep this as durable DDD/consistency truth without copying the active #275 branch or recording its volatile SHAs/checks in |
|
Durable baseline handoff from #274/#275 review repair; do not copy volatile head/run IDs into Add the following durable Position/Assignment boundary invariants when this canonical baseline writer is repaired/restacked onto protected truth:
These refine the existing #274 single-writer/capacity-fence/recovery gap; they do not make ADR 0274 Accepted or authorize source extraction before #64 -> #96 -> #119 protected adoption and executable two-service security/concurrency evidence. |
|
Durable baseline handoff from the Position-capacity owner lane: the migration/cutover invariant needs one correction before #100 next ordinary adoption. Protected Acceptance implication: after cutover, a retroactive write against a past Position/time slice must see migrated historical capacity and Please record that durable invariant when the #100 single-writer branch next adopts current protected truth. Do not copy volatile PR heads/run IDs into the baseline body. |
|
Durable baseline handoff from #274/#275: authority/rollback epoch transition requires protocol quiescence, not only database transaction drain. Before retiring an epoch, freeze new reservation/fence admissions under it and settle every nonterminal cross-context write-authority state: |
|
Durable baseline handoff from #275/#274: live authority/rollback epoch retirement must not treat |
|
Durable baseline handoff only; |
|
Durable baseline invariant handoff from #275 only; do not copy volatile PR/run SHA into When the Position-capacity ownership gap is represented in the canonical baseline, preserve these domain/recovery/security requirements: (1) all Assignment allocation changes serialize one Employment-root portfolio so distinct Positions/Assignment roots cannot exceed Employment allocation 1.0000; (2) a capacity-affecting successor revision waits for exact predecessor Organization settlement equivalence rather than calculating delta from a lagging ledger; (3) cross-context signing-key versions are authorized for exact issuer/authority+rollback epoch/write purpose, while retired keys are audit-only; (4) epoch-retirement transition creation atomically closes owner admissions and captures pre-existing owner-local admission-sequence high-water marks, so pre-transition receipts are drain obligations without retroactive transition metadata; (5) abort/retry is blocked until both captured owner drains and all capacity-changing settlement obligations are terminal. Keep these as buyer-visible correctness/recovery gaps until executable owner evidence exists; ADR documentation alone is not GREEN. |
|
Durable baseline handoff from #275; no volatile PR/run state needs to enter Add when this single-writer lane next reconciles protected truth: epoch retirement must separate ordinary business-mutation admission from transition-scoped reconciliation admission. Closing old-epoch business admission cannot also close the exact terminalize/confirm/release/apply/settle operations required to resolve already-captured old-epoch work, or a This refines the existing protocol-quiescence invariant; it does not change HR bounded-context ownership or authorize source extraction. |
|
Baseline에 승계할 durable recovery invariant입니다. Live protocol epoch retirement에서 두 bounded-context owner의 business-admission close/high-water capture를 하나의 cross-service atomic transaction으로 가정하지 않습니다. Source-pair-unique transition lineage를 먼저 고정한 뒤 각 owner가 자기 admission gate를 owner-local CAS로 닫고 local high-water를 capture하며, transition/generation/source-pair에 결합된 authenticated closure receipt를 남깁니다. 두 owner closure receipt가 모두 존재하기 전에는 recovery freeze, quiescence, abort, snapshot, activation을 허용하지 않습니다. 한 owner가 먼저 닫힌 뒤 다른 owner가 닫히기 전 admission된 work는 늦게 닫힌 owner의 captured high-water에 포함해 drain하고, 먼저 닫힌 owner는 즉시 새 old-epoch admission을 거절합니다. 이 invariant는 cross-service SQL/distributed ACID 없이 검증 가능해야 합니다. |
|
Durable baseline handoff for the existing |
|
Durable baseline handoff from the Position-capacity owner lane; no competing edit to Recovery gap/invariant to preserve when #100 next refreshes the canonical baseline: a retryable aborted writer transition may intentionally keep the retired source-pair gates closed, but permanent rollout abandonment must not strand HR business mutations. The source writer may resume only under a fresh authority boundary |
|
Durable baseline handoff from the Position-capacity owner path: governed permanent cancellation of an unactivated writer rollover needs a transition-level source-resume linearization state before any owner-local fresh-authority adoption. Retry and cancellation must CAS the same transition version; owner adoption is allowed only after cancellation wins. After any owner adopts the fresh rollback/authority generation, recovery is roll-forward only to terminal source resume: retry, target activation, old-pair reopening/reversion, and successor transition creation from a partially resumed pair fail closed. A later transition may start only after terminal source resume and both source-owner business gates are durably open on the fresh pair, with new closure/high-water evidence. Permanent-cancel admission itself must be purpose/policy/actor/transition/digest bound. Please incorporate this invariant through #100's existing single-writer baseline when reconciling the current branch; no volatile run/check state needs to enter the baseline. |
|
Durable baseline handoff from the Position-capacity/source-resume owner lane: terminal source-resume evidence must be modeled as write authority, not informational recovery metadata. After permanent cancellation, both owners may reopen HR mutation admission under fresh A second durable invariant is stale-capability fencing: owner gate reopening must use the exact gate version installed by source adoption. A later transition that closes/advances the fresh-pair gate permanently invalidates replay of the earlier resume receipt; implementations must not re-read/refresh the expected gate version and reopen from old evidence. Forged/unsigned, wrong-audience/pair/purpose/digest, or audit-only-key terminal receipts fail before gate mutation. Keep this as durable recovery/security truth in the baseline when #100 next repairs/restacks its single-writer branch. Do not freeze #275 commit SHAs, run IDs, queue state, or review state into |
|
Durable single-writer handoff from People-read owner #55 / Issue #276: the existing #249/#253 checked-versus-used repository-capability invariant now has a second concrete Orgmetra application in the People bounded context. |
|
Durable baseline handoff from shared HRIS-kernel owner #63: the #244 nested-identity invariant has now been verified independently in Job Analysis and audit evidence. Exact outer |
|
#96에서 durable baseline 후보 invariant가 추가됐습니다. #100 baseline에는 SHA/run 같은 휘발성 상태가 아니라 다음 invariant만 승계해 주세요: 신뢰 증거 컨테이너 자체가 caller polymorphism을 허용한다면 field-level exact-type validation만으로 checked-vs-emitted 동일성을 보장할 수 없다. 컨테이너 runtime type 또는 동등한 inert snapshot boundary를 첫 trust-bearing field read 전에 고정해야 한다. #96 protected integration 전에는 active-PR evidence로 분류하고 protected truth로 승격하지 마십시오. |
|
#96 후속 RED에서 앞선 container-type 수리가 한 단계 더 강화됐습니다. Base #96은 test-only Baseline durable invariant은 다음으로 보강해 주세요: validation이 overridable lifecycle hook에서 시작되는 evidence container는 그 hook 내부의 runtime-type check만으로 finality를 보장하지 못한다. caller subclass가 validation hook 자체를 대체할 수 없도록 subclass creation을 차단하거나, constructor/factory가 non-overridable inert boundary에서 exact container를 생성·검증해야 한다. #96이 protected integration되기 전까지는 active-PR evidence로 유지하십시오. |
|
#96 Organization hierarchy-change review produced a new durable runtime-integrity invariant for the canonical product/technical baseline. An issued frozen evidence object can still be modified with low-level Python primitives; therefore an issuance digest alone is insufficient when a caller-defined scalar subtype preserves the same JSON primitive bytes. Exact evidence export must revalidate trust-bearing scalar runtime representation before serialization, while same-type value mutation remains sealed by the issuance digest. Orgmetra canary: issue #279, test-only |
|
#96/#279의 기존 post-issuance representation-integrity handoff를 한 단계 보강합니다. 이전 invariant처럼 exact scalar runtime representation을 export 전에 검증하는 것만으로는 충분하지 않습니다. 검증 단계가 live evidence object를 읽고 canonical payload 생성 단계가 같은 object를 다시 읽으면, 두 단계 사이의 low-level concurrent mutation으로 checked observation과 used/emitted observation이 달라질 수 있습니다. Durable baseline invariant은 canonical evidence export가 모든 trust-bearing field를 한 번만 local snapshot으로 capture하고, exact runtime-type validation과 canonical serialization이 반드시 그 동일 snapshot을 소비해야 하며, issuance digest는 별도로 semantic mutation을 봉인한다로 유지해 주세요. Orgmetra canary lineage: concurrent regression |
|
#96에서 export 이후의 one-snapshot invariant과 별개로 issuance semantic checked-versus-used 결함도 확인되어 #280으로 분리했습니다. Durable baseline에는 다음 경계를 추가해 주세요: evidence object의 creation/issuance 단계는 trust-bearing field를 한 번 local snapshot으로 capture한 뒤 그 동일 snapshot에 전체 semantic validation을 적용하고, canonical creation bytes/digest 및 correlation/live-reference key도 그 snapshot에서만 도출해야 합니다. live object를 semantic validation에서 읽고 sealing 단계에서 다시 읽으면, 저수준 concurrent mutation이 이미 검증이 끝난 뒤 바뀐 exact-built-in 값을 검증 없이 creation evidence로 봉인할 수 있습니다. Orgmetra canary: finalized regression |
1 participant
Scope
Canonical single-writer lane for
docs/product-technical-gap-baseline.md. The baseline records durable product/domain/control-plane truth and causal dependency order; it is not merge authorization and does not freeze volatile PR heads, run IDs, queue snapshots, or review state into the document.Current durable baseline
The baseline at
c0a40a4d598635cc1056a29451a4707d00c613c5remains code-current at the durable-contract level after workflow owner #161 integrated as protecteddevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f. It already records #63 shared HRIS-kernel ownership, #64-before-#65 owner order, protected-owner adoption before consumer evidence, Assignment dependency order, ruleset controls, and the release gate.#211–#214 refine the shared trust boundary. #215–#228 refine durable People/hire scalar/container and command/result boundaries. #229 requires ordinary generic People results and confirmed-hire results to remain bound to authoritative pre-port target identities. #246 records the necessary idempotent-replay qualification for generic Employment/Position/Assignment: their published semantic digest deliberately excludes generated record IDs, so an identical same-key retry may return the first committed identity instead of the retry's fresh generated identity only when the persistence result carries exact replay evidence and the application independently recomputes the same semantic command digest. Unexplained foreign results remain fail-closed; confirmed-hire remains exact-identity-bound because its materialization identities are part of that route's command contract. #230 detaches direct PostgreSQL commands; #231 completes application-input ownership before purpose-bound authorization; #232 requires exact built-in Assignment allocation text. #233 closes a public-contract inconsistency by making the parser and published OpenAPI reject zero while retaining the authoritative Assignment allocation domain
(0, 1.0000]; deterministic manifest evidence is resealed. These are refinements of the existing durable application/API trust-boundary and idempotency invariants, not new HR aggregates, so leaf SHAs and run IDs remain PR/Issue metadata rather than baseline-body data.A distinct durable buyer/scientific gap remains #234: protected architecture assigns validity-study registry/scientific evidence ownership to
workforce_validation, while protected implementation still lacks the complete owner API and durable owner-table adoption. Draft #235 establishes the independent owner application read boundary from protecteddevelop; #236 makes retained persisted study evidence structurally immutable; #237 applies the same structural-immutability requirement to authenticated principal evidence before purpose-bound authorization. #238 corrects the PostgreSQL role-isolation model: a NOLOGIN schema owner cannot rely onALTER ROLE ... SET search_pathfor laterSET ROLEruntime isolation, because PostgreSQL applies role defaults at login. #239 adds the complementary constructor-bypass invariant for identity evidence: exact tuple-backed principal type alone is insufficient because low-leveltuple.__new__can bypassValidationPrincipal.__new__; the owner read boundary must reconstruct/revalidate stored tenant/actor/scope evidence before Keyverse request construction/evaluation. #240 adds the repository-capability invariant exposed by the earlier review graph: runtime Protocol shape alone is not proof of a callable repository dependency, and dependency checking itself must not execute a caller-controlled descriptor before authorization. #241 extends retained-evidence hardening to the data projection by makingValidityStudyViewstructurally immutable. #242 narrows the ordinary public constructor surface, but does not treat constructor exclusivity or the Python runtime type as proof that authorization occurred; low-level tuple fabrication remains possible and consequential consumers must re-authorize and re-resolve authoritative state. #243 adds the nested-identity invariant: an immutable outer value object is still unsafe if it retains a mutable UUID object alias. Canonical identity authority must be reduced to interpreter-immutable scalar evidence, public UUIDs reconstructed fresh, and executable repository calls must receive detached UUID objects while post-port target verification remains bound to an immutable pre-port snapshot. #244 adds the ingress-scalar invariant: exact UUID outer type is still insufficient if its internalintslot was forged; the boundary must read the payload once, prove exact built-inintbefore any sentinel/range/equality behavior, and only then store the validated scalar. #245 completes the ordinary issuance-surface cleanup by removing an unconditional module-level projection issuer. #249 closes the remaining checked-versus-used capability gap: inertly validating a repository member before authorization is insufficient if the authorized path later performs a fresh dynamic attribute lookup. The exact ordinary repository function accepted before authorization must be the same function directly invoked afterward; caller-controlled__getattribute__or descriptor machinery cannot be allowed to substitute a new executable capability after the access decision. #253 completes the concrete-dependency side of that rule: an inherited Protocol/interface declaration is still a runtime function and can satisfy a function-type gate even though no repository implementation exists, so the canonical interface placeholder itself must be rejected before authorization rather than treated as a concrete executable dependency.#254 adds the Foundation provenance invariant exposed by a real hosted RED: executing a root PostgreSQL acceptance contract from the canonical Foundation workflow is not enough. Every such executable contract must also be registered in both canonical required-file inventories—Node
REQUIRED_FILESand PythonREQUIRED—and appear in the deterministicmanifest.jsonexact path/hash/bytes/lines seal. A missing inventory entry or stale seal is a real acceptance failure; the repair is to register and reseal the exact artifact, not exempt discovery, remove execution, weaken the manifest path-set equality check, or lower coverage/security gates. #255 adds the complementary exact retained-policy-scalar coverage invariant: an immutablefrozensetis not sufficient if one contained field is a caller-defined executablestrsubtype. The Workforce Validation boundary must reject non-exact policy-field strings before authorization comparison/hashing/persistence, and 100% coverage must execute that fail-closed branch rather than delete or weaken it. Volatile commit/run identifiers remain in #235/#254/#255 metadata rather than the baseline body.#235 keeps
workforce_validation_roleas deny-default migration/schema-owner authority only, proves actualSET ROLEbehavior in PostgreSQL acceptance, revalidates principal storage before authorization, binds the exact validated owner repository function across authorization, rejects the inherited Protocol declaration as a non-concrete capability, stores UUID authority without retained mutable aliases, validates UUID internal payloads before executable comparison, exposes no ordinary unconditional view issuer, and explicitly treats the returnedValidityStudyViewas data rather than reusable authority. A distinct least-privilege runtime role plus schema-qualified relations/function-level search-path controls remain part of the durable adapter increment. The service test lane and owner-schema PostgreSQL contract are admitted to canonical Foundation without weakening hash/coverage controls, and #254 requires the executable contract to be represented in both provenance inventories plus the exact manifest seal. Current #235 exact head isdd95dd7256f37aab2c4f26aa1fb43e8c867f4e4d: Foundation and SAST are terminal GREEN, including owned coverage and isolated PostgreSQL acceptance. Security remains terminal non-passing only at the central Dependency Review availability probe tracked by.github#810; CodeQL remains terminal non-passing only after current-head dispatch succeeds and the central verdict handoff fails, tracked by.github#1927/#1929. These foreign control-plane failures are not leaf source defects and do not authorize no-op churn, synthetic verdicts, gate weakening, or mutable-source adoption. A qualifying independent approval is still absent.Dependency-first Draft #248 / Issue #247 contains the next forward-only owner-table adoption, least-privilege runtime role and schema-qualified PostgreSQL read adapter. #250 adds the durable dependency-ownership invariant that a validated connection factory must be structurally bound against retained-reference replacement. #251 adds the migration-integrity invariant exposed by the owner-schema move: preserving a table OID, FKs, RLS and triggers is insufficient when an existing trigger/function body embeds a schema-qualified reference to the old relation. A forward owner migration must repair that dependent executable SQL in place while preserving function signature/trigger attachment and governance semantics; it must not paper over the defect with a compatibility copy/view or rewrite protected global migration history. #252 completes the adapter-side checked-versus-used rule: storing an executable connection capability immutably is insufficient if the read path later resolves a subclass-overridable property; execution must consume the exact structurally stored capability rather than perform a fresh dynamic lookup. #248 remains exact
d54d44d795444df572efbb301a667d74ac574d58on stale mutable-parent snapshot656a0c41c06bc517b2cf7c554e35a6fb4f8c4f4b; it must not absorb mutable #235 source merely to restore mechanical mergeability. #235 integrates normally first; then #248 non-force adopts protected owner truth—including #249/#253/#254/#255—and reacquires exact-head coverage, PostgreSQL, security and review evidence before integration.The durable follow-on after #248 integration is idempotent registration → explicit predictor/sample/decision-policy/analysis-protocol model → versioned scientific adapters/API/performance evidence. This independent lane does not change the People/Assignment owner order and must not copy mutable #63/#64/#65 source.
#63 exact Foundation CI is terminal success after its predecessor real RED (218 tests passed, 99.43% coverage) and three-branch test repair; SAST and Security are also terminal success. CodeQL remains failed in the central exact-head handoff state and qualifying approval is still absent, so normal integration remains blocked without an Orgmetra no-op retrigger or gate bypass. #64 owns #229–#233 plus #246's replay-result reconciliation; its current exact head is
4be7f1681959e43d32c8e85a8f2660da36ff6d9c. Foundation, Security and SAST are terminal GREEN on that head; People API is 239/239 with 1472 statements / 482 branches at 100.00% statement/branch coverage and isolated PostgreSQL acceptance. CodeQL remains terminal FAILURE only at the same shared current-head verdict handoff after both compatibility jobs successfully request dispatch; no qualifying independent approval exists. #65 ownsvalidate_authorization_decision(...)and purpose-bound durable-consumer validation. They overlap on People files, so #65 must non-force adopt protected #64 after normal #64 integration and preserve both invariant sets.A further owner relationship is explicit: #141 contains a valid employing-legal-Organization HRIS feature but is Draft/non-mergeable on an old base and overlaps #64/#65 on People, authorization, and OpenAPI files. It must follow #65, non-force adopting protected owner truth while preserving its legal-employer feature. Assignment #163/#165 remain downstream consumers and must not adopt mutable sibling source.
Canonical People/Assignment durable order is #63 → #64 → #65 → #141 → #163 → #165, each through normal protected integration and non-force protected adoption where required. The independent
workforce_validationorder is #235 → #248 → later scientific/API increments, with mutable-parent source never treated as protected dependency evidence.Writer branch repair finding
PR #100 remains Draft and non-mergeable because its long-lived branch is based on predecessor protected
develop@ef1b143368cb6249c9520ca8cae10ebe844a5aa1. This is a repair finding, not a close condition. Its valid baseline delta is preserved; no force-push/destructive rebase is allowed. Safe non-force adoption of current protected truth must preserve valid doctoring while resolving real conflicts and reacquiring exact-head checks/review.No self-approval, routine administrator bypass, gate weakening, predecessor-evidence substitution, mutable-owner source copy, or release claim is authorized by this PR.