From 2bd2d6a160b61c8a2a4a121c87ecd77ef1ff5b6c Mon Sep 17 00:00:00 2001
From: iacore <noreply+gpg-stub@1a-insec.net>
Date: Sun, 2 Aug 2026 17:41:27 +0800
Subject: [PATCH] S017-S021 logs: PWA parity, invites, prod deploy, external
 sign-in, bootstrap scope fix

- s017: PWA feature parity (multi-space, members, edit/move/delete, export) + per-user data rights
- s018: space invite links end to end + gruvbox UI redesign
- s019: production deploy on Fly.io (zds.linji.at + app0.linji.at)
- s020: external sign-in (any atproto handle) + handle-resolution bug addendum
- s021: bsky bootstrap 403 - request rpc scope for service-auth minting
- roadmap: mark S017-S020 done, update dogfood note
---
 log/s017.dj |  69 +++++++++++++++++++++++++++++++++
 log/s018.dj |  80 ++++++++++++++++++++++++++++++++++++++
 log/s019.dj |  67 ++++++++++++++++++++++++++++++++
 log/s020.dj |  98 +++++++++++++++++++++++++++++++++++++++++++++++
 log/s021.dj | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 roadmap.dj  |  18 ++++++++-
 6 files changed, 439 insertions(+), 1 deletion(-)
 create mode 100644 log/s017.dj
 create mode 100644 log/s018.dj
 create mode 100644 log/s019.dj
 create mode 100644 log/s020.dj
 create mode 100644 log/s021.dj

diff --git a/log/s017.dj b/log/s017.dj
new file mode 100644
index 0000000..69f8a06
--- /dev/null
+++ b/log/s017.dj
@@ -0,0 +1,69 @@
+# S017 — PWA feature parity + per-user data rights (2026-07-31)
+
+## Context
+
+The web app could only read/move in one hardcoded space. Meanwhile the CLI
+had grown: multiple spaces, create space, member management, edit/delete of
+posts, thread export — plus account export/delete existed only as zds
+endpoints. The user asked for per-user data rights (own-data export +
+deletion) **before** demoing to the 同喜 class community; multi-space
+support is needed anyway, so ship both in one PWA pass.
+
+## What changed
+
+**BFF (`app0/src/server.zig`, `core/spaces.zig`, `core/push.zig`)**
+- `GET /api/spaces` — caller's spaces; space accounts see `owned`; others
+  see the BFF-configured community space if a member.
+- `POST /api/space` — create space `{name?}` → `{uri}`.
+- `GET /api/space/members?space=` — owner-gated roster.
+- `POST /api/space/add-member` / `/api/space/remove-member` — owner-gated.
+- `GET /api/account/export` — JSON of the caller's own records across
+  every space they belong to (`{did, handle, exportedAt, spaces[]}` with
+  their threads and posts). NOTE: mvp.dj (revised 2026-07-31) now says
+  data export should live in a separate program and "the API deliberately
+  does not own export" — this endpoint satisfies the user's direct request
+  and matches the doc's export *shape* (own records, as JSON), but is
+  interim until the standalone export program exists.
+- `POST /api/account/delete` — deletes the caller's own posts and threads
+  from every space they belong to (their records only; other members'
+  records — including replies to them — are untouched), prunes their push
+  subscriptions, and ends the session. The account itself is preserved:
+  the user can log straight back in to an empty slate. Returns
+  `{posts, threads}` counts.
+- `deletePost` now routes through a generic `deleteRecord` (collection
+  parsed from the record URI) — CLI `delete` and `move --delete` work for
+  threads too, not just posts. `collectionFromUri` handles both the
+  canonical and the space-qualified URI forms.
+
+**Web (`app0/web/`)**
+- Sidebar: auto-listed spaces (no paste-URI-to-enter), owner ★, create
+  space (name input), join by URI, per-user account controls (export →
+  `.car` download; delete → irreversible, full-page confirm).
+- Space page: thread list + thread composer for everyone; owner gets a
+  manage-members panel (roster, add by handle, remove) and a 导出
+  (markdown thread export) action; posts show author/time; 编辑 / 移动 /
+  删除 per post (delete own; all actions when authority).
+- Route `#/s/<space>` now takes any space URI; entering a space persists
+  it to localStorage so it survives relogin.
+
+## Verification
+
+- `zig build test`, `zig build scenario-space` (member-only space) — PASS.
+- `zig build scenario-serve` — extended checkpoints incl. sections
+  6d (spaces listing + create + members owner-gating), 6e (move via API,
+  thread export), 6g (account-data export JSON; delete cascades: session
+  401, own records gone from spaces, others' records survive, account
+  still able to log in and post afterwards) — PASS.
+- `bun run test` — 35 vitest (FakeBff parity for every new endpoint) — PASS.
+- Real-browser smoke against a live rig: login → sidebar spaces/★/create/
+  join/account links → thread view with 编辑/移动/删除 → owner members
+  panel with roster/add/remove.
+
+## Not in slice
+
+- Account (identity) deletion — only the user's linji records are deleted;
+  the DID/handle and PDS account survive. mvp.dj's "messages, then the
+  account" second step is deliberately not here: zds account deletion is
+  dev-tools-only and DID-censoring; production needs a real flow.
+- Standalone export program (mvp.dj 2026-07-31) — see note above.
+- Webauthn/passkey, markdown rendering in posts.
diff --git a/log/s018.dj b/log/s018.dj
new file mode 100644
index 0000000..fa7cef4
--- /dev/null
+++ b/log/s018.dj
@@ -0,0 +1,80 @@
+# S018 — space invite links + UI redesign (2026-08-01)
+
+## Context
+
+S017 gave the PWA full space CRUD, but the only way in was owner-side
+add-member (you must already know the member's handle/DID) — no way to
+hand a prospective member a link, which is how the 同喜班 class actually
+invites people. Meanwhile the UI was still the S010 accordion with
+Chinese copy and a dark-only theme; dogfooding needs something calm and
+presentable on phones.
+
+## What changed
+
+**zds (`src/atproto/space.zig`, `src/http/router.zig`)**
+- `com.atproto.simplespace.inviteInfo` — non-member-safe invite preview.
+  Validates in contract order (not-found → wrong-space → wrong-authority
+  → expired) reading the invite record through the store, bypassing the
+  space read ACL; returns `{valid, space, skey, inviter, inviterHandle,
+  expiresAt}` or `{valid:false, reason}`. Scope-gated only.
+- `com.atproto.simplespace.join` — redeem. Same validation (403
+  InviteInvalid with a `reason` field), idempotent member add, and the
+  `at.linji.join` event written into the joiner's repo via the normal
+  createRecord path. Deliberately NOT behind requireSpaceAccess — the
+  invite record IS the authorization.
+- Both registered in the HTTP router table: the space.zig dispatch arms
+  alone are unreachable — router entries are what route requests.
+
+**BFF (`app0/src/server.zig`, `core/spaces.zig`)**
+- `POST /api/space/invite` `{space, expiresAt}` → `{uri, url, expiresAt}`.
+  Owner-only: `createInvite` refuses non-authority callers up front —
+  member-minted invite records would be inert anyway (zds join requires
+  inviter == authority), so allowing them only writes confusing data.
+- `GET /api/invite?space=&invite=` and `POST /api/space/join` — zds
+  passthrough. Passthrough bodies are duped to `req.arena`: httpz writes
+  the response after the handler returns, and scratch-arena bodies were
+  an EFAULT crash in writev.
+- The invite record carries `$type` — zds's `validateRecordForWrite`
+  hard-requires `$type == collection` for any record written to a space.
+
+**Web (`app0/web/`)**
+- Full redesign: gruvbox light + dark (system preference, toggle in the
+  account menu), sidebar shell + single stream + thread chips, sticky
+  composer, hover actions, native `<dialog>` modals, mobile drawer +
+  scrim. English copy throughout (international-first).
+- Invite UX: owner's Invite dialog (24h / 7d / 30d expiry → copyable
+  `#/join/<space>/<invite>` link); recipient side: logged-out landing
+  banner → sign in → join screen preview (space, inviter, expiry; human
+  reasons for expired / not-found / wrong-space / wrong-authority) →
+  Join → lands in the space. The add-space dialog also redeems pasted
+  invite URLs.
+- Bug-class fixes found by the rewritten test suite + browser pass:
+  Solid dialog reactivity (uniform open-prop + createEffect pattern —
+  body-run sync, `props.ref.close()`, and the nonexistent `show` event
+  all silently did nothing), JoinScreen `Show` narrowing, composer
+  default-thread one-shot (`touched` flag), sign-out reload race,
+  Chromium's `flex-direction: column` UA quirk on `<button>`.
+
+## Verification
+
+- zds: `zig build test -Dtarget=x86_64-linux-gnu.2.36` — 118/118 (+8
+  invite tests: URI shape, rfc3339, join writes record, expired,
+  wrong-authority, wrong-space, idempotency, preview).
+- app0: `zig build scenario-serve` — PASS; new section 6h: non-owner
+  invite create 403, owner create (uri/url/expiresAt), preview valid +
+  bogus, join → spaces list / read / post as the new member, idempotent
+  rejoin (`alreadyMember`), bogus join 403.
+- Web: `bun run test` — 52/52 vitest (was 35; FakeBff mirrors zds's
+  invite validation order; join flows incl. all four invalid reasons).
+- Real browser on a live rig: alice creates a link in the UI → dave
+  (logged out) opens it → banner → sign in → preview → Join → lands in
+  the space → creates thread 欢迎 and posts. Light + dark themes and the
+  390px mobile drawer visually checked.
+
+## Not in slice
+
+- Invite revocation UI (deleting the invite record — CLI/API only).
+- Expired-invite E2E in the scenario (zds unit tests cover the reason;
+  vitest covers the UI copy).
+- Space metadata beyond the skey (display name, description) in invites
+  and the sidebar.
diff --git a/log/s019.dj b/log/s019.dj
new file mode 100644
index 0000000..77ee32f
--- /dev/null
+++ b/log/s019.dj
@@ -0,0 +1,67 @@
+# S019 — production deploy: zds.linji.at + app0.linji.at on Fly.io (2026-08-02)
+
+## Context
+
+Milestone 001's "done when" names app0.linji.at as the dogfood surface,
+but until now everything ran on the loopback rig. This slice put the
+two-process stack on Fly.io with real domains, real certs, and real
+did:plc identities — and ran the whole invite flow against it.
+
+## What changed
+
+**Deploys**
+- `zds-linji` fly app (sin): zds PDS at https://zds.linji.at,
+  `did:web:zds.linji.at`, handles `*.zds.linji.at`, invite-required,
+  permissioned data on. Volume `zds_data`; secrets ZDS_ADMIN_TOKEN,
+  ZDS_PLC_ROTATION_KEY (real PLC writes).
+- `linji` fly app (sin): BFF + built PWA at https://app0.linji.at.
+  Volume `linji_data`; secret LINJI_INVITE (login gate).
+- zds/fly.toml retargeted from pds.zat.dev (upstream's instance — probed:
+  no simplespace endpoints) to zds.linji.at; app0/fly.toml gained
+  LINJI_BASE/LINJI_PDS/LINJI_HOST.
+
+**app0 fixes found by the deploy (each verified in prod)**
+- build.zig.zon: zat dep moved from local path to the tangled archive URL
+  (`linji.at/zat` fork, fix-oauth-client-zig-016 @ f8995c9) — path deps
+  break remote builds.
+- `writeFile600` mkdirs its parent — fresh fly volumes have no
+  $LINJI_HOME; VAPID key creation crashed the first boot.
+- `LINJI_HOST` env for the bind address (default 127.0.0.1; fly needs
+  0.0.0.0 — the proxy timed out against a loopback-only server).
+- `LINJI_PDS` env actually read by `serve` (was flag-only; the fly env
+  was silently ignored → beginLogin hit 127.0.0.1:2583).
+- Runtime image installs ca-certificates (TlsInitializationFailed
+  without it).
+- Landing login: empty password now hands off to the PDS consent page
+  (`/api/login` redirect); the password box is the dev-rig scripted
+  consent, kept for the rig. 53/53 vitest incl. a handoff test.
+
+**Seeded (real did:plc on plc.directory)**
+- community/alice/bob `.zds.linji.at` accounts (passwords in the ops
+  note), space `tongxi` (owner community), 30-day invite link, bob
+  joined and posted the first production message (thread 自我介绍).
+
+## Verification
+
+Real browser, all on prod: community OAuth consent login → create space
+→ create invite link; logged-out invite URL → landing + banner; bob
+signs in (UI form → OAuth handoff → zds consent) → preview (tongxi ·
+community · 29 days) → join → thread + post → community reads it.
+zig build test ✓, web 53/53 ✓.
+
+## Not in slice / follow-ups
+
+- ~~Sessions are in-memory: every deploy signs everyone out~~ — fixed
+  same-day: stateless HMAC-SHA256 cookies (`core/session.zig`, secret
+  persisted at {LINJI_HOME}/session.key, 30-day expiry). Verified: login,
+  `fly machine restart`, cookie still verifies. Revocation is by expiry
+  only — deliberate at dogfood scale.
+- CLI/loopback OAuth can't log in against a remote PDS: zds PAR fetches
+  the loopback client_id from *its own* 127.0.0.1 (no localhost-client
+  exemption). Seeding happens via the browser; upstream zds fix someday.
+- Wildcard handle resolution: `*.zds.linji.at` A/AAAA + ACME CNAME
+  (`_acme-challenge.zds.linji.at`) requested but not yet in DNS — new
+  accounts' handles won't resolve externally until it lands. zds's own
+  resolveHandle covers login regardless.
+- bsky.network/vsky.network crawler requests rejected (expected: our
+  records are permissioned).
diff --git a/log/s020.dj b/log/s020.dj
new file mode 100644
index 0000000..8ef0c4b
--- /dev/null
+++ b/log/s020.dj
@@ -0,0 +1,98 @@
+# S020 - external sign-in ("Bluesky users can log in")
+
+Date: 2026-08-02
+Slice: any atproto handle signs into app0.linji.at; invite codes gate
+spaces, not the service.
+
+## Policy change (user decision)
+
+- Sign-up to the service needs only an Internet handle. The app-level
+  invite gate (`LINJI_INVITE`, `--invite-code`, the Landing invite field)
+  is removed end to end; space invite links remain the space-join
+  mechanism.
+
+## How external sign-in works
+
+1. Landing: type any handle (`alice.bsky.social`). BFF resolves
+   handle -> DID -> home PDS (`.well-known/atproto-did` -> DID doc).
+2. PAR against the home PDS with the **plain `atproto` scope** (external
+   ASes reject our custom `space:` scope). Discovery follows the
+   protected-resource metadata chain: bsky's regional hosts
+   (morel.us-east.host.bsky.network) 404
+   `/.well-known/oauth-authorization-server` and must be read via
+   `/.well-known/oauth-protected-resource` -> `authorization_servers[0]`
+   (fixed in `fetchAsEndpoints`; zds falls back to self).
+3. Callback: after the home-PDS token exchange, `bootstrapSpaceCreds`:
+   a. `describeServer` on our zds -> `did:web:zds.linji.at` (aud);
+   b. `getServiceAuth` on the home PDS (DPoP) -> service JWT proving DID
+      ownership to zds;
+   c. zds `createAccount` (its service-auth path) adopts the DID:
+      external handle (resolves to the DID), placeholder email, derived
+      password, bootstrap invite code (`LINJI_ZDS_INVITE` secret,
+      500-use admin code). "account already exists" = re-login, skip.
+   d. Full-scope OAuth login against zds (scripted consent with the
+      derived password) swaps the stored creds to zds ones; the home PDS
+      URL is kept in the new `home_pds` field (accounts.json roundtrip).
+4. From then on the account looks exactly like a zds-local one: space
+   ops, delegation/credential ceremony, join - all against zds with the
+   full scope. Records live on our zds (the deliberate spec departure).
+
+Derived password = HMAC-SHA256(session secret, "zds-bootstrap-password:"+did)
+hex - deterministic, nothing extra to store; the session secret never
+leaves the box.
+
+## Verification
+
+- zig build test (new: scopeFor, derived password/email determinism),
+  scenario-serve PASS (gate removal + new beginLogin arg), web 50/50.
+- Prod probes: `/api/config` has no inviteRequired;
+  `/api/login?handle=alice.bsky.social` -> 302 to
+  `bsky.social/oauth/authorize` with a successful PAR.
+- **Not verified**: the callback leg with a real bsky account
+  (getServiceAuth at bsky, zds createAccount service-auth, zds OAuth) -
+  no bsky credentials available to the agent. Every bootstrap stage logs
+  a distinct failure line for the user's first run.
+
+## Addendum: handle-resolution bug found in user testing (2026-08-02)
+
+User's handle `1a-insec.net` (did:plc:73xkqje76lj5tostbsqa74b7,
+custom-domain, DNS-TXT-only) got stuck on the zds consent page: PAR on
+zds succeeded because `resolvePdsForHandle` fell back to zds whenever
+well-known lookup failed - and zds's resolveHandle DOES DNS TXT, so the
+PAR ran with full scope against an account that did not exist on zds.
+
+Fix (app0-only, zds untouched): `resolveDidForHandle` uses
+`zat.HandleResolver` (well-known -> DNS TXT over DoH); the zds fallback
+is restricted to `isHostedHandle(handle, handle_domain)` (dot-boundary
+suffix match, unit-tested incl. the `evillinji.at` false-positive);
+unresolvable external handles are a hard 400 (HandleResolutionFailed),
+never a redirect to the wrong consent page. `beginLogin` gained a
+`handle_domain` param; `didForHandle` deleted.
+
+Verified 2026-08-02 (deploy v14): local BFF (LINJI_BASE/PDS env, store
+seeded with prod clientSecretHex; /etc/hosts not writable - used
+`curl --resolve app0.linji.at:8787:127.0.0.1`) and prod agree:
+
+- `1a-insec.net` -> 302 to bsky.social/oauth/authorize (PAR ok, `atproto`
+  scope).
+- `alice.bsky.social` -> 400 (no _atproto TXT - correct, not a typo
+  redirect; the old pre-fix 302 was the buggy fallback).
+- `bob.zds.linji.at` -> 302 to zds (hosted path intact).
+- `zzz.linji.at` -> 502 via zds fallback (ResolveFailed; acceptable).
+
+Still pending: the full callback leg with a real bsky account; user's
+first live retry via the tongxi invite link.
+
+## Follow-ups
+
+- Invite code for bootstrap is a shared 500-use code in a fly secret;
+  fine for dogfood, revisit if sign-ups grow.
+- External accounts on zds carry a placeholder email and a repo signed
+  by a zds-generated key (not the DID-doc key) - known departure,
+  invisible inside our appview.
+- Unresolved: zds logs a steady ~1.3Hz `bearer auth invalid: jwt
+  parse/verify failed token_len=424` (foreign JWT hitting a bearer
+  XRPC route; pre-dates the fix, survived the app0 v14 restart; not our
+  code - no 424-char token exists in BFF state, bootstrap logs different
+  lines). ZDS_LOG_LEVEL=debug would print the request path; parked
+  pending user retry.
diff --git a/log/s021.dj b/log/s021.dj
new file mode 100644
index 0000000..a213799
--- /dev/null
+++ b/log/s021.dj
@@ -0,0 +1,108 @@
+# S021 - bsky bootstrap 403: granular rpc scope for service auth
+
+Date: 2026-08-02
+Slice: external sign-in callback ("could not set up your account on our
+server - try again" on app0.linji.at after bsky OAuth consent).
+
+## Symptom
+
+Sign-in flow: app0.linji.at -> OAuth -> bsky consent -> redirect to
+`/oauth/callback?code=...&state=...` -> 502 page "could not set up your
+account on our server - try again". This is the `bootstrapSpaceCreds`
+failure path in `callbackHandler` (server.zig:270-275), *after*
+`finishLogin` already upserted the bsky-token account into the store
+(the account row persisted with bsky creds and no `home_pds`; zds had no
+account for the DID).
+
+## Root cause
+
+Production app0 log (2026-08-02T04:41:21Z):
+
+    getServiceAuth failed: 403 {"error":"ScopeMissingError","message":
+      "Missing required scope \"rpc:com.atproto.server.createAccount?aud=did:web:zds.linji.at\""}
+    bootstrap failed did=did:plc:73xkqje76lj5tostbsqa74b7
+      pds=https://yellowfoot.us-west.host.bsky.network err=BootstrapFailed
+
+The DID-adoption contract: zds's `verifyCreateAccountServiceAuth` only
+accepts a service-auth JWT signed by the user's home PDS (bsky holds the
+account signing key; we cannot forge it). The JWT comes from
+`com.atproto.server.getServiceAuth` on bsky, called with the first-leg
+OAuth access token. bsky's granular-permission enforcement (atproto
+permissions spec, 2025+) requires that token to carry
+`rpc:com.atproto.server.createAccount?aud=<space-host-did>`; the legacy
+`atproto` scope no longer implies rpc permissions. Our first leg only
+ever requested `atproto` (S020 step 2), so getServiceAuth refused to
+mint the JWT and the whole bootstrap aborted.
+
+Confirmed non-causes: zds invite gate (all three codes on zds had
+remaining uses; `LINJI_ZDS_INVITE` secret present on app0); zds
+scripted-consent JSON path (not dev-tools-gated - only `dev.zat.debug.*`
+routes are); zds `resolveHandle` for external handles (local lookup
+first, then HandleResolver).
+
+## Fix (app0 only; zds, zat untouched)
+
+- `oauth.zig`:
+  - `externalScope(allocator, space_did)` returns
+    `rpc:com.atproto.server.createAccount?aud={space_did}` (no `atproto`
+    prefix - see the duplicate-scope gotcha below). `scopeFor` /
+    `external_scope` deleted.
+  - `beginLoginAt`: external PDS leg (pds_url != space_pds) fetches the
+    space host's DID via `describeServerDid` and requests
+    `atproto <rpc scope>`; space-host legs keep the full linji scope.
+    `describeServerDid` made `pub`.
+  - `clientMetadata(..., space_did)`: the metadata's `scope` declares the
+    rpc scope too, so bsky's "scope must be declared in the client
+    metadata" check passes.
+- `server.zig`: `serve()` resolves the space DID up front
+  (`oauth.describeServerDid(allocator, io, pds)`) - fail fast, the app
+  is useless without zds anyway - and passes it to `clientMetadata`.
+
+### Gotchas found while verifying (both fixed)
+
+1. bsky's PAR validates the requested scope against the client metadata:
+   `400 invalid_scope ... not declared in the client metadata`. Declaring
+   it in the metadata is mandatory, not just good hygiene.
+2. bsky validates the metadata's declared scopes as a *set*:
+   `400 invalid_client_metadata: Duplicate scope "atproto"` when the
+   legacy token appears both in `scope` and as an `atproto ` prefix of
+   the rpc scope. Hence `externalScope` returns only the rpc part and the
+   `atproto` token is composed at the PAR site only.
+3. Probing bsky's PAR directly required the *exact* zat assertion shape:
+   `aud` = AS issuer (not the token endpoint), JWS signature raw r||s
+   (JOSE ES256), not DER - bsky rejects DER with a misleading
+   "signature verification failed"; zds is lenient and accepted both,
+   which masked the format bug until the aud error surfaced.
+
+## Verification
+
+- `zig build`, `zig build test` (new `externalScope` unit test),
+  `zig build scenario-serve` PASS.
+- Deployed twice (v15, v16) to app0.linji.at; live metadata probe:
+  4 distinct scopes, no duplicate `atproto`, rpc scope declared.
+- Live bsky PAR probe with the deployed client key (clientSecretHex from
+  the prod store + jwks x/y from the served metadata) and the new scope:
+  **201 request_uri** (was 400 invalid_scope pre-fix).
+- Full callback leg with a real bsky account still needs the user's
+  retry; the consent screen will show the extra "make authenticated API
+  requests to zds.linji.at" permission (that is the scope working).
+
+## Addendum: concurrent-edit incident (same day)
+
+A hand edit to `oauth.zig` after deploy v16 added an `ext_tail` slice
+`ext[indexOf(ext, " ").? + 1 ..]` in `clientMetadata`, deduping an
+`atproto ` prefix - but `externalScope` no longer returns that prefix
+(the dedupe fix), so `indexOf` is null and `.?` panics at startup.
+Removed; the dedupe intent is already satisfied by the rpc-only scope.
+If a similar dedupe is ever re-added, it must target the metadata
+composition, not `externalScope`.
+
+## Follow-ups
+
+- User's first live retry of the full bsky callback leg (pending at time
+  of writing).
+- S020's parked mystery: zds ~1.3Hz `bearer auth invalid: jwt
+  parse/verify failed token_len=424` (foreign JWT on a bearer route) -
+  still unresolved; ZDS_LOG_LEVEL=debug would name the path.
+- Revisit the shared 500-use bootstrap invite code if sign-ups grow
+  (from S020).
diff --git a/roadmap.dj b/roadmap.dj
index 8b2d8d0..2d140e8 100644
--- a/roadmap.dj
+++ b/roadmap.dj
@@ -14,7 +14,8 @@ Done when: two accounts hold a topical conversation.
 
 **001 — Dogfood.**
 Migrate 同喜班 off Zulip onto spaces hosted on linji.at. Multiple spaces,
-but space creation is admin-only via the CLI — not exposed in the web UI.
+created from the web UI or CLI (S017); whether creation stays open to every
+member or gets admin-gated is a dogfood policy call.
 Members log in via OAuth with an account on any PDS (e.g. *.bsky.social);
 we host their space records on our zds, since their PDSes are not
 permissioned-data-capable (see architecture.dj "External members").
@@ -104,6 +105,21 @@ would be what fails.
  closed-app delivery = best-effort. [log](log/s015.dj)
 - **S016** v - Web UI behavior tests: Vitest + happy-dom in
   `app0/web/tests/` (fake in-memory BFF), 19 tests. [log](log/s016.dj)
+- **S017** ✓ — PWA feature parity (multi-space, members, edit/move/delete,
+  export) + per-user data rights (own-data export + deletion).
+  [log](log/s017.dj)
+- **S018** ✓ — space invite links end to end (zds simplespace.join /
+  inviteInfo, BFF endpoints, join screen) + gruvbox UI redesign
+  (light/dark, mobile drawer, English copy). [log](log/s018.dj)
+- **S019** ✓ — production deploy: zds.linji.at (PDS) + app0.linji.at
+  (BFF+PWA) on Fly.io, real did:plc accounts, seeded tongxi space,
+  invite flow verified end to end in prod, stateless session cookies.
+  [log](log/s019.dj)
+- **S020** ✓ — external sign-in: any atproto handle (bsky.social
+  included) logs into app0; app-level invite gate removed (handles are
+  the sign-up credential, invite codes gate spaces only); bootstrap
+  swaps home-PDS tokens for full-scope zds creds via getServiceAuth +
+  zds service-auth createAccount + zds OAuth. [log](log/s020.dj)
 
 ## Open questions
 
-- 
2.51.2