.gitbay/wiki/Parity.org

A capability lands over SSH first. If it belongs to the triage/review/respond loop, it lands on the web in the same merge request. Nothing is held back from a surface any more (#234): the registry has no flag for it, and what a caller may do is the account's rights narrowed by the scope of the key or token it arrived with, decided in one place. A no in the web or ios column is a page nobody has built yet, not a refusal.

Rows are one page or one action each. Grouped rows hide gaps, twice now: "browse, log, blame, search" read as covered while blame had no command at all, and "build list, log" read as covered while the job list a trigger can name had none (krz/gitbay#50), leaving the picker browser-only and the iOS build screen unable to say more than the log.

Reviews and checks carry the time they last said something, and a ci/<job> check carries how long its build ran, so a merge request reads without opening the build. Statuses posted through status set have no build and report only the time. A merged or closed merge request names who resolved it and when; a row without that stamp — a migrate import, or one merged before krz/gitbay!137 with no mr.merged event to backfill from — says neither rather than inventing a time.

A merge request whose target is another open merge request's source branch is stacked on it: mr show and the page say so both ways, and when the lower one merges, everything stacked on it is retargeted onto what it merged into with its reviews kept. A squash or rebase merge is refused while anything is stacked on the merge request, since it would rewrite the commits the stack builds on. All three surfaces show the stack both ways.

A draft merge request is open but not asking: it does not merge, and it does not appear in anyone's review queue. Draft is a flag rather than a fifth state, so every state = 'open' rule still means what it did. mr revisions lists the heads a merge request has had; the web page lists them beside the reviews they staled, and the iOS client has a Revisions section. mr range-diff compares two heads: the iOS client shows it from a revision to the one before, as text; the web renders the same view, with a "compare to previous" link on each revision after the first. Batched review — draft diff comments held with mr comment --pending and sent together with --comment=/–discard= or a verdict — is built and the web uses it: composing review comments before publishing them is the same round trip as the CLI's --pending flag.

mr review request --add <user> asks a particular person, who then carries the merge request in their queue and is notified; --remove withdraws the ask. Without one the queue is computed from involvement — what you own, are granted, or reach through an org or team — so a collaborator with write access who has not touched a thread hears nothing until they do (krz/gitbay#145).

Creating from a fork works anywhere the source can be typed as owner/name:branch. The web's source picker offers the branches of every fork the viewer can push to in that form, and the repository header has the fork control, so the whole path — fork, edit a file, propose — runs in a browser. Retargeting moves an open merge request onto another branch of the same repository and stales the reviews, since an approval was of the diff against the old branch.

Labels are created on the fly by issue label --add and mr label --add, and managed by label list, label set <label> --color rrggbb and label remove, which takes the label off every issue and merge request. One set serves both. The web paints the stored colour on every chip and derives one from the name when none is set. The set itself is at /<owner>/<repo>/labels, linked from the issue list: create, recolour and remove, dispatching the same commands.

Org labels and milestones are managed on the CLI, the API and the iOS client's org screen; /<org>/-/labels and /<org>/-/milestones show them on the web. The repository label page's form exists for colour alone, and three org forms nobody asked for were not worth their handlers.

Issue, MR and release bodies, and their comments, carry the markup they were written in — --format md|org on create, comment and edit, stored alongside the text so changing a preference later cannot reinterpret prose that already exists. Every surface renders the stored format, and every surface now offers the choice: the web's create forms, and the iOS composer on create, edit and comment. An edit starts on the format its body was stored in, since starting elsewhere would silently reinterpret it on the next save. Diff-line comments have no format column and are always markdown.

Every web form that takes markup has a Preview button beside its own submit: issue and merge request create, their edit and comment boxes, release create and edit, and the file editor on a path the forge renders. It posts to the form's own action, which renders the draft and hands the page back without writing, so what you see is the rendering the thread will show, autolinks included. It is a round trip rather than a live preview because the instance serves no JavaScript, the same way the blob page's rendered/source toggle works. The row is n/a on the CLI: a terminal has no form to preview, and issue show already renders. Diff-line comments are left out — they sit inside the diff, where a page-level preview has nowhere to go.

The iOS client resolves no autolinks: #N and owner/name#N render as text in its threads, so a preview there will show the app's rendering rather than the one the web page shows.

No row is web-only any more. Blame, file editing, log at a ref, archive, the public listing and the wiki were all in that state — a handler reading git or the store directly instead of dispatching a command — until krz/gitbay!99, !101 and !102 gave them commands.

build cancel withdraws a queued build, or ends a running one: the server closes the runner's log session and the runner kills the step within a couple of seconds. Cancelling a duplicate of a commit that already passed the job puts that result back on the commit. The build page carries the button while a build is still cancellable.

A pin and a bookmark are different things and are stored separately. A pin is private quick access to what you are working on, and drives the rail; a bookmark is public, says a repository is worth coming back to, and its count is the only popularity signal on the instance. Bookmarking needs read access only — it is something you do to someone else's repository — and a repository bookmarked while public and since made private drops out of the listing rather than leaking that it exists (krz/gitbay#146).

The web's watch and pin controls dispatch repo pin=/=repo unpin and repo watch=/=repo mute=/=repo unwatch, the same commands the CLI runs (krz/gitbay#261). The single watch button cycles default, watching and muted.

Dependency checks are off until a repository's admin turns them on: the check tells a public registry what the repository depends on. repo deps status lists what is behind; the repository's settings page renders the same report under the toggle — last check, last error, the tracking issue, and the rows. The issue the worker opens, rewrites and closes is still the copy every other surface reads.

The wiki row covers reading. A wiki lives at .gitbay/wiki/ on the default branch, so editing one is editing a file in the repository — a push, or repo commit-file — and there is no wiki-specific edit row to have parity on. The web editor reaches it on any repository that permits server-authored commits; one requiring verified signatures does not, because the server signs nothing on a user's behalf, so those wikis are push-only.

n/a marks a capability deliberately absent from a surface rather than missing from it. Archive download is n/a on iOS: the read API carries a command's stdout as a JSON string, so a gzip stream cannot survive it, and the app has nowhere useful to put a tarball — the brief rules out local git, so there is no clone, checkout or build to feed. The web's route stays the way to get one. release asset add is n/a on iOS for the same reason from the other direction: the file arrives on stdin, which the API carries as a JSON string. Attaching a runner is n/a on iOS for a plainer reason: the key is generated by gitbay-runner init on the machine that will run builds, and that machine's terminal (the command init prints) or the settings page is where the paste happens. A phone has neither the key nor the runner.

A README or wiki page's org renders per surface: the web through go-org, the iOS client through the shared OrgSwift package (krz/org-swift). OrgSwift is held to orgo's output by the krz/org-conformance corpus — golden renderings from orgo, itself diffed against Emacs ox-html — so constructs the iOS client used to approximate (tables, footnotes, timestamps, heading tags, nested lists) now render the way the reference does. go-org is not yet on the corpus.

explore is the listing without a query; repo search is the one with. search is both plus the title and body of every issue and merge request the caller can read, over FTS5; the web serves it at /search with a field in the rail, and an anonymous visitor gets the public rows from the same query. issue list --search and mr list --search narrow one repository. What someone types is quoted term by term, so an FTS5 operator — c++, AND, a lone quote — is a word to match and never a syntax error. repo grep remains the per-repository file-contents search.

The about text is profile/README.{md,org,markdown} on the default branch of <owner>/.gitbay, resolved in that order, so the extension picks the renderer rather than a stored format. profile show reports it as about, about_format and about_path. It reads with the repository's own access, so a private .gitbay is a profile with no about text to anyone but its owner and the admins. A repository whose name starts with a dot stays out of explore and off the profile's repository list. On the web a profile is tabs: /<owner> is About — the text, the year of squares and a log of the newest thirty events — then /<owner>/-/repositories, /<owner>/-/bookmarks, /<owner>/-/snippets, and /<owner>/-/people for an organization's members and teams. A tab nobody may open is not offered and its URL is a 404: bookmarks are the viewer's own, only a user has snippets, and people is the org admin panel. The log counts what the graph over it counts — a user's own events, an organization's repositories' — on public repositories only; activity.atom is the feed that goes back further. The CLI's profile show is unchanged and still returns all of it at once. The iOS client decodes and renders both formats, through the same OrgSwift path a README takes.

help lists the command registry. Bare it is an index, one line per command, sorted. With a prefix (help mr) it adds each command's argument syntax, which is the only place flags are written down; gitbay <cmd> --help asks the server for the same thing, and --json returns {path, summary, usage}. No web page renders it, and a native client has no use for one (krz/gitbay#57).

Notifications land in an inbox row per recipient whether or not the instance sends mail, and mail is the second half when SMTP is configured. notifications list reads it, unread by default; notifications read <id>... | --all clears it; the dashboard and the web rail carry the unread count. repo watch adds you to a repository's notifications, repo mute silences it, and repo unwatch returns you to the default from either — told about work you are part of, nothing more. notifications settings watch on widens that default to every repository you can write to, without a row per repository. A mute wins over owning the repository, having written the thread, or the preference.

Push is the third leg beside inbox and mail, delivered to Apple devices an account has registered. notifications device add runs on every surface like every other command, but no web page offers a form for it, because only the iOS app can produce an APNs device token — a browser has no way to ask Apple for one. device list and device remove have no such limit and are yes on the web like the rest.

A login link is requested from the login page by username or verified address, and arrives by mail: it works once and expires in fifteen minutes. The row is n/a for the CLI because a terminal with a registered key runs web login, which mints a link directly and needs no mail. It exists because an account with no SSH key had no way into the web at all (krz/gitbay#155). The page offers the form only when the instance has SMTP configured; there is no separate switch. The response never says whether the account exists. It is n/a on iOS for the same reason it is on the CLI, from the other end: the app authenticates with a bearer token pasted at sign-in, so a one-time link into the web unlocks nothing it can use.

The account export bundle is n/a on iOS on the archive-download argument above — a JSON bundle has nowhere useful to land on a phone, and the web route stays the way to get one.

profile set carries description, website and links; the JSON API runs it like any other write. The account settings page has the form, and so does the iOS client: --link replaces the whole set rather than appending, so a client sends every link it keeps on every save, and --link '' is how they are cleared.

The about text is not among those flags. It is a file, written by a push or repo commit-file like any other file, which is why writing it is yes on every surface: anything that can commit a file can write it. The settings page points at the file and offers to create <owner>/.gitbay when there is none.

/admin/users carries the account list with the command's state filter and cursor, and promote, demote, disable and enable per row; demote and disable ask for the username to be typed. The rest is a page nobody has built yet rather than a refusal — see below. Account creation and deletion stay on the command line on purpose: one takes a key, the other cannot be undone.

issue list, mr list, repo list, feed and build list take --limit <n> and --cursor <c>. Cursors are opaque; each page carries the next one. Without the flags a list stays as it was, so existing scripts are unchanged — for build list that means the newest fifty matching builds, which is what the cursor now reaches past. The web pages the issue and merge request lists at fifty and the builds list at thirty with the same cursors; iOS pages with them too.

Build secrets, mirror configuration and tokens, custom domain claims, API token minting, web session listing and revocation, deploy keys, and instance administration have no page yet. Until #234 these were refused outright on the other surfaces; the refusal is gone, so each is now a page waiting to be built rather than a rule. A credential still travels on stdin wherever it is set, since argv is world-readable in /proc and the audit log keeps flag values.

Deleting or transferring a repository stays CLI-only on purpose, as does deleting an organization and pruning merge request heads (admin mr prune): each removes or moves what clone URLs point at, and wants a typed command rather than a button. Renaming is the exception: the iOS client offers it, and the web has no page yet.

n/a means a surface cannot usefully carry the capability at all — see the archive note above.