audit: record crate boundary findings

This commit is contained in:
Keisuke Hirata 2026-05-28 22:25:54 +09:00
parent 92a9c1416c
commit 6083121574
No known key found for this signature in database
8 changed files with 2724 additions and 0 deletions

View File

@ -0,0 +1,412 @@
# Crate boundary audit
Date: 2026-05-28
## summary
The workspace dependency graph is broadly acyclic and mostly layered in the expected direction: `protocol` / `lint-common` / proc-macros sit at the bottom, `llm-worker` / `manifest` / `tools` / `provider` / `session-store` provide shared infrastructure, and `pod` / `tui` are orchestration or UI layers. I did not find a hard Cargo-level cycle or an obvious UI crate being depended on by a lower crate.
The main boundary problems are subtler:
1. `protocol` exposes several public wire payloads as `serde_json::Value` while documenting them as the JSON form of `session_store::*` types. This avoids a Rust dependency edge but creates a hidden schema dependency from `protocol`/clients to `session-store`.
2. `workflow` depends on `memory` for `WorkspaceLayout`, and `memory::WorkspaceLayout` owns workflow paths. This makes `memory` a cross-domain workspace-layout hub rather than only the memory subsystem.
3. Several lower/shared crates have comments/doc-comments explaining `Pod`, `TUI`, controller, prompt-catalog, or downstream orchestration behavior. Most are acceptable integration-contract notes, but a few are implementation knowledge that should move upward or be generalized.
No code, formatting, commits, merges, or project-record files outside `artifacts/` were changed.
## inspected commands / files
### Commands run
- `cargo metadata --no-deps --format-version 1 | jq ... > artifacts/deps.txt`
- Extracted workspace-internal normal/dev dependency edges.
- `cargo metadata --no-deps --format-version 1 | jq ... > artifacts/reverse-deps.txt`
- Extracted reverse dependency summary.
- `rg -n 'pub (struct|enum|fn|mod|trait|type|use) ...' crates --glob '*.rs' > artifacts/public-concept-hits.txt`
- Searched public APIs for boundary-relevant terms (`Pod`, `TUI`, `Workflow`, `Manifest`, `Memory`, `Session`, etc.).
- `rg -n '(^\s*(//!|///|//)\s?.*(...))' crates --glob '*.rs' > artifacts/comment-concept-hits.txt`
- Searched comments/doc-comments for crate names and upper-layer concepts.
- `rg -n 'TUI / GUI|session_store::|parent Controller|Pod treats|Pod side|...' ... > artifacts/suspicious-excerpts.txt`
- Narrowed suspicious comment excerpts.
- `rg -n 'use (session_store|pod_registry|llm_worker|manifest)::|...' crates/tui/src`
- Checked why TUI depends on lower internal crates.
- `rg -n 'WorkspaceLayout|memory::' crates/workflow/src`
- Checked `workflow -> memory` dependency use.
Failed exploratory commands:
- `python` / `python3` parse attempts failed because Python was not available in the environment; switched to `cargo metadata` + `jq`.
Supplemental raw outputs left in the artifact directory:
- `deps.txt`, `reverse-deps.txt`
- `deps-numbered.txt`, `reverse-deps-numbered.txt`
- `public-concept-hits.txt`
- `comment-concept-hits.txt`
- `suspicious-excerpts.txt`
### Main files inspected directly
- Root/workspace:
- `Cargo.toml`
- `work-items/open/20260528-131317-crate-boundary-audit/item.md`
- Cargo manifests:
- `crates/protocol/Cargo.toml`
- `crates/manifest/Cargo.toml`
- `crates/llm-worker/Cargo.toml`
- `crates/pod/Cargo.toml`
- `crates/client/Cargo.toml`
- `crates/tui/Cargo.toml`
- `crates/memory/Cargo.toml`
- `crates/workflow/Cargo.toml`
- `crates/provider/Cargo.toml`
- `crates/session-store/Cargo.toml`
- `crates/pod-registry/Cargo.toml`
- `crates/session-metrics/Cargo.toml`
- `crates/tools/Cargo.toml`
- `crates/daemon/Cargo.toml`
- `crates/lint-common/Cargo.toml`
- `crates/llm-worker-macros/Cargo.toml`
- Public/API and suspicious source files:
- `crates/protocol/src/lib.rs`
- `crates/manifest/src/lib.rs`
- `crates/manifest/src/model.rs`
- `crates/llm-worker/src/lib.rs`
- `crates/llm-worker/src/interceptor.rs`
- `crates/llm-worker/src/llm_client/types.rs`
- `crates/pod/src/lib.rs`
- `crates/pod/src/pod.rs` (grep/read excerpts)
- `crates/pod/src/spawn/comm_tools.rs` (grep excerpts)
- `crates/client/src/lib.rs`
- `crates/client/src/spawn.rs`
- `crates/tui/src/app.rs` (grep excerpts)
- `crates/tui/src/spawn.rs` (grep excerpts)
- `crates/tui/src/picker.rs` (grep excerpts)
- `crates/memory/src/lib.rs`
- `crates/memory/src/scope.rs`
- `crates/memory/src/workspace.rs`
- `crates/memory/src/extract/mod.rs` (grep excerpts)
- `crates/memory/src/consolidate/mod.rs` (grep excerpts)
- `crates/memory/src/resident.rs` (grep excerpts)
- `crates/workflow/src/lib.rs`
- `crates/workflow/src/linter.rs` (grep excerpts)
- `crates/workflow/src/scope.rs` (grep excerpts)
- `crates/workflow/src/workflow.rs` (grep excerpts)
- `crates/session-store/src/lib.rs`
- `crates/session-store/src/segment.rs`
- `crates/session-store/src/segment_log.rs` (grep excerpts)
- `crates/session-store/src/system_item.rs`
- `crates/session-store/src/pod_metadata.rs`
- `crates/pod-registry/src/lib.rs`
- `crates/provider/src/lib.rs`
- `crates/tools/src/lib.rs`
## dependency graph overview
Internal dependency edges from `cargo metadata --no-deps`:
```text
client -> manifest, protocol
daemon -> manifest, protocol
lint-common -> (none)
llm-worker -> llm-worker-macros
llm-worker-macros -> (none)
manifest -> llm-worker, protocol
memory -> lint-common, llm-worker, manifest
pod -> llm-worker, manifest, memory, pod-registry, protocol, provider, session-metrics, session-store, tools, workflow
pod-registry -> manifest, session-store
protocol -> (none)
provider -> llm-worker, manifest
session-metrics -> session-store
session-store -> llm-worker, protocol
tools -> llm-worker, manifest
tui -> client, llm-worker, manifest, pod-registry, protocol, session-store; dev-dep tools
workflow -> lint-common, manifest, memory
```
Reverse summary:
```text
client <- tui
lint-common <- memory, workflow
llm-worker <- manifest, memory, pod, provider, session-store, tools, tui
manifest <- client, daemon, memory, pod, pod-registry, provider, tools, tui, workflow
memory <- pod, workflow
pod-registry <- pod, tui
protocol <- client, daemon, manifest, pod, session-store, tui
provider <- pod
session-metrics <- pod
session-store <- pod, pod-registry, session-metrics, tui
tools <- pod, tui
workflow <- pod
```
This is directionally reasonable for orchestration-heavy code: `pod` is the main integrator; `tui` sits above `client` but also reads lower schemas; `protocol` has no Rust workspace dependencies.
## dependency/interface findings grouped by severity
### Severity: actual problem / should ticket
#### 1. `protocol` public API has hidden `session-store` schema coupling through `serde_json::Value`
Evidence:
- `crates/protocol/src/lib.rs:237` documents `Event::SystemItem.item` as the JSON form of `session_store::SystemItem`.
- `crates/protocol/src/lib.rs:394` documents `Event::Snapshot.entries` as the JSON form of `session_store::LogEntry`.
- `crates/protocol/src/lib.rs:419` documents `Event::SegmentRotated.entry` as the JSON form of `session_store::LogEntry::SegmentStart`.
- `crates/tui/src/app.rs:1236` and nearby lines deserialize snapshot entries back into `session_store::LogEntry`.
- `crates/tui/src/app.rs:1277` and nearby lines deserialize `Event::SystemItem.item` into `session_store::SystemItem`.
Why this is a boundary issue:
- `protocol` is dependency-free at the Cargo level, but its wire contract is not actually self-owned: clients must know `session-store` schemas to reconstruct state correctly.
- The type system cannot enforce compatibility between `protocol` and `session-store` because the public protocol type is only `serde_json::Value`.
- This explains why `tui` depends directly on `session-store` despite also depending on `client`/`protocol`.
Recommended direction:
- Extract the wire-stable log/system-item DTOs into a neutral crate, or move protocol-facing DTOs into `protocol` and have `session-store` convert to/from them.
- Avoid public protocol docs that say “this is `session_store::X` JSON” unless `session-store` is intentionally part of the protocol contract and typed as such.
#### 2. `workflow -> memory` dependency exists for shared workspace layout
Evidence:
- `crates/workflow/Cargo.toml:11` depends on `memory`.
- `crates/workflow/src/linter.rs:5`, `crates/workflow/src/scope.rs:6`, `crates/workflow/src/workflow.rs:17` use `memory::WorkspaceLayout`.
- `crates/memory/src/workspace.rs:8` includes `<root>/.insomnia/workflow/<slug>.md` in memory's layout documentation.
- `crates/memory/src/workspace.rs:16-18` says workflows are human-managed and live one level up under `.insomnia/workflow/`.
- `crates/memory/src/workspace.rs:127-165` exposes `workflow_dir()` / `workflow_path()` from the memory crate.
Why this is a boundary issue:
- `workflow` is conceptually a sibling subsystem, not a consumer of generated memory state.
- The current dependency is only for path layout. That makes `memory` own cross-subsystem workspace conventions and forces workflow to import a memory-domain crate for non-memory concerns.
- This is not severe yet, but it will make future workflow growth pull against crate ownership.
Recommended direction:
- Extract `WorkspaceLayout` / `.insomnia` path conventions into a neutral crate or a neutral module under `manifest`/new `workspace-layout` crate.
- Then make `memory` and `workflow` both depend on that neutral layout instead of depending on each other.
### Severity: suspicious but currently acceptable
#### 3. `session-store` owns Pod metadata and spawned-child metadata
Evidence:
- `crates/session-store/src/pod_metadata.rs:1-6` defines “Pod metadata persistence API”.
- `crates/session-store/src/pod_metadata.rs:42-60` defines `PodSpawnedScopeRule` / `PodSpawnedChild`, including delegated scope and `callback_address`.
- `crates/session-store/src/pod_metadata.rs:62-88` exposes `PodMetadata` and `PodMetadataStore` publicly.
Assessment:
- This is Pod/orchestration-specific state inside a crate named `session-store`.
- It is acceptable if `session-store` is intentionally “insomnia persistence primitives”, not a generic conversation-log crate. Current project decisions appear to lean that way.
- If the intended boundary is “session-store only stores sessions/segments/logs”, this should be split or renamed. If the intended boundary is “session-store stores all durable Pod state”, the naming/docs should say that explicitly.
Recommended direction:
- No immediate refactor unless the ownership goal changes.
- Clarify crate-level docs: either broaden `session-store`'s stated responsibility to durable Pod/session persistence, or split Pod metadata into a `pod-state`/`pod-metadata` crate.
#### 4. TUI directly depends on persistence/registry crates
Evidence:
- `crates/tui/Cargo.toml` depends on `session-store`, `pod-registry`, `manifest`, `llm-worker`, and `protocol` in addition to `client`.
- `crates/tui/src/picker.rs` uses `pod_registry::{LockFileGuard, default_registry_path}` and `session_store::{...}`.
- `crates/tui/src/app.rs:1236-1298` parses `session_store::LogEntry` / `session_store::SystemItem`.
- `crates/tui/src/spawn.rs:408-409` uses `session_store::FsStore` and `restore_by_segment` for resume-related paths.
Assessment:
- TUI is a top-level crate, so dependency direction is allowed.
- The direct `session-store` parse dependency is largely a symptom of finding #1: protocol sends untyped JSON whose real schema lives in `session-store`.
- Direct `pod-registry` access for picker/runtime discovery may be acceptable for a local-first TUI, but it bypasses a cleaner “TUI talks protocol/client only” boundary.
Recommended direction:
- Fix protocol DTO ownership first.
- After that, re-evaluate whether TUI still needs direct `session-store` and `pod-registry` dependencies or whether picker/discovery can move behind `client`/`protocol` APIs.
#### 5. `manifest -> llm-worker` dependency is acceptable but should remain one-way
Evidence:
- `crates/manifest/Cargo.toml` depends on `llm-worker` and `protocol`.
- `crates/manifest/src/model.rs:17-19` re-exports `llm_worker::llm_client::capability::{ModelCapability, ReasoningControl, ReasoningEffort}`.
Assessment:
- This is a reasonable tradeoff to avoid duplicate model-capability types.
- It does mean `manifest` is not a pure data crate independent of worker runtime types.
- The boundary remains acceptable as long as `llm-worker` does not depend back on `manifest`, and provider-level resolution stays in `provider`.
### Severity: no issue found
- No Rust workspace dependency cycle was found in the inspected graph.
- I did not find lower crates depending on `tui` or `client` implementation crates.
- `client -> protocol/manifest` and `pod -> provider/tools/session-store/memory/workflow` are directionally appropriate.
- `provider -> llm-worker/manifest` is appropriate: provider constructs concrete `LlmClient` implementations from resolved model configuration.
- `tools -> llm-worker/manifest` is appropriate: tools expose `ToolDefinition`s and enforce manifest scopes.
- `pod-registry -> session-store` is acceptable if registry entries need session/segment identity and durable state coordination.
## comment/doc-comment findings
### Problematic or should be generalized
#### `protocol` describes parent controller and pod-registry side effects
- `crates/protocol/src/lib.rs:65-70`
- `PodEvent` docs say the “parent Controller applies variant-specific side effects (registry / pod-registry updates)”.
- This is implementation knowledge from the `pod` crate inside a dependency-free protocol crate.
- Better: state the wire contract (“event is delivered to the parent; receiver is responsible for handling lifecycle effects”) and keep registry-specific behavior in `pod` docs.
#### `protocol` documents `session_store::*` JSON shapes as protocol payloads
- `crates/protocol/src/lib.rs:237`
- `crates/protocol/src/lib.rs:394`
- `crates/protocol/src/lib.rs:419`
This is the comment-level manifestation of the public-interface issue in finding #1.
#### `llm-worker` public request docs mention Pod-specific cache-key choice
- `crates/llm-worker/src/llm_client/types.rs:523-526`
- `Request::cache_key` doc says pod side is expected to pass `SegmentId`.
- `llm-worker` should expose the generic concept: a stable caller-provided conversation/cache namespace key.
- Pod's choice of `SegmentId` belongs in `pod` docs/tests, not in the generic request type.
#### `memory` docs prescribe Pod assembly details
- `crates/memory/src/lib.rs:3-7`
- Says generic CRUD tools must not touch memory/knowledge and Pod is responsible for denying them.
- `crates/memory/src/scope.rs:4-8`
- Says Pod is expected to call `deny_write_rules` and pass the result to `tools::ScopedFs`.
- `crates/memory/src/extract/mod.rs:3-14`
- Explains Pod post-run hook, `PromptCatalog`, `PodPrompt::MemoryExtractSystem`, and pointer persistence responsibility.
- `crates/memory/src/consolidate/mod.rs:5-15`
- Explains Pod assembling a disposable Worker and using `PodPrompt::MemoryConsolidationSystem`.
- `crates/memory/src/resident.rs:3-11`
- Says surfaces are used by the Pod system-prompt assembler and Pod IPC layer for TUI `#` completion.
Assessment:
- These are understandable because `memory` is currently a helper subsystem consumed by `pod`.
- They nevertheless make `memory` read like it is documenting Pod orchestration rather than memory-owned contracts.
- Prefer caller-neutral wording: “the orchestrator/caller registers these tools”, “the caller persists the pointer”, “completion consumers may use ...”. Keep Pod-specific sequence docs in `pod`.
### Suspicious but acceptable integration-contract comments
#### `protocol::Segment` docs mention TUI/GUI and Pod parsing behavior
- `crates/protocol/src/lib.rs:116-126`
- Mentions richer clients (TUI/GUI) producing typed atoms and Pod not re-parsing flattened strings.
- `crates/protocol/src/lib.rs:143-153`
- Mentions Pod resolving `FileRef` and treating unknown variants as unresolved input.
- `crates/protocol/src/lib.rs:222-231`
- Mentions additional TUI/GUI instances rendering user messages.
Assessment:
- Mentioning client classes can be acceptable in protocol docs when it explains wire semantics.
- The Pod behavior details are more debatable; they should be limited to required protocol semantics, not specific controller implementation.
#### `session-store::SystemItem` mentions TUI typed rendering
- `crates/session-store/src/system_item.rs:27-35`
- `crates/session-store/src/system_item.rs:49-52`
Assessment:
- It is valid to document why typed payload exists.
- “so the TUI can render” should probably be generalized to “so clients can render” because `session-store` is lower than `tui`.
#### `session-store::segment` mentions Pod as typical caller
- `crates/session-store/src/segment.rs:3-5`
- `crates/session-store/src/segment.rs:38-40`
- `crates/session-store/src/segment.rs:175-180`
- `crates/session-store/src/segment.rs:252-254`
Assessment:
- Mostly acceptable because Pod is currently the primary writer.
- Better wording would say “caller/orchestrator” first and optionally “e.g. Pod” only where it clarifies current integration.
#### `client` docs mention TUI/GUI/E2E
- `crates/client/src/lib.rs:9`
- `crates/client/src/spawn.rs:4-10`
- `crates/client/src/spawn.rs:92-96`
Assessment:
- Acceptable: `client` is explicitly a library for UI/GUI/E2E callers to speak Pod protocol. These are consumer examples rather than lower-layer implementation leakage.
#### `llm-worker::Interceptor` docs mention Pod as an upper layer
- `crates/llm-worker/src/interceptor.rs:3-6`
- `crates/llm-worker/src/interceptor.rs:122-126`
- `crates/llm-worker/src/interceptor.rs:140-146`
Assessment:
- Mostly acceptable: the docs explicitly say Worker does not know higher-level concepts and Pod is only an example upper layer.
- For stricter boundary hygiene, prefer “upper layers/orchestrators” and avoid naming Pod except in examples.
## acceptable dependency-aware comments criteria
I treated a comment as acceptable when it met at least one of these criteria:
1. It explains a public wire or file-format contract that consumers must honor, without prescribing one consumer's private implementation.
2. It names a higher layer only as an example (`e.g. Pod`) while the API remains generic and caller-owned.
3. It documents an intentional direction-of-control boundary, such as “the lower crate exposes a hook; upper layers implement policy”.
4. It references another crate that the current crate actually depends on and whose type or function is part of the local API.
5. It appears in tests/examples whose purpose is cross-crate contract verification.
I treated a comment as problematic when it did any of the following:
1. A lower crate explains what a dependent higher crate currently does internally.
2. A lower crate's public docs define a payload as another higher crate's private or semi-private JSON schema.
3. A shared subsystem describes its API mainly as a sequence of Pod/TUI orchestration steps, rather than a caller-neutral contract.
4. The comment reveals a hidden dependency that Cargo cannot type-check.
## recommended follow-up tickets
1. **Typed protocol snapshot/system-item payloads**
- Goal: remove `protocol` public `serde_json::Value` payloads whose real schemas are `session_store::*`.
- Candidate implementation directions:
- Move wire DTOs for log entries/system items into `protocol`, with `session-store` converting to/from them; or
- Extract a neutral `session-log-schema` / `wire-log` crate used by both `protocol` and `session-store`.
- Success condition: TUI/client code can parse snapshots/system items using protocol-owned typed structures, not `session_store::LogEntry` hidden behind JSON.
2. **Extract neutral workspace layout from `memory`**
- Goal: remove `workflow -> memory` when the only need is `.insomnia` path layout.
- Candidate implementation directions:
- New neutral crate/module for `WorkspaceLayout`; or
- Move `.insomnia` path layout into `manifest` if that crate is intended to own workspace configuration.
- Success condition: `workflow` and `memory` are siblings depending on a neutral layout owner.
3. **Boundary-comment hygiene pass**
- Goal: replace reverse-knowledge comments in lower/shared crates with caller-neutral wording.
- Scope:
- `protocol/src/lib.rs` controller/session-store JSON wording.
- `llm-worker/src/llm_client/types.rs` Pod `SegmentId` cache-key wording.
- `memory/src/{scope,extract,consolidate,resident}.rs` Pod/TUI orchestration wording.
- `session-store/src/{system_item,segment}.rs` TUI/Pod-specific wording where not required.
- Success condition: comments explain local contracts and extension points; dependent-crate implementation details live in the dependent crate.
4. **Clarify `session-store` crate responsibility**
- Goal: decide whether `session-store` is only session/segment log storage or the broader durable Pod-state persistence crate.
- If broader: update crate docs/naming comments to say so.
- If narrower: split `pod_metadata` into a Pod-owned persistence crate/module.
## unresolved questions
1. Is `protocol` intended to be the sole owner of all stable wire DTOs, or is `session-store` intentionally part of the protocol contract despite the current `serde_json::Value` indirection?
2. Is `session-store` deliberately the durable state crate for all Pod metadata, or should it be constrained to conversation/session logs?
3. Should `WorkspaceLayout` be considered a memory-domain concept, or a repository/workspace-domain concept shared by memory, knowledge, and workflow?
4. Should TUI remain allowed to inspect local registry/session files directly for picker and restore UX, or should those capabilities move behind `client`/`protocol` APIs?
5. Are comments allowed to name the primary current consumer (`Pod`) when documenting a generic lower-layer extension point, or should comments avoid such names unless the type itself is Pod-specific?

