feat: bind sensitive disclosure to exact task scope

[seonghobae]

Buyer-visible gap

Begin issue #10 with a bounded purpose-bound authority kernel that prevents ambient sensitive-data disclosure. The slice binds disclosure and opaque-handle admission to one exact classified authority: tenant, task, field, business purpose, canonical destination origin, and data classification. The policy API never carries protected values.

TDD evidence

The durable first disclosure contract is crates/originweave-policy/tests/sensitive_data_policy.rs. Exact-head CI run 31287629785 on RED head 5ffe5f3ea213cbf921dd22ad8c61f9a254577c17 reached cargo check --locked --workspace --all-targets and failed at the intended production API boundary with unresolved imports for the disclosure and handle-use contracts.

CodeRabbit then exposed two valid security boundaries, each corrected from current evidence:

• raw destination strings could diverge from OriginWeave's canonical browser-origin interpretation, so tests first required originweave_core::Origin and realistic credentials/path/port/Unicode/control/numeric-host cases before production constructors changed;
• a pure use-count comparison could be mistaken for stateful authorization, so test-first head ecdd2caf41a6d766c407444c89784e8c2db01fdb required the public name evaluate_handle_use; CI run 31289910081, Rust job 93185229947, failed at the intended unresolved production API boundary before implementation and documentation separated pure admission from later atomic broker enforcement.

A later review of the shipped opaque-handle scope found a separate reclassification defect: the handle retained tenant/task/field/purpose/destination but not DataClassification, so an old handle could survive a field's move from ordinary personal data to sensitive personal, credential, or payment data. Test-only head bdda17ebda36c40a01650216e00869ac16d56ec2 added a focused regression; CI run 31302701008, Rust job 93217937595, failed at the intended constructor boundary because handle scope and use requests had no classification input. Production then bound handle authority to classification.

Adding one more primitive parameter exposed an API-design defect under strict Clippy: CI on 200efba0d1d49fcfa6d4c1ee029ebfa7265e8c64 passed tests but rejected the primitive-heavy public constructors. The root-cause fix is the public SensitiveDataAuthority value object, which atomically represents tenant, task, field, purpose, canonical destination, and classification. Disclosure requests/scopes and handle scopes/use requests now consume that exact value rather than independently reconstructing authority.

Scope and architecture

• exact disclosure outcomes: deny, opaque handle only, derived value only, partial disclosure, full disclosure, human approval required, or dual control required;
• fail-closed denial when any classified authority dimension differs or an identifier is missing/malformed;
• canonical destination authority through originweave_core::Origin, not caller-supplied raw URL text;
• classification-bound opaque handles, so reclassification requires newly authorized handle authority;
• pure opaque-handle admission evaluation against exact authority, exclusive expiry, and maximum use count without pretending to mutate authoritative state;
• approval-required outcomes are control states, not execution permission: approval evidence must be obtained and the same exact classified authority re-evaluated before disclosure;
• ADR/architecture/README/doctoring define the later trusted broker boundary: trusted time, caller-unforgeable state, atomic use reservation/increment before value resolution, concurrent/replay protection, expiry/revocation recheck, and explicit compensation semantics after a reserved use;
• no database, encryption implementation, network access, model call, raw value storage, broker resolution, persistence, or certification claim in this slice.

The first attempt to register a separate workspace crate was rejected by the locked-workspace contract because it required an unauthorized lockfile mutation; those tree changes were reverted. This PR therefore implements the reusable policy foundation inside originweave-policy. Issue #10 remains open for the separately versioned originweave-sensitive-data crate and provider-neutral service/storage/broker/evidence/lifecycle contracts.

Exact-head verification

On unchanged head a5cdad6fcf550e250d1502ca77524d49ef344d7e:

• CI 31303777506 completed successfully, including repository contracts, formatting, locked workspace checks, all Rust tests, strict Clippy, rustdoc, and exact production coverage enforcement;
• Security Scan 31303777521 completed successfully;
• SAST Semgrep 31303777551 completed successfully;
• CodeRabbit exact-head commit status is successful;
• all returned review threads are resolved.

Ready for qualifying independent review. Merge remains subject to an exact-current-head non-author formal APPROVED review and a final unchanged-head gate and writer-lease revalidation.

Partial implementation of #10.

Summary by CodeRabbit

