Bring the sample response back on reopen, kept only for the life of the tab

[gabrieljablonski]

Reopening an HTTP tool threw the sample response away, so the path pickers were re-earned with a real call against the customer's API. Fixes #566.

What the base does, measured

Opened a tool with Cliente: {{cliente.nome}} saved and a sample pasted, saved it, reopened it on main:

• the sample field is empty;
• there is no preview at all, the whole Preview block is absent, so the template on screen cannot be checked from that dialog;
• the "Insert a field" button is not rendered either.

The issue described the first of those. The other two are worse than it claimed, and they are the reason this falls on the operator who is being careful.

The design, arrived at by two refusals

There are exactly two places a captured response could be kept, and review refused both, for two different reasons. The module header carries both, because together they are the design.

A redacted SHAPE in a column (rounds 1 and 2). The first draft answered the issue's own analysis (the pickers need paths; only the preview needs values) by storing the keys with every value replaced by a stand-in, so the pickers would work on any machine. Round 1 said a key is data too and was answered with a rule: drop every key outside ^[A-Za-z_$][A-Za-z0-9_$-]*$, subtree and all. Round 2 came back on the other leg of the same question and is right. That pattern refuses {"users": {"ana@example.com": …}} and accepts {"users": {"Ana": …}}, a map keyed by a first name, whole. No lexical rule separates a schema key from customer data, and a third heuristic would have been the third answer to one question. A path THROUGH a map resolves for exactly one customer anyway, so the column was paying a privacy question for an offer no operator could use.

The response in localStorage (round 3). docs/ui.md:201 carries a standing product rule that names this case in its own words: localStorage is not admissible for product data, and "History, save, remember, resume" belong to a backend with tenant_id and RLS. A captured response is content data and not a UI preference, and the caption I had written said "comes back the next time you open this tool" two hundred lines below the rule it was breaking. The reviewer's second point is the same defect from another side: a copy in storage outlives every deletion that does not go through this browser, so a tool dropped over REST or MCP leaves the customer's response behind.

So it is kept where the response already is while the modal is open: in memory, for the life of the tab, keyed by the tenant selector and the tool id, with the status it came back under, and written on SAVE rather than per keystroke so what comes back is the sample the tool was last saved with and not a draft that was abandoned.

question	answered by
the modal is closed and reopened, or the operator navigates away and back	the tab's memory, which still has it
a reload, a second tab, a second machine	nothing is offered, and "Send a test request" is the way back, exactly as today
does any of it get written down	no. Not in a column, not in localStorage, not in sessionStorage

The cost is stated rather than papered over, in the module header and in the caption the operator reads: "It is never saved: it stays open for as long as this tab is, and is gone after a reload." What it buys is that "we never store the customer's response" needs no qualification: no column, no per-tool opt-in, no backup question, no export rule, no retention policy, and nothing whose redaction a future reader has to re-derive before trusting it.

Live exercise, against this tree

Dev server on this worktree's tree, identified before anything was read: the served bundle carries the new caption and contains no @app:toolSample key.

Created a tool with the template Cliente: {{cliente.nome}} and this sample:

{"cliente":{"nome":"Ana Prado","cpf":"12345678901"},"pedidos":[{"id":9001}]}

• after the save, both stores dumped in full: localStorage holds @app:branding and @app:sidebar-width and nothing else, sessionStorage is empty. Neither the name nor the CPF is anywhere in either;
• reopen the modal → the response is back, the preview reads Cliente: Ana Prado, and "Insert a field" is there;
• navigate to Agents and back, reopen → still there;
• reload, reopen → the field is empty (the placeholder, not a value), no preview, "Send a test request" on screen, and the caption saying that is what a reload does. This is the cost, on screen, in the operator's own words.

An earlier round measured the other half of the invariant on the same seam and it still holds: the POST body of a real save carries no field about the sample, and neither the name nor the CPF appears in it.

What empties it, and both are fenced over the tree

