fix(examples): use valid event kinds in lobu-crm reactions

[buremba]

The lobu-crm funnel-digest and inbound-triage reactions (shipped in #1064) call client.knowledge.save with semantic_type: "funnel_digest" / "lead_interaction". Those aren't registered event kinds — knowledge.save validates semantic_type against the agent's event_kinds (built-ins: fact, note, todo, event, change, content, summary, decision, identity, preference, observation) and throws ScriptError: Invalid kind. Because knowledge.save runs before client.notifications.send, the reaction aborts and the digest never reaches #leads — the notify half of #1064 was never actually exercised end to end.

Fix

• funnel-digest: semantic_type "funnel_digest" → "summary"
• inbound-triage: semantic_type "lead_interaction" → "observation"
• Keep the domain label in metadata.kind so week-over-week queries still discriminate digest vs. triage events.

E2E reproducer (prod, org_lobucrm)

Driven via manage_watchers.complete_window (which runs the reaction in-process), against the deployed #1064 image:

• Red: with the old scripts → reaction_status: "failed", reaction_error: ScriptError: Invalid kind 'funnel_digest'. Valid kinds: fact, note, todo, ... (retried 3×, logged in watcher_reactions).
• Green: after pushing the fixed semantic_type via set_reaction_script → reaction_status: "success", a notification_sent reaction row (tool notify), notification event "Weekly funnel digest — 2026-06-01" created, and zero bot-delivery failures on either app pod.

The prod DB scripts for watchers 219/220 were already hot-fixed the same way; this PR makes the repo source match so the next lobu apply doesn't revert it.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Refactor
  • Updated internal data model structures for digest and knowledge event persistence to improve consistency and queryability.

[coderabbitai]

📝 Walkthrough

Walkthrough

Two CRM reaction handlers refactor how knowledge events are persisted. Both move domain-specific labels from the semantic_type field to metadata.kind, while adopting generic semantic types ("summary" for funnel digests, "observation" for lead interactions). Comments are updated accordingly.

Changes

Knowledge Event Classification Refactoring

Layer / File(s)	Summary
Funnel digest event classification examples/lobu-crm/funnel-digest.reaction.ts	Funnel digest persistence changes from semantic_type: "funnel_digest" to semantic_type: "summary" with metadata.kind: "funnel_digest". Header comment updated to match new digest/event wording.
Inbound triage event classification examples/lobu-crm/inbound-triage.reaction.ts	Inbound triage persistence changes from semantic_type: "lead_interaction" to semantic_type: "observation" with metadata.kind: "lead_interaction". Inline comments explain keeping the domain label in metadata for queryability; header comment reworded.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

Semantic types now wear their proper dress,
Domain labels tucked in metadata's nest,
Summary and observation take the lead,
While funnel and triage find what they need.
🐰✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'fix(examples): use valid event kinds in lobu-crm reactions' clearly and specifically summarizes the main change: fixing invalid semantic_type values in lobu-crm reaction files.
Description check	✅ Passed	The description comprehensively explains the problem, the fix, and includes E2E verification with before/after results. While the test plan checklist is not explicitly marked, the description adequately documents the changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/fix-crm-reaction-kinds

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint skipped: no ESLint configuration detected in root package.json. To enable, add eslint to devDependencies.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@examples/lobu-crm/inbound-triage.reaction.ts`:
- Around line 5-7: Header comment incorrectly claims an observation is persisted
"per run" even though the code returns early when data.notable is false or
recommended_actions is empty; update the comment to reflect the actual gate.
Edit the header above the reaction function to say that an observation
(metadata.kind: "lead_interaction") is only saved when the function reaches the
client.knowledge.save call (i.e., when data.notable is truthy and
recommended_actions is non-empty), and not on every invocation, and mention the
early return behavior that prevents saving.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: bbc65ed2-11ea-4310-8664-383a5329af38

📥 Commits

Reviewing files that changed from the base of the PR and between 6889f8f and 0e40d0b.

📒 Files selected for processing (2)

• examples/lobu-crm/funnel-digest.reaction.ts
• examples/lobu-crm/inbound-triage.reaction.ts

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Header comment overstates when triage events are persisted.

The function returns before client.knowledge.save when data.notable is false or recommended_actions is empty, so it does not persist an observation “per run.” Reword this comment to match the actual gate; otherwise the next-digest counting semantics are misleading.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@examples/lobu-crm/inbound-triage.reaction.ts` around lines 5 - 7, Header
comment incorrectly claims an observation is persisted "per run" even though the
code returns early when data.notable is false or recommended_actions is empty;
update the comment to reflect the actual gate. Edit the header above the
reaction function to say that an observation (metadata.kind: "lead_interaction")
is only saved when the function reaches the client.knowledge.save call (i.e.,
when data.notable is truthy and recommended_actions is non-empty), and not on
every invocation, and mention the early return behavior that prevents saving.