Add receipt-bound Feishu approval tools - #950
Draft
Y1fe1Zh0u wants to merge 2 commits into
Draft
Conversation
Add typed Feishu approval definition, attachment upload, and create tools while binding provider submission to the exact tenant, Run, Tool Ledger receipt, applicant, and in-chat confirmation. Constraint: Approval creation must not depend on a new frontend or legacy ApprovalRequest flow Constraint: Existing user worktree changes remain outside this commit Rejected: Bare yes/no confirmation | stale replies could authorize another request Rejected: Raw approver and CC open IDs | bypasses tenant roster authorization Rejected: Reusable bearer proof | could replay an identical provider write Confidence: high Scope-risk: moderate Reversibility: clean Directive: Do not expose feishu_approval_create outside the receipt-bound Durable Runtime conversation gate Tested: 335 relevant backend tests; scoped Ruff; compileall; diff check; independent code review and verification Not-tested: Live Feishu Provider create and 3010 deployment
Preserve a bounded, sanitized Provider receipt in the Tool outcome and surface HTTP status, business code, message, and response body to the model. Approval reads and writes retain their existing retry classification, while attachment inputs are rejected before confirmation unless they contain stable file-code strings. Constraint: External approval writes must never be replayed after an ambiguous Provider outcome Constraint: Provider response metadata must pass through the Tool Ledger sanitizer before model visibility Rejected: Return only a generic rejection string | leaves the model unable to repair invalid form controls or permissions Rejected: Accept attachment objects in form_data | confirmation would bind an unstable provider payload shape Confidence: high Scope-risk: moderate Directive: Preserve provider receipt bounds and redaction whenever adding new Feishu failure fields Tested: 804 Runtime and Tool tests; 201 approval-focused tests; fatal Ruff; Architecture Guard P0; diff check Not-tested: Live Feishu Provider create and deployed 3010 approval flow
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Why
Approval creation is an external write. A generic confirmation or generic Provider error can either authorize the wrong request or cause the model to retry an ambiguous write. The Runtime needs a single-use proof tied to the exact Tool call, and the model needs sanitized Provider facts to repair deterministic validation failures without replaying uncertain writes.
Safety and behavior
unknownoutcomes that require reconciliation.form_datastays redacted from observability.Validation
Remaining validation
CI baseline dependency
This branch is intentionally based directly on
main. Currentmainstill contains the independentf061_enterprise_info_tenant_idfresh-database duplicate-column defect. PR #945 fixes that migration and passed the same fresh PostgreSQL lane in Drone #489. If this PR's Drone run stops on that known migration failure, refresh this branch after #945 reachesmain; do not mix the migration repair into this approval PR.