feat: add Moltis hook provider - #25
Conversation
6b52980 to
5d076f3
Compare
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed
Tip: instead of fixing issues one by one fix them all with cubic
Re-trigger cubic
There was a problem hiding this comment.
1 issue found across 31 files (changes from recent commits).
Confidence score: 5/5
agenthookstest/fixtures/moltis/README.mddocuments Moltis 20260902.01 at commit77b0d0ac..., while the PR description cites610e9fba...; this creates a minor reproducibility and release-traceability ambiguity—confirm the correct commit and make the references consistent.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="agenthookstest/fixtures/moltis/README.md">
<violation number="1" location="agenthookstest/fixtures/moltis/README.md:4">
P3: The README pins these fixtures to Moltis 20260902.01 at commit 77b0d0ac..., but the PR description cites a different commit (610e9fba...) for the same release. A tagged release points to exactly one commit, so the two references contradict each other. Reconcile them to a single verified hash so a reader re-qualifying against the pinned commit lands on the intended revision.</violation>
</file>
Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.
Fix all with cubic | Re-trigger cubic
| # Moltis fixture provenance | ||
|
|
||
| These payloads target **Moltis 20260902.01** at the official tag commit | ||
| [`77b0d0ac52744aa4d59cbfe83db23cb7a6283ccf`](https://github.com/moltis-org/moltis/commit/77b0d0ac52744aa4d59cbfe83db23cb7a6283ccf). |
There was a problem hiding this comment.
P3: The README pins these fixtures to Moltis 20260902.01 at commit 77b0d0ac..., but the PR description cites a different commit (610e9fba...) for the same release. A tagged release points to exactly one commit, so the two references contradict each other. Reconcile them to a single verified hash so a reader re-qualifying against the pinned commit lands on the intended revision.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At agenthookstest/fixtures/moltis/README.md, line 4:
<comment>The README pins these fixtures to Moltis 20260902.01 at commit 77b0d0ac..., but the PR description cites a different commit (610e9fba...) for the same release. A tagged release points to exactly one commit, so the two references contradict each other. Reconcile them to a single verified hash so a reader re-qualifying against the pinned commit lands on the intended revision.</comment>
<file context>
@@ -0,0 +1,34 @@
+# Moltis fixture provenance
+
+These payloads target **Moltis 20260902.01** at the official tag commit
+[`77b0d0ac52744aa4d59cbfe83db23cb7a6283ccf`](https://github.com/moltis-org/moltis/commit/77b0d0ac52744aa4d59cbfe83db23cb7a6283ccf).
+The complete 17-variant wire schema comes from the public `HookPayload` enum in
+`crates/common/src/hooks.rs`; Moltis does not version the hook protocol
</file context>
There was a problem hiding this comment.
Reconciled the PR description and fixture provenance on the verified official tag commit 77b0d0ac52744aa4d59cbfe83db23cb7a6283ccf. The newer f640c9b7 reference is used only for the separately documented 20260902.02 release audit, not as the 20260902.01 fixture source.
|
Addressed all valid Cubic findings in
Current verification: |
Preserve Moltis tool_call_id values in normalized events and typed provider views while retaining synthesized fallback identities for released payloads. Extend the live conformance test to require AgentEnd, stable pre/post correlation, and direct shell denial against the lifecycle implementation proposed in moltis-org/moltis#1257. Document the official-release gap and the forward-compatible patched wire.
There was a problem hiding this comment.
All reported issues were addressed across 8 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
Install native MessageSending and MessageSent observers in the real Moltis E2E harness. Assert that outbound content is non-empty, unchanged across the two events, and emitted in pre-send then post-send order.
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Confidence score: 4/5
- In
e2e/moltis_test.go,requireMoltisMessageLifecyclecompares the finalMessageSendingandMessageSentcontents even though the fixtures show these are distinct payloads; valid lifecycles could therefore fail end-to-end tests. Align the assertion with the intended lifecycle semantics.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="e2e/moltis_test.go">
<violation number="1" location="e2e/moltis_test.go:415">
P2: requireMoltisMessageLifecycle asserts the last MessageSending content equals the last MessageSent content, but Moltis models these as distinct payloads (the PR's own fixtures show "message entering the model" vs "message delivered"), and in a real multi-iteration session the last MessageSending is an input message while the last MessageSent is the assistant output. Track each pair by session/message instead, or assert that a Sending has a corresponding Sent with matching content rather than comparing the last occurrences globally.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
Match MessageSending to a later MessageSent by session key and content instead of comparing whichever two lifecycle events happened to be last. This keeps the process-level acceptance test robust when unrelated turns add more events.
Require every observed BeforeToolCall and AfterToolCall ID to have a counterpart instead of accepting the first matching pair. Rename the typed-view test to describe forward-compatible decoding without implying that unpatched Moltis releases already emit stable IDs.
1 participant
Summary
ProviderMoltis, native process-per-event decoding, shape detection, and typed views for all 17HookPayloadvariantsHOOK.mdpacks for user/project installs; grouptool.postandtool.errorinto oneAfterToolCallsubscriptiontool_call_idwhen present and retain the synthesized-ID fallback for unpatched releasesNative semantics covered
{"action":"modify","data":...}: tool-argument rewriteMessageReceivedcontext: append to the only mutable native field,contentAfterToolCall.success=false: normalize astool.errorMessageSendingandMessageSent: retain as Moltis-native extension events;AgentEndmaps to the portable stop eventThe quirk registry records the stock
20260902.01-20260902.02gaps: no native tool-call correlation ID and missing production dispatch for some declared lifecycle payloads. It also records native fail-open behavior on hook crashes/timeouts. moltis-org/moltis#1257 supplies the host-side lifecycle and identity changes while this adapter remains backward-compatible.Ground truth
The codec and fixtures are qualified against the official Moltis
20260902.01tag, commit77b0d0ac52744aa4d59cbfe83db23cb7a6283ccf:HookEvent/HookPayloadMessageReceiveddecision handlingLive compatibility was then verified against a portable
20260902.02build carrying moltis-org/moltis#1257, including its review fix that suppressesMessageSentwhen persistence or known-channel delivery fails.Verification
go mod tidy -diffgo build ./...go vet ./...golangci-lint v2.7.2 run— 0 issuesgo test -race ./...— PASSgo test ./... -run 'Moltis' -count=1— PASSAGENTHOOKS_E2E=1 AGENTHOOKS_MOLTIS_BASE_URL=http://127.0.0.1:11434/v1 AGENTHOOKS_MOLTIS_MODEL=Q4-ColdFusion-27B go test ./e2e -run '^TestMoltisEventsAndDecisions$' -count=1 -v— PASS in 118.04s on the current headAGENTHOOKS_E2E=1 go test ./e2e -run '^TestCodexPortableHandler$' -count=1 -v— PASS in 16.38sThe Moltis E2E starts an isolated localhost Gateway with temporary config/data/project roots and uses the same provider-free recorder used by the Codex E2E. It proves:
BeforeToolCallandAfterToolCallhas a non-empty, bidirectionally matched stable IDMessageSendingprecedesMessageSentfor the same session and contentAgentEndis observed as the portable stop event/shdenial prevents the marker command from executingThe test does not modify the live Moltis configuration or Gateway.