`integrations/tests/nudge-lib.test.mjs` (78 lines) covers the pure-JS nudge library and byte-parity between Claude and Codex scripts. It does not exercise the actual save-nudge flow against a running daimon server.
The README admits the gap honestly:
"Integration paths against live Postgres/Qdrant are still exercised manually."
Without integration tests, every pilot is a leap of faith and the "experimental" status flag in the README can't be reconsidered.
Proposed change
Test scaffolding, not a feature:
1. A `tests/integration/` directory with a Docker-Compose-up harness that starts `daimon-mcp` + Postgres + Qdrant (uses the existing `docker-compose.yml`).
2. A node test that exercises the round-trip:
```js
// tests/integration/save-nudge.test.mjs
import { test } from "node:test";
import assert from "node:assert/strict";
const ENDPOINT = process.env.DAIMON_ENDPOINT || "http://localhost:8080\";
test("save-nudge round-trip", async (t) => {
// 1. POST a fake turn containing a decision-signal
// 2. Verify the nudge regex matches
// 3. POST a remember call
// 4. Assert the resulting daimon://... record exists
// 5. recall() returns it
});
```
3. A Makefile target (`make test-integration`) that does up → test → down.
4. CI matrix: run on Linux + macOS only (skip Windows for these specific tests because Docker Desktop's Linux engine behavior is well-tested upstream). The byte-parity test continues to run everywhere.
5. Coverage targets (not strict gates, but reported):
- All 5 `SIGNALS` regexes in `nudge-lib.mjs` have at least one positive and one negative test.
- The cadence state machine (`decide`) has tests for: signal-hits-suppress-nudge, signal-misses-emit-nudge, cadence-resets, session-end-sweep.
- The RRF fusion has a unit test that verifies score decomposition (`{rrf, raw_keyword, raw_semantic}`) is present per hit.
Why this matters for a second user
This is the "trust the system" gap. With integration tests, the experimental flag can be reconsidered, and second users (like Pizo) can adopt the system with confidence that the contracts are real, not aspirational.
Acceptance
- `make test-integration` runs end-to-end on Linux/macOS CI.
- README's "Status" section mentions the new coverage.
- The existing `nudge-lib.test.mjs` parity test is preserved unchanged.
`integrations/tests/nudge-lib.test.mjs` (78 lines) covers the pure-JS nudge library and byte-parity between Claude and Codex scripts. It does not exercise the actual save-nudge flow against a running daimon server.
The README admits the gap honestly:
Without integration tests, every pilot is a leap of faith and the "experimental" status flag in the README can't be reconsidered.
Proposed change
Test scaffolding, not a feature:
1. A `tests/integration/` directory with a Docker-Compose-up harness that starts `daimon-mcp` + Postgres + Qdrant (uses the existing `docker-compose.yml`).
2. A node test that exercises the round-trip:
```js
// tests/integration/save-nudge.test.mjs
import { test } from "node:test";
import assert from "node:assert/strict";
const ENDPOINT = process.env.DAIMON_ENDPOINT || "http://localhost:8080\";
test("save-nudge round-trip", async (t) => {
// 1. POST a fake turn containing a decision-signal
// 2. Verify the nudge regex matches
// 3. POST a remember call
// 4. Assert the resulting daimon://... record exists
// 5. recall() returns it
});
```
3. A Makefile target (`make test-integration`) that does up → test → down.
4. CI matrix: run on Linux + macOS only (skip Windows for these specific tests because Docker Desktop's Linux engine behavior is well-tested upstream). The byte-parity test continues to run everywhere.
5. Coverage targets (not strict gates, but reported):
Why this matters for a second user
This is the "trust the system" gap. With integration tests, the experimental flag can be reconsidered, and second users (like Pizo) can adopt the system with confidence that the contracts are real, not aspirational.
Acceptance