test: cover Jules activity normalization

[cursor]

Summary

• Add deterministic coverage for realJulesPort.listActivities request wiring.
• Verify Jules payload variants (role/author, content/message, and timestamp/createTime) normalize into stable agent/human messages.

Risky behavior now covered

Jules activity responses feed the session conversation drawer. Field-name or role-normalization regressions could silently hide content or misattribute user messages as agent output.

Test files added

• test/jules-port-activities.test.ts

Regression value

The fixture exercises every existing normalization fallback in one API-boundary test without a live Jules dependency. A mutation that removed the author fallback changed a USER activity to agent and failed the test, demonstrating that it detects a materially user-visible regression.

Validation

• npm test -- test/jules-port-activities.test.ts (1/1 passed)
• npm test (36/36 passed)
• npm run build
• npx prettier --check test/jules-port-activities.test.ts

  

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
polyagent	Ready	Preview, Comment	Jul 29, 2026 10:11am

[parvezk]

@cursoragent I didn't quite get this test normalizes heterogeneous Jules activities into agent and human messages. Your fetchMock response sends author: "USER", when realJulesPort("test-api... is called. Then you expect the role in the second object to equal role: "human",. Where is the mutation 'A mutation that removed the author fallback '? Perhaps I have trouble understanding this test.

[cursor]

The mutation isn’t in the fixture itself; it was a local/manual mutation of the production normalization code to validate that the test would fail if the fallback were removed.

Relevant path:

• Fixture sends second activity with author: "USER" and no role
• Production code uses a.role ?? a.author ?? "agent"
• "USER".toLowerCase().startsWith("user") maps to role: "human"

So if someone mutates the adapter from:

a.role ?? a.author ?? "agent"

to something like:

a.role ?? "agent"

then that second activity has no role, falls back to "agent", and the expected role: "human" fails.

Suggested reply:

The “mutation” was a local mutation of the adapter logic, not a different fixture in the test. The second activity intentionally has author: "USER" and no role to exercise the a.role ?? a.author ?? "agent" fallback. If the author fallback is removed, that activity defaults to agent, so the test fails because it expects the user-authored activity to normalize to human.

  

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[parvezk]

Internal change — no release note.

---

Generated by Claude Code