• Deleting an HTTP tool clears its entry: a response left behind describes a row that is gone.
• A change of operator empties the whole map, which is a wider question than the logout button. A 401 on any request, the socket's auth-loss close and a /me that answers with a null user all end a session without one; and a shared cookie can move a live tab from operator A straight to B with no null in between, which asking about the null misses entirely. So the module is asked noteOperator(id), whether this is who it was, and AuthContext calls it unconditionally beside its single caller of setUser. Measured live for the session case, one tab, no reload (one navigation entry): saved a tool with a pasted response, signed out through the menu, signed back in, reopened the tool. Empty field, no preview. Not measured live for the A-to-B case, and the scope is worth stating rather than overstating: today the only consumer of this context's refresh is SetupPage, so an ordinary console does not observe B in a live tab without a reload, and a reload takes the map with it. The path exists on the context and a reload's boot goes through the same call, so the guard is unconditional rather than argued about.

The fence over the second one counts calls to the raw setUser and requires exactly one. It had asked for a spelling twice and been walked past twice: first the logout REQUEST, which a 401 and the socket do not make, then setUser(null), which setUser(data.user ?? null) is not. Both times the tree had another way of saying the same thing, and the sweep answered about the words.

A request is in flight for as long as the operator's API takes

Three review rounds found the same shape here: something the continuation reads at the end that had already changed while the request was out. So there is one value rather than a habit of capturing things. The ticket is the world as it was when the request went out: read before it, handed back to whatever mutates the cache afterwards, carrying the clock and the tenant.

The clock half. Both things that end a sample's life can happen while a save is out, and the response then arrives and writes it back in, undoing a deletion or a logout with a request that was already on the wire. Checked per SCOPE and not globally, because a global check over-rejects: deleting tool B while tool A's save is out would drop A's write too, and the operator sees a tool they never touched come back with an older response or none. A clock ticks on every forgetting, one mark records the last global clear and one per tool records its own; the per-tool marks are dropped on a global clear, since nothing older than one can be accepted anyway, which is also what keeps that map bounded.

The tenant half. keyFor used to read the selector at call time, and that selector lives in localStorage, shared across tabs and free to move mid-flight (activeTenant.ts says so in as many words). A save whose selector moved cached the response under a tenant nobody asked about; a delete cleared the wrong scope and left the deleted tool's response in memory. The reader still reads at call time, which is right (a render asks about the tenant on screen now); the writers take it from the ticket (a continuation asks about the tenant its request went out under).

Worth stating rather than letting it read as worse: ToolDefinition.id is a plain autoincrement on one table, so two tenants never share a tool id and a mis-keyed entry is unreachable rather than aliased. What was lost was the entry; what lingered was a deleted tool's response. The tenant in the key is depth, not the thing that stops one tenant's response reaching another, and the module header and the test that covers it both say so.

Two things make the ticket hard to get wrong rather than merely correct today:

• it is a required parameter at both sites. Optional, dropping the argument at the one call site survived the whole battery; required, tsc answers Expected 3 arguments, but got 2;
• what tsc cannot see is a call that reads it AT the write, or an await slipped in before the request. Both are questions about ORDER, so a fence asks them of the source, once per site: the read precedes the request, the write is handed a name and not a call, and the first suspension after the read is the request itself. That last one is what makes the ticket and the request see the same tenant selector, and it is measured rather than assumed: Eden evaluates its headers callback INSIDE the call expression, in the same synchronous block, and another tab's localStorage write becomes visible only at a task boundary. There is no boundary between the two reads, and an await added in between (which would look like an innocent refactor) now fails.

Also separated: deleting one tool and losing the session are two entry points (forgetToolSample, noteOperator), neither of them rememberToolSample(id, null). A save saying there is no sample is not a lifecycle event; the other two are, and only they invalidate what is in flight.

Tests

tests/client/tool-sample-persistence.test.ts (69) and tests/client/auth-logout-failure.test.ts (7), in eight parts: what the editor opens with; that nothing is sent and nothing is stored, the second asserted as a before/after snapshot of both stores rather than as "the store is empty", because the suite shares one global environment and other files leave entries behind, so emptiness would measure them and not this; what the tab remembers (round trip, oversize, nothing at all, a status that came back with an empty body, the eviction order, the tenant a request went out under, a browser that refuses storage entirely, one tool gone, the session gone, one operator becoming another); a save that lands after the sample's life ended, in every direction plus the control that it still writes when nothing relevant happened; and the source fences, each with a positive control.

