Files
website/server/test/engagementManifest.test.js
wtclaude 82a50e5e04
All checks were successful
PR Checks / bot-tests (pull_request) Successful in 1m5s
PR Checks / client-build (pull_request) Successful in 2m40s
PR Checks / server-tests (pull_request) Successful in 12m22s
fix(engagement): the trigger manifest was stale, and its check was crying wolf
Two defects, and the second is why the first survived a whole phase.

The manifest is stale. `engagement-triggers.json` embeds `moduleApiVersion`
deliberately -- "a stale manifest needs to know which API's rules produced it"
-- and Phase 7 (website#189) bumped MODULE_API_VERSION to 1.10.0 without
regenerating it. The committed file has said 1.9.0 ever since. One line, and
regenerating is the whole fix.

The check could not be believed. Both the test and the `--check` CI gate
compared bytes, and this repo is developed on Windows under core.autocrlf=true,
so git checks the committed LF blob out as CRLF and the comparison then calls an
unchanged manifest stale. That failure fires on every Windows checkout, says "a
trigger declaration changed", and is "fixed" by regenerating a file whose
content was already correct.

So the one check that exists to be believed had been failing for a reason
everyone had learned to write off as environmental -- including me, twice: the
Phase 7 PR recorded it as a pre-existing CRLF failure, and the Phase 8 PR
repeated the claim. It was neither pre-existing nor CRLF. A check that cries
wolf is a check nobody reads, and the genuine staleness underneath it went
unnoticed for exactly that reason.

Line endings are now normalised on both sides, which is the convention
routeManifest.js and routeManifest.test.js already use one file along -- that
pair had clearly hit this and been fixed; the engagement pair never was. What is
being asserted is that the committed manifest describes the same declarations,
and a line ending is not a declaration. Policing the encoding is .gitattributes'
job, not this check's.

Verify

- The check is still LIVE, proved by breaking it deliberately: with the content
  changed the gate exits 1; with only the line endings changed it exits 0. That
  is the whole point of the fix, so it is not taken on trust.
- `npm test` under the TAP reporter: 1950 tests, 1877 pass, 0 fail. That is
  pristine `edge`'s 1950/1876 plus the one test this repairs.

A harness note, disclosed rather than buried

The default (spec) reporter intermittently reports a FILE-level failure with all
of that file's subtests passing, no assertion, and no diagnostic beyond 'test
failed'. It named a different unrelated file on each of four runs
(requireInternalKey, routeManifest, eventAuthorize, totp) and the TAP reporter
shows zero failures over the same suite. It appears to be a reporter artifact
under concurrency rather than a failing test, but it correlates with this branch
(4/4) against pristine edge (0/2) on the same machine state, which I could not
explain and am not claiming to have. Worth its own look; it does not indicate a
product defect and no assertion fails.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-09-04 02:43:53 -05:00

86 lines
3.6 KiB
JavaScript

// ── The engagement trigger manifest ────────────────────────────────────────
//
// ENGAGEMENT.md §4.3 property 4. CI runs `npm run engagement:manifest -- --check`
// and that is the gate; this file is here for the reason
// `checkModuleIdentifiers.test.js` exists — **a check that silently stops
// checking is worse than no check**. So there are two tests: the committed file
// is current, and the generator actually notices a changed declaration.
//
// It also makes a stale manifest fail `npm test`, which is the run a developer
// does before pushing.
process.env.DB_HOST = '127.0.0.1'
process.env.DB_PORT = '59999'
const { test, afterEach, after } = require('node:test')
const assert = require('node:assert/strict')
const fs = require('fs')
const path = require('path')
const { build } = require('../scripts/engagementManifest')
const registries = require('../src/modules/registries')
const db = require('../src/utils/db')
after(() => db.close())
afterEach(() => registries._reset())
const MANIFEST_PATH = path.join(__dirname, '..', 'engagement-triggers.json')
const serialize = (m) => `${JSON.stringify(m, null, 2)}\n`
// **Normalised, like `routeManifest.test.js`'s `read()` one file along.** Under
// `core.autocrlf=true` git checks the committed LF blob out as CRLF, so a byte
// comparison fails on every Windows checkout while CI stays green — and it fails
// saying "the manifest is stale", which is the one thing it is not. The claim
// here is that the committed file describes the same declarations; a line ending
// is not a declaration.
const committedManifest = () => fs.readFileSync(MANIFEST_PATH, 'utf8').replace(/\r\n/g, '\n')
test('the committed manifest matches the declarations in the tree', () => {
const committed = committedManifest()
assert.equal(
serialize(build()),
committed,
'engagement-triggers.json is stale — run `npm run engagement:manifest` and commit the result',
)
})
test('the manifest holds core\'s triggers only, never a module\'s', () => {
// A module ships its own copy in its bundle (MODULE_API.md §6.1a), because
// core never has its sources to analyse. If a module's declarations leaked
// into core's manifest, the file would change depending on which modules
// happened to be installed on the machine that regenerated it.
registries._reset()
const api = registries.stage('uo')
api.registerEventTriggers([{
id: 'uo.house.idoc_warning',
label: 'House approaching collapse',
ceiling: 'owner',
variables: [{ name: 'house', type: 'string', required: true, example: 'The Silver Anvil' }],
}])
registries.apply(api.staged)
const manifest = build()
assert.equal(manifest.triggers.every((t) => t.owner === 'core'), true)
assert.equal(manifest.triggers.some((t) => t.id === 'uo.house.idoc_warning'), false)
})
test('and it notices a changed declaration — the check is live', () => {
const before = serialize(build())
// Register one more trigger AS CORE, then rebuild. `build()` calls
// registerCore(), which is a no-op once core has registered, so this lands
// beside core's five rather than replacing them.
registries._reset()
const api = registries.stage('core')
api.registerEventTriggers([{
id: 'core.probe',
label: 'A declaration the committed manifest does not have',
ceiling: 'staff',
variables: [{ name: 'why', type: 'string', required: true, example: 'proving the check works' }],
}])
registries.apply(api.staged)
const after_ = serialize(build())
assert.notEqual(after_, before)
assert.match(after_, /core\.probe/)
})