litany

Recurring task engine: due dates, no-due tasks, recurrence rules, completion history, streaks. Part of the TechGodHQ fleet.

Shape

• Core (crates/litany-core): pure domain logic — tasks, recurrence rules, occurrences. No HTTP, no Telegram, no UI.
• Surfaces: CLI/HTTP/MCP/TypeScript generated by hydra from api/operations.yaml.
• Storage: SQLite at /data/litany.db in the deployed container.

Generated contract

From a clean, writable checkout at the repository root (Rust/Cargo installed; no globally installed Hydra binary required):

cargo run --locked -p litany-codegen -- check
cargo run --locked -p litany-codegen -- write

check validates api/operations.yaml and hydra.yaml against Litany's locked Hydra dependencies and compares, without rewriting, all four committed artifacts:

• generated/cli.rs
• generated/http.rs
• generated/mcp.json
• generated/ts-client/index.ts

write regenerates those paths. Run it twice when changing the definition; the outputs are byte-deterministic. Generation only maintains the contract. It does not start local HTTP/MCP surfaces, deploy the Litany service, publish an npm package, or configure an Iris provider.

Model

• Task — name, optional due date, optional recurrence (daily, every N days, weekly [on weekday], every N weeks, monthly [on day], every N months, every N days from last due date).
• Occurrence — one row per actual completion, with its real timestamp. Streaks and history are derived from occurrences; nothing stores a mutable counter that can drift from reality.

Dogfood consumer

Litany is consumed over iris (Telegram) the way hermes-comms is: "done", "what's due today", streak check-ins. No client UI is planned; the hydra surfaces are the product.

License

MIT. See LICENSE.