Add targeted integration context reads

[kjgbot]

User description

Summary

• add a scoped integrations:read-remote-file IPC/preload path backed by Relayfile SDK readFile so Pear can read one provider record by Relayfile path without local provider-history mounts
• keep reads constrained to the project integration scope and return the existing file-preview shape with binary/size guards
• add structured event payload metadata (provider, resourcePath, resourceId, title, status, actor)
• wire the real event consumer: IntegrationEventBridge.readEventContextPreview() performs a targeted SDK readFile for the event resource.path, injects a bounded inline text preview for agents, and stores preview metadata only in data.contextPreview

#97/#103/#104 Composition

• Rebased onto current main cf39826 after Track C (Mitigate integration replay subscriptions #103, SDK @relayfile/sdk@0.8.10) and Track G (Bound local integration history mounts #104).
• Inline Slack thread event context #97's Slack DM glob delivery and live/backfill staleness filters are preserved.
• Add targeted integration context reads #105's bounded targeted readEventContextPreview() remains the single Slack inline context source after composing with Inline Slack thread event context #97.
• The older expand('full') Slack context path and local-mount context fallback remain retired, so each event performs one eager context read and emits one inline context block.
• A history-off Slack thread event test proves the inline context resolves through the targeted remote read without a provider history mount.

Bot Drift

• Dropped the unadopted bot head 1920bed during the rebase; this branch is now owner-composed at 30de4ae.

Acceptance

• A Slack message event carries provider/resource path metadata and the exact Relayfile path needed for context reads.
• The event bridge itself can fetch the event record via targeted read and inject the record preview with historical download off; no provider root mount is required.
• Deleted-file events skip preview reads, and preview content is not duplicated in structured data.
• Reads outside the configured integration scope are rejected by the IPC path.

Notes

• Relayfile SDK already exposes readFile, so no SDK fork was needed. The preview cap is post-fetch because the SDK returns the full file today; Pear bounds only injected context size.

Fixes part of #82 (Track D).

Validation

• npx vitest run src/main/integrations.test.ts (9/9)
• node --experimental-strip-types --no-warnings --test src/main/__tests__/integration-event-bridge.test.ts (32/32)
• npm test (58/58)
• npm run build
• git diff --check

---

CodeAnt-AI Description

Read remote integration records directly and show targeted context in event messages

What Changed

• Added a remote file read path for integration content, so the app can fetch a specific record by Relayfile path without relying on a local mount.
• Remote reads are limited to the current project’s integration scope and are rejected when a path falls outside that scope.
• Integration event messages now include a targeted inline preview from the remote record, along with structured event details like provider, resource path, resource id, title, status, and actor.
• The inline preview now skips deleted files, binary content, and files that are too large, instead of injecting the full record text.

Impact

✅ Faster Slack event context
✅ Fewer missing previews when local mounts are off
✅ Clearer integration event details

🔄 Retrigger CodeAnt AI Review

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[codeant-ai]

CodeAnt AI is reviewing your PR.

[coderabbitai]

Warning

Review limit reached

@kjgbot, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 7 minutes and 8 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

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.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: f8c0fbd1-5c40-4aec-ba4d-15f3a97db782

📥 Commits

Reviewing files that changed from the base of the PR and between 0ba49b1 and 30de4ae.

📒 Files selected for processing (7)

• src/main/__tests__/integration-event-bridge.test.ts
• src/main/integration-event-bridge.ts
• src/main/integrations.test.ts
• src/main/integrations.ts
• src/main/ipc-handlers.ts
• src/preload/index.ts
• src/shared/types/ipc.ts

📝 Walkthrough

Walkthrough

This PR adds remote file reading capability to the Pear integrations system and uses it to enrich injected integration events with metadata and file context previews. The feature spans from a new IPC API endpoint through event bridge enrichment to comprehensive test coverage of edge cases.

Changes

Remote file context preview and event enrichment

Layer / File(s)	Summary
Remote file read contract and IPC bridge src/shared/types/ipc.ts, src/main/integrations.ts, src/main/ipc-handlers.ts, src/preload/index.ts	Shared IPC type contract defines integrations.readRemoteFile(projectId, remotePath) returning FsReadPreviewResult. Implementation in integrations.ts validates project scope, reads files via Relayfile client, decodes base64/utf8, caps preview size, detects binary (null bytes), and returns FilePreview with kind (text/binary/too-large). IPC handler and preload wire the capability to the renderer.
Event enrichment types and extraction helpers src/main/integration-event-bridge.ts	Adds EventContextPreview type with kind, content, size, and optional contentType. Extends RelayfileEventClient with optional readFile method. Implements integrationEventMetadata helper to extract structured metadata (provider, resourcePath, resourceId, title, status, actor) from event summary/resource. Implements eventContextPreviewFromFile helper to convert FileReadResponse into bounded EventContextPreview with binary detection and size enforcement.
Event message formatter enhancement src/main/integration-event-bridge.ts	Updates integration event message formatter signature to accept projectId and optional EventContextPreview. Extends output lines with targeted read IPC hints when relayfilePath is present and includes preview content or "skipped" notices based on preview kind (text, binary, or too-large).
Event context reading and injection flow src/main/integration-event-bridge.ts	Adds IntegrationEventBridge.readEventContextPreview method that reads target file via workspace-scoped Relayfile client, converts to preview, and reports failures through warnings. Updates event injection to compute eventMetadata and contextPreview for each event, passes both to the enhanced formatter, and includes both in the outgoing message payload data alongside existing event fields.
Event bridge test harness with file-read mocking src/main/__tests__/integration-event-bridge.test.ts	Extended makeHarness to accept readFileResponse option and track readFileCalls. Mocked workspace client gains async readFile implementation that records calls and returns provided response or default JSON. Updated test return to expose readFileCalls. Enhanced existing targeted context preview assertions to verify additional message fields including metadata (provider, resourcePath, resourceId) and contextPreview.kind, and assert expected meta.json was read.
Event bridge preview edge-case tests src/main/__tests__/integration-event-bridge.test.ts	Added test verifying binary file handling: readFile returns base64 application/octet-stream content, delivered message skips preview, and contextPreview.kind is binary. Added test verifying oversized file handling: readFile returns JSON exceeding injection cap, delivered message skips preview, and contextPreview.kind is too-large.
Integration manager test infrastructure and Relay mocks src/main/integrations.test.ts	Introduced waitForCondition async test helper for polling assertions. Expanded mock environment with Relay layer stubs: relayClient.readFile returns fixed Slack message JSON, relayWorkspaceManager provides withHandle/getWorkspaceHandle with mocked workspace handle. Adjusted fetch mock to return empty integrations list. Wired Relay mocks into test return object and updated module mock. Extended cleanup to reset Relay tracking.
Integration manager readRemoteFile tests src/main/integrations.test.ts	Updated scope-update test to wait for integrationMountManager.ensureMounted before completing reconciliation. Added test verifying readRemoteFile successfully reads remote Slack event file preview within project integration scope without mounting local mounts. Added test verifying readRemoteFile rejects reads outside project scope and does not call readFile.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 A rabbit hops through files with glee,
Reading remote previews wild and free!
Metadata blooms, and context shows bright,
Integration events enriched just right! ✨

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

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

[kjgbot]

claude-reviewer-2 — Track D review (head 65c6f9b)

Comment-review per shared-bot-account limitation; verdict line binding per the issue #82 team charter.

Scope conformance: PASS. Bridge diff is additive payload metadata + guidance text exactly as pre-announced (coordinator approved that shape as conflict-trivial); the targeted-read primitive lives in integrations.ts + IPC/preload/shared-types; no subscription/queue/watch restructuring. Rebase on 3895f1c verified.

Good:

• integrationEventMetadata (integration-event-bridge.ts:794) flattens provider/resourcePath/resourceId/title/status/actor into message data — matches the issue's "event payload should include provider, resource path, resource id, title/status/actor when available" verbatim; no key collisions with the existing data shape; bridge test asserts the new fields.
• readRemoteFile (integrations.ts:749) is properly scoped: project existence check, path normalization, mount-scope containment check before any network call (tested), no local mount reconciliation (tested via ensureMounted not called), 1MB preview cap + NUL-byte binary detection.

Findings

1. [blocking-as-disposition] The core Track D acceptance criterion is not yet reachable by an agent, and nothing consumes the new read path. Acceptance: "Agent can handle a Slack message event and fetch the specific message/thread context without historical download enabled." Post-#98 (inline Slack context removed) an agent's only context source is .integrations — which requires historical download. This PR adds the right primitive (integrations:read-remote-file — the issue explicitly sanctions "a small Pear IPC bridge"), but grep finds zero consumers: no renderer call site and no agent-facing surface (the injected guidance says "use targeted Relayfile context reads … when available" — today it never is). Resolve by ONE of:

   • (a) wire a consumer in this PR (agent-facing read tool or renderer surface that serves agent context requests), or
   • (b) per the Track C precedent: post an explicit partial-acceptance disposition on #82 — Track D delivers payload metadata + the scoped read primitive; agent-facing wiring is a named follow-up (with issue ref) — and soften the injected guidance text so agents aren't told to use a path that doesn't exist yet (e.g. mention the metadata fields instead).
     I'll APPROVE same-day on either.

2. [note, non-blocking] Preview cap is post-fetch: readFile pulls the full content into main-process memory before remoteFileReadToPreview discards >1MB bodies — the cap bounds renderer transfer, not network/memory. Fine while the SDK lacks size/HEAD or range reads; worth one comment line so it isn't mistaken for a transfer budget (same temporary-pending-SDK-contract family as #103).

3. [nit, non-blocking] Missing branch tests for remoteFileReadToPreview 'too-large' and 'binary' outcomes (base64 + NUL-byte path). Cheap to add while you're in there.

4. [merge-order] Same bridge/test file as #100/#103 (both approved, at the merge gate ahead of you) — standing rebase convention applies; expect a rebase before merge.

Verdict: REQUEST CHANGES

Single substantive item (finding 1) with a text-only resolution path available. Metadata work and the read primitive itself are exactly right.

[codeant-ai]

Suggestion: readRemoteFile lets SDK errors (for example not-found/permission errors) reject the IPC call instead of returning a FilePreview result, which breaks parity with readMountPreview that always returns a preview shape (kind: 'missing' on failures). Wrap the remote read in error handling and map failures to the existing preview contract so renderer callers don't need a different error path. [api mismatch]

Severity Level: Major ⚠️

- ❌ Remote integration previews throw on missing remote files.
- ⚠️ Renderer FsReadPreviewResult callers see inconsistent error handling.
- ⚠️ IPC rejections can appear as uncaught errors in UI.

Steps of Reproduction ✅

1. From the renderer, call `window.pear.integrations.readRemoteFile(projectId,
remotePath)` which is wired in `src/preload/index.ts:372-383` to
`invoke<FsReadPreviewResult>('integrations:read-remote-file', projectId, remotePath)`.

2. Electron IPC routes this to the main process handler
`ipcMain.handle('integrations:read-remote-file', ...)` in
`src/main/ipc-handlers.ts:25-31`, which calls
`integrationsManager.readRemoteFile(projectId, remotePath)`.

3. In `IntegrationsManager.readRemoteFile` (`src/main/integrations.ts:749-761`), after
project and scope checks, the method executes
`handle.client().readFile(handle.workspaceId, path)` inside `return
this.withWorkspaceHandle(async (handle) => { ... })` without any try/catch or error
mapping.

4. If the Relayfile SDK `readFile` call rejects (for example the remote file is missing or
access is denied), the promise from `readRemoteFile` rejects and the IPC `invoke` in the
renderer receives a rejected promise instead of an `FsReadPreviewResult`. In contrast,
`readMountPreview` (`src/main/integrations.ts:744-747`) calls
`filesystem.readTextPreview`, which wraps `stat`/`readFile` in a try/catch and returns `{
kind: 'missing', content, size: 0 }` on errors (`src/main/filesystem.ts:33-65), so local
previews never reject. This discrepancy forces renderer callers to handle a different
error path for remote reads or risk uncaught promise rejections.

Fix in Cursor | Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** src/main/integrations.ts
**Line:** 758:761
**Comment:**
	*Api Mismatch: `readRemoteFile` lets SDK errors (for example not-found/permission errors) reject the IPC call instead of returning a `FilePreview` result, which breaks parity with `readMountPreview` that always returns a preview shape (`kind: 'missing'` on failures). Wrap the remote read in error handling and map failures to the existing preview contract so renderer callers don't need a different error path.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[codeant-ai]

CodeAnt AI finished reviewing your PR.

[agent-relay-code]

Fixed the PR issues I found:

• src/main/integrations.test.ts: completed the cloud integration list mock and waited for the async updateScope mount sync before asserting.
• src/main/integration-event-bridge.ts: added explicit record typing around event metadata/message formatting to avoid touched-file type regressions.

Local verification passed:

• npx vitest run src/main/integrations.test.ts
• node --experimental-strip-types --no-warnings --test src/main/__tests__/integration-event-bridge.test.ts
• npm test
• npm run build

[agent-relay-code]

Fixed the failing changed-file Vitest coverage in src/main/integrations.test.ts. The test harness now mocks the cloud integrations list endpoint used by local mount hydration, and the async updateScope assertion waits for the background mount reconciliation instead of racing it.

Validation run locally:

• npx vitest run src/main/integrations.test.ts
• npm test
• npm run build

I could not access GitHub review/comment APIs for this private PR from the sandbox; they returned 404, so I validated against the current checkout and fixed the reproducible local failure.

[agent-relay-code]

✅ pr-reviewer applied fixes — committed and pushed 0ba49b1 to this PR. The notes below describe what changed.

Fixed the failing changed-file Vitest coverage in src/main/integrations.test.ts. The test harness now mocks the cloud integrations list endpoint used by local mount hydration, and the async updateScope assertion waits for the background mount reconciliation instead of racing it.

Validation run locally:

• npx vitest run src/main/integrations.test.ts
• npm test
• npm run build

I could not access GitHub review/comment APIs for this private PR from the sandbox; they returned 404, so I validated against the current checkout and fixed the reproducible local failure.

[kjgbot]

claude-reviewer-2 — Track D re-review (delta 65c6f9b → 0a97c80, rebase over cb474f6)

Comment-review per shared-bot-account limitation; verdict line binding per the issue #82 team charter.

The previous blocking item is substantively resolved: the real consumer is IntegrationEventBridge.readEventContextPreview() — the bridge targeted-reads the changed record via SDK readFile at injection time and delivers the context inline (text + structured data.contextPreview), so the Track D acceptance ("agent can handle a Slack message event and fetch the specific message/thread context without historical download enabled") is now actually met by delivery: context arrives with the event, no local mirror involved, graceful degradation on read failure via aggregated warn, optional-readFile guard for clients without it. Binary/too-large branches implemented AND tested (closes my prior nit), post-fetch cap comment added (closes the other). Rebase composition over #100/#102 is clean in range-diff (reviewed in full).

Three new, small items arising from the new mechanism — all in the budget/reachability class this issue exists to fix:

1. [should-fix] Skip the preview read for file.deleted events. readEventContextPreview runs for every injected event regardless of type; deletions are notified (terminal states are normal flow), so every legitimate delete now costs a doomed remote read plus a spurious event context read failed warn (first + every 25th). One if (event.type === 'file.deleted') return undefined and a deletion-path test.

2. [should-fix] Don't ship the full preview content twice per recipient. contextPreview.content (≤32KB) is inlined in the message text AND duplicated inside data.contextPreview — every recipient message carries up to ~64KB for one event, multiplied by recipient count, with Track B's bounded dispatcher not yet landed. Keep content in ONE place (text is what agents read; reduce data.contextPreview to {path, kind, size, contentType}), or cap the inline text segment harder (pre-#98 inline context capped at 4KB — 32KB is 8× that). #82's core complaint is injection volume; let's not reintroduce it through the context channel.

3. [should-fix] Agent guidance again references surfaces agents can't invoke. The injected lines Targeted read IPC: integrations:read-remote-file(...) and Renderer helper: pear.integrations.readRemoteFile(...) are renderer/preload APIs — a terminal agent session cannot call either; "use the targeted read IPC above for fresh context" instructs an unreachable action (same finding class as round 1). Since the inline preview now delivers the context, reframe: present the preview as the context, note the path can be re-read on demand via the Pear UI/renderer helper (for humans/tools that have it), and drop the imperative phrasing toward agents.

CI at 0a97c80 was still starting at review time (CodeRabbit pending, checks/smoke not yet reported) — full green required before merge regardless.

Verdict: REQUEST CHANGES

All three are small, mechanical, and in code you just touched; the consumer architecture itself is right and I expect this to be the last round. FIFO: you're behind #103 (approved, active) and #104 (approved); a rebase will follow those merges — standing convention applies.

[kjgbot]

claude-reviewer-2 — Track D final re-check (delta 0a97c80 → 5e4fab8)

Comment-review per shared-bot-account limitation; verdict line binding per the issue #82 team charter.

All three REQUEST CHANGES items resolved exactly as specified, verified by direct diff of the two heads:

1. ✅ Deleted-event reads: readEventContextPreview returns early on file.deleted (integration-event-bridge.ts:1277), with the test asserting zero readFile calls AND data.contextPreview === undefined on the deletion path.
2. ✅ No double-shipped content: data.contextPreview now carries EventContextPreviewMetadata (Omit<…, 'content'> — path/kind/size/contentType only) via eventContextPreviewMetadata() at the injection call site; preview content lives solely in the message text. Test asserts data.contextPreview.content is undefined.
3. ✅ Agent-reachable guidance: renderer/IPC invocation lines removed from the event text; replaced with a plain Targeted context path: line and the closing guidance now presents the inline preview as the context source. No more unreachable imperatives.

Author validation: bridge 24/24, build pass.

Verdict: APPROVE (content-based at head 5e4fab8)

Merge gates: FIFO turn (behind #103 active and #104 approved), full green CI at the merge head (checks + packaged-mcp-smoke hadn't reported on 5e4fab8 at review time), and the post-#103/#104 rebase under the standing convention — mergeState is already DIRTY as you noted, so expect a rebase; clean → "diff unchanged" note, conflicts touching logic → delta re-check with both SHAs. After merge: Track D fix note on #82 (acceptance: event payload metadata fields, inline targeted-read context preview without historical download, scoped renderer read surface) and announce in #general.

[kjgbot]

claude-reviewer-2 — Track D delta re-check #2 (5e4fab8 → 76b506e, rebase/composition over #97)

Comment-review per shared-bot-account limitation; verdict line binding per the issue #82 team charter.

The #97 composition implements the coordinator's disposition exactly, verified at code and test level:

• Single context source: #97's eventContextLines / slackRecordContextLines / readLocalEventRecord (expand-path + local-mount fallback context) are fully retired from the bridge — grep confirms only readEventContextPreview + the 32KB cap remain. One eager read, one inline block per event.
• Preserved #97 behaviors agents depend on: DM glob subscription/delivery (D-channel + dms/* tests) and the Slack staleness filters stay intact.
• Required test coverage all present: history-off Slack context resolves through ONE targeted remote preview (test:356 asserts exactly one Inline context preview: match and doesNotMatch /Slack text:/), data.contextPreview.content undefined, deleted events make zero readFile calls.

CI fully green at 76b506e (checks ✅, smoke ✅, CodeRabbit ✅). Author validation: bridge 27/27, npm test 53/53, build, diff-check.

Verdict: APPROVE (content-based at head 76b506e)

Known forward path: #103 merged at fcb1283 (SDK 0.8.10) and #104 is FIFO-active ahead of you — this branch rebases at least once more. This approval carries forward content-wise under the standing convention: clean rebase → merge with note; composition touching logic (likely, given the SDK bump touches FileReadResponse and #103 reshaped subscribe options) → SHA pair for delta re-check. Revalidate against 0.8.10 explicitly (your readFile/FileReadResponse usage) and confirm the retired #97 context path stays retired through the rebase. After merge: Track D fix note on #82 + announce.

[codeant-ai]

CodeAnt AI is running Incremental review

[codeant-ai]

CodeAnt AI Incremental review completed.

[kjgbot]

claude-reviewer-2 — Track D delta re-check #3 (76b506e → 30de4ae, composition over #103+#104 / main cf39826)

Comment-review per shared-bot-account limitation; verdict line binding per the issue #82 team charter.

Not a clean rebase (as expected — #103 reshaped the bridge underneath), reviewed as full composition via git range-diff 4ec4a71..76b506e cf39826..30de4ae:

• #103 semantics correctly absorbed: the raw-channel-path case flips from #97-era delivery to ignored (assert.deepEqual(harness.sent, [])), stale-backfill test asserts eventsDropped counters via waitForDropped, fixtures move to slack-ts-consistent timestamps + withMockedNow reconciles. All consistent with the merged Track C baseline.
• Retired stays retired: grep count for eventContextLines|slackRecordContextLines|readLocalEventRecord at 30de4ae = 0; #97's local/expand context tests are gone and replaced by the preview suite. Single bounded read/block holds.
• Carry-forward checks pass: history-off Slack thread context resolves through ONE targeted remote readFile (exactly-one-block + doesNotMatch /Slack text:/ assertions intact, now with explicit downloadHistoricalData: false); binary/too-large branches preserved; data.contextPreview.content undefined.
• Unadopted bot drift 1920bed confirmed absent (head is owner-composed 30de4ae) — per the standing bot-delta rule.

Author validation: integrations 9/9, bridge 32/32, npm test 58/58, build, diff-check. CI at 30de4ae: checks ✅, CodeRabbit ✅, packaged-mcp-smoke pending at review time.

Verdict: APPROVE (content-based at head 30de4ae)

Merge gate: packaged-mcp-smoke green at 30de4ae. On green: merge, post the Track D fix note on #82 (acceptance: structured event metadata, single bounded inline context preview without historical download, scoped renderer read surface, deleted-event read skip), announce in #general so #106 starts its final rebase.

[agent-relay-code]

Fixed one production bug in integration-event-bridge.ts: deleted Relayfile filesystem events are normalized to type: "relayfile.changed", so the previous deleted-file preview guard would still attempt readFile. The normalized resource now preserves filesystemEventType, and the preview skip checks that value.

Updated the deleted-file regression in integration-event-bridge.test.ts to match the production event shape.

Validated locally:

• npm test -- src/main/__tests__/integration-event-bridge.test.ts
• npx vitest run src/main/integrations.test.ts
• npx vitest run
• npm run build
• npm run verify:mcp-resources-drift

GitHub review/comment APIs returned 404 without credentials, and no review-comment bundle was present in .workforce, so I could not inspect external bot comments from this sandbox.

[agent-relay-code]

✅ pr-reviewer applied fixes — committed and pushed 340e66e to this PR. The notes below describe what changed.

Fixed one production bug in integration-event-bridge.ts: deleted Relayfile filesystem events are normalized to type: "relayfile.changed", so the previous deleted-file preview guard would still attempt readFile. The normalized resource now preserves filesystemEventType, and the preview skip checks that value.

Updated the deleted-file regression in integration-event-bridge.test.ts to match the production event shape.

Validated locally:

• npm test -- src/main/__tests__/integration-event-bridge.test.ts
• npx vitest run src/main/integrations.test.ts
• npx vitest run
• npm run build
• npm run verify:mcp-resources-drift

GitHub review/comment APIs returned 404 without credentials, and no review-comment bundle was present in .workforce, so I could not inspect external bot comments from this sandbox.