• 새로운 기능

  • 민감 데이터 공개를 목적·테넌트·작업·필드·대상·분류에 기반해 세밀하게 제어합니다.
  • 보호 값 대신 불투명 핸들을 사용하며, 만료 및 최대 사용 횟수를 검증합니다.
  • 권한 범위가 불완전하거나 일치하지 않으면 공개와 핸들 사용을 거부합니다.

• 문서

  • 민감 데이터 권한 정책, 보안 원칙, 아키텍처 및 로드맵을 업데이트했습니다.
  • 관련 의사결정 기록과 검증 기준을 추가했습니다.

• 테스트

  • 권한 불일치, 만료, 사용 한도 초과 및 정상 승인 시나리오를 검증합니다.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 35 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1f7d549a-2095-492b-802b-ab7cde399f1b

📥 Commits

Reviewing files that changed from the base of the PR and between ecdd2ca and 901265b.

📒 Files selected for processing (8)

• ARCHITECTURE.md
• CHANGELOG.md
• crates/originweave-policy/src/lib.rs
• crates/originweave-policy/src/sensitive_data.rs
• crates/originweave-policy/tests/handle_classification.rs
• crates/originweave-policy/tests/sensitive_data_policy.rs
• docs/adr/0007-purpose-bound-sensitive-data-authority.md
• docs/doctoring.md

📝 Walkthrough

Walkthrough

민감 데이터 공개 권한 커널을 추가했다. 권한 범위와 데이터 분류를 정확히 검증한다. 불투명 핸들의 대상, 만료 시각, 사용 횟수를 검증한다. 아키텍처, ADR, README, CHANGELOG, 로드맵을 새 정책에 맞게 갱신했다.

Changes

민감 데이터 권한 커널

Layer / File(s)	Summary
정책 커널과 공개 API crates/originweave-policy/src/sensitive_data.rs, crates/originweave-policy/src/lib.rs	민감 데이터 분류, 공개 결정, 권한 범위, 불투명 핸들 범위와 사용 요청을 추가했다. 범위와 분류가 정확히 일치할 때만 공개를 허가한다. 핸들은 대상, 만료 시각, 사용 횟수를 검증한다.
정책 검증 테스트 crates/originweave-policy/tests/sensitive_data_policy.rs	테넌트, 작업, 필드, 목적, 대상, 분류의 불일치와 누락을 검증한다. 핸들의 대상 불일치, 만료, 사용 한도 초과 및 정상 승인을 검증한다.
아키텍처와 결정 기록 ARCHITECTURE.md, docs/adr/0007-purpose-bound-sensitive-data-authority.md, docs/doctoring.md, docs/README.md	민감 데이터 authority를 네트워크·세션 권한과 분리했다. 보호 값의 모델 컨텍스트, 로그, 추적 및 provenance 유입을 금지했다. ADR 0007과 관련 문서 색인을 추가했다.
프로젝트 설명과 로드맵 README.md, CHANGELOG.md, docs/product-roadmap.md	새 정책 계약, 보안 조건, Chromium 범위, 브로커·서비스·저장소·보존·철회 관련 후속 작업을 문서화했다.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related issues

• [Enterprise Gap] Preserve operational PII through policy-bound disclosure instead of blanket masking #10 — 목적 기반 민감 데이터 authority, 필드 범위 공개 결정, 불투명 핸들 검증을 직접 다룬다.

Possibly related PRs

• ContextualWisdomLab/OriginWeave#3 — 공개 범위의 대상 권한이 destination 및 Origin 정규화와 연결된다.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 55.56% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 민감 데이터 공개를 정확한 작업 범위에 연결하는 핵심 변경을 간결하게 설명합니다.

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/purpose-bound-sensitive-data

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

@coderabbitai review

[seonghobae]

Superseded by #33 after protected main advanced through the governance, network, resource, evidence, hourly-workflow, and browser-session merges. #33 was rebuilt from the exact current main lineage rather than destructively rebasing this 61-commit branch. It preserves the policy-kernel implementation and both focused regression files (including byte-identical sensitive_data.rs, handle_classification.rs, and canonical sensitive-data regression content), ADR 0007, current-main-aware CHANGELOG/doctoring, and explicitly carries this PR's original RED→GREEN TDD lineage without transferring old checks or reviews. Product-wide sensitive-data architecture/status reconciliation is also being maintained on canonical documentation PR #25. This branch remains available as historical TDD/review evidence; issue #10 remains open for the trusted broker/storage/lifecycle work.