View File

@ -0,0 +1,58 @@
1 client:
2 -> manifest [normal]
3 -> protocol [normal]
4 daemon:
5 -> manifest [normal]
6 -> protocol [normal]
7 lint-common:
8 (no workspace deps)
9 llm-worker:
10 -> llm-worker-macros [normal]
11 llm-worker-macros:
12 (no workspace deps)
13 manifest:
14 -> llm-worker [normal]
15 -> protocol [normal]
16 memory:
17 -> lint-common [normal]
18 -> llm-worker [normal]
19 -> manifest [normal]
20 pod:
21 -> llm-worker [normal]
22 -> manifest [normal]
23 -> memory [normal]
24 -> pod-registry [normal]
25 -> protocol [normal]
26 -> provider [normal]
27 -> session-metrics [normal]
28 -> session-store [normal]
29 -> tools [normal]
30 -> workflow [normal]
31 pod-registry:
32 -> manifest [normal]
33 -> session-store [normal]
34 protocol:
35 (no workspace deps)
36 provider:
37 -> llm-worker [normal]
38 -> manifest [normal]
39 session-metrics:
40 -> session-store [normal]
41 session-store:
42 -> llm-worker [normal]
43 -> protocol [normal]
44 tools:
45 -> llm-worker [normal]
46 -> manifest [normal]
47 tui:
48 -> client [normal]
49 -> llm-worker [normal]
50 -> manifest [normal]
51 -> pod-registry [normal]
52 -> protocol [normal]
53 -> session-store [normal]
54 -> tools [dev]
55 workflow:
56 -> lint-common [normal]
57 -> manifest [normal]
58 -> memory [normal]

