What
Two tools call POST /api/auth/tokens/anon and disagree about its response shape.
| tool |
file |
check |
download-template |
database.ts:190 / :243 |
requires accessToken to be a non-empty string (isAnonTokenResponse) |
get-anon-key |
docs.ts:140 |
no validation — formats whatever comes back as success |
Nothing in the repo pinned which was right: no test, no fixture, and the
backend source is not in this repo.
Settled by a live call
Driven against the deployed slug with a real project on 2026-08-01:
get-anon-key ok "Anon key retrieved successfully (deprecated route,
use GET /api/metadata/anon-key)" { "accessToken": … }
download-template ok "Template configuration ready…"
download-template succeeding is the proof: it only returns after
isAnonTokenResponse passes, which requires a non-empty accessToken. So the
backend does return accessToken, download-template is correct, and
get-anon-key is the lax one.
Why it still matters even though both currently pass
get-anon-key would report a malformed response as success. If the endpoint
ever changes shape — and see below, it is already deprecated — download-template
fails loudly with "Failed to retrieve anon key from backend" while
get-anon-key prints a cheerful success containing nothing usable. The failure
modes diverge exactly when a human most needs them to agree.
This is the same species as #104: a component asserting something a caller then
relies on, invisible until something makes a real call.
Also found by the same call
The live backend answers that route with "deprecated route, use
GET /api/metadata/anon-key". Both callers are on a deprecated endpoint, and
download-template is documented as "CRITICAL: MANDATORY FIRST STEP for all
new InsForge projects" — so the mandatory first step is the thing sitting on
the route that is going away.
Suggested
- Give
get-anon-key the same isAnonTokenResponse check, so both agree.
- Move both to
GET /api/metadata/anon-key before the deprecated route is
removed.
- A fixture pinning the response shape, so the next reader does not have to
spend a live credential to learn it.
Found while completing the token -> session -> tool call span against the slug.
What
Two tools call
POST /api/auth/tokens/anonand disagree about its response shape.download-templatedatabase.ts:190/:243accessTokento be a non-empty string (isAnonTokenResponse)get-anon-keydocs.ts:140Nothing in the repo pinned which was right: no test, no fixture, and the
backend source is not in this repo.
Settled by a live call
Driven against the deployed slug with a real project on 2026-08-01:
download-templatesucceeding is the proof: it only returns afterisAnonTokenResponsepasses, which requires a non-emptyaccessToken. So thebackend does return
accessToken,download-templateis correct, andget-anon-keyis the lax one.Why it still matters even though both currently pass
get-anon-keywould report a malformed response as success. If the endpointever changes shape — and see below, it is already deprecated —
download-templatefails loudly with "Failed to retrieve anon key from backend" while
get-anon-keyprints a cheerful success containing nothing usable. The failuremodes diverge exactly when a human most needs them to agree.
This is the same species as #104: a component asserting something a caller then
relies on, invisible until something makes a real call.
Also found by the same call
The live backend answers that route with "deprecated route, use
GET /api/metadata/anon-key". Both callers are on a deprecated endpoint, anddownload-templateis documented as "CRITICAL: MANDATORY FIRST STEP for allnew InsForge projects" — so the mandatory first step is the thing sitting on
the route that is going away.
Suggested
get-anon-keythe sameisAnonTokenResponsecheck, so both agree.GET /api/metadata/anon-keybefore the deprecated route isremoved.
spend a live credential to learn it.
Found while completing the token -> session -> tool call span against the slug.