feat: M6 — tests + guardrails + cleanup for principal-based auth (#10961)

[noanflaherty]

Summary

Final milestone of the canonical-identity-binding cutover. Migrates all test files from the legacy isTrusted boolean pattern to guardianPrincipalId principal-match authorization, adds a guard test to prevent reintroduction, and cleans up stale comments.

Changes

Test updates (6 files)

• guardian-decision-primitive-canonical.test.ts: Full rewrite — added TEST_PRINCIPAL_ID constant, updated guardianActor()/trustedActor() helpers, added guardianPrincipalId to all createCanonicalGuardianRequest calls for decisionable kinds, updated test descriptions
• guardian-routing-invariants.test.ts: Full rewrite — same principal-match pattern, updated section titles and test descriptions
• guardian-actions-endpoint.test.ts: Updated 2 assertions from expect(actorContext.isTrusted).toBe(true) to expect(actorContext.guardianPrincipalId).toBeDefined()
• trusted-contact-inline-approval-integration.test.ts: Updated guardianActor() helper and all createCanonicalGuardianRequest calls
• tool-grant-request-escalation.test.ts: Updated guardianActor() helper and all 7 createCanonicalGuardianRequest calls
• tool-approval-handler.test.ts: Updated stale test description

Guard test (1 new file)

• no-is-trusted-guard.test.ts: Scans production code for isTrusted references (excluding tests, node_modules, and allowed trust-class variables). Verifies ActorContext interface does not declare isTrusted field.

Comment cleanup (2 production files)

• guardian-request-resolvers.ts: (undefined for desktop/trusted) → (undefined for desktop actors)
• guardian-decision-primitive.ts: there is no trusted bypass → principal identity must always match

Verification

• grep confirms zero isTrusted references in production code (excluding allowed patterns)
• ActorContext interface confirmed clean of isTrusted field

Closes #10961

---

[noanflaherty]

@codex review this PR again — the previous issues have been fixed in commit 2eaada3

[noanflaherty]

@devin review this PR again — the previous issues have been fixed in commit 2eaada3

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 10 additional findings in Devin Review.

[devin-ai-integration]

🔴 Mock guardian binding missing guardianPrincipalId causes end-to-end approval tests to fail with identity_mismatch

The guardianActor() helper was updated to include guardianPrincipalId: 'test-principal-id', but the mock getGuardianBinding return value (lines 81-88) was NOT updated to include guardianPrincipalId. This creates a fatal mismatch in end-to-end tests that go through the handler path.

Root Cause and Impact

When checkPreExecutionGates creates a tool_grant_request via createOrReuseToolGrantRequest (assistant/src/runtime/tool-grant-request-helper.ts:126), it reads binding.guardianPrincipalId ?? undefined from the mock binding. Since the mock binding has no guardianPrincipalId field, the canonical request is created with guardianPrincipalId: null.

Later, when the test calls applyCanonicalGuardianDecision with actorContext: guardianActor() (which has guardianPrincipalId: 'test-principal-id'), the decision primitive at assistant/src/approvals/guardian-decision-primitive.ts:391-401 checks:

if (!request.guardianPrincipalId) {
    return { applied: false, reason: 'identity_mismatch' };
}

Since the request's guardianPrincipalId is null, the approval is rejected. No grant is minted, the inline wait times out, and end-to-end tests like "inline wait: guardian approves during wait -> tool proceeds inline" (line 456) and "pre-existing grant from prior approval is consumed immediately" (line 499) will fail because result.allowed is false instead of true.

Prompt for agents

In assistant/src/__tests__/tool-grant-request-escalation.test.ts, the mock getGuardianBinding at lines 78-91 needs to include guardianPrincipalId in the returned binding object. Update the mock return value at line 81-88 to add guardianPrincipalId: 'test-principal-id' to the binding object, so that requests created through createOrReuseToolGrantRequest will have a guardianPrincipalId that matches the test actor's principal.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Mock guardian binding missing guardianPrincipalId causes end-to-end inline approval tests to fail

The guardianActor() helper was updated to include guardianPrincipalId: 'test-principal-id', but the mockGuardianBinding object set in beforeEach blocks (e.g. lines 256-263) was NOT updated to include guardianPrincipalId. This causes the same mismatch as in tool-grant-request-escalation.test.ts.

Root Cause and Impact

The mockGuardianBinding at line 256-263 is:

mockGuardianBinding = {
    id: 'binding-1',
    assistantId: 'self',
    channel: 'telegram',
    guardianExternalUserId: 'guardian-1',
    guardianDeliveryChatId: 'guardian-chat-1',
    status: 'active',
    // guardianPrincipalId is MISSING
};

When checkPreExecutionGates creates a tool_grant_request via createOrReuseToolGrantRequest (assistant/src/runtime/tool-grant-request-helper.ts:126), it reads binding.guardianPrincipalId ?? undefined, which resolves to undefined → stored as null in the DB.

When the test later calls applyCanonicalGuardianDecision with guardianActor() (which now has guardianPrincipalId: 'test-principal-id'), the decision primitive at assistant/src/approvals/guardian-decision-primitive.ts:391-401 rejects because the request has no guardianPrincipalId. This breaks tests like "trusted contact requests tool, guardian approves mid-wait, tool executes inline" (line 266) and "complete flow" (line 314).

Prompt for agents

In assistant/src/__tests__/trusted-contact-inline-approval-integration.test.ts, the mockGuardianBinding objects set in all beforeEach blocks (e.g. lines 256-263, and similar blocks in other describe sections) need to include guardianPrincipalId: 'test-principal-id'. Without this, requests created through the handler's createOrReuseToolGrantRequest path will have guardianPrincipalId: null, and all end-to-end approval flows will fail with identity_mismatch.

---

Was this helpful? React with 👍 or 👎 to provide feedback.