fix: every write tool reports durability; resolve_thread stops claiming success (GIT-101)

[nTEG-dev]

What

Every write tool now says whether its write is durable, and resolve_thread stops claiming success it doesn't have (GIT-101).

• WriteResult { success, durable, stored_in } (src/types/index.ts, helpers in src/services/write-result.ts) is create_thread's contract, now shared by every write tool:
  • durable: the record is in Supabase. Never true on free.
  • stored_in: "supabase", "local" (free), "local_only" (pro, durable write failed, local copy kept) or null (stored nowhere).
  • success = durable || !hasSupabase(), and false whenever nothing was stored.
• Applied to create_learning, create_decision, create_thread, resolve_thread, archive_learning, record_scar_usage, record_scar_usage_batch, session_close, promote_suggestion (passes create_thread's outcome through) and save_transcript. Their result types extend WriteResult, so the compiler made every return state its outcome.
• resolve_thread on pro without a durable write returns success: false, durable: false, stored_in: "local_only", and its display says RESOLVED LOCALLY ONLY — not durable … other sessions still see t-… as open.
• session_close reports on every exit whether the session row reached the store, including a failure that happens after the row landed. A partial close (a thread didn't sync) is durable: true, success: false: the row is saved, the close isn't complete.

Why

resolve-thread.ts computed supabaseSynced, logged it to metrics and then returned success: true regardless. A resolve the durable store never saw looked done, while every other session still saw the thread open.

How to test

One parameterized test (write-result-contract.test.ts): pro tier, Supabase configured, and every request to it fails at fetch. For each of the 10 tools it asserts:

• the store was actually tried;
• success: false, durable: false;
• the right stored_in (local_only for create_thread, resolve_thread and promote_suggestion; null for the rest);
• the display carries the same verdict (fail|not stored|not durable|locally only). Over MCP, server.ts sends only display when one exists, so the fields alone never reach the agent.

	origin/main	This branch
Contract test	10 of 12 fail. resolve_thread: success: true with the store unreachable; display "Thread resolved".	12/12

Venue (v1.8.0 setup.sql, vujndhcumgroztfkkdus; production not touched): flow now creates a second thread, resolves it, and reads gitmem_threads back: status: resolved, display "Thread resolved", no "LOCALLY ONLY". The success side lands on a customer-shaped store; resolution_note and resolved_by_session exist in v1.8.0. Exit 0; close persisted; thread counts match; only GIT-73 and GIT-105 seen (the GIT-105 400 is the resolve's triple write, which item 7 addresses).

Unit tests: 1286/1286 pass (+12). No existing test encoded the old behaviour.

Left out on purpose (flagging)

• absorb_observations, dismiss_suggestion, contribute_feedback: they write session state or local files by design, not the durable store. Observations reach the store with session_close.
• cleanup_threads: a report with an optional archive. archiveDormantThreads swallows errors and returns 0, so "nothing dormant" and "archive failed" look identical. Giving it a WriteResult means changing that service first. That would be a separate ticket.
• Free-tier record_scar_usage_batch stores nothing (it defers to the single-record tool) and has always returned success. It now says stored_in: null alongside success: true (no durable store to miss). That's the one place success and stored_in: null coexist.
• record_scar_usage_batch, partial: if some inserts land and one throws, it still reports notStored. The per-row outcome isn't tracked yet.

Checklist

• npm run test:unit passes (1286)
• New tests added (parameterized across all 10 tools)
• No schema change; verified on a v1.8.0 store
• Docs: tool reference doesn't document result fields

Breaking changes

resolve_thread (and the others, whose failure paths already said so) now return success: false when the durable write didn't land on pro. That's the fix. New fields durable and stored_in are additive.

🤖 Generated with Claude Code