@celilo/cli 0.15.0 → 0.16.1

package/src/services/alerting/inbound-poller.ts

@@ -20,7 +20,6 @@ import { loadCapabilityFunctions } from '../../hooks/capability-loader';
 import { createCapturingLogger } from '../../hooks/logger';
 import { type AckResult, acknowledgeAlert } from './ack';
 import { interpretInbound } from './inbound';
-import { parseInterviewAnswer } from './interview-responder';
 import type { NotificationTransport } from './notifier';
 import { composeAckBroadcastBody } from './notifier';
 import { consumeDelivery } from './tokens';
@@ -48,7 +47,16 @@ export interface TransportFailure {
 /** A message that was read but not acted on, and why. */
 export interface UnheardMessage {
   senderAddress: string;
-  reason: 'unknown_sender' | 'unknown_token' | 'wrong_sender' | 'ambiguous' | 'unrecognised';
+  reason:
+    | 'unknown_sender'
+    | 'unknown_token'
+    | 'wrong_sender'
+    | 'ambiguous'
+    | 'unrecognised'
+    /** A deploy question was named, but with no value to answer it with. */
+    | 'needs_value'
+    /** The token was valid, but the alert it names no longer exists. */
+    | 'stale_target';
 }
 
 export interface InboundPollDeps {
@@ -150,14 +158,19 @@ export async function pollInbound(db: DbClient, deps: InboundPollDeps): Promise<
 
       // An interview reply IS the answer rather than an acknowledgement —
       // same token table, same sender check, different meaning for the body.
-      if (outcome.delivery.kind === 'interview') {
-        const value = parseInterviewAnswer(message.body, outcome.delivery.token);
-        if (!value || !deps.answerInterview) {
+      // The value was extracted by `interpretInbound`, which is the only place
+      // that knows the delivery's kind; re-parsing it here is what left the
+      // real grammar unreachable for months (#533).
+      if (outcome.action === 'answer') {
+        if (!deps.answerInterview) {
+          // Nothing is attached to publish the answer against, so the question
+          // is still unanswered. Say so rather than consuming the token: the
+          // operator's next attempt has to be able to work.
           report.unheard.push({ senderAddress: message.senderAddress, reason: 'unrecognised' });
           continue;
         }
         consumeDelivery(db, outcome.delivery.id, deps.now());
-        deps.answerInterview(outcome.delivery.targetId, value);
+        deps.answerInterview(outcome.delivery.targetId, outcome.value);
         report.answered++;
         continue;
       }
@@ -171,12 +184,23 @@ export async function pollInbound(db: DbClient, deps: InboundPollDeps): Promise<
         outcome.route.personId,
         deps.now(),
       );
+
+      // A live token can outlive the alert it names. When the row is gone
+      // there is nothing to acknowledge, and saying "1 acked" anyway is a lie
+      // the operator has no way to catch — observed live: a reply reported
+      // `1 acked` while every alert still read `ackedBy: null`. Count what
+      // HAPPENED, never what was attempted.
+      if (!ack) {
+        report.unheard.push({ senderAddress: message.senderAddress, reason: 'stale_target' });
+        continue;
+      }
+
       report.acked++;
 
       // Everyone else who was paged is still expecting to act. Telling them is
       // the entire point of a per-delivery token — it is what makes the reply
       // identify a PERSON rather than just an alert.
-      if (ack) report.broadcast += await broadcastAck(db, ack, deps);
+      report.broadcast += await broadcastAck(db, ack, deps);
     }
 
     deps.writeCursor(transportId, received.cursor);

package/src/services/alerting/inbound.test.ts

@@ -33,8 +33,37 @@ describe('parseInbound', () => {
     expect(parseInbound('K7QM2X ack')).toEqual({ kind: 'ack', token: 'K7QM2X' });
   });
 
-  test.each(['', '   ', 'what is going on', 'K7QM', 'K7QM2XY'])('%p is unrecognised', (body) => {
-    expect(parseInbound(body)).toEqual({ kind: 'unrecognised' });
+  test.each(['', '   ', 'what is going on', 'K7QM2XY', 'ack now please'])(
+    '%p is unrecognised',
+    (body) => {
+      expect(parseInbound(body)).toEqual({ kind: 'unrecognised' });
+    },
+  );
+
+  // The bug that started this: the page says "reply BPRJEH", and a human types
+  // "ack BPRJEH". The old grammar read the VERB as the token, failed the length
+  // check, and rejected a real acknowledgement over word order.
+  test.each([
+    ['ack K7QM2X', 'K7QM2X'],
+    ['ACK K7QM2X', 'K7QM2X'],
+    ['ok k7qm2x', 'K7QM2X'],
+    ['K7QM2X ack', 'K7QM2X'],
+    ['k7qm2x OK', 'K7QM2X'],
+    ['👍 K7QM2X', 'K7QM2X'],
+    ['  ack   k7qm2x  ', 'K7QM2X'],
+  ])('%p yields token %p — the verb may lead, trail, or be absent', (body, token) => {
+    expect(parseInbound(body)).toEqual({ kind: 'ack', token });
+  });
+
+  // A prefix is legal INPUT; whether it identifies anything is the delivery
+  // table's question, not the parser's.
+  test.each([
+    ['bp', 'BP'],
+    ['ack bp', 'BP'],
+    ['BP ack', 'BP'],
+    ['b', 'B'],
+  ])('%p parses as the prefix %p', (body, token) => {
+    expect(parseInbound(body)).toEqual({ kind: 'ack', token });
   });
 });
 
@@ -128,6 +157,69 @@ describe('interpretInbound', () => {
     expect(interpretInbound(db, late)).toEqual({ action: 'rejected', reason: 'unknown_token' });
   });
 
+  describe('an abbreviated token', () => {
+    // How much an operator must type depends on what is actually outstanding.
+    test('resolves when the prefix is unique among live deliveries', () => {
+      const delivery = mintFor('r-peter');
+      const prefix = delivery.token.slice(0, 2);
+      const outcome = interpretInbound(db, context(PETER, `ack ${prefix.toLowerCase()}`));
+      expect(outcome).toMatchObject({ action: 'ack' });
+      expect(outcome.action === 'ack' && outcome.delivery.id).toBe(delivery.id);
+    });
+
+    test('a single character is enough when only one alert is live', () => {
+      const delivery = mintFor('r-peter');
+      // One character in 32 is `K`, which is ALSO an ack synonym — so that
+      // token parses as a bare ack rather than as a prefix. Either reading
+      // must land on the single live delivery, so the harness reflects it as
+      // outstanding as well; without this the test failed ~3% of runs with
+      // `unknown_token`, because the bare-ack path saw nothing outstanding.
+      outstanding.push(delivery);
+      const outcome = interpretInbound(db, context(PETER, delivery.token.slice(0, 1)));
+      expect(outcome).toMatchObject({ action: 'ack' });
+    });
+
+    // Never a guess: acknowledging the wrong alert is worse than asking again.
+    test('is refused as ambiguous when two live deliveries share the prefix', () => {
+      const a = mintFor('r-peter', 'alert-a');
+      let b = mintFor('r-peter', 'alert-b');
+      // Force a shared prefix rather than hoping two random tokens collide.
+      for (let i = 0; i < 40 && b.token[0] !== a.token[0]; i++) {
+        b = mintFor('r-peter', `alert-b-${i}`);
+      }
+      if (b.token[0] !== a.token[0]) return; // vanishingly unlikely; do not flake
+      // As above: a shared first character of `K` parses as a bare ack, and
+      // that path reads `outstandingForRoute` rather than the prefix search.
+      // Both readings must answer `ambiguous` here, so both are given two
+      // candidates to be ambiguous between.
+      outstanding.push(a, b);
+      expect(interpretInbound(db, context(PETER, a.token[0]))).toEqual({
+        action: 'rejected',
+        reason: 'ambiguous',
+      });
+    });
+
+    // Uniqueness is scoped to what is LIVE, so yesterday's tokens cannot make
+    // today's prefix ambiguous.
+    test('an expired delivery does not make a prefix ambiguous', () => {
+      const delivery = mintFor('r-peter');
+      const late = {
+        ...context(PETER, delivery.token.slice(0, 2)),
+        now: new Date(NOW.getTime() + TTL_MS + 1),
+      };
+      expect(interpretInbound(db, late)).toEqual({ action: 'rejected', reason: 'unknown_token' });
+    });
+
+    // The second factor still holds for a prefix.
+    test('a prefix from the WRONG sender is still refused', () => {
+      const delivery = mintFor('r-peter');
+      expect(interpretInbound(db, context(WIFE, delivery.token.slice(0, 3)))).toEqual({
+        action: 'rejected',
+        reason: 'wrong_sender',
+      });
+    });
+  });
+
   test('gibberish from a known sender is rejected as unrecognised', () => {
     expect(interpretInbound(db, context(PETER, 'what is going on'))).toEqual({
       action: 'rejected',
@@ -168,6 +260,125 @@ describe('interpretInbound', () => {
       });
     });
   });
+
+  /**
+   * Answering a deploy question.
+   *
+   * These ran against `parseInterviewAnswer` in isolation and all passed while
+   * the feature was dead in production (#533) — the alert grammar rejected
+   * every one of these bodies before the answer path was ever reached. They
+   * live here now, against `interpretInbound`, because the wiring is the part
+   * that was broken and the part worth guarding.
+   */
+  describe('a deploy question', () => {
+    const askFor = (routeId: string, targetId = 'evt-1') =>
+      mintDelivery(db, { kind: 'interview', targetId, routeId, now: NOW, ttlMs: TTL_MS });
+
+    test('takes everything after the token as the answer', () => {
+      const q = askFor('r-peter');
+      expect(interpretInbound(db, context(PETER, `${q.token} www.example.com`))).toMatchObject({
+        action: 'answer',
+        value: 'www.example.com',
+      });
+    });
+
+    test('is case-insensitive on the token', () => {
+      const q = askFor('r-peter');
+      expect(
+        interpretInbound(db, context(PETER, `${q.token.toLowerCase()} www.example.com`)),
+      ).toMatchObject({ action: 'answer', value: 'www.example.com' });
+    });
+
+    // An answer may legitimately contain spaces and punctuation. Second-guessing
+    // it would corrupt exactly the values that are painful to retype. This is
+    // the shape that was refused as `unrecognised` for months.
+    test('preserves an answer containing spaces and punctuation verbatim', () => {
+      const q = askFor('r-peter');
+      expect(
+        interpretInbound(db, context(PETER, `${q.token} my value: with, punctuation`)),
+      ).toMatchObject({ action: 'answer', value: 'my value: with, punctuation' });
+    });
+
+    // The word that must NOT acknowledge an alert is a perfectly good answer to
+    // a question. That the same text means different things is the whole reason
+    // the token is resolved before the grammar is chosen.
+    test('an answer that looks like a terminal verb is still an answer', () => {
+      const q = askFor('r-peter');
+      expect(interpretInbound(db, context(PETER, `${q.token} resolve`))).toMatchObject({
+        action: 'answer',
+        value: 'resolve',
+      });
+    });
+
+    test('a token with no value says so, rather than being unrecognised', () => {
+      const q = askFor('r-peter');
+      for (const body of [q.token, `${q.token}   `]) {
+        expect(interpretInbound(db, context(PETER, body))).toEqual({
+          action: 'rejected',
+          reason: 'needs_value',
+        });
+      }
+    });
+
+    // A verb-led message names no value, so it is not an answer.
+    test('a leading ack verb is not an answer', () => {
+      const q = askFor('r-peter');
+      expect(interpretInbound(db, context(PETER, `ack ${q.token}`))).toEqual({
+        action: 'rejected',
+        reason: 'unrecognised',
+      });
+    });
+
+    // Both factors still apply — a question is no less sensitive than a page.
+    test('an answer from the wrong number is refused', () => {
+      const q = askFor('r-peter');
+      expect(interpretInbound(db, context(WIFE, `${q.token} www.example.com`))).toEqual({
+        action: 'rejected',
+        reason: 'wrong_sender',
+      });
+    });
+
+    // Reported as `unrecognised` rather than `unknown_token`, and that is
+    // deliberate: `ZZZZZZ value` and `what is going on` are the same shape to
+    // celilo — a token-shaped word followed by text — because the token
+    // alphabet is most of the Latin one. Nothing corroborates that the leading
+    // word was meant as a token, so claiming the operator got a TOKEN wrong
+    // would send them hunting for a typo they may not have made.
+    test('an unknown leading token is not answerable', () => {
+      askFor('r-peter');
+      expect(interpretInbound(db, context(PETER, 'ZZZZZZ value'))).toEqual({
+        action: 'rejected',
+        reason: 'unrecognised',
+      });
+    });
+  });
+
+  /**
+   * The two grammars share a table, so the same body must mean different
+   * things depending on what the token names. Asserting both readings side by
+   * side is the guard against one of them quietly swallowing the other again.
+   */
+  describe('the two grammars do not bleed into each other', () => {
+    test('`<token> resolve` answers a question and REFUSES an alert', () => {
+      const question = mintDelivery(db, {
+        kind: 'interview',
+        targetId: 'evt-1',
+        routeId: 'r-peter',
+        now: NOW,
+        ttlMs: TTL_MS,
+      });
+      const alert = mintFor('r-peter');
+
+      expect(interpretInbound(db, context(PETER, `${question.token} resolve`))).toMatchObject({
+        action: 'answer',
+        value: 'resolve',
+      });
+      expect(interpretInbound(db, context(PETER, `${alert.token} resolve`))).toEqual({
+        action: 'rejected',
+        reason: 'unrecognised',
+      });
+    });
+  });
 });
 
 /**

package/src/services/alerting/inbound.ts

@@ -12,20 +12,52 @@
  * A message from an address matching no route is discarded and logged WITHOUT
  * a reply. Replying would confirm the number is live and that this is a celilo
  * instance, which is free reconnaissance for anyone probing.
+ *
+ * ── ORDER MATTERS: RESOLVE THE TOKEN, THEN PICK THE GRAMMAR ────────────────
+ *
+ * The same table carries alert pages and deploy questions, and they want
+ * OPPOSITE parsing. An alert reply is a token and at most a verb; anything
+ * wordier is refused, because `<token> resolve` silently acknowledging an
+ * alert the operator meant to escalate is the worst outcome here. An interview
+ * answer is a token followed by arbitrary text, because the text IS the answer.
+ *
+ * Parsing before resolving cannot serve both, and #533 is what that cost: the
+ * alert grammar ran first, read every real answer as a sentence, and rejected
+ * it before the poller could ever see it was a question. The feature was dead
+ * for months and the operator was told `unrecognised`, which reads as their
+ * typing being wrong.
+ *
+ * A delivery knows its own kind, so the token is resolved FIRST and the
+ * grammar chosen from what it named. Which rule applies was never a property
+ * of the text.
  */
 
 import { eq } from 'drizzle-orm';
 import type { DbClient } from '../../db/client';
 import { type NotificationDelivery, type Route, routes } from '../../db/schema';
-import { findLiveDelivery, normaliseToken } from './tokens';
+import { findLiveDeliveriesByPrefix, normaliseToken } from './tokens';
 
 /**
- * v1 grammar: a bare token acknowledges. `snooze` and `resolve` verbs are
- * deferred — ack is what an operator does at 3am, and every extra verb is
- * another thing to mistype under stress.
+ * v1 grammar: a token acknowledges. `snooze` and `resolve` verbs are deferred —
+ * ack is what an operator does at 3am, and every extra verb is another thing to
+ * mistype under stress.
  *
- * A bare `ack` with no token is accepted when the sender has exactly one
- * outstanding delivery, since the token adds nothing when there is no ambiguity.
+ * Deliberately forgiving about everything EXCEPT what the message means. An
+ * earlier cut accepted `<token> ack` but not `ack <token>`, so an operator who
+ * read "reply BPRJEH" and typed the natural "ack BPRJEH" was refused — the verb
+ * was parsed as the token, failed the length check, and the reply was rejected.
+ * That is a real page going unacknowledged over word order, so:
+ *
+ *   - the ack verb may come BEFORE the token, AFTER it, or not at all
+ *   - case never matters, for the verb or the token
+ *   - the token may be shortened to any unambiguous prefix (see below)
+ *
+ * `token` here is a CANDIDATE, not necessarily a whole token: resolution
+ * against what is actually outstanding happens in `interpretInbound`, because
+ * only the database knows which prefixes are unique right now.
+ *
+ * A bare ack with no token at all is accepted when the sender has exactly one
+ * outstanding delivery, since a token adds nothing when there is no ambiguity.
  */
 export type InboundIntent =
   | { kind: 'ack'; token: string }
@@ -33,37 +65,87 @@ export type InboundIntent =
   | { kind: 'unrecognised' };
 
 const ACK_VERB = /^(ack|ok|k|👍)$/iu;
-const TOKEN_SHAPE = /^[0-9ABCDEFGHJKMNPQRSTVWXYZ]{6}$/;
+/**
+ * One to six characters of the token alphabet. Not anchored to the full
+ * length: a prefix is legal input, and whether it identifies something is a
+ * question for the delivery table, not for a regex.
+ */
+const TOKEN_SHAPE = /^[0-9ABCDEFGHJKMNPQRSTVWXYZ]{1,6}$/;
 
 export function parseInbound(body: string): InboundIntent {
-  const trimmed = body.trim();
-  if (!trimmed) return { kind: 'unrecognised' };
+  const words = body.trim().split(/\s+/).filter(Boolean);
+  if (words.length === 0) return { kind: 'unrecognised' };
+
+  // Strip ack synonyms wherever they appear. What remains must be the token,
+  // or nothing at all.
+  const remainder = words.filter((word) => !ACK_VERB.test(word));
+  if (remainder.length === 0) return { kind: 'bare_ack' };
+
+  // More than one non-verb word is not a token with politeness around it, it
+  // is a sentence — and a sentence may be a request celilo does not implement.
+  // Guessing at it risks acknowledging an alert the operator meant to escalate:
+  // an earlier cut let `<token> resolve` silently ACK, so the operator believed
+  // they had cleared an alert that was still firing. Doing nothing and saying
+  // so is strictly better than doing the wrong thing quietly.
+  if (remainder.length > 1) return { kind: 'unrecognised' };
+
+  const token = normaliseToken(remainder[0]);
+  if (!TOKEN_SHAPE.test(token)) return { kind: 'unrecognised' };
 
-  if (ACK_VERB.test(trimmed)) return { kind: 'bare_ack' };
+  return { kind: 'ack', token };
+}
 
-  const [first, ...rest] = trimmed.split(/\s+/);
-  const token = normaliseToken(first);
-  if (!TOKEN_SHAPE.test(token)) return { kind: 'unrecognised' };
+/** A message that leads with a token, and whatever text followed it. */
+export interface TokenLedMessage {
+  token: string;
+  /** Everything after the token, trimmed. Empty when the token stood alone. */
+  rest: string;
+}
 
-  // A verb after the token must be an ack synonym or nothing. An earlier cut
-  // ignored the verb entirely, which meant `<token> resolve` silently
-  // ACKNOWLEDGED — the operator believes they cleared the alert and it is
-  // still firing. Doing nothing and saying so is strictly better than doing
-  // the wrong thing quietly.
-  //
-  // `resolve` and `silence` are terminal operations, not reply verbs (design
-  // D10): every extra verb is another thing to mistype at 3am.
-  if (rest.length > 0 && !ACK_VERB.test(rest.join(' '))) {
-    return { kind: 'unrecognised' };
-  }
+/**
+ * Split a message that LEADS with a token, or null if it does not.
+ *
+ * This is the interview grammar and it is deliberately not the alert one: the
+ * page says `reply <TOKEN> <value>`, and the value is whatever follows,
+ * verbatim. It may contain spaces, punctuation, or a word that happens to look
+ * like a verb — second-guessing it would corrupt exactly the values an operator
+ * cannot easily retype.
+ *
+ * `parseInbound` cannot serve both. Its "more than one non-verb word is a
+ * sentence" rule is what protects an ALERT from `<token> resolve`, and it is
+ * also what made every real interview answer unrecognised (#533): a value is
+ * a sentence by construction. Which rule applies is not a property of the text
+ * — it is a property of what the token names, and only the delivery table
+ * knows that. So both readings are produced here and `interpretInbound`
+ * chooses between them AFTER resolving the token.
+ */
+export function parseTokenLed(body: string): TokenLedMessage | null {
+  const trimmed = body.trim();
+  if (!trimmed) return null;
 
-  return { kind: 'ack', token };
+  const boundary = trimmed.search(/\s/);
+  const head = boundary === -1 ? trimmed : trimmed.slice(0, boundary);
+  const token = normaliseToken(head);
+  if (!TOKEN_SHAPE.test(token)) return null;
+
+  return { token, rest: boundary === -1 ? '' : trimmed.slice(boundary).trim() };
 }
 
 export type InboundOutcome =
   | { action: 'ack'; delivery: NotificationDelivery; route: Route }
+  /** An answer to a deploy question. `value` is the operator's text, verbatim. */
+  | { action: 'answer'; delivery: NotificationDelivery; route: Route; value: string }
   | { action: 'ignored'; reason: 'unknown_sender' }
-  | { action: 'rejected'; reason: 'unknown_token' | 'wrong_sender' | 'ambiguous' | 'unrecognised' };
+  | {
+      action: 'rejected';
+      reason:
+        | 'unknown_token'
+        | 'wrong_sender'
+        | 'ambiguous'
+        | 'unrecognised'
+        /** A question was named, but no value was supplied to answer it with. */
+        | 'needs_value';
+    };
 
 function routeForAddress(db: DbClient, senderAddress: string): Route | undefined {
   return db.select().from(routes).where(eq(routes.address, senderAddress)).get();
@@ -91,10 +173,9 @@ export function interpretInbound(db: DbClient, context: InboundContext): Inbound
 
   const intent = parseInbound(context.body);
 
-  if (intent.kind === 'unrecognised') {
-    return { action: 'rejected', reason: 'unrecognised' };
-  }
-
+  // A bare ack names no token, so there is nothing to resolve and nothing a
+  // question could be answered with. It is an ALERT reply by construction —
+  // `outstandingForRoute` supplies alert deliveries only.
   if (intent.kind === 'bare_ack') {
     const outstanding = context.outstandingForRoute(route.id);
     if (outstanding.length === 0) return { action: 'rejected', reason: 'unknown_token' };
@@ -102,11 +183,59 @@ export function interpretInbound(db: DbClient, context: InboundContext): Inbound
     return { action: 'ack', delivery: outstanding[0], route };
   }
 
-  const delivery = findLiveDelivery(db, intent.token, context.now);
-  if (!delivery) return { action: 'rejected', reason: 'unknown_token' };
+  // Both readings of the text, neither yet privileged. The alert reading is
+  // the more constrained one, so it names the token when it applies; otherwise
+  // a leading token does.
+  const led = parseTokenLed(context.body);
+  const namesAToken = intent.kind === 'ack';
+  const candidate = namesAToken ? intent.token : led?.token;
+
+  // Nothing token-shaped anywhere: not a reply celilo can act on.
+  if (!candidate) return { action: 'rejected', reason: 'unrecognised' };
+
+  // A prefix is resolved against what is LIVE right now, so how much of the
+  // token an operator must type depends on what is actually outstanding — one
+  // alert, one character. Matching is deliberately global rather than scoped to
+  // this route: it keeps `wrong_sender` a distinguishable answer below, and a
+  // globally-unique prefix is a stricter bar than a per-route one.
+  const matches = findLiveDeliveriesByPrefix(db, candidate, context.now);
+  if (matches.length === 0) {
+    // Ordinary words are token-shaped surprisingly often — the alphabet is
+    // most of the Latin one, so `what is going on` leads with a perfectly
+    // well-formed `WHAT`. Only call it a token the operator got WRONG when the
+    // alert grammar agreed it was one; otherwise this is a sentence, and
+    // saying `unknown_token` would send them hunting for a typo they did not
+    // make.
+    return { action: 'rejected', reason: namesAToken ? 'unknown_token' : 'unrecognised' };
+  }
+
+  // Ambiguous is its own answer, never a guess. Taking the first match would
+  // acknowledge an alert the operator did not name.
+  if (matches.length > 1) return { action: 'rejected', reason: 'ambiguous' };
+
+  const delivery = matches[0];
 
   // Factor two: a valid token replayed from a different number is refused.
+  // Checked before the grammar so a stranger learns nothing about which of the
+  // two a token names.
   if (delivery.routeId !== route.id) return { action: 'rejected', reason: 'wrong_sender' };
 
+  // NOW the kind is known, so the right grammar can be applied to the body.
+  if (delivery.kind === 'interview') {
+    // The value must follow the token the question was asked with; a verb-led
+    // message (`ack <TOKEN>`) names no value and is not an answer.
+    if (!led || led.token !== candidate) return { action: 'rejected', reason: 'unrecognised' };
+    // Named the question but supplied nothing to answer it with. Distinct from
+    // `unrecognised`: the operator got the token right and stopped too soon,
+    // and telling them that is the difference between retyping six characters
+    // and giving up.
+    if (!led.rest) return { action: 'rejected', reason: 'needs_value' };
+    return { action: 'answer', delivery, route, value: led.rest };
+  }
+
+  // An alert. The strict grammar applies, which is what keeps `<token> resolve`
+  // from silently acknowledging something the operator meant to escalate.
+  if (intent.kind !== 'ack') return { action: 'rejected', reason: 'unrecognised' };
+
   return { action: 'ack', delivery, route };
 }

package/src/services/alerting/interview-responder.test.ts

@@ -4,7 +4,6 @@ import {
   decideInterviewDelivery,
   describeQuestion,
   isRefusedFamily,
-  parseInterviewAnswer,
 } from './interview-responder';
 
 const headless = { hasTty: false, hasBidirectionalRoute: true };
@@ -98,37 +97,6 @@ describe('composeInterviewBody', () => {
   });
 });
 
-describe('parseInterviewAnswer', () => {
-  test('takes everything after the token as the answer', () => {
-    expect(parseInterviewAnswer('K7QM2X www.example.com', 'K7QM2X')).toBe('www.example.com');
-  });
-
-  test('is case-insensitive on the token', () => {
-    expect(parseInterviewAnswer('k7qm2x www.example.com', 'K7QM2X')).toBe('www.example.com');
-  });
-
-  // An answer may legitimately contain spaces and punctuation. Second-guessing
-  // it would corrupt exactly the values that are painful to retype.
-  test('preserves an answer containing spaces and punctuation verbatim', () => {
-    expect(parseInterviewAnswer('K7QM2X my value: with, punctuation', 'K7QM2X')).toBe(
-      'my value: with, punctuation',
-    );
-  });
-
-  test('an answer that looks like a verb is still an answer', () => {
-    expect(parseInterviewAnswer('K7QM2X resolve', 'K7QM2X')).toBe('resolve');
-  });
-
-  test('a token with no value is not an answer', () => {
-    expect(parseInterviewAnswer('K7QM2X', 'K7QM2X')).toBeNull();
-    expect(parseInterviewAnswer('K7QM2X   ', 'K7QM2X')).toBeNull();
-  });
-
-  test('a different token does not match', () => {
-    expect(parseInterviewAnswer('ZZZZZZ value', 'K7QM2X')).toBeNull();
-  });
-});
-
 /**
  * The families disagree on payload shape, and reading the wrong field means an
  * operator gets the raw event type instead of the question.

package/src/services/alerting/interview-responder.ts

@@ -136,23 +136,12 @@ export function composeInterviewBody(input: {
   return lines.join('\n');
 }
 
-/**
- * Extract the answer from an inbound reply.
- *
- * Everything after the token is the value, verbatim and unparsed — an answer
- * may legitimately contain spaces, punctuation, or something that looks like a
- * verb, and second-guessing it would corrupt exactly the values an operator
- * cannot easily retype.
- */
-export function parseInterviewAnswer(body: string, token: string): string | null {
-  const trimmed = body.trim();
-  const upper = trimmed.toUpperCase();
-  const normalisedToken = token.toUpperCase();
-  if (!upper.startsWith(normalisedToken)) return null;
-
-  const answer = trimmed.slice(token.length).trim();
-  return answer.length > 0 ? answer : null;
-}
+// `parseInterviewAnswer` lived here and is gone. It was correct and had the
+// tests to prove it, and it was never reachable: the caller only ran it for a
+// body the ALERT grammar had already accepted, which no real answer ever was
+// (#533). Extraction now happens in `interpretInbound` — the one place that
+// knows a delivery's kind before it parses — so the reply grammar exists once
+// rather than in two halves that could disagree.
 
 /** Severity an interview question is delivered at — never a page-worthy one. */
 export const INTERVIEW_SEVERITY: AlertSeverity = 'warning';