The Trust Contract

Same everywhere: what an action means, who is asking, what they may touch, when a human must say yes, and what gets written down afterward.

Different on purpose: the UI previews and confirms visually. The CLI is terse and scriptable. The API is strict and stable. MCP describes every tool in plain text, because text is all an agent gets.

Trackly runs an iOS and macOS app, a web app, a versioned API, an npm CLI, a local MCP server, and a hosted OAuth MCP server, across 170K+ jobs at 3,800+ companies, plus a packaged plugin in marketplace review. I built the parts that keep those doors honest with each other: shared schemas, one approval model, one auth story, one telemetry boundary. The rest of this page is the times that was hardest.

One catch. The backend applies this filter only to the fresh job feed, never to jobs you already saved. It refuses to hide a saved job behind your back: a saved card keeps showing the text you saved it with, while verdicts keep getting re-checked in the background, and the two can disagree.

So when a caller asks for the filter without naming a view, the CLI and MCP add status=new ("fresh feed only") on their own. Without that, --sponsorship exclude_no by itself would come back completely unfiltered while you believe it worked. You asked for a filter, so the client either applies it for real or narrows the request until it can.

The same trap exists in one SQL operator: NOT (status = 'no') also throws away every job with no answer, because comparing against a missing value returns "unknown," not false. That is "silence becomes a No" in a single line of code. The shipped predicate guards it with CASE ... ELSE FALSE and a test that locks it in.

Early on, the MCP schema accepted locationFilter: ["us","non_us"]. Perfectly valid to the schema. The backend silently dropped what it did not understand and returned US-only jobs: the exact opposite of the ask, delivered with HTTP 200 and a plausible-looking list. Four review bots flagged it in the same week. The fix rejects the combination at the schema, so the agent gets a visible error instead of a confident wrong answer (cli #14). The sponsorship model above went through the same discipline in cli #65 and #112: make the schema tell the truth about the backend, including the uncomfortable parts.

It is built on PostHog's MCP SDK with the transport swapped out. The npm package holds no project key (a write key in a public package is an unrotatable credential in everyone's node_modules) and no user ID; each process mints a random anonymous ID. Events go to Trackly's backend, which treats its own shipped client as untrusted: it re-sanitizes everything from scratch, so an old or forked CLI cannot widen the privacy boundary. The backend attaches identity server-side, signs every event, and forwards it to PostHog. Signing matters because PostHog's collection endpoint is public: unsigned usage numbers are vibes, signed ones are evidence. And only 6 of the 55 tools may carry payloads at all, every one a public-data read. A new tool is private by default.

First verified reading: 114 signed events from 7 authenticated users, cleanly split local vs hosted. My favorite part: the first automated recommendation refused to fire. It had 9 latency samples against its own 20-call minimum, so it stayed monitor-only. The measurement system holds itself to the same evidence bar the agents get held to (close-ai #1440, #1461, #1523, #1535 · cli #103, #110).

When we need a production diagnostic, there is no box to type SQL into. Anywhere. There are four pre-approved questions, ordered by number, like dishes on a fixed menu. Adding a fifth means a code review, not a text field.

Ordering one is deliberately heavy: you type a confirmation phrase, and the question runs in a throwaway machine that first double-checks it is connected to the right database as the read-only account. The answer format only has room for numbers and a few fixed labels, so actual data rows physically cannot come back through it. And every run leaves a record: who asked, which question, on exactly which version of the code (close-ai #1372).

During login, an MCP client sends a "resource" value: the address its access key is allowed to work at. Pinning a key to one address is what stops a stolen key from being replayed somewhere else. That value is the delivery address of the story above, and the key is the package.

Some real clients, due to bugs, sent that value twice in one request. Reject them all, strictly by the spec, and those users cannot log in at all. Quietly take the first copy, the friendly fix, and you have also decided to "take the first copy" on the day the two copies differ, which is the attack. The shipped rule sits in between: if every copy is non-empty and byte-for-byte identical, treat it as one. If they differ, or any is empty or malformed, refuse the login (close-ai #1598, cli #113).

The line: fix the stutter, never the disagreement. Compatibility code may remove noise; it may never remove a warning sign.

An action class climbs a rung when its numbers stay boring: task success, guardrail compliance, escalation accuracy, verification quality, and recovery performance, all stable for that scope. It climbs back down when drift, overrides, or near misses cross a threshold. Demotion is not a failure of the program. Demotion is the program.

Everpure's public material frames Pure1 as the intelligence and Fusion as fleet-wide action. Fusion MCP starts observability-first, with preview-first plans and explicit approval described for later phases. SafeMode already trained their customers to expect multi-party authorization and recoverability. The grammar on this page lands on that roadmap almost word for word. This is a candidate sketch, not a claim about their internal plans.

Current and proposed placement. Affected arrays and volumes. Capacity and performance headroom after the move. Replication, RPO, and RTO impact. The change window. Reversibility and the recovery point. Who must approve. A retry-safe key. The checks that verify success. The immutable receipt.