A sample describes one version of a tool. Change a tool's URL or response contract from another tab, over REST or over MCP, and the id stays the same, which is exactly what an id-keyed cache matches on: the picker went on offering paths that describe nothing. The entry carries the row's updatedAt, the editor asks about the revision it just loaded, and a mismatch gets what a tool this tab has never opened gets. The revision stored is the one the SAVE returned, since the save is what moved it, and it is stringified at the boundary because the treaty TYPES that field as Date while the wire carries a string (the parseDate: false trap in docs/eden-treaty.md).

A status with no body is the sample that matters most. A test that came back 404 with nothing in it is what makes the runtime bypass the template, and a template reading no field previews perfectly well over an empty body. Dropped for having no text, the status went with it, and the reopened tool previewed that same template as APPLIED, under the box that promises exactly what the agent would receive. What counts as nothing is neither text nor status, and that judgement lives in the module alone: the rule used to be written twice, and the copy at the call site is what said something else.

Mutation battery: 68 mutations, 67 deaths, counting the type error as the kill it is. Among them: writing the sample into localStorage (the rule round 3 is about), evicting the oldest entry rather than the least recently saved, keying without the tenant selector, noteOperator not emptying or asking only about null, either mark failing to move the clock, a per-tool forgetting made global, the ticket ignored, the argument dropped at either call site, the ticket read inline at either write, the write or the delete reading the tenant selector on the way back, the key dropping the tenant, the module dropping an empty body that carries a status, the call site judging what to keep again, an await inserted before each request, the revision ignored on read or taken from the wrong place at the save, and each auth path going back to calling the setter directly. The control printed 0 fail first and the code files were byte-compared against their pre-battery state afterwards.

The battery also caught something about itself, which is why it is run every round rather than once: a fence had been deleted by a later edit that replaced the block around it, and two mutations of that call site went from dead to alive with nothing else saying so. A missing test looks exactly like a passing one.

