fix(policy): prioritize trusted PostHog command risk - #146
Conversation
|
Caution Review failedAn error occurred during the review process. Please try again later. 📝 WalkthroughWalkthrough
ChangesRisk classification
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
9c976a2 to
e8d8557
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
The Windows Node 24 failure is not in this policy change: the completed log shows the pre-existing cold-provider marker test timing out. It is tracked in #148 and addressed by the already-open #147 / #144 readiness-barrier PR. I will rebase and revalidate this PR after that fix is integrated; no timeout increase or unrelated change will be made here. |
e8d8557 to
debe435
Compare
|
@coderabbitai full review |
Fixes #142
Why
A trusted static
readOnlyHintwas evaluated before Miftah's origin-pinned PostHog command adapter. A destructive PostHog command could therefore be classified as read.Change
Evaluate the internal PostHog command metadata before trusted upstream annotations, while keeping local overrides highest priority.
TDD evidence
readOnlyHint: trueandcall dashboard-delete {}.read/trusted-upstream-annotation.destructive/trusted-command-adapter.Validation
npm test -- tests/risk-classifier.test.tsnpm test -- tests/mcp-wrapper.test.tsnpm run lintnpm run typecheckSummary by CodeRabbit
Bug Fixes
Tests