# Naming Conventions This document defines naming conventions for the Feed-based ingestion daemons and shared libraries in the HomeOps ecosystem. These conventions are intentionally simple and consistent, and are designed to make system behavior obvious from names alone. --- ## Core Shared Module **Module / repository name** maximumdirect.net/feedkit **Purpose** `feedkit` provides the domain-agnostic core used by all feed-processing daemons: polling, scheduling, filtering, routing, persistence fanout, and signaling. It contains *infrastructure primitives*, not domain logic. --- ## Feed Daemons ### Naming Format feeder This name is used for **both**: - the repository / Go module name - the compiled binary name ### Rationale A *feeder* is an active agent that: - consumes one or more upstream feeds - normalizes new items into events - emits facts and/or signals into the system ### Examples | Domain | Repository / Binary | |---------------|---------------------| | Weather | `weatherfeeder` | | RSS | `rssfeeder` | | News | `newsfeeder` | | NBA | `nbafeeder` | | Earthquakes | `earthquakefeeder` | | Patreon | `patreonfeeder` | --- ## Non-Feed Daemons Daemons that perform downstream work (downloads, archiving, transformation, etc.) **should not** use the `feeder` suffix. Preferred naming reflects the primary action: - `mediafetcher` - `videodownloader` - `archiver` - `syncd` This preserves a clear semantic boundary between: - **feed detection** (feeders) - **work execution** (workers) --- ## Go Naming Conventions - All repository, module, package, and binary names are **lowercase** - No dashes (`-`) or underscores (`_`) in Go package names - Repository name and binary name should match unless there is a compelling reason not to --- ## Summary - **Core library:** `feedkit` - **Feed daemons:** `feeder` - **Downstream workers:** action-based names - Names should communicate *role*, not implementation details