Filesystem watcher daemon: debounces project writes into /NEXUS/LOGOS/, commits per origin_project, pushes to origin
  • F# 97.2%
  • Shell 2.8%
Find a file
Ivan The Geek 1b42c3dae7 Merge fix/chronicon-empty-read-quarantine: skip empty mid-write CHRONICON reads
Intrinsic-path sibling of the merged sidecar empty-read fix. An empty
CHRONICON read (CREATE inotify event at 0 bytes, body not yet landed)
is now treated as "not ready" -- skipped, not quarantined as
MissingField "provenance" -- and re-read on the writer's subsequent
Changed event.
2026-05-31 10:31:58 -04:00
docs feature: migrate AlarmService to event-sourced todo escalation 2026-05-25 15:56:43 -04:00
src/Watcher fix: skip empty mid-write CHRONICON reads instead of quarantining 2026-05-31 10:31:48 -04:00
systemd docs: add testing tutorial; audit + fix all link 404s 2026-05-25 13:06:23 -04:00
tests fix: skip empty mid-write CHRONICON reads instead of quarantining 2026-05-31 10:31:48 -04:00
.build-image feature: adopt containerized build system (LOGOS template pilot) 2026-05-24 22:35:54 -04:00
.gitignore docs: add testing tutorial; audit + fix all link 404s 2026-05-25 13:06:23 -04:00
AGENTS.md docs: add testing tutorial; audit + fix all link 404s 2026-05-25 13:06:23 -04:00
AGENTS.source.md docs: add testing tutorial; audit + fix all link 404s 2026-05-25 13:06:23 -04:00
build refactor: drop YoloDev.Expecto.TestSdk; tests run via dotnet run 2026-05-25 00:27:26 -04:00
CLAUDE.md chore: bootstrap NEXUS-LOGOS-WATCHER repo with NEXUS compliance 2026-05-24 17:22:47 -04:00
Directory.Build.props feature: adopt containerized build system (LOGOS template pilot) 2026-05-24 22:35:54 -04:00
global.json feature: adopt containerized build system (LOGOS template pilot) 2026-05-24 22:35:54 -04:00
LOGOS-WATCHER.slnx chore: add checked-in LOGOS-WATCHER.slnx solution file 2026-05-25 11:51:22 -04:00
README.md docs: explain user-service lifecycle (login-gated, RDP, linger) 2026-05-25 14:02:07 -04:00

NEXUS LOGOS Watcher

Long-running daemon that watches /NEXUS/LOGOS/, batches filesystem writes from other NEXUS projects, and commits + pushes them to the central LOGOS forgejo remote — one commit per origin_project per debounce window.

Why this exists

/NEXUS/LOGOS/ is the central knowledge store. Project sessions (Claude Code, Codex CLI, etc.) write findings to /NEXUS/LOGOS/CHRONICON/<uuid>.toml, notes to /NEXUS/LOGOS/HYPOMNEMATA/<project>/, and occasionally edits to CORPUS/ or ARMAMENTARIUM/. Those sessions run inside the originating project's repo, not inside LOGOS, so LOGOS never sees a Stop hook fire — there's nothing to trigger a commit or push.

This daemon fills that gap: it watches LOGOS, attributes each write to its originating project, and commits under that project's identity so the resulting history reads correctly.

Quick context

flowchart LR
    P1[Project A session]
    P2[Project B session]
    LOGOS[(/NEXUS/LOGOS/ working tree)]
    W{{LOGOS Watcher daemon}}
    FG[(forgejo NEXUS/LOGOS)]

    P1 -- writes CHRONICON/<uuid>.toml --> LOGOS
    P2 -- writes HYPOMNEMATA/B/note.md --> LOGOS
    LOGOS -- inotify --> W
    W -- commit as Project A --> LOGOS
    W -- commit as Project B --> LOGOS
    W -- push origin main --> FG

Documentation

  • Architecture — pipeline stages, modules, state machines, sequence diagrams.
  • Protocol — attribution rules, sidecar TOML format, quarantine semantics.
  • Operations — systemd unit, logs, alarm recovery, push-failure handling.
  • Testing — test layout, what each package contributes, how to add tests, how to diagnose flakes.

Build

./build              # build + test
./build publish      # produce ./out/Watcher/Watcher

Requires Docker. Everything else (the .NET SDK, NuGet packages, build tooling) runs inside a pinned container; nothing else to install. Full contract: /NEXUS/LOGOS/CORPUS/conventions/build-system.md (cross-repo link; opens in forgejo).

The systemd user unit at systemd/nexus-logos-watcher.service launches the container-built binary at out/Watcher/Watcher. Build once with ./build publish before systemctl --user start.

Because the unit is a user service (not a system service), it runs only while the installing user has at least one active login session — ssh, console, graphical, or RDP (xrdp). It does not start at machine boot unless loginctl enable-linger <user> is set. Full lifecycle, including how to make it run continuously, is in docs/operations.md → When the watcher runs.