evalhub 0.1.3

README: the UI ships in the binary, and /whoami returns no roles (0.1.3) (#23)

Release 0.1.3. What changed since 0.1.2:

Organisations in the web UI (#17)

Settings creates an organisation (the creator is its first admin); the organisation's namespace page shows its roster and adds, updates and removes members. Browser tests drive the flow against the release binary.

The roster rule, documented as the token rule it is (#20)

GET /orgs/{org}/members asks that the presented token names the organisation, like every other read. The module doc, the handler, /openapi.json and the README said membership was enough; they now say what the code does. docs/hosting.md gains a section on making an organisation in two steps: create it, then issue a token that names it.

The organisation page after creating one (#21)

A signed-in token that does not name the organisation now gets a line saying why the roster is missing and a link to Settings with the token form filled in; Settings fills the same form right after creating an organisation. Member controls appear only for an admin token of an admin member, which is what the hub accepts.

This pull request

README.md: §Status no longer says the UI is being built, and the /whoami row names the fields the response has (user, scope, namespaces — no organisation roles). Carries the version bump to 0.1.3.

Verification

cargo fmt --check; cargo clippy --workspace --all-targets -- -D warnings; cargo test -p evalhub-schema, -core, -query; just package (all three crates at 0.1.3, gate ok); just semver-check: no semver update required for any of the three. No Rust source changed in this pull request; evalhub-store / evalhub-server tests were not run here.

The UI changes of #21 were deployed to the hosted service from main before this release and passed deploy/fly/smoke.sh.

Refs #22

---

SDK crates: evalhub-schema evalhub-core evalhub-query
Image: ghcr.io/ynishi/evalhub:0.1.3