~bigbes/sr-ht-spec

ref: be33cce12a517c4c129905c733bbc098f5c9c62f sr-ht-spec/.gitignore -rw-r--r-- 672 bytes
53e56db2 — Eugene Blikh 9 days ago
web: draw the chrome from sr-ht-ecore

The nav/service-switcher, the login block, the environment banner and the
brand were this service's own copy of code compare.sr.ht had already copied
from somewhere else. They come from sourcecraft.dev/bigbes/sr-ht-ecore/chrome
now: one chrome.Service built at startup from the shared config.ini, one
chrome.Page per request, embedded in viewData so the shared partials find
their fields on the dot.

web/chrome.go is gone — buildNav, navItem, canonIndex, the login/logout/
profile URL building and the chrome half of viewData with it. The layout
renders srht-env-banner and srht-nav instead of the local markup, the landing
page's space list renders through srht-repo-list, and the template FuncMap
starts from chrome.Funcs() (the local shortsha was a duplicate of the shared
one). sameOrigin and the login redirect ask the chrome for our origin rather
than keeping a second copy that could disagree with the links on the page.

Three of ecore's policies differ from what this service did, and win, per that
package's own doc: [sr.ht]site-name defaults to "sr.ht" rather than
"sourcehut" and [sr.ht]environment to "development" rather than "production"
when the key is absent, and the brand carries a fixed 15rem min-width so the
switcher starts at the same x on every service. The instance's config.ini sets
both keys, so on it only the brand width is visible.

The nav tests that only restated ecore's rules — switcher order, the
paste/pages/hub exclusion, the shape of a login URL — are dropped; ecore tests
those. What is left covers this service's seam: that the identity authn
resolved is the one the chrome is handed.
b87d2866 — Eugene Blikh 26 days ago
bd init: initialize beads issue tracking
33a3deaf — Eugene Blikh 27 days ago
feat: foundation — go.mod with every dependency, and the core/ domain

Phase 1 foundation commit. Two things, so that later parallel waves write
disjoint directories and never touch go.mod:

  - go.mod / go.sum carrying every external dependency the whole module will
    need (go-git, bleve, goldmark, chi, lib/pq, yaml.v3, the MCP SDK, brant,
    auxilia, testify, and the sr-ht-core fork). Populated by building a
    throwaway blank-import file, which is then deleted; `go mod tidy` runs
    once, at the very end of the build-out.
  - core/, the pure domain: owner/space names, safe relative paths, the
    globally-unique document ID grammar, frontmatter parsing and schema
    validation, `.spec.yml` policy with auto_merge glob matching, and the
    proposal state machine. Standard library plus yaml.v3, nothing else.

Two design invariants are enforced here rather than documented and hoped for:
"approved" is not a status (it is a property of the branch a document is
reachable from), and the proposal machine has exactly open/merged/rejected.
A per-space `.spec.yml` cannot reintroduce either.

Note on the sr-ht-core pin: the design calls for a `replace` onto
git.srht.bigb.es/~bigbes/core-go at c2c2f38, but that commit's go.mod still
declares `module git.sr.ht/~sircmpwn/core-go`, so Go rejects the replacement.
Both siblings pin the later dd418a20 under the canonical path with no
replace; this does the same.