authn: name the grant scope dolt.sr.ht/DATABASES api-meta.json published the scope as lowercase "repos" while every other service on the instance publishes it upper case — git.sr.ht/REPOSITORIES, todo.sr.ht/TRACKERS, paste.sr.ht/PASTES, builds.sr.ht/JOBS. Upstream derives those from a GraphQL enum; this service has no @access directive to derive from, so the spelling was free and drifted. It matters because meta.sr.ht compares the string verbatim. Its oauth2 blueprint fetches every service's api-meta.json once at import time and validates a requested grant with `scope in service_scopes[svc]` — no case folding, no aliasing. So a grant typed by hand as dolt.sr.ht/REPOS:RO was refused, by analogy with every neighbouring service. DATABASES rather than REPOS: that is what the surface calls the object everywhere a user meets it — the GraphQL databases connection, the web pages, the docs. The storage layer underneath still says "repo"; renaming that is a deeper change and is not what a token grant names. No backward compatibility. auth.Grants.Has is a map lookup, so a PAT minted against the old spelling is refused rather than quietly honoured, and two table cases assert that instead of leaving it implied. Deploying this is two-sided: meta.sr.ht has to be restarted before anyone can mint a token carrying the new name. The federation gateway is unaffected — it forwards the client's Authorization header to each service and never reads api-meta.json. sr-ht-dolt-xic
storage: create databases empty so the first push needs no --force Every automatic creation path wrote an "Initialize data repository" commit through WriteEmptyRepo, and that commit is history. dolt decides fast-forward on the client (actions.CanFastForward over the remotesapi), so the server cannot forgive the collision: pushing a database that has a root commit of its own — a beads tracker, anything grown locally — was rejected as a non-fast-forward and could only land with --force. That is the whole reason the companion-database recipe starts with a forced push. push-to-create already provisioned an empty store for this exact reason. Give the other two paths the same default: /internal/repos, whose caller is git.sr.ht's post-update hook and therefore fires before its user has ever pushed, now always provisions empty, and the web form does unless its new "initialize with an empty commit" checkbox is ticked. The checkbox buys what an empty store cannot offer — a database that can be cloned before anything is pushed to it, since dolt refuses a store with no commits as "contains no Dolt data". Which is also why the overview of a database with no branches now teaches push rather than clone: the clone box there quoted a command that could not work. A store that fails to open is deliberately not treated as empty — an unreadable database must not be advertised as a fresh one.
web: draw the chrome from sr-ht-ecore The brand, the service switcher, the login block, the environment banner and the database listing were a local port of core.sr.ht's nav — one of five such ports on this instance, and they had already drifted. They are now sourcecraft.dev/bigbes/sr-ht-ecore/chrome, the one copy every custom service draws from. Deleted: web/chrome.go entire (navEntry, networkOrder, networkExcluded, buildNetwork, basePage, loginURL, logoutURL), templates/nav.html, templates/icons/circle.svg (ecore inlines the identical SVG), the repoList partial, and the local dict/shortHash duplicates. Added: one chrome.Service built in newApp from our config section with the hashed stylesheet href set on it, a chrome.Page per request through app.page, chrome.Attach on every template set, and chrome.Funcs as the base of the funcmap. Handlers embed chrome.Page in their view structs instead of copying its fields; the row browser sets ContainerClass to container-fluid, since its column count is the table's and not ours. Three behaviour changes come with ecore's policy, all deliberate: the profile link now prefers hub's ~username page when hub.sr.ht is configured (it was always meta's /profile), the brand carries a fixed 15rem min-width so the switcher starts at the same x on every service, and a binary built without a stylesheet renders bare rather than linking an empty href. The nav test went with the code it tested — ordering, exclusions and login URLs are ecore's to cover — and what replaced it asserts only what is ours: that pages are drawn through the chrome at all, and that the row browser is full-bleed. The auth path is untouched: a foreign bearer token is still accepted as a meta.sr.ht PAT.
rename module to sourcecraft.dev/bigbes/sr-ht-dolt; depend on sourcecraft sr-ht-core
docs: add design spec Architecture plan the v1 implementation followed: verified upstream facts, schema, access matrix, remotesapi/auth design, browse subsystem, config + nginx wiring, phase breakdown, and the post-deploy verification script.