graft batch 3: 6 lands from backlog-1

bench/render.py

@@ -176,8 +176,8 @@ def clean_count(case: dict, tool: str) -> int:
         "</style>",
         f'<text x="24" y="28" class="h">graft vs git, p50 ms (lower is faster)</text>',
         '<text x="24" y="48" class="sub">teal graft, grey git. '
-        "1k: vogt-prod, seed 2294, 5 iterations. "
-        "10k: graft-dev, seed 2294, 5 iterations. "
+        "1k host A: 24 CPUs, 62.6 GiB, seed 2294, 5 iterations. "
+        "10k host B: 4 vCPUs, 7.8 GiB, seed 2294, 5 iterations. "
         "Fresh CLI process per step.</text>",
         f'<rect x="16" y="64" width="888" height="250" rx="8" class="box"/>',
     ]

changes/WI-2542.md

@@ -0,0 +1 @@
+Added a user glossary and git-to-graft concept table to the guide.

changes/WI-2544.md

@@ -0,0 +1 @@
+Added a complete MCP registration and tool reference, enforced by a test that every registered tool is documented.

changes/WI-2545.md

@@ -0,0 +1 @@
+Document server configuration, authorization, administration, health, and schema upgrades.

changes/WI-2546.md

@@ -0,0 +1 @@
+- Add a Git migration guide covering lossless import, GitHub follow, batch pull-request delivery, full export, and the advanced authority switch.

changes/WI-2547.md

@@ -0,0 +1,2 @@
+Added a concise guide FAQ covering interoperability, offline use, lines,
+conflicts, CI, git export, performance, licensing, and supported platforms.

changes/WI-2548.md

@@ -0,0 +1 @@
+- Benchmark documentation describes the measured hosts by CPU and memory instead of estate-specific names, and the agent guide now documents `graft serve --dev` as available.

crates/graft-mcp/tests/guide.rs

@@ -0,0 +1,23 @@
+//! Documentation coverage for the public MCP tool registry.
+
+use std::fs;
+
+#[test]
+fn mcp_guide_lists_every_registered_tool() {
+    let guide = fs::read_to_string(
+        std::path::Path::new(env!("CARGO_MANIFEST_DIR")).join("../../docs/guide/mcp.md"),
+    )
+    .expect("read docs/guide/mcp.md");
+
+    let missing: Vec<&str> = graft_mcp::TOOLS
+        .iter()
+        .map(|tool| tool.name)
+        .filter(|name| !guide.contains(&format!("### `{name}`")))
+        .collect();
+
+    assert!(
+        missing.is_empty(),
+        "docs/guide/mcp.md is missing registered MCP tools: {}",
+        missing.join(", ")
+    );
+}

docs/agents.md

@@ -13,7 +13,7 @@ export GRAFT_AUTHOR_NAME="Name" GRAFT_AUTHOR_EMAIL="name@example"
 
 The token is a bearer credential. Never print it, never pass it as an argument, never copy it into the checkout or a prompt. `graft login` copies it into a private token file and stores only that file's path in the user config. For command overrides, endpoint and token resolve independently in this order: `--endpoint` / `--token-file`, `GRAFT_ENDPOINT` / `GRAFT_TOKEN`, the working copy's named server, then the user's `default_server`.
 
-`graft serve --dev` (a local server with a dev token) is also coming in v0.1.0.
+`graft serve --dev` starts a local server with a dev token.
 
 ## The loop
 

docs/guide/benchmarks.md

@@ -11,8 +11,8 @@ CLI process for every step (graft and git alike):
 
 | Scale | File | Host | graft commit |
 | --- | --- | --- | --- |
-| 1,000 commits | `bench/results/2026-10-23-scales-10-1000/results.json` | 24 CPUs, 62.6 GiB | `35c308759e8f` |
-| 10,000 commits | `bench/results/2026-10-23-scale-10000/results.json` | graft-dev, 4 vCPU, 7.8 GiB | `2c32be2d39a3` |
+| 1,000 commits | `bench/results/2026-10-23-scales-10-1000/results.json` | host A: 24 CPUs, 62.6 GiB | `35c308759e8f` |
+| 10,000 commits | `bench/results/2026-10-23-scale-10000/results.json` | host B: 4 vCPUs, 7.8 GiB | `2c32be2d39a3` |
 
 Bars are p50 milliseconds. Lower is faster. Teal is graft, grey is git.
 Operations: full clone, sparse clone, `log -50`, `log --path`, blame,

docs/guide/concepts.md

@@ -0,0 +1,119 @@
+# Graft concepts for git users
+
+Graft is a server-centric source control system. A working copy contains the
+files you edit, while the server owns history, workspaces, drafts, lines, and
+the operations that move work between them.
+
+## Glossary
+
+### Repository
+
+A repository is a named namespace on a server. It contains the repository's
+objects, changesets, refs, workspaces, and journal.
+
+### Object
+
+An object is an immutable, content-addressed value. A blob holds file bytes;
+a tree describes one directory.
+
+### Changeset
+
+A changeset is the unit of work. It names its parents, records file changes
+against its first parent, and identifies the resulting root tree.
+
+### Draft
+
+A draft is a changeset that no line has reached yet. `graft commit` creates a
+draft from inline content or the working copy, and a workspace holds it while
+it is active.
+
+### Landed
+
+A changeset is landed when it is on a line's first-parent history. Landed
+changesets remain part of that line's history.
+
+### Line
+
+A line is a protected ref, such as `main` or `release/1.4`, that moves forward
+through landed changesets. `graft line create` forks a new line at a changeset
+and never overwrites an existing line.
+
+### Ref
+
+A ref is a named pointer to a changeset. Lines are movable refs; tags are
+immutable refs.
+
+### Tag
+
+A tag is an immutable name for a changeset. `graft tag create` creates it once
+and never moves it.
+
+### Workspace
+
+A workspace is a named, owned, leased server record with a base and a head. It
+is the server-side twin of a working copy; `graft workspace` can show, list,
+open, renew, or close workspaces.
+
+### Stack
+
+A stack is the drafts between a workspace's base and head, oldest first.
+`graft stack` lists, squashes, reorders, splits, or drops those drafts.
+
+### Journal
+
+The journal is the repository's append-only, sequence-numbered record of
+writes. Watchers and mirrors follow it without scanning repository history.
+
+### Base
+
+The base is the landed changeset on a line that a workspace starts from.
+`graft sync` moves the workspace base to the line tip and rebases its stack.
+
+### Head
+
+The head is the newest draft in a workspace, or the base when the stack is
+empty. Working-copy status is measured against the workspace head.
+
+### Land
+
+To land is to put the workspace stack on a line. `graft land` rebases the
+stack on the server and moves the line only if its expected version still
+matches.
+
+### Sync
+
+To sync is to move the workspace base to the line tip. The server rebases the
+stack, and the client updates the working-copy files.
+
+### Line merge
+
+A line merge brings one line into another and records a merge point between
+them. `graft line merge` uses a three-way merge and writes unresolved
+conflicts into the working copy for resolution.
+
+### Conflict
+
+A conflict is a path that cannot be merged automatically. Text conflicts use
+markers in the file; other conflicts use a `.graft-conflict` sidecar until the
+workspace records a resolution.
+
+## Git to graft
+
+Graft keeps familiar command names where their meaning is close, but its
+server-owned workspaces and drafts replace git's local-history workflow.
+
+| Git term | Graft term | What differs |
+| --- | --- | --- |
+| Repository | Repository | A remote repository is a named namespace on one server, not a collection of peer clones and remotes. |
+| Commit | Changeset; `graft commit` creates a draft | The changeset is created on the server and is visible immediately; there is no later push of a private local commit. |
+| Branch | Line for shared history; workspace stack for work in progress | Lines are few protected refs. Ongoing work stays as leased drafts rather than short-lived branches. |
+| Tag | Tag | A graft tag is an immutable ref to a changeset and never moves. |
+| Working tree | Working copy | The files are the client-side view of a server workspace, often limited to selected path prefixes. |
+| Index / staging area | None | `graft commit` records the working copy's changes, or only the paths named by the caller. |
+| Push | `graft land` | Land rebases the workspace stack on the server and advances the line with a compare-and-swap. |
+| Pull / fetch | `graft sync`; object fetch | Sync moves the workspace base to the line tip and updates files. Object fetch retrieves named content rather than negotiating histories. |
+| Merge | Land, or line merge | Ordinary work lands by server-side rebase. A line merge integrates one line into another and records a merge point. |
+| Rebase | Server-side rebase during sync or land | The server rebases the workspace stack; the client resolves only paths that cannot merge automatically. |
+| Cherry-pick | `graft pick` | Pick creates a draft that re-applies a landed changeset; conflicts are written into the working-copy files. |
+| Revert | `graft revert` | Revert creates a draft that inverts a changeset, ready to land like any other draft. |
+| Pull request | Review of a workspace stack before land | Graft itself has no pull-request object or branch-per-change requirement; review can use changesets, diffs, and workspace metadata directly. |

docs/guide/faq.md

@@ -0,0 +1,67 @@
+# Frequently asked questions
+
+## Why is graft not compatible with git on the wire?
+
+Graft is server-centric: the server owns workspaces, drafts, rebases, history,
+and landing. It therefore does not speak the git wire protocol or store git
+objects; familiar command names are used only where their meanings remain
+close.
+
+## Can I use graft offline?
+
+A working copy of a remote repository has a bounded cache, so reads of cached
+objects continue to work while disconnected. Remote writes wait for the server;
+for fully local, single-user work, `graft init` runs the engine in the client
+process and needs no network connection.
+
+## Are lines the same as branches?
+
+Lines are a small set of shared, protected histories rather than a feature
+branch for every change. Work in progress lives in a leased workspace as a
+stack of drafts, and landing rebases that stack on the server before moving the
+line with compare-and-swap.
+
+## How do changes move between lines?
+
+`graft line merge` brings one line into another with a three-way merge and
+records a merge point between them. The source line is read, not moved, and an
+unresolved merge is returned to the working copy for resolution.
+
+## How do conflicts reach me?
+
+Graft reports conflicting paths and leaves the shared line unchanged. After
+`graft sync` or `graft land --sync`, text conflicts appear as markers in the
+files and other conflicts use `.graft-conflict` sidecars, so they can be
+resolved and committed from the working copy.
+
+## Where does CI run?
+
+In phase one, graft runs no build, test, check, or checker anywhere, including
+the land path. For git-primary repositories, CI stays on the forge and runs on
+the batch pull request that carries landed changes back to git.
+
+## Can I go back to git?
+
+Yes. `graft mirror export` writes the full history back to git, and import keeps
+raw tag objects so migration does not discard them; deterministic full export
+is the exit path, not an afterthought.
+
+## Is graft faster than git?
+
+It depends on the operation and scale. Recorded results show graft ahead on
+full and sparse clone, path log, blame, and some concurrent lands, but behind
+on recent log, status, and sync; see the [benchmark results](benchmarks.md) for
+the measurements and limitations.
+
+## What does AGPL-3.0-only mean for an internal server?
+
+The licence is AGPL-3.0-only; if users interact over a network with your
+modified version, those users must be offered its corresponding source. See
+the [FSF licence FAQ](https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingRemotely)
+for the rule and consult your own counsel for legal advice.
+
+## Which platforms are supported?
+
+The documented release archives target Linux on x86_64 and aarch64, plus macOS
+on Apple Silicon. There is no Intel macOS archive, and no Windows archive is
+currently documented.