bun check in the master worktree: 11015 pass, 4 skip, 0 fail, on a base that moved twice during the work (#574, #575); the branch was rebased onto it and the diff hash of its own changes was unchanged either side. The one battery survivor is equivalent and recorded as one: dropping the per-tool marks on a global clear cannot change an answer, because the global mark is checked first.

What empties it, continued

• A failed logout does not. The session cookie is HttpOnly, so only the response's Set-Cookie ends a session; clearing the console's user on a failure shows the login screen to someone still signed in, and a reload brings the session back for whoever is at the machine. Measured against the treaty with a fetcher that rejects: Eden reports a transport failure as a VALUE, { data: null, error }, and does not raise, so the previous shape (await, clear, with a catch) cleared on the common failure too. The rule is performLogout(post, endSession), a function taking its two effects, tested directly.

Two things about the tests that are worth more than the code they cover

performLogout is a function and not a rendered provider because two attempts to test it through one failed, each for a reason this repo should not learn twice:

• mock.module("@/client/lib/api", …) replaces the module for the whole test process, not the file. It took 237 tests in other files down with it, every one of them importing that client and getting a stub shaped for this one;
• with the transport stubbed at fetch instead (in beforeAll, restored in afterAll), the test passed alone and failed in the suite: another file mocks @/client/contexts/AuthContext the same way, so rendering the real AuthProvider here gets that stub.

And the mutation battery caught a fence that an earlier round's edit had deleted, by replacing the block around it: two mutations of that call site went from dead to alive with nothing else saying so. A missing test looks exactly like a passing one, which is why the battery is run every round rather than once.

What the marker says, and how many ways it was wrong

A sample describes ONE version of a tool, so the entry carries the row's updatedAt and a mismatch discards it. But the revision alone cannot answer the question, because the save is what sets it: a response captured against one URL, followed by an edit to the URL, the method, the headers, the body, the query or the credential, passes that check by construction. So the editor also records what the sample DESCRIBES — requestShapeOf over the part of the definition that decides which response comes back, as an EXCLUSION list whose direction is the point: a field added later counts as response-affecting until someone says otherwise.

That marker was maintained by hand at four sites, and review found two of them wrong at once, which is why it is one rule (shapeOfArrival) with the four arrivals as a table in the test rather than four call sites:

• a sample restored from this tab's memory recorded no definition at all, so the refusal above lasted exactly as long as the modal stayed open: reopen, change the URL, save, and the old response was stamped with the new revision;
• Format re-recorded the definition on screen NOW, so pretty-printing after an edit erased the mismatch;
• a status with no body recorded nothing either, because the emptiness test was spelled here instead of asked of the module — the same defect as the round before it.

And credentialRef is a NAME. What it resolves to is a row in the vault, which the picker inlined in this very modal can edit: the tool's updatedAt never moves, the payload is byte for byte the same, and a relative urlTemplate now resolves against another host (credential-wiring.ts does the joining) with another authorization. So the marker carries the vault's own revision too — only for a payload that names a credential, since prefixing it unconditionally made any credential saved anywhere in the console refuse a sample nothing could have invalidated, and the vault's OWN revision rather than a count of announcements, since refreshVault announces twice for one change.

What empties it, continued

• A failed logout does not. The session cookie is HttpOnly, so only the response's Set-Cookie ends a session; clearing the console's user on a failure shows the login screen to someone still signed in, and a reload brings the session back for whoever is at the machine. Measured against the treaty with a fetcher that rejects, Eden reports a transport failure as a VALUE, { data: null, error }, and does not raise, so the previous shape (await, clear, with a catch) cleared on the common failure too.
• And a failed logout does not navigate either. Both callers went to /login on any resolution, and LoginPage sends a signed-in visitor straight to redirectTo: the account menu cost the operator the route they were on, and "Switch account" on the consent screen came back as the same operator, both without a word on screen. performLogout answers whether the session ended and afterLogout is what the two buttons do with that answer, as a value, because an if written at two call sites survives anything a source fence can ask (measured: one reading if (!ended && false) walked past the battery).

Two things about the tests that are worth more than the code they cover

Both logout rules live in src/client/lib/logout.ts and not in AuthContext, because two attempts to test them through the provider failed for reasons this repo should not learn twice:

• mock.module("@/client/lib/api", …) replaces the module for the whole test process, not the file. It took 237 tests in other files down with it;
• with the transport stubbed at fetch instead, the test passed alone and failed in the suite: another file mocks @/client/contexts/AuthContext the same way, so anything imported from there is a stub in every suite that mock reaches.

And the mutation battery is what found four things the review did not: a fence an earlier round's edit had deleted (two mutations of that call site went from dead to alive with nothing else saying so), the save that CLEARED the sample field never reaching the module, the credential taken from the form instead of the payload, and the deletion mark that has to beat a save which started after the delete went out. A missing test looks exactly like a passing one.

Two findings from review are deliberately not fixed, and both are written down

Neither is a defect this PR introduces; each is a property of a layer underneath it, and each would be half-closed by a fix scoped to this feature. Both are in docs/roadmap.md with the measurement, why it is not this PR's, and the shape of the fix.

A tab whose cookie changed to another operator learns nothing about it (raised in rounds 9, 12, 15 and 17). Measured: after boot nothing revalidates /me on focus or visibilitychange, and no event is broadcast. Such a tab already shows A's name, A's tenant selection and A's permissions while every request it sends is authenticated as B — wrong in every way a tab can be wrong before any cache is involved. The fix is broadcasting session changes or revalidating on focus, which changes the auth model for every screen.

A vault change made in another window is invisible to this one (round 16). VAULT_CHANGED_EVENT is a window event from the window that made the change, and editing a credential does not move the tool's updatedAt. The sample cache is the FOURTH consumer of that gap, not the first: the same window shows the stale base URL under the URL field, judges relativeWithoutBase on it, answers useVaultBaseUrls from it, and sends test requests against it. Closing it needs a server-visible revision that listVaultInfos does not select today, plus an ordering change in how the editor opens.