Skip to content

test(reactions): lock down agent-runtime path + clawdbot follow-up#380

Open
samxu01 wants to merge 1 commit into
mainfrom
feat/agent-reactions
Open

test(reactions): lock down agent-runtime path + clawdbot follow-up#380
samxu01 wants to merge 1 commit into
mainfrom
feat/agent-reactions

Conversation

@samxu01
Copy link
Copy Markdown
Contributor

@samxu01 samxu01 commented May 16, 2026

Summary

Gap 4 (autonomous agent reactions) inventory + regression coverage:

  • Backend kernelPOST /api/messages/:messageId/reactions already accepts `cm_agent_*` tokens via `dualAuth` and gates agent callers correctly (`AgentInstallation` → `Pod.members` fallback). Same `messageReaction` socket emit fires for both paths. Shipped.
  • MCP server — `commonly_react_to_message` tool already exposed in `packages/commonly-mcp/src/tools/cap-react.ts`. MCP-driven agents (Cody, Cursor, Claude Code) can react today. Shipped.
  • Clawdbot / openclaw extension — does NOT yet expose the tool, so moltbot agents (theo/nova/pixel/aria/ops + community) can't react autonomously. Follow-up PR in `Team-Commonly/openclaw` needed to satisfy the goal's "@nova react 👍" acceptance test for moltbot agents.

This PR adds:

  1. Six unit tests in `backend/tests/unit/controllers/reactionController.test.js` asserting the agent-runtime path stays working (installation gate, fallback, 403, socket emit fires).
  2. A CLAUDE.md `Agent Runtime — Quick Rules` entry documenting the dual-auth shape as a kernel invariant.

Test plan

  • `cd backend && npx jest tests/unit/controllers/reactionController.test.js` → 6/6 passing.
  • Once openclaw fork adds the tool: `@nova react 👍 to my last message` in dev cluster → live badge update for a non-agent observer (browser, no refresh).

Follow-up

  • PR in `Team-Commonly/openclaw` adding `commonly_react_to_message` to `extensions/commonly/src/tools.ts` so moltbot agents get the same primitive.

🤖 Generated with Claude Code

The reaction endpoint already accepted cm_agent_* tokens through
dualAuth + the req.agentUser branch in reactionController, but there
was no test asserting the agent path works — a refactor of dualAuth or
agentRuntimeAuth could silently regress it.

Adds 6 unit tests covering:
- agent caller with active AgentInstallation → reacts + socket emits
- agent caller without installation but in Pod.members → still works
- agent caller in neither → 403
- human caller takes the pg pod_members path (no AgentInstallation lookup)
- unauthenticated → 401
- bad emoji shape → 400

Documents the dual-auth invariant in CLAUDE.md so future social-presence
primitives (typing, read-receipts, ...) take the same shape.

Note: the openclaw/clawdbot extension does not yet expose
commonly_react_to_message as a tool, so moltbot agents (theo/nova/...)
can't react autonomously yet — that work lives in the openclaw fork.
The MCP server already exposes the tool, so MCP-driven agents (Cody,
Cursor, Claude Code with @commonlyai/mcp) can react today.
samxu01 added a commit that referenced this pull request May 16, 2026
#380)

The reaction endpoint already accepted cm_agent_* tokens through
dualAuth + the req.agentUser branch in reactionController, but there
was no test asserting the agent path works.

Adds 6 unit tests covering:
- agent caller with active AgentInstallation → reacts + socket emits
- agent caller without installation but in Pod.members → still works
- agent caller in neither → 403
- human caller takes the pg pod_members path (no AgentInstallation lookup)
- unauthenticated → 401
- bad emoji shape → 400

Documents the dual-auth invariant in CLAUDE.md so future social-presence
primitives (typing, read-receipts, ...) take the same shape.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
samxu01 added a commit that referenced this pull request May 16, 2026
…MCP servers

Verified empirically 2026-05-15 after merging #388: codex CLI 0.125.0
recognizes [mcp_servers.commonly] in config.toml (`codex mcp list`
shows it enabled), but `codex exec` does NOT actually connect to or
expose tools from configured MCP servers. The model's tool list stays
limited to codex's built-in tools (web, image_gen, exec_command,
apply_patch, ...). list_mcp_resources returns empty regardless.

Per docs/MCP_INTEGRATION.md, the supported codex pattern is to wrap
codex AS an MCP server (codex-as-mcp), not to have codex consume MCP
servers. So #388 adds noise without effect.

For Cody to actually call commonly_react_to_message autonomously, the
real options are:
  - Switch her adapter from codex → claude-code or another MCP-
    consuming host (architectural decision).
  - Add the reaction tool to the openclaw extension's commonly_*
    block (separate Team-Commonly/openclaw PR; out of the
    "make-collab-bulletproof" goal's "no openclaw-coupled fixes"
    constraint).

Keeping the four ship-PRs (#379/#380/#381/#382 + #383/#384/#385/#386
follow-ups) in place — they're all correct. Just removing #388.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant