RIG-404 feat: implementation

[ArLeyar]

Summary

Pipeline engineer task 20260409-001.

Linear: RIG-404

[ArLeyar]

Code review

Found 2 issues:

1. UserConfig::load() called on every daemon tick (every 5s), performing a disk read of ~/.werma/config.toml 12 times/minute. All other daemon external resources (linear_poll, cmd_runner, notifier) are initialized once before the loop. This should be loaded once at startup and passed in, consistent with the established daemon pattern.

werma/engine/src/daemon/mod.rs

Lines 159 to 170 in 23e2e3f

	// (Linear or GitHub). The optional `linear_poll` is passed as fallback for
	// Linear identifiers; GitHub effects are resolved via user_cfg.
	{
	let user_cfg = crate::config::UserConfig::load();
	match crate::pipeline::effects::process_effects(
	&db,
	linear_poll.as_deref(),
	&cmd_runner,
	&notifier,
	&user_cfg,
	) {
	Ok(r) if r.processed > 0 || r.failed > 0 => {

2. Behavior regression: before this PR, the if let Some(lp) = linear_poll.as_deref() guard meant that when LINEAR_API_KEY is absent, Linear effects stayed in pending state (waited for config). After this PR, process_effects always runs — any Linear effect (non-# identifier, e.g. RIG-123) processed when linear is None is now permanently dead-lettered with "no Linear client available". Effects marked failed here are not retried. This breaks setups where the API key is temporarily absent.

werma/engine/src/pipeline/effects.rs

Lines 82 to 91 in 23e2e3f

	l
	} else {
	let msg = format!("no Linear client available for '{}'", effect.issue_id);
	db.mark_effect_failed(effect.id, &msg)?;
	failed += 1;
	if effect.blocking {
	eprintln!(
	"[effects] blocking effect {} (type={:?}) failed for task {}: {msg}",
	effect.id, effect.effect_type, task_id
	);

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}