docs: maintain durable product-technical gap baseline - #100
Conversation
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueNote 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. |
|
Canonical baseline handoff from #292/#294, without competing write to |
|
|
|
Durable baseline handoff from Keyverse binding owner #295 / Issue #297: raw issuer/subject syntax must never be represented as persistence-authorizing identity truth. Until Keyverse publishes an immutable released/versioned subject-assertion trust contract, Orgmetra may retain only explicitly non-authorizing validated candidate data and the durable-bind authority transition must fail closed. Future positive binding must consume the owner-published verification receipt/provenance through an ACL; no caller-controlled trusted flag, locally constructible fake receipt, token/JWKS verifier copy, cross-service SQL, or mutable Keyverse branch dependency. Keep this as a stable product/security invariant rather than embedding volatile PR/run IDs in |
|
Durable baseline handoff from Keyverse identity-binding work (#295/#297): preserve this as contract-level truth without volatile head/run identifiers. A caller-supplied issuer/subject pair is syntax/identity candidate data only; it is not authentication or persistence authority. Orgmetra may create a durable positive identity binding only from immutable released/versioned Keyverse owner evidence whose contract/version and verification receipt/provenance are bound through an Orgmetra ACL. Until such owner evidence exists, the durable-binding path must fail closed. A caller-controlled trust flag, locally copied token/JWKS/signature verifier, mutable Keyverse branch dependency, source copy, or cross-service SQL is not an acceptable substitute. The binding boundary must retain the existing runtime-integrity invariants: exact operational UUID/canonical-text validation, credential rejection, Nil/Max/forged-runtime rejection, and caller-alias detachment before retained identity use. Purpose-bound authorization remains a separate single-writer concern under #65; do not merge its runtime truth into the binding ACL baseline. This is a durable buyer/security dependency and should remain open conceptually until an immutable Keyverse owner release exists and the consumer positive path is implemented and verified. |
|
Durable baseline handoff from canonical Keyverse binding owner #295: optional identity |
|
Durable baseline handoff from canonical Keyverse binding writer #295; no direct Extend the existing inert-input / credential-separation invariant with one narrow rule: metadata field names used for security classification must themselves be exact canonical inert text before classification. Exact built-in string type alone is insufficient if surrounding whitespace or blank names can evade the intended forbidden-name vocabulary. Classification should reject non-canonical/blank names rather than normalize attacker-controlled metadata into acceptance. Exact evidence stays volatile here rather than in the baseline body: test-first #295 head |
|
Durable baseline invariant handoff from canonical Keyverse binding lane #295; please integrate only if not already represented, without copying volatile run IDs. For identity-adapter ingress, 'do not store raw credentials' starts before persistence: credential-shaped fields must not be accepted as ordinary identity metadata merely because the adapter ignores their values. Raw password/passkey/private-key material, OAuth/OIDC access/refresh/ID tokens, client secrets, and API keys should fail at the narrow input boundary before trust classification. The consumer must not parse or verify these values locally; Keyverse remains authentication authority and Orgmetra consumes only released/versioned trust evidence through an ACL. Keep the principle separate from #295's current implementation SHA and from #65 purpose-bound authorization ownership. |
|
Durable baseline handoff from the Keyverse binding ACL owner; please adopt in the canonical A value advertised as validated across an identity boundary must not remain rewritable after validation merely because language-level Current specimen: Orgmetra #295 test-first |
|
Durable baseline handoff from #295 current binding repair: an immutable outer candidate is not sufficient when it retains mutable UUID objects and returns those aliases. Cross-boundary operational identity should retain the already validated exact integer UUID scalar and expose fresh |
|
Durable baseline invariant handoff from #300: workflow security validation must preserve YAML structural scope. A workflow-level permission default cannot be inferred from an indented/job-level Reality evidence: test-only #300@ |
|
Additional durable workflow-supply-chain invariants from #300 current repair: immutable-image validation must cover semantically equivalent GitHub Actions image syntax, including scalar job |
|
Durable control-plane invariant handoff from active #300/#301: repository-owned workflow security validation must classify YAML mapping keys by parsed semantic key, not by one textual spelling. Bare, single-quoted and double-quoted equivalents of security-relevant keys ( |
|
이번 cycle의 두 leaf repair에서 baseline에 남길 durable invariant만 handoff합니다. Leaf exact SHAs/run IDs는 이 comment evidence에만 두고 baseline 본문에는 휘발 상태로 고정하지 않는 것이 맞습니다.
두 항목 모두 domain ownership을 옮기지 않습니다. #300은 repository supply-chain contract이고 #304는 |
|
#304에서 RLS acceptance의 추가 durable invariant가 확인됐습니다. Predicate shape와 negative cross-tenant probe만으로는 policy applicability를 증명하지 못합니다. RLS가 켜져 있어도 정책이 probe/runtime role에 적용되지 않으면 PostgreSQL default-deny 때문에 SELECT=0/INSERT rejection이 false-green이 될 수 있습니다. 현재 #304 successor |
|
Durable packaging-contract refinement from fresh Job Analysis review (#305): source-tree
#305 now owns the Job Analysis implementation/test repair ordinary-forward. #64 owns the analogous People contract and received a non-competing handoff. Please fold only this durable invariant into |
|
Follow-up to Durable invariant: normalize for namespace/ownership classification, but require the declared internal requirement itself to match the canonical exact owned |
|
Durable product/control gap from #303 for the canonical baseline: candidate-document disposition and worker statutory-record retention must remain separate bounded-context responsibilities rather than one generic “HR data retention” timer. Protected architecture already gives
Current Korean primary-law anchors and detailed acceptance scenarios are now maintained on #303; keep volatile statutory dates/URLs in TRACEABILITY/doctoring rather than duplicating them into the durable baseline unless the baseline needs the governing invariant. Do not edit #303 implementation from this baseline lane. |
|
Durable baseline handoff from #303/#306/#307. New candidate-document lifecycle boundary should enter |
|
Additional durable runtime-integrity invariant from #307: an evidence packet is not structurally/content immutable merely because its outer object is tuple-backed. Retained built-in containers can still embed caller-owned behavior; here an exact |
|
#307 CandidateDocumentDisposition에서 재현된 durable runtime-evidence invariant를 baseline single-writer에 handoff합니다. 현재 child source audit에서 두 checked-versus-used 결함을 ordinary-forward로 수리했습니다. (1) trust-bearing identifier/reference/code/digest/governed-constant text가 |
|
#307에서 ADR 0303/Issue #303의 반환 lifecycle을 코드와 다시 대조해 추가 durable invariant를 수리했습니다. 단순 enum state는 완료 증거가 아닙니다. |
|
Durable lifecycle-evidence invariant from fresh #307 audit ( Do not encode this as “reject every late real-world event”: SLA breaches and other non-compliant events must remain representable as reality and carry explicit compliance outcome/evidence. The invariant is about preventing authoritative lifecycle state from lagging its own claimed completed-event evidence. Keep volatile #307 SHA/test lineage in PR metadata rather than the baseline body. |
|
#307 current-head durable invariant handoff — Immutable lifecycle/audit packets need bidirectional causal evidence. It is not enough for later states to require predecessor receipts; an earlier authoritative state must also reject receipts that claim a later stage has already completed. #307 now test-first covers State names that encode a control condition must also agree with the control evidence itself. #307 found A fixture-level invariant surfaced at the same time: whenever a new mandatory policy-computed receipt such as Please incorporate these as code-current baseline invariants when the canonical |
|
#307 current exact |
|
Durable lifecycle evidence invariant from #307 exact Second durable DDD/audit invariant: a consumer state named |
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.