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. |
|
SOURCE WRITER CLAIM — 2026-09-12. Fresh live metadata shows canonical baseline head |
|
SOURCE WRITER RELEASE — exact head |
|
Canonical-baseline handoff from Durable operability invariant exposed by #309/#312: an idempotency acceptance is incomplete if it proves only sequential same-key replay after a known successful first call. For commands whose caller may lose the result after the database has committed, acceptance must create a durable first result and then make the original caller path fail/lose the usable result before a fresh connection retries. The retry must recover the exact first authoritative identity, semantic/receipt evidence, and database-owned time without duplicate business/audit/outbox state. Where the acceptance uses PostgreSQL backend termination, it must prove commit externally (for example, another session can see the receipt) before terminating the original backend; elapsed time alone is not commit evidence. The executable #312 implementation is currently |
|
Durable baseline handoff from #312: destructive acceptance actions must bind checked identity through use, not only at observation time. For PostgreSQL backend termination/cleanup, a captured numeric PID is insufficient because the intended backend can disappear and the PID can later identify another session. The recovery fixture now uses an execution-unique UUID-derived application marker, captures |
|
2026-09-12 exact-head terminal RCA checkpoint — product source remains unchanged at
No predecessor GREEN transfers. #100 remains Draft: unresolved threads are 0 and mergeable=true, but exact Security/CodeQL and qualifying independent review are absent. |
|
Durable baseline handoff from |
|
Durable provenance invariant handoff from current #312 repair: when a stacked owner ordinary-forward adopts a parent provenance seal, every file newly added to either canonical Foundation required-file inventory and every tracked file changed by the child must be re-closed under |
|
Durable baseline handoff from the |
|
Canonical baseline handoff from #312; no competing edit to |
|
Durable-invariant handoff from the A persisted owner relation introduced by migration is not code-current merely because its SQL exists. The same durable truth must be represented in the bounded-context Data Model/ERD and in executable migration-backed provenance inventory, and repository validation must distinguish executable DDL from DDL-shaped text in comments/string/dollar-quoted literals. For idempotency receipts specifically, canonical docs must also preserve PII minimization and the lifecycle boundary: a creation/retry receipt is not return/destruction completion evidence. The #313 repair also exposed a cardinality rule worth retaining: documentation must describe constraints over the full persisted dataset, not only the new write port. Migration 0024 creates exactly one receipt for first commits through Current implementation authority is #312 |
|
Durable baseline handoff from stacked canonical packet owner #307: an eligible candidate-document return request must retain the versioned policy's |
|
#302/#314에서 baseline-worthy People invariants를 확인했습니다. Canonical baseline writer에서 다음 durable rule을 reconciliation 대상으로 검토해 주세요.
Fresh live metadata finding도 함께 넘깁니다. #100 body의 People section은 아직 |
|
Durable baseline handoff from the new Employment-separation owner slice (#314/#64): PostgreSQL acceptance that creates temporary roles/users/schemas must use collision-resistant per-execution identities whenever failure cleanup is necessarily best-effort. Failure cleanup must not mask the causal assertion/runtime error; conversely, a nominal success path must verify cleanup and fail closed if the temporary authority remains. PID/BASHPID or one fixed role name is not sufficient when runners/containers can share a persistent database. The current People owner also exposes a stale volatile receipt in #64’s PR body: live #64 is now |
|
Baseline single-writer handoff from current People owner work: the PR description's #64 exact head Durable invariant worth folding into People #64 demonstrates the repair at RED |
|
Fresh baseline-writer handoff: this PR's body is stale for canonical People owner #64. It still names Durable invariants that should be reflected by the #100 single writer, without copying volatile run IDs into
Current #64 exact-head Foundation is hosted GREEN including repository PostgreSQL contracts, but merge remains unauthorized because required Security/CodeQL/Strix/independent-approval evidence is non-passing or absent. Please currentize the #100 PR authority text through its existing single-writer lane; this handoff does not edit the baseline from #64. |
|
Durable baseline handoff from canonical People #64 at Also retain #314's unresolved concurrency qualification: same-key advisory-lock replay evidence is not proof of the Employment aggregate conflict boundary. Distinct idempotency keys against the same expected Employment version require a real two-session DB blocker/loser acceptance before the separation transition can be treated as requirement-5 complete. |
|
Baseline owner handoff from current People writer #64: the prior Current #64 exact head is Durable invariant for Evidence status must stay precise: implemented on active #64, but awaiting canonical Foundation #311 registration and exact-head PostgreSQL execution; protected |
|
Durable baseline handoff from current People/Employment separation owner (#64), without competing edit to A concurrency acceptance is incomplete if it proves only the normal winner/replay or winner/stale-loser path. For a transactional HR mutation that starts client and server sessions, the failure path must also prove quiescence before test/database teardown and rollback of all durable side effects. The executable form now added on #64 establishes a real blocker, terminates the blocked loser before the pre-commit winner, waits both clients, requires both named PostgreSQL backends to disappear from This should generalize as a Foundation/PostgreSQL contract invariant: process cleanup is not merely Current #64 exact head after this increment is |
|
Baseline single-writer handoff from current People work; no competing Durable invariant to absorb when #100 next writes: ordinary same-key replay is not sufficient evidence for a retry-safe high-impact mutation. Where the caller can lose trust in the outcome after the database commits, acceptance must prove an uncertain-commit path: independent database state qualifies the first commit; the original caller subsequently fails; a fresh connection with the same semantic command/idempotency key recovers the exact first committed identity and database-owned recorded time; and retry-only audit/outbox identities leave no durable rows. This complements, rather than replaces, the existing failure-cleanup invariant that pre-commit aborts must leave zero durable side effects and quiesce server sessions. People exact evidence is #64 |
|
Baseline single-writer handoff from People #64 current head Durable invariant to absorb when #100 next currentizes the baseline: a governed Employment separation and Assignment creation that can establish contradictory People truth must share the same aggregate conflict boundary. Under PostgreSQL READ COMMITTED, putting Capability corollary: do not broaden the ordinary Assignment runtime with Employment UPDATE merely to obtain |
|
Durable People-domain invariant for the baseline writer from fresh #64 review:
Canonical contract split should remain explicit: confirmed recruiting hire/rehire materialization may atomically create/bind new Employment + governed conversion from the sealed selection decision; direct People-admin Employment/rehire must use its own purpose-bound human-confirmed evidence and must not fabricate/reuse candidate conversion. Assignment/Employment truth remains People-owned; recruiting provenance remains a referenced fact, never a substitute for target-aggregate authorization. Also currentize the volatile #64 receipt only in PR metadata, not durable baseline prose: #64 moved beyond the stale |
|
Durable baseline handoff from current #64 People owner: generic Employment creation must not use |
|
Fresh #64 owner handoff for the baseline single-writer lane:
Current #64 exact head is |
|
Baseline-owner handoff from the People lane: high-impact HR reason codes must be a closed canonical People vocabulary and remain identical across public API schema, application command validation, database function/table constraints, audit/event semantics, and evidence/review packets. A lower_snake_case syntax check alone is not governance. Current #64 candidate closes Employment separation to exactly |
|
Baseline single-writer handoff: #64 now carries the Employment-separation docs-to-code reconciliation through exact head
Please also currentize any stale #64 exact-head references in |
|
Final baseline-writer handoff from the #64 People owner line is now Durable baseline facts to carry when #100 safely advances:
Please currentize any stale #64 exact-head references in |
|
Single-writer handoff for |
|
Durable baseline handoff from #316/#317: commercial performance evidence must bind both the benchmark runner's effective option surface and the approved load model. k6 CLI options have higher precedence than script/config options, so a canonical runner must not pass opaque caller CLI arguments. Likewise RPS/duration/preallocated-VU/max-VU cannot remain caller-supplied environment values if post-run acceptance merely checks result/runtime agreement; otherwise a weaker load can be internally consistent and still false-GREEN. #317 exact |
1 participant
Current execution receipt — 2026-09-12
1da55ee20e640a6dab1b5afbba52ce842482adf9; protected base:develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f; mergeable, Draft, unresolved threads 0.34682956904and SAST34682956911: SUCCESS.34682956901: terminal FAILURE only because authenticated Dependency Graph compare returned HTTP 403 in dependency-review job103524934799; OSV, Trivy and Scorecard succeeded.34682956915: terminal FAILURE after actions/python compatibility jobs reportedVERDICT_STATE=pending; exact dispatch job103525312078succeeded. Central settlement remains owned byContextualWisdomLab/.github#2040.ContextualWisdomLab/.github#1725@59063ff7be935849671600d539a57fd1219bd4ae, but non-200 remains fail-closed and a live HTTP 200 consumer canary is required.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 at exact head
1da55ee20e640a6dab1b5afbba52ce842482adf9on protecteddevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f. Fresh comparison is ahead 215 / behind 0 and GitHub reports it mergeable. The branch preserves the canonical baseline plus the latest acceptance-infrastructure invariants; its newly materialized exact-head checks and independent review must be evaluated without transferring predecessor evidence. This is a normal integration boundary, not authority for force-push, destructive rebase, synthetic status or routine bypass.No self-approval, routine administrator bypass, gate weakening, predecessor-evidence substitution, mutable-owner source copy, or release claim is authorized by this PR.