Expand description
Workspace mode — two variants.
Github mode (Workspace::open, the default when
--workspace DIR is set): the agent activates a GitHub repo via
repo_management('org/repo'), the binary clones it into the
workspace, and the active repo becomes the bound source root for
read_source / grep / list_source. Idle repos auto-sweep after
--stale-after-days. Layout:
workspace/
repos/
Local mode (Workspace::open_local, the manifest-driven
workspace: { kind: local, root: ... } variant): the active source
root is a fixed local directory, not a clone target. repo_management
reports the active root and triggers rebuilds; an set_root_dir
tool can swap the root at runtime. Closes the code_review_mcp_server
use case from the kglite wishlist.
Both modes share one activation state machine. Existing consumers may use
the serialized PostActivateHook callback family; concurrency-aware
consumers use ActivationTransactionHook to prepare off-lock and publish
only while their request generation is current. Both honour the same
last_built_sha gating to skip pointless rebuilds.
Re-exports§
pub use crate::server::manifest::WorkspaceKind;
Structs§
- Activation
Id - Monotonically increasing identity for one workspace activation request.
- Activation
Request - Immutable input to an
ActivationTransactionHook. - Prepared
Activation - Prepared downstream activation that has not yet been published.
- Workspace
- Workspace runtime state. Shared across MCP request clones via Arc.
Enums§
- Activation
Build - Work required for a request-scoped activation.
- Revs
Request - A revisions request carried by the activation tools.
Count(n)resolves to the newestnstable release tags of the repo’s dominant tag family (plusHEAD);List(revs)is an explicit set of git revspecs used verbatim. The untagged deserialization maps a JSON integer toCountand a JSON array of strings toList, so the tool arg acceptsint | [str]. Resolution happens at activate time — seeWorkspace::resolve_revs. - Root
Ownership - Who chose the currently active root.
Type Aliases§
- Activation
Summary Hook - Optional hook that returns a short agent-facing summary appended to
the activation result message — the “graph ready” mini-map / opening
steer (e.g.
"Graph ready: 9,999 Functions · 656 Classes · 31k CALLS. Open with graph_overview() → cypher_query; grep = literal text only."). - Activation
Transaction Hook - Request-scoped activation transaction.
- Post
Activate Hook - Hook fired after a successful clone or update. Receives the absolute
path to the cloned repo and the org/repo name. Legacy callback activations
are serialized through summary generation. Errors abort publication of the
framework’s new active source state; use
ActivationTransactionHookwhen downstream product installation must also be deferred until commit. - Post
Activate Revs Hook - Hook fired after a successful clone/update when revisions were
requested on the activation call (
repo_management(revs=…)/set_root_dir(revs=…)). Receives the repo path, theorg/repo(or synthetic local) name, and the resolved revspecs in oldest→newest order — for aCount(n)request the final entry is alwaysHEAD, so a downstream multi-rev builder can merge oldest→newest with HEAD’s signature winning. Set viaWorkspace::with_post_activate_revs.