@bongos/core 1.19.705 → 1.19.707

package/tests/smoke_write_contract.mjs

@@ -0,0 +1,110 @@
+// tests/smoke_write_contract.mjs — the write-path smoke's own contract
+// (task 1002018).
+//
+// TWO DEFECTS, ONE FILE. Both were found by trying to RUN scripts/gds/smoke-write.sh
+// rather than by reading it, and neither was visible to any existing test:
+//
+// 1. IT COULD NOT RUN AT ALL. goal_id became required on POST /tasks (task 1003598,
+//    ADR 0250 D4) and this script still sent none, so step 1 died on a 400
+//    goal_id_required. The production write-path smoke had been dead since that
+//    landed, and nothing said so — the same silent-rot shape as the PMS-V1 version
+//    literal that tests/version_literals.mjs exists to prevent, one field over.
+//
+// 2. IT LEAKED ITS THROWAWAY TASK. The smoke creates a REAL task to exercise the
+//    create API and never disposed of it: 94 rows accumulated under PMS-V1 before
+//    the task-2016 sweep cleared them by hand.
+//
+// WHY ASSERT ON SOURCE TEXT. This script talks to a live API, needs a session
+// token and (for the rest of the file) python3, so it cannot be executed in the
+// DB-free unit gate. Source assertions are what CAN run here. They are written
+// narrowly — each one names a specific defect that actually happened, and the
+// resolution assertions deliberately REJECT a hardcoded id rather than merely
+// requiring the field to be present, because "send goal_id" is satisfied just as
+// well by a literal that goes stale the moment the version rolls. That is the
+// over-broad-source-assertion trap this repo keeps relearning (learning 1000196):
+// the cure is specificity, not a bigger regex.
+import { strict as assert } from 'node:assert';
+import { test } from 'node:test';
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
+const SH = fs.readFileSync(path.join(ROOT, 'scripts', 'gds', 'smoke-write.sh'), 'utf8');
+
+// ---- defect 1: the create must carry a goal_id, resolved not hardcoded -----
+
+test('the create body sends goal_id at all (the 400 that killed the smoke)', () => {
+  assert.match(SH, /'goal_id':/, 'POST /tasks has required goal_id since task 1003598');
+});
+
+test('goal_id is the RESOLVED id, never a literal', () => {
+  assert.match(SH, /'goal_id': \$\{GOAL_ID\}/, 'the create interpolates the resolved id');
+  assert.ok(
+    !/'goal_id': *[0-9]/.test(SH),
+    'a numeric goal id in the body would go stale the moment the version rolls'
+  );
+});
+
+test('GOAL_ID is resolved at runtime, from the is_maintenance flag', () => {
+  assert.match(SH, /GOAL_ID=\$\(call GET "\/api\/gds\/goals\?version=\$\{VERSION_ID\}"/,
+    'it asks the API for this version-s goals');
+  assert.match(SH, /is_maintenance/, 'and picks the maintenance goal by its flag');
+  // Exactly one open maintenance goal exists per version (BV1.R18). Ambiguity here
+  // means the instance is misconfigured, and guessing would file the smoke row into
+  // a real working area — so the resolution must refuse rather than pick.
+  assert.match(SH, /m\.length !== 1/, 'it refuses on anything but exactly one match');
+});
+
+// ---- defect 2: the throwaway task is disposed of ---------------------------
+
+test('a passing run abandons its throwaway task', () => {
+  assert.match(SH, /cleanup_throwaway_task\(\) \{/, 'the cleanup exists');
+  assert.match(SH, /tasks\/\$\{TASK_ID\}\/abandon/, 'and it abandons the row it created');
+});
+
+test('cleanup runs ONLY on success — a failed run keeps its evidence', () => {
+  const guard = SH.slice(SH.indexOf('--- 5. clean up'));
+  assert.match(guard, /if \[\[ "\$\{fail\}" -eq 0 \]\]; then\s*\n\s*cleanup_throwaway_task/,
+    'the call is gated on fail==0');
+  assert.match(guard, /kept for post-mortem/,
+    'and a failing run says why the row is still there');
+});
+
+test('cleanup is best-effort: it can never fail a passing smoke', () => {
+  const fn = SH.slice(SH.indexOf('cleanup_throwaway_task() {'), SH.indexOf('--- summary ---'));
+  // The three ways this could turn a PASS into a FAIL, each closed:
+  assert.match(fn, /\|\| true/, 'the curl cannot trip set -e');
+  assert.ok(!/fail=1/.test(fn), 'and it never touches the fail counter');
+  // task.abandon is floor-metic (ADR 0152), so a Xenos/Thetes token gets a 403
+  // here while every assertion above genuinely passed. That must read as SKIP.
+  assert.match(fn, /403\)/, 'a rank refusal is reported as SKIP, not as a failure');
+  assert.match(fn, /000\)/, 'so is no response at all');
+});
+
+// ---- the id is spliced as CODE, so its SHAPE is a security property ---------
+//
+// Raised by the grader's hacker worker on the first round of this task, and it
+// was right: `'goal_id': ${GOAL_ID},` lands inside a `python3 -c "..."` SOURCE
+// string, unquoted. The resolver validated the goal COUNT and never the id's own
+// shape, so a non-numeric id from /goals — schema drift, a misbehaving API, any
+// future path where an id-like field is influenced — would have been executed as
+// Python rather than read as data. Validating the count is not validating the id.
+
+test('the resolver refuses a non-numeric goal id', () => {
+  const ext = SH.slice(SH.indexOf('GOAL_ID=$(call GET'), SH.indexOf("') || {"));
+  assert.match(ext, /\/\^\[0-9\]\+\$\//, 'the extracted id is shape-checked');
+  assert.match(ext, /is not numeric/, 'and says so when it refuses');
+  // The check must come BEFORE the value is emitted, or it guards nothing.
+  assert.ok(
+    ext.indexOf('is not numeric') < ext.lastIndexOf('process.stdout.write'),
+    'the refusal precedes the write'
+  );
+});
+
+test('and the interpolation site re-checks it', () => {
+  // Belt-and-braces where the risk actually is: between resolution and the
+  // python3 heredoc the value passes through shell, so it is re-validated there.
+  assert.match(SH, /\[\[ "\$\{GOAL_ID\}" =~ \^\[0-9\]\+\$ \]\]/,
+    'bash re-checks the id before the create body interpolates it');
+});