[Phase 6.9] Directory Watchers #78
Labels
No labels
blocked:children
blocked:commit-ready-failed
blocked:depends-231
blocked:depends-236
blocked:depends-237
blocked:depends-238
blocked:depends-239
blocked:gate-fetch
blocked:gate-fetch
blocked:gate-lint
blocked:gate-research
blocked:needs-attention
blocked:needs-decision
blocked:no-changes
blocked:no-procedure
blocked:preflight
blocked:verify-failed
bug
enhancement
feature-request
high-priority
in-progress
lint-cleanup
needs-decompose
needs-triage
ops-retry
ops-task
phase-5
quickfix
security/medium
self-building
triage-approved
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/mesh-seed#78
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Overview
Directory watchers for continuous file-based document pipelines.
Problem Statement
Currently files must be manually submitted for processing. Cannot:
Proposed Solution
6.9.1: Watcher Configuration
6.9.2: Directory Watcher Service
6.9.3: Event Handling
6.9.4: Post-Processing Actions
Deliverables
runtime/directory_watcher.py- Watcher serviceconfig/watchers.yaml- Watcher configuration/v1/watchers/*Dependencies
Estimated Duration
1 week
Success Criteria
Related
⏸ Needs Decision
What needs to be decided?
blocked:needs-decisionlabel to route back to triage.Blocking factors:
Scope: small Risk: low Spec: partial Type: feature
Summary: Add a directory watcher service that monitors filesystem paths for new/modified documents and automatically emits processing intents into the mesh.
Suggestion: Don't reimplement watchdog integration — the heavy lifting already exists in substrate/document_scanner.py's DirectoryWatcher class (polling + watchdog-optimized backends, file metadata, skip patterns, and change detection). Create runtime/directory_watcher_service.py that loads config/watchers.yaml, wraps DirectoryWatcher instances, and pipes file events into the backplane as intent.discovered signals with properly shaped intent payloads. Post-processing (move/delete/archive) is a simple callback. This is an orchestration layer on top of existing infrastructure — about 3-4 files total (service + config + tests).
Rationale: Scope is small because the filesystem watching primitives already exist in substrate/document_scanner.py (DirectoryWatcher class with both polling and watchdog backends). The issue mostly requires an orchestration layer that loads YAML config, wires watchers to the backplane, and handles post-processing. Risk is low because it's additive (no changes to existing code paths) and follows established patterns (watchdog Observer, backplane intent emission). Spec alignment is partial — the intent-ingestion-protocol.md already defines File Watcher as an entrypoint, so it aligns with the architecture, but it's not listed in any current milestone (MILESTONES.md has no Phase 6.9). It's a clean additive feature with no breaking changes.
To unblock: Remove the
blocked:needs-decisionlabel. The triage will apply the appropriate outcome based on your choice above.Approved — removing blocked:needs-decision. Triage failed to auto-approve, but this is low/medium risk, aligned.