Re-annotate plugin-approvals + plugin-reports onto the full `ExecutionContext` and delete the now-redundant casts (services half of #7070)

[os-zhuang]

Services-lane half of the #7070 split (promotion executed by the triage seat per the split plan recorded on that card, 2026-08-09). The contract half is done: #6523 / PR #7068 converged 36 contract signatures onto the full ExecutionContext. This card widens the implementation-side annotations in the services lane so the casts the narrow type forced become deletable.

File face (verified on origin/main @ 445a0c2)

file	SharingExecutionContext refs
packages/plugins/plugin-approvals/src/approval-service.ts	27
packages/plugins/plugin-reports/src/report-service.ts	14
packages/plugins/plugin-approvals/src/approval-node.ts	2

Casts that become deletable, all re-verified live:

• approval-service.ts:661 — const posture = (context as any).posture; feeding isOverrideActor(); the doc comment above it already names the derived posture (ADR-0095) as the intended read, and the contract now declares the field. This is the load-bearing one: an unchecked cast on an enforcement input.
• approval-service.ts:2773, 2813, 3259 — SYSTEM_CTX as unknown as SharingExecutionContext
• approval-node.ts:174 — } as unknown as SharingExecutionContext);

Scope boundary (both inherited from #7070)

• ⛔ (context as any).organizationId (approval-service.ts:1465, :3649, :3916) is a separate question — organizationId is not on ExecutionContext at all; per [#5852 契约半边] HierarchyScopeContext 未声明 organizationId / tenantId 哪个权威 —— producer 只填一个、consumer 只读另一个,两边都「符合契约」 #5858 / check:org-identifier that spelling has its own history. Do not fold it in.
• The removal of the exported SharingExecutionContext type itself rides whichever of the two split halves lands second — do not remove it here if the identity half (sibling card) is still open.

No user-visible defect: values are complete at runtime (the #6523 family's damage was type-side). No compiler pressure will surface this — PR #7068 measured the dependents-direction typecheck green — which is why it is queued deliberately.

Part of #7070 (progress view). Sibling: identity half. Refs: #6523, PR #7068, #6206 (ruling), #6430 / PR #6511.

[os-zhuang]

Cross-reference from the sibling half — NOT a claim on this card. This seat is working #7136 (identity lane) only; #7135 is unclaimed and untouched, and nothing here changes its assignee, labels or state.

Posting because the two cards share one coordination point: removing the exported SharingExecutionContext type rides whichever half lands second.

• The identity half (Re-annotate plugin-sharing + plugin-audit onto the full ExecutionContext and delete the double-casts (identity half of #7070) #7136) is now up as draft PR refactor(plugin-sharing,plugin-audit): annotate enforcement on the full ExecutionContext and delete the double-casts (#7136) #7140 and touches only plugin-sharing + plugin-audit. It leaves the type exported, exactly as this card's body instructs its sibling to.
• So if refactor(plugin-sharing,plugin-audit): annotate enforcement on the full ExecutionContext and delete the double-casts (#7136) #7140 lands first, this card becomes the second-lander and inherits the deletion. At that point the type has no remaining references outside packages/spec — refactor(plugin-sharing,plugin-audit): annotate enforcement on the full ExecutionContext and delete the double-casts (#7136) #7140 takes plugin-sharing and plugin-audit to zero, and this card takes the last three files (approval-service.ts, report-service.ts, approval-node.ts) plus the plugin-sharing/src/index.ts re-export, which is a public-surface removal worth calling out in that PR's changeset.
• If this card lands first instead, the rule is unchanged and refactor(plugin-sharing,plugin-audit): annotate enforcement on the full ExecutionContext and delete the double-casts (#7136) #7140 picks the deletion up; the PR body records that explicitly.

Two things measured while doing the identity half that may save the claimant of this one a lap:

1. A green typecheck is not evidence here. The values were always complete at runtime, so reverting the whole change leaves the suite green — measured on refactor(plugin-sharing,plugin-audit): annotate enforcement on the full ExecutionContext and delete the double-casts (#7136) #7140: 547 tests pass with the fix fully reverted. What does bite is a compile-time pin using TypeScript's excess-property check on a fresh object literal naming envelope-only fields (posture, accessible_org_ids). refactor(plugin-sharing,plugin-audit): annotate enforcement on the full ExecutionContext and delete the double-casts (#7136) #7140 adds one at packages/plugins/plugin-sharing/src/exec-context-annotation.pin.ts and measures it going red on the revert; the same shape transfers directly to approval-service.ts.
2. Check the target package's tsconfig.json before placing that pin. plugin-sharing excludes **/*.test.ts, so a pin written in a test file there is a phantom check that can never fail (AGENTS.md PINS_CHECKED). Hence .pin.ts, which the package's tsc program does read. Whether plugin-approvals / plugin-reports have the same exclusion is worth checking rather than assuming.

Also filed out of #7136, and adjacent to this card's (context as any).organizationId boundary rather than inside it: #7141, on a five-field context projection in plugin-audit that drops onBehalfOf before a sharing probe documented to fail closed on it.

---

Generated by Claude Code