Lossless Changelog
fleet

didi.sh — the three services get a platform: one login, one agent, and an identity-service spec

We bought didi.sh and decided what converges on it: exactly two shared planes — a central identity service (one account, SSO via a .didi.sh cookie) and a shared agent named didi that loads skills per task. The identity service is specced to implementation depth, on an Elixir/Phoenix stack, with augment-it and its two waiting client teams as the first consumer.

Michael StatonMusic Editoraugmented with Claude Code on Claude Fable 5

Why Care?

memos (memopop-ai), decks (dididecks-ai), and augment-it were built organically as independent tools for venture-capital work. Two client teams — reach-edu and humain-vc — now want to log in and use them. Today the family got its coordinating decision: the tools stay independent point solutions (GTM: people search for a deck designer or a memo generator, never a platform), but exactly two things converge on the newly-purchased didi.sh — shared identity and a shared agent. Nothing else.

What Happened

A planning arc across four documents, each building on the last:

  • [[Two-Clients-One-Flow-Corpora-Auth-and-Deployment-Converge]] mapped the week's convergence: both clients need the same flow (corpus by domain-type → memos + decks), both teams want logins, and the anticipated forcing-functions — typed domains, auth, deployment, corpus substrate — all fired at once.

  • [[Didi-sh-One-Login-One-Agent-Three-Services]] committed the platform shape: a .didi.sh session cookie makes true SSO cheap (flipping Shared-Auth's Fork 1 on exactly the trigger it named in advance), and didi the agent rides the existing In-App-Agent architecture, adding a persona, a task-loaded skill library, and cross-service continuity. A GTM revision made the identity service headless-first: accounts are created from inside the app the user arrived at — the service owns the pixels, the identity service owns the record. Clarifications pinned the boundaries: shared-session ≠ federated login, domain topology ≠ repo/deploy topology (no rearchitecture — each service keeps its independent deploy behind a DNS record), and one cookie = one trust boundary (nothing untrusted ever runs on *.didi.sh).

  • [[Id-Didi-Sh-Identity-Service]] specs the service to implementation depth: signed EdDSA cookie tokens verified locally by every consumer, invite-only accounts, magic-link + OAuth pathways, the domain-as-id org model carried over from Shared-Auth, a LiveView admin console, and six implementation increments starting with a walking skeleton and augment-it as first consumer. Stack: Elixir/Phoenix — the one service in the estate where the implementation language is invisible by design (consumers see only HTTP, a cookie, and a public key), and Phoenix 1.8 generates magic-link auth as its default.

Also today, on the augment-it side: the Strategy Curator spec corrected content_url semantics (an alternate fetch URL still downloads — remote PDF URLs rot) and queued domain-type selection in the UI, unblocking humain-vc's thesis-typed corpus (its first domain was mis-filed under strategies/ because the UI only speaks one noun).

What's Next

The identity service's increment 1 (Phoenix walking skeleton: magic-link → cookie → offline verify → /api/me), the domain-type UI in the Strategy Curator, and the augment-it deploy plan that carries id.didi.sh to a real DNS record — at which point reach-edu and humain-vc get their invites.