View File

@ -0,0 +1,58 @@
client:
-> manifest [normal]
-> protocol [normal]
daemon:
-> manifest [normal]
-> protocol [normal]
lint-common:
(no workspace deps)
llm-worker:
-> llm-worker-macros [normal]
llm-worker-macros:
(no workspace deps)
manifest:
-> llm-worker [normal]
-> protocol [normal]
memory:
-> lint-common [normal]
-> llm-worker [normal]
-> manifest [normal]
pod:
-> llm-worker [normal]
-> manifest [normal]
-> memory [normal]
-> pod-registry [normal]
-> protocol [normal]
-> provider [normal]
-> session-metrics [normal]
-> session-store [normal]
-> tools [normal]
-> workflow [normal]
pod-registry:
-> manifest [normal]
-> session-store [normal]
protocol:
(no workspace deps)
provider:
-> llm-worker [normal]
-> manifest [normal]
session-metrics:
-> session-store [normal]
session-store:
-> llm-worker [normal]
-> protocol [normal]
tools:
-> llm-worker [normal]
-> manifest [normal]
tui:
-> client [normal]
-> llm-worker [normal]
-> manifest [normal]
-> pod-registry [normal]
-> protocol [normal]
-> session-store [normal]
-> tools [dev]
workflow:
-> lint-common [normal]
-> manifest [normal]
-> memory [normal]

View File

@ -0,0 +1,202 @@
crates/llm-worker-macros/src/lib.rs:257: pub fn #definition_name(&self) -> ::llm_worker::tool::ToolDefinition {
crates/provider/src/codex_oauth/error.rs:49: pub fn to_client_error(self) -> ClientError {
crates/session-store/src/system_item.rs:114:pub fn render_pod_event(event: &PodEvent) -> String {
crates/memory/src/tool/read.rs:182:pub fn read_tool(layout: WorkspaceLayout) -> ToolDefinition {
crates/provider/src/codex_oauth/mod.rs:62: pub fn from_default_home() -> Result<Self, ClientError> {
crates/llm-worker/src/interceptor.rs:97:pub struct ToolCallInfo {
crates/llm-worker/src/interceptor.rs:107:pub struct ToolResultInfo {
crates/memory/src/tool/write.rs:188:pub fn write_tool(layout: WorkspaceLayout) -> ToolDefinition {
crates/session-store/src/lib.rs:69:pub type SessionId = uuid::Uuid;
crates/session-store/src/lib.rs:75:pub fn new_session_id() -> SessionId {
crates/memory/src/tool/query.rs:473:pub fn memory_query_tool(layout: WorkspaceLayout, config: QueryConfig) -> ToolDefinition {
crates/memory/src/tool/query.rs:488:pub fn knowledge_query_tool(layout: WorkspaceLayout, config: QueryConfig) -> ToolDefinition {
crates/session-store/src/pod_metadata.rs:18:pub struct PodActiveSegmentRef {
crates/session-store/src/pod_metadata.rs:26: pub fn pending_segment(session_id: SessionId) -> Self {
crates/session-store/src/pod_metadata.rs:34: pub fn active_segment(session_id: SessionId, segment_id: SegmentId) -> Self {
crates/session-store/src/pod_metadata.rs:46:pub struct PodSpawnedScopeRule {
crates/session-store/src/pod_metadata.rs:55:pub struct PodSpawnedChild {
crates/session-store/src/pod_metadata.rs:64:pub struct PodMetadata {
crates/session-store/src/pod_metadata.rs:74: pub fn new(pod_name: impl Into<String>, active: Option<PodActiveSegmentRef>) -> Self {
crates/session-store/src/pod_metadata.rs:88:pub trait PodMetadataStore: Send + Sync {
crates/memory/src/tool/mod.rs:33:pub enum MemoryToolKind {
crates/session-store/src/segment_log.rs:174:pub struct PodScopeSnapshot {
crates/llm-worker/src/worker.rs:57:pub enum ToolRegistryError {
crates/llm-worker/src/worker.rs:483: pub fn on_tool_result(&mut self, callback: impl Fn(&ToolResult) + Send + Sync + 'static) {
crates/llm-worker/src/worker.rs:528: pub fn tool_server_handle(&self) -> ToolServerHandle {
crates/llm-worker/src/worker.rs:1646: pub fn set_tool_output_limits(&mut self, limits: Option<ToolOutputLimits>) {
crates/memory/src/tool/edit.rs:268:pub fn edit_tool(layout: WorkspaceLayout) -> ToolDefinition {
crates/llm-worker/src/llm_client/transport.rs:98: pub fn with_http_client(mut self, client: reqwest::Client) -> Self {
crates/memory/src/tool/delete.rs:98:pub fn delete_tool(layout: WorkspaceLayout) -> ToolDefinition {
crates/llm-worker/src/lib.rs:56:pub use callback::{TextBlockScope, ThinkingBlockScope, ToolUseBlockScope};
crates/llm-worker/src/lib.rs:57:pub use handler::ToolUseBlockStart;
crates/llm-worker/src/lib.rs:60:pub use tool::{ToolCall, ToolOutputLimits, ToolResult};
crates/memory/src/scope.rs:19:pub fn deny_write_rules(layout: &WorkspaceLayout) -> Vec<ScopeRule> {
crates/llm-worker/src/llm_client/error.rs:7:pub enum ClientError {
crates/llm-worker/src/llm_client/error.rs:107:pub fn is_retryable(error: &ClientError) -> bool {
crates/llm-worker/src/tool.rs:16:pub enum ToolError {
crates/llm-worker/src/tool.rs:48:pub struct ToolOutputLimits {
crates/llm-worker/src/tool.rs:99:pub struct ToolOutput {
crates/llm-worker/src/tool.rs:135:pub struct ToolMeta {
crates/llm-worker/src/tool.rs:190:pub type ToolDefinition = Arc<dyn Fn() -> (ToolMeta, Arc<dyn Tool>) + Send + Sync>;
crates/llm-worker/src/tool.rs:245:pub trait Tool: Send + Sync {
crates/llm-worker/src/tool.rs:265:pub struct ToolCall {
crates/llm-worker/src/tool.rs:279:pub struct ToolResult {
crates/llm-worker/src/tool.rs:294: pub fn from_output(tool_use_id: impl Into<String>, output: ToolOutput) -> Self {
crates/memory/src/error.rs:10:pub enum MemoryError {
crates/pod-registry/src/error.rs:11:pub enum ScopeLockError {
crates/llm-worker/src/llm_client/capability.rs:41:pub enum ToolCallingSupport {
crates/llm-worker/src/tool_server.rs:13:pub enum ToolServerError {
crates/llm-worker/src/tool_server.rs:27:pub struct ToolServer {
crates/llm-worker/src/tool_server.rs:39: pub fn handle(&self) -> ToolServerHandle {
crates/llm-worker/src/tool_server.rs:49:pub struct ToolServerHandle {
crates/llm-worker/src/tool_server.rs:108: pub fn get_tool(&self, name: &str) -> Option<(ToolMeta, Arc<dyn Tool>)> {
crates/llm-worker/src/tool_server.rs:137: pub fn unregister(&self, name: &str) -> Result<(), ToolServerError> {
crates/llm-worker/src/tool_server.rs:150: pub fn replace(&self, factory: WorkerToolDefinition) -> Result<(), ToolServerError> {
crates/pod-registry/src/lifecycle.rs:18:pub struct ScopeAllocationGuard {
crates/pod-registry/src/lifecycle.rs:129:pub fn update_segment(pod_name: &str, new_segment_id: SegmentId) -> Result<(), ScopeLockError> {
crates/pod-registry/src/lifecycle.rs:164:pub fn lookup_segment(segment_id: SegmentId) -> Result<Option<SegmentLockInfo>, ScopeLockError> {
crates/llm-worker/src/callback.rs:191:pub struct ToolUseBlockScope {
crates/llm-worker/src/callback.rs:212: pub fn on_stop(&mut self, f: impl FnMut(&ToolCall) + Send + Sync + 'static) {
crates/memory/src/lib.rs:21:pub use error::{LintError, LintWarning, MemoryError};
crates/pod-registry/src/lib.rs:28:pub use error::ScopeLockError;
crates/llm-worker/examples/record_test_fixtures/recorder.rs:23:pub struct SessionMetadata {
crates/pod-registry/src/mutate.rs:161:pub fn release_pod(guard: &mut LockFileGuard, pod_name: &str) -> Result<(), ScopeLockError> {
crates/llm-worker/src/timeline/tool_call_collector.rs:30:pub struct ToolCallCollector {
crates/llm-worker/src/timeline/tool_call_collector.rs:44: pub fn take_collected(&self) -> Vec<ToolCall> {
crates/llm-worker/src/timeline/tool_call_collector.rs:50: pub fn collected(&self) -> Vec<ToolCall> {
crates/pod-registry/src/conflict.rs:50:pub fn is_within_effective_write(lock: &LockFile, parent: &str, rule: &ScopeRule) -> bool {
crates/memory/src/extract/tool.rs:92:pub fn write_extracted_tool(ctx: Arc<ExtractWorkerContext>) -> ToolDefinition {
crates/llm-worker/src/timeline/mod.rs:23:pub use tool_call_collector::ToolCallCollector;
crates/workflow/src/skill.rs:74: pub fn into_workflow_record(self, source: WorkflowSource) -> WorkflowRecord {
crates/llm-worker/src/handler.rs:158:pub struct ToolUseBlockKind;
crates/llm-worker/src/handler.rs:165:pub enum ToolUseBlockEvent {
crates/llm-worker/src/handler.rs:173:pub struct ToolUseBlockStart {
crates/llm-worker/src/handler.rs:180:pub struct ToolUseBlockStop {
crates/tui/src/input.rs:63:pub struct WorkflowInvokeAtom {
crates/workflow/src/schema.rs:12:pub struct WorkflowFrontmatter {
crates/workflow/src/schema.rs:45:pub fn split_frontmatter(content: &str) -> Result<(&str, &str), WorkflowLintError> {
crates/client/src/lib.rs:14:pub use pod_client::PodClient;
crates/workflow/src/workflow.rs:29:pub enum WorkflowSource {
crates/workflow/src/workflow.rs:50:pub struct WorkflowRecord {
crates/workflow/src/workflow.rs:93:pub struct WorkflowRegistry {
crates/workflow/src/workflow.rs:110: pub fn get(&self, slug: &Slug) -> Option<&WorkflowRecord> {
crates/workflow/src/workflow.rs:114: pub fn iter(&self) -> impl Iterator<Item = &WorkflowRecord> {
crates/workflow/src/workflow.rs:143: pub fn merge_skill(&mut self, record: WorkflowRecord) -> Option<ShadowedSkill> {
crates/workflow/src/workflow.rs:165:pub enum WorkflowLoadError {
crates/workflow/src/workflow.rs:191:pub fn load_workflows(layout: &WorkspaceLayout) -> Result<WorkflowRegistry, WorkflowLoadError> {
crates/client/src/pod_client.rs:9:pub struct PodClient {
crates/workflow/src/scope.rs:10:pub fn deny_write_rules(layout: &WorkspaceLayout) -> Vec<ScopeRule> {
crates/tui/src/block.rs:98:pub struct ToolCallBlock {
crates/tui/src/block.rs:113:pub enum ToolCallState {
crates/workflow/src/error.rs:10:pub enum WorkflowLintError {
crates/memory/src/workspace.rs:90: pub fn resolve(cfg: &manifest::MemoryConfig, default_root: &Path) -> Self {
crates/workflow/src/lib.rs:10:pub use error::WorkflowLintError;
crates/workflow/src/lib.rs:12:pub use linter::{WorkflowLintReport, WorkflowLinter};
crates/workflow/src/lib.rs:13:pub use schema::{WorkflowFrontmatter, split_frontmatter};
crates/workflow/src/linter.rs:15:pub struct WorkflowLintReport {
crates/workflow/src/linter.rs:24: pub fn push_error(&mut self, err: WorkflowLintError) {
crates/workflow/src/linter.rs:30:pub struct WorkflowLinter {
crates/workflow/src/linter.rs:47: pub fn lint(&self, content: &str) -> WorkflowLintReport {
crates/tui/src/tool.rs:22:pub struct ToolRenderOutput {
crates/tui/src/app.rs:193: pub fn set_pod_status(&mut self, status: PodStatus) {
crates/tools/src/task.rs:464:pub fn task_tools(store: TaskStore) -> Vec<ToolDefinition> {
crates/tools/src/bash.rs:330:pub fn bash_tool(fs: ScopedFs, output_dir: PathBuf) -> ToolDefinition {
crates/llm-worker/src/llm_client/scheme/openai_chat/events.rs:68: pub fn parse_event(&self, data: &str) -> Result<Option<Vec<Event>>, ClientError> {
crates/manifest/src/scope.rs:22:pub struct Scope {
crates/manifest/src/scope.rs:37:pub enum ScopeError {
crates/manifest/src/scope.rs:58: pub fn from_config(config: &ScopeConfig) -> Result<Self, ScopeError> {
crates/manifest/src/scope.rs:151: pub fn allow_rules(&self) -> Vec<ScopeRule> {
crates/manifest/src/scope.rs:168: pub fn deny_rules(&self) -> Vec<ScopeRule> {
crates/manifest/src/scope.rs:320: pub fn new(scope: Scope) -> Self {
crates/manifest/src/scope.rs:331: pub fn load(&self) -> Guard<Arc<Scope>> {
crates/manifest/src/scope.rs:338: pub fn snapshot(&self) -> Arc<Scope> {
crates/manifest/src/scope.rs:347: pub fn update<F>(&self, f: F) -> Result<(), ScopeError>
crates/tools/src/lib.rs:35:pub use error::ToolsError;
crates/tools/src/lib.rs:39:pub use scoped_fs::ScopedFs;
crates/tools/src/tracker.rs:116: pub fn verify(&self, path: &Path, current_bytes: &[u8]) -> Result<(), ToolsError> {
crates/llm-worker/src/llm_client/types.rs:573: pub fn tool(mut self, tool: ToolDefinition) -> Self {
crates/llm-worker/src/llm_client/types.rs:638:pub struct ToolDefinition {
crates/tools/src/read.rs:117:pub fn read_tool(fs: ScopedFs, tracker: Tracker) -> ToolDefinition {
crates/tools/src/glob.rs:196:pub fn glob_tool(fs: ScopedFs) -> ToolDefinition {
crates/tools/src/grep.rs:106:pub fn grep_tool(fs: ScopedFs) -> ToolDefinition {
crates/llm-worker/src/llm_client/client.rs:39:pub type ResponseStream = Pin<Box<dyn Stream<Item = Result<Event, ClientError>> + Send>>;
crates/tools/src/write.rs:78:pub fn write_tool(fs: ScopedFs, tracker: Tracker) -> ToolDefinition {
crates/manifest/src/lib.rs:19:pub use protocol::{Permission, ScopeRule};
crates/manifest/src/lib.rs:20:pub use scope::{Scope, ScopeError, SharedScope};
crates/manifest/src/lib.rs:35:pub struct PodManifest {
crates/manifest/src/lib.rs:90:pub struct MemoryConfig {
crates/manifest/src/lib.rs:153:pub struct PodMeta {
crates/manifest/src/lib.rs:223:pub struct ToolOutputLimits {
crates/manifest/src/lib.rs:295:pub struct ScopeConfig {
crates/manifest/src/lib.rs:307:pub struct SessionConfig {
crates/manifest/src/lib.rs:320:pub struct ToolPermissionConfig {
crates/manifest/src/lib.rs:328:pub struct ToolPermissionRule {
crates/manifest/src/lib.rs:341:pub enum ToolPermissionAction {
crates/tools/src/edit.rs:137:pub fn edit_tool(fs: ScopedFs, tracker: Tracker) -> ToolDefinition {
crates/tools/src/error.rs:12:pub enum ToolsError {
crates/tools/src/scoped_fs.rs:34:pub struct ScopedFs {
crates/tools/src/scoped_fs.rs:67: pub fn new(scope: Scope, pwd: PathBuf) -> Self {
crates/tools/src/scoped_fs.rs:83: pub fn scope(&self) -> Arc<Scope> {
crates/tools/src/scoped_fs.rs:108: pub fn read_bytes(&self, path: &Path) -> Result<Vec<u8>, ToolsError> {
crates/tools/src/scoped_fs.rs:160: pub fn write(&self, path: &Path, content: &[u8]) -> Result<WriteOutcome, ToolsError> {
crates/manifest/src/config.rs:28:pub struct PodManifestConfig {
crates/manifest/src/config.rs:58:pub struct PodMetaConfig {
crates/manifest/src/config.rs:95:pub struct ToolOutputLimitsPartial {
crates/manifest/src/config.rs:109:pub struct SessionConfigPartial {
crates/manifest/src/config.rs:282: pub fn merge(self, upper: PodManifestConfig) -> Self {
crates/pod/src/controller.rs:34:pub struct PodHandle {
crates/pod/src/controller.rs:130:pub struct PodController;
crates/protocol/src/lib.rs:77:pub enum PodEvent {
crates/protocol/src/lib.rs:492:pub struct MemoryWorkerEvent {
crates/protocol/src/lib.rs:575:pub enum PodStatus {
crates/protocol/src/lib.rs:649:pub struct ScopeRule {
crates/manifest/src/cascade.rs:63:pub fn load_layer(path: &Path) -> Result<PodManifestConfig, LayerLoadError> {
crates/pod/src/ipc/event.rs:46:pub fn fire_and_forget(socket: Option<PathBuf>, event: PodEvent) {
crates/pod/src/ipc/event.rs:60:pub fn render_event(event: &PodEvent) -> String {
crates/pod/src/lib.rs:20:pub use controller::{PodController, PodHandle, ShutdownReceiver};
crates/pod/src/lib.rs:21:pub use factory::{FactoryError, PodFactory};
crates/pod/src/lib.rs:28:pub use pod::{Pod, PodError, PodRunResult, apply_worker_manifest};
crates/pod/src/lib.rs:29:pub use prompt::catalog::{CatalogError, PodPrompt, PromptCatalog};
crates/pod/src/lib.rs:32:pub use protocol::{ErrorCode, Event, Method, PodStatus, TurnResult};
crates/pod/src/lib.rs:36:pub use shared_state::PodSharedState;
crates/pod/src/ipc/notify_buffer.rs:68: pub fn push_pod_event(&self, event: PodEvent) {
crates/pod/src/shared_state.rs:10:pub struct WorkflowCandidate {
crates/pod/src/shared_state.rs:29:pub struct PodSharedState {
crates/pod/src/shared_state.rs:67: pub fn set_fs_view(&self, view: PodFsView) {
crates/pod/src/shared_state.rs:73: pub fn fs_view(&self) -> Option<&PodFsView> {
crates/pod/src/shared_state.rs:77: pub fn set_workflows(&self, workflows: Vec<WorkflowCandidate>) {
crates/pod/src/shared_state.rs:81: pub fn list_workflow_completions(&self, prefix: &str) -> Vec<WorkflowCandidate> {
crates/pod/src/shared_state.rs:111: pub fn set_status(&self, status: PodStatus) {
crates/pod/src/shared_state.rs:117: pub fn get_status(&self) -> PodStatus {
crates/pod/src/pod.rs:86: pub fn new(session_id: SessionId, segment_id: SegmentId, entries_written: usize) -> Arc<Self> {
crates/pod/src/pod.rs:100: pub fn session_id(&self) -> SessionId {
crates/pod/src/pod.rs:222:pub struct Pod<C: LlmClient, St: Store> {
crates/pod/src/pod.rs:690: pub fn session_id(&self) -> SessionId {
crates/pod/src/pod.rs:695: pub fn manifest(&self) -> &PodManifest {
crates/pod/src/pod.rs:713: pub fn scope_snapshot(&self) -> Arc<Scope> {
crates/pod/src/pod.rs:791: pub fn scope_change_sink(&self) -> Arc<dyn Fn(PodScopeSnapshot) + Send + Sync> {
crates/pod/src/pod.rs:1056: pub fn push_pod_event_notify(&self, event: protocol::PodEvent) {
crates/pod/src/pod.rs:4061:pub enum PodRunResult {
crates/pod/src/pod.rs:4332:pub enum PodError {
crates/pod/src/discovery.rs:33:pub struct PodDiscovery<St> {
crates/pod/src/discovery.rs:368:pub enum PodStateStatus {
crates/pod/src/discovery.rs:441:pub struct PodDetail {
crates/pod/src/discovery.rs:482:pub enum PodDiscoveryError {
crates/pod/src/discovery.rs:678:pub fn list_visible_pods_tool<St>(discovery: PodDiscovery<St>) -> ToolDefinition
crates/pod/src/discovery.rs:699:pub fn inspect_pod_tool<St>(discovery: PodDiscovery<St>) -> ToolDefinition
crates/pod/src/discovery.rs:716:pub fn attach_or_restore_pod_tool<St>(discovery: PodDiscovery<St>) -> ToolDefinition
crates/pod/src/factory.rs:76:pub struct PodFactory {
crates/pod/src/factory.rs:189: pub fn with_overlay_config(mut self, config: PodManifestConfig) -> Result<Self, FactoryError> {
crates/pod/src/factory.rs:241: pub fn resolve(self) -> Result<(PodManifest, PromptLoader), FactoryError> {
crates/pod/src/hook.rs:75:pub struct ToolCallSummary {
crates/pod/src/hook.rs:90:pub struct ToolResultSummary {
crates/pod/src/fs_view.rs:40:pub struct PodFsView {
crates/pod/src/fs_view.rs:77: pub fn new(fs: ScopedFs) -> Self {
crates/pod/src/fs_view.rs:81: pub fn fs(&self) -> &ScopedFs {
crates/pod/src/workflow/mod.rs:17:pub enum WorkflowResolveError {
crates/pod/src/prompt/catalog.rs:61:pub enum PodPrompt {
crates/pod/src/prompt/catalog.rs:303: pub fn render(&self, prompt: PodPrompt, ctx: Value) -> Result<String, CatalogError> {
crates/pod/src/spawn/comm_tools.rs:94:pub fn send_to_pod_tool(registry: Arc<SpawnedPodRegistry>) -> ToolDefinition {
crates/pod/src/spawn/comm_tools.rs:169:pub fn read_pod_output_tool(registry: Arc<SpawnedPodRegistry>) -> ToolDefinition {
crates/pod/src/spawn/comm_tools.rs:229:pub fn stop_pod_tool(registry: Arc<SpawnedPodRegistry>) -> ToolDefinition {
crates/pod/src/spawn/comm_tools.rs:299:pub fn list_pods_tool(registry: Arc<SpawnedPodRegistry>) -> ToolDefinition {

View File

@ -0,0 +1,16 @@
1 client <- tui
2 daemon <-
3 lint-common <- memory, workflow
4 llm-worker <- manifest, memory, pod, provider, session-store, tools, tui
5 llm-worker-macros <- llm-worker
6 manifest <- client, daemon, memory, pod, pod-registry, provider, tools, tui, workflow
7 memory <- pod, workflow
8 pod <-
9 pod-registry <- pod, tui
10 protocol <- client, daemon, manifest, pod, session-store, tui
11 provider <- pod
12 session-metrics <- pod
13 session-store <- pod, pod-registry, session-metrics, tui
14 tools <- pod, tui
15 tui <-
16 workflow <- pod

View File

@ -0,0 +1,16 @@
client <- tui
daemon <-
lint-common <- memory, workflow
llm-worker <- manifest, memory, pod, provider, session-store, tools, tui
llm-worker-macros <- llm-worker
manifest <- client, daemon, memory, pod, pod-registry, provider, tools, tui, workflow
memory <- pod, workflow
pod <-
pod-registry <- pod, tui
protocol <- client, daemon, manifest, pod, session-store, tui
provider <- pod
session-metrics <- pod
session-store <- pod, pod-registry, session-metrics, tui
tools <- pod, tui
tui <-
workflow <- pod

View File

@ -0,0 +1,35 @@
crates/protocol/src/lib.rs:68:/// parent Controller applies variant-specific side effects (registry /
crates/protocol/src/lib.rs:118:/// `Segment::Text`; richer clients (TUI / GUI) construct typed atoms
crates/protocol/src/lib.rs:120:/// send them through directly so the Pod side never has to re-parse a
crates/protocol/src/lib.rs:124:/// `Segment::Unknown`. Pod treats this the same as known-but-unresolved
crates/protocol/src/lib.rs:152: /// Unknown variant from a newer client. Pod treats this as an
crates/protocol/src/lib.rs:224: /// additional TUI / GUI instances show the same pending user line
crates/protocol/src/lib.rs:237: /// Carries the JSON form of `session_store::SystemItem`. Covers
crates/protocol/src/lib.rs:394: /// as the JSON form of `session_store::LogEntry`. This is the
crates/protocol/src/lib.rs:419: /// Payload is the JSON form of `session_store::LogEntry::SegmentStart`.
crates/protocol/src/lib.rs:459: /// `CompactDone` (with the new `SegmentId`); failure by `CompactFailed`.
crates/llm-worker/src/llm_client/types.rs:523: /// 会話単位の安定キー。`prompt_cache_key` として送られる
crates/llm-worker/src/llm_client/types.rs:526: /// ほぼヒットしないため、pod 側で `SegmentId` を渡す運用を想定。
crates/llm-worker/src/llm_client/types.rs:529: /// `prompt_cache_key` を持たない provider は無視する。
crates/session-store/src/segment.rs:11:use crate::{SegmentId, SessionId};
crates/session-store/src/segment.rs:29:) -> Result<(SessionId, SegmentId), StoreError> {
crates/session-store/src/segment.rs:44: segment_id: SegmentId,
crates/session-store/src/segment.rs:69: source_segment_id: SegmentId,
crates/session-store/src/segment.rs:71:) -> Result<SegmentId, StoreError> {
crates/session-store/src/segment.rs:96: segment_id: SegmentId,
crates/session-store/src/segment.rs:109: segment_id: SegmentId,
crates/session-store/src/segment.rs:146: segment_id: &mut SegmentId,
crates/session-store/src/segment.rs:184: segment_id: SegmentId,
crates/session-store/src/segment.rs:209: segment_id: SegmentId,
crates/session-store/src/segment.rs:258: segment_id: SegmentId,
crates/session-store/src/segment.rs:276: segment_id: SegmentId,
crates/session-store/src/segment.rs:294: segment_id: SegmentId,
crates/session-store/src/segment.rs:317: segment_id: SegmentId,
crates/session-store/src/segment.rs:342: segment_id: SegmentId,
crates/session-store/src/segment.rs:372: segment_id: SegmentId,
crates/session-store/src/segment.rs:392: segment_id: SegmentId,
crates/session-store/src/segment.rs:409: segment_id: SegmentId,
crates/session-store/src/segment.rs:432:) -> Result<(SessionId, SegmentId), StoreError> {
crates/session-store/src/segment.rs:466: source_id: SegmentId,
crates/session-store/src/segment.rs:468:) -> Result<SegmentId, StoreError> {
crates/session-store/src/segment.rs:511: segment_id: SegmentId,