Skip to content

[Fleet Execution] [File System Events Example] #239

@davideast

Description

@davideast

Goal Reference

This issue was generated from .fleet/goals/sdk-examples.md. The worker agent should read this file for full context including verification commands, constraints, and structural guidance.

Objective

Create an example demonstrating how to trigger event-driven Jules sessions from file system events (e.g., using chokidar to watch for local file changes and initiate a coding session).

Code-Level Diagnosis

Code path: packages/core/examples/file-system-events/
Mechanism: The packages/core/examples/file-system-events/ directory and its corresponding examples are entirely missing.
Root cause: The SDK lacks a runnable, practical example of integrating Jules with local file system events.

Current Implementation

// Missing example

Proposed Implementation

Files to modify: Create packages/core/examples/file-system-events/index.ts and packages/core/examples/file-system-events/README.md. Update packages/core/README.md to link to the new example.

Integration (Before -> After)

--- a/packages/core/README.md
+++ b/packages/core/README.md
@@ -10,6 +10,7 @@
 Orchestrate complex, long-running coding tasks to an ephemeral cloud environment integrated with a GitHub repo.
 
 ## Examples
 
 - [Basic Session](./examples/basic-session/README.md)
+- [File System Events](./examples/file-system-events/README.md)

Test Scenarios

  1. Run bun run build and bun run index.ts (or equivalent) in the example directory -> The watcher starts up. Making a file change triggers a Jules session.
  2. Follow the README.md instructions -> Instructions correctly guide a user to run the example.

Target Files

  • packages/core/examples/file-system-events/index.ts
  • packages/core/examples/file-system-events/README.md
  • packages/core/examples/file-system-events/package.json
  • packages/core/README.md

Boundary Rules

Restrict your modifications exclusively to the files listed in the Target Files section. Ensure your source changes are entirely backward-compatible if unowned tests outside your boundary fail. Retain all existing file names and locations outside your explicitly declared target list.


Fleet Context

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions