Skip to content

test(telegram): pin that the route uses the service's shape answer, and name the hex arm honestly (TASK-159 follow-up) - #1939

Merged
lilyshen0722 merged 1 commit into
mainfrom
kai/task159-followup
Sep 27, 2026
Merged

lilyshen0722 merged 1 commit into
mainfrom
kai/task159-followup

Conversation

@lilyshen0722

Copy link
Copy Markdown
Contributor

Both items from Vera's review of #1937 (74641), as a follow-up cut from the merged main (1defa900) rather than a moved head — so her clearance of 3cde635f stood and she was owed no re-gate. Test-only, two files.

(a) An arm that claimed a derivation it cannot witness

draws its width from the same constant as the minter asserted mintConnectCode().connectCode has CONNECT_CODE_BYTES * 2 characters — true by construction, because hex of N bytes is always 2N characters. It survived every constant mutation (20 bytes, 3 bytes, the {32} drift), so a reader would think the derivation is witnessed twice when it is witnessed once.

Renamed to what it pins, with the assertion that makes the title true:

it('mints hex, so the code is twice CONNECT_CODE_BYTES wide', () => {
  const { connectCode } = mintConnectCode();
  expect(connectCode).toMatch(/^[0-9a-f]+$/);
  expect(connectCode).toHaveLength(CONNECT_CODE_BYTES * 2);
});

The hex assertion is exactly what Vera's mutation (toString('hex') → toString('base64')) reddens; the comment records that the derivation claim belongs to accepts what the minter produces and refuses one character either side.

(b) The route asked the service but did not have to use its answer

The #1937 arm asserted isConnectCodeShape was called with the normalised code. A belt-and-braces drift — call the service, then also apply a local regex — stayed green. New arm:

it('lets the service answer decide, rather than re-checking the code itself', async () => {
  Integration.findOne = jest.fn().mockResolvedValue(null);
  isConnectCodeShape.mockReturnValueOnce(true);
  await enable('not-a-connect-code');
  expect(registerEnableAttempt).toHaveBeenCalledTimes(1);
  expect(Integration.findOne).toHaveBeenCalledTimes(1);
});

Mocking the service to admit a malformed code must let the lookup proceed. Re-checking the code in the route refuses instead and reddens — measured as M1 below.

Ledger — 3 mutations, baseline and restore 25/25

mutation red
the route re-checks the code locally as well as asking the service 1 — lets the service answer decide…, alone
the minter stops emitting hex 3 — the renamed mints hex… arm, accepts what the minter produces…, and the pre-existing literal pin on minted output
the predicate always refuses (control) 12 — the whole route path, so the new arm is not sitting on a dead call site

No survivors. The control is deliberate: an arm that mocks the predicate can pass because the route never consults it, so M3 shows the path it gates is live.

Scope

  • Two test files, no source change. telegramConnectCode.test.js +3/−2; telegram.webhook.connectCode.test.js +13.
  • Verified: 2 suites / 25 tests green; 0 diagnostics on added lines (the import/extensions pair on the suite's requires is ambient — 9 such diagnostics in that file for the same shape).

Gate: Vera.

…nd name the hex arm honestly (TASK-159 follow-up)

Vera's 74641 review of #1937 left two items; both are here rather than in a moved
head, so her clearance of `3cde635f` stood.

(a) `draws its width from the same constant as the minter` survived every constant
mutation, because hex of N bytes is always 2N characters — it claimed a derivation
it cannot witness. Renamed to what it pins and given the assertion that makes the
title true: the minted code matches `^[0-9a-f]+$`. The derivation claim is carried
by `accepts what the minter produces and refuses one character either side`, and
the arm now says so.

(b) The route-side witness pinned WHERE the shape answer comes from, not that the
answer is USED: a belt-and-braces drift — ask the service and then also apply a
local regex — stayed green. New arm mocks `isConnectCodeShape` to admit a
malformed code and asserts the lookup proceeds, so re-checking the code in the
route reddens.
@lilyshen0722
lilyshen0722 added this pull request to the merge queue Sep 27, 2026
Merged via the queue into main with commit 97f1aa6 Sep 27, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant