refactor: rename pod crate to worker
This commit is contained in:
+3
-3
@@ -8,7 +8,7 @@ It is not a dumping ground for external research, old plans, API inventories, or
|
||||
|
||||
1. [`design/overview.md`](design/overview.md) — the system map.
|
||||
2. [`design/context-history.md`](design/context-history.md) — the highest-risk invariant: inputs that affect the model must be committed to history before they enter context.
|
||||
3. [`design/pod-session-state.md`](design/pod-session-state.md) — Pod identity, replayable session logs, current metadata, and live process hints.
|
||||
3. [`design/worker-session-state.md`](design/worker-session-state.md) — Worker identity, replayable session logs, current metadata, and live process hints.
|
||||
4. [`design/profiles-manifests-prompts.md`](design/profiles-manifests-prompts.md) — reusable Profiles, resolved Manifests, and prompt resources.
|
||||
5. [`design/tool-permissions-scope.md`](design/tool-permissions-scope.md) — tool policy and filesystem scope.
|
||||
6. [`design/plugin-packages.md`](design/plugin-packages.md) — plugin package distribution, discovery, and enablement boundaries.
|
||||
@@ -24,10 +24,10 @@ Keep documentation when it records a stable design boundary, a non-obvious ratio
|
||||
|
||||
Examples that belong:
|
||||
|
||||
- Why Pod metadata is not the session log.
|
||||
- Why Worker metadata is not the session log.
|
||||
- Why `Profile` and resolved `Manifest` are different layers.
|
||||
- Why context-only event injection is forbidden.
|
||||
- Why child Pod notifications are hints rather than completion proof.
|
||||
- Why child Worker notifications are hints rather than completion proof.
|
||||
|
||||
## What does not belong here
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ This rule protects both explainability and prompt-cache behavior. If the model r
|
||||
|
||||
## Allowed context transformations
|
||||
|
||||
A context transformation is acceptable when it is reproducible from durable Pod state and does not introduce new volatile facts.
|
||||
A context transformation is acceptable when it is reproducible from durable Worker state and does not introduce new volatile facts.
|
||||
|
||||
Examples:
|
||||
|
||||
@@ -23,7 +23,7 @@ Do not insert turn-crossing information directly into context without first appe
|
||||
|
||||
Forbidden examples:
|
||||
|
||||
- Delivering a `Notify` or `PodEvent` only as a temporary context note.
|
||||
- Delivering a `Notify` or `WorkerEvent` only as a temporary context note.
|
||||
- Adding a `<system-reminder>` that explains behavior but is not persisted.
|
||||
- Rewriting old messages to include new facts.
|
||||
- Letting UI/controller-only state become model-visible without a committed record.
|
||||
|
||||
@@ -7,25 +7,25 @@ That rule shapes the crate split. The runtime can restart, attach, compact, or d
|
||||
## Core layers
|
||||
|
||||
- `yoi` owns the product CLI and top-level command shape. It is the façade that wires profile selection, memory linting, and normal TUI launch.
|
||||
- `pod` turns a `Engine` into a named runtime entity with scope, session persistence, protocol handling, tools, and Pod metadata integration.
|
||||
- `worker` turns a `Engine` into a named runtime entity with scope, session persistence, protocol handling, tools, and Worker metadata integration.
|
||||
- `llm-engine` owns model-facing turns: history append, retries, continuation, pruning/compaction mechanics, tool loops, and provider-independent callbacks.
|
||||
- `session-store` owns replayable append-only conversation/session logs.
|
||||
- `pod-store` owns current Pod metadata keyed by Pod name.
|
||||
- `pod-store` owns current Worker metadata keyed by Worker name.
|
||||
- `protocol` defines the socket message boundary between clients and Pods.
|
||||
- `client` contains reusable one-shot socket/runtime-command mechanics so lower crates do not depend on the product CLI.
|
||||
- `manifest` resolves Profiles, Manifests, model/provider references, scopes, prompts, and tool permission policy into a runtime contract.
|
||||
- `tools` implements built-in tools with bounded output and policy-aware execution.
|
||||
- `memory` owns generated memory, Knowledge records, linting, staging, and audit observations.
|
||||
- `workspace-server` is the local Workspace control-plane seam. It can project Tickets, Workers, lifecycle, usage, and orchestration events, but browser/API operations must stay on opaque backend identities instead of raw local paths, sockets, Pod names, or session files.
|
||||
- `tui` is a UI over Pod authority; it should not invent durable state.
|
||||
- `workspace-server` is the local Workspace control-plane seam. It can project Tickets, Workers, lifecycle, usage, and orchestration events, but browser/API operations must stay on opaque backend identities instead of raw local paths, sockets, Worker names, or session files.
|
||||
- `tui` is a UI over Worker authority; it should not invent durable state.
|
||||
|
||||
## Why these boundaries exist
|
||||
|
||||
The Engine should not know process identity, Pod names, live sockets, spawned children, or UI state. It should know how to run an LLM turn over committed history and tools.
|
||||
The Engine should not know process identity, Worker names, live sockets, spawned children, or UI state. It should know how to run an LLM turn over committed history and tools.
|
||||
|
||||
The Pod should not make provider-specific wire decisions. It coordinates runtime identity, persistence, scope, and protocol delivery around a Engine.
|
||||
The Worker should not make provider-specific wire decisions. It coordinates runtime identity, persistence, scope, and protocol delivery around a Engine.
|
||||
|
||||
The TUI should not be an alternate source of truth. It may queue local input, show optimistic affordances, and render snapshots, but durable state comes from Pod/session records.
|
||||
The TUI should not be an alternate source of truth. It may queue local input, show optimistic affordances, and render snapshots, but durable state comes from Worker/session records.
|
||||
|
||||
The CLI should own product command shape. Other crates should expose library APIs and typed runtime commands rather than re-parsing product arguments.
|
||||
|
||||
|
||||
@@ -79,7 +79,7 @@ Packages under `${XDG_DATA_HOME:-~/.local/share}/yoi/plugins/` or `<workspace>/.
|
||||
|
||||
Trust differs by source, but none of the sources is self-authorizing:
|
||||
|
||||
- Builtin packages can be trusted as shipped code/data, but still require explicit enablement for a Pod/Profile when they affect runtime behavior.
|
||||
- Builtin packages can be trusted as shipped code/data, but still require explicit enablement for a Worker/Profile when they affect runtime behavior.
|
||||
- User packages are local user-installed artifacts and should be visible to workspaces, but they cannot bypass manifest/profile/tool/scope/secret policy.
|
||||
- Project packages are repository-controlled artifacts and should be treated as untrusted until explicitly enabled by local policy. Cloning a repository must not be enough to execute a package.
|
||||
|
||||
@@ -99,7 +99,7 @@ Collision handling:
|
||||
|
||||
Discovery is a read-only inventory operation. It may report package metadata, validation errors, source, canonical store path, and deterministic digest. It must not initialize any runtime contribution.
|
||||
|
||||
Enablement is a resolved runtime plan. It should come from Profile/manifest configuration or another explicit local policy layer, then be recorded into the resolved Manifest/session metadata used to start the Pod. Restored Pods should use that resolved enabled-plugin plan instead of silently re-running fresh discovery and picking newer packages. Fresh discovery must not silently upgrade a restored Pod.
|
||||
Enablement is a resolved runtime plan. It should come from Profile/manifest configuration or another explicit local policy layer, then be recorded into the resolved Manifest/session metadata used to start the Worker. Restored Pods should use that resolved enabled-plugin plan instead of silently re-running fresh discovery and picking newer packages. Fresh discovery must not silently upgrade a restored Worker.
|
||||
|
||||
A minimal implemented enablement record is shaped like this. `version` is an exact package-version requirement; richer range constraints are deferred. `digest` is optional in authoring config, but fresh startup records the resolved digest into runtime metadata.
|
||||
|
||||
@@ -111,7 +111,7 @@ digest = "sha256:..." # optional pin in authoring, resolved in runtime metadata
|
||||
config = { level = "concise" }
|
||||
```
|
||||
|
||||
If no digest is pinned in authoring, fresh startup may resolve the newest acceptable discovered package according to explicit policy. Once a Pod is started, the resolved manifest/session metadata should record the exact source-qualified id and digest so restore is stable.
|
||||
If no digest is pinned in authoring, fresh startup may resolve the newest acceptable discovered package according to explicit policy. Once a Worker is started, the resolved manifest/session metadata should record the exact source-qualified id and digest so restore is stable.
|
||||
|
||||
## Permissions and grants
|
||||
|
||||
@@ -125,7 +125,7 @@ Plugin permission declarations are requests, not grants. Effective grants are th
|
||||
- secret references and secret-store policy;
|
||||
- runtime limits for WASM or other execution engines.
|
||||
|
||||
The Plugin package permission model must not reuse `pod::feature` HostAuthority or grant concepts. The feature layer is an API/contribution substrate; it is not a security boundary for untrusted plugin packages. Plugin grants need their own explicit policy that can fail closed before a Hook, Tool, WASM host function, provider bridge, or external runtime is exposed.
|
||||
The Plugin package permission model must not reuse `worker::feature` HostAuthority or grant concepts. The feature layer is an API/contribution substrate; it is not a security boundary for untrusted plugin packages. Plugin grants need their own explicit policy that can fail closed before a Hook, Tool, WASM host function, provider bridge, or external runtime is exposed.
|
||||
|
||||
When a package requests authority outside policy, diagnostics should explain the denied category and package identity without leaking raw secret values, environment contents, full private config, or large plugin-provided text.
|
||||
|
||||
@@ -157,7 +157,7 @@ Optional lock behavior can be added in a later Ticket:
|
||||
|
||||
- an authoring-time pin in Profile/manifest configuration;
|
||||
- a workspace lock file recording source-qualified id, version, source store, digest, and selected package path;
|
||||
- restore metadata that records the actual digest used by the Pod.
|
||||
- restore metadata that records the actual digest used by the Worker.
|
||||
|
||||
A lock or pin is selection authority, not execution authority. Enablement and grants are still required.
|
||||
|
||||
@@ -192,7 +192,7 @@ Good follow-up Tickets are intentionally separable:
|
||||
1. Manifest/Profile plugin enablement schema and resolved-session metadata, including restore behavior and digest pins.
|
||||
2. Package discovery for builtin, user, and project stores with source-qualified identity and collision diagnostics.
|
||||
3. `.yoi-plugin` archive validation, deterministic digest computation, and digest-keyed cache materialization.
|
||||
4. Plugin-layer permission policy that combines package requests with existing tool/scope/web/secret/runtime allowlists without using `pod::feature` HostAuthority concepts.
|
||||
4. Plugin-layer permission policy that combines package requests with existing tool/scope/web/secret/runtime allowlists without using `worker::feature` HostAuthority concepts.
|
||||
5. Declarative hook package loading from enabled, materialized packages.
|
||||
6. WASM package ABI, initialization limits, host-function grants, and Tool/Hook contribution plumbing.
|
||||
7. Optional lock-file or pin update workflow for reproducible fresh startup.
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
# Pod, session, and state authority
|
||||
|
||||
Yoi separates replayable history from current Pod identity because they answer different questions.
|
||||
|
||||
A session log answers: "what happened and what can be replayed?" Pod metadata answers: "what does this Pod name currently refer to?" Live sockets and registries answer only: "what seems reachable right now?"
|
||||
|
||||
## Session logs
|
||||
|
||||
Session JSONL is the durable replay record. It contains committed user inputs, assistant items, tool results, system/runtime events that must explain later behavior, segment boundaries, and persisted effective snapshots needed to understand a run.
|
||||
|
||||
The session log should be append-oriented and schema drift should be compile-visible. Compatibility shims that silently reinterpret old plural/current entries make future readers less safe.
|
||||
|
||||
Session logs do not own current Pod-name state. A historical session can be replayable without being the active session for a Pod name.
|
||||
|
||||
## Pod metadata
|
||||
|
||||
Pod metadata is the current-state layer keyed by Pod name. It records active/pending session pointers, resolved manifest snapshots, current delegation metadata, spawned-child visibility, and restoration information.
|
||||
|
||||
This avoids reconstructing current Pod state by scanning every session log. It also gives `--pod <name>`, TUI resume, `ListPods`, and `RestorePod` a single current authority.
|
||||
|
||||
Pod metadata should stay thin. It is not a second transcript, and it should not duplicate model conversation content.
|
||||
|
||||
## Live runtime hints
|
||||
|
||||
Sockets, process registries, and runtime files are liveness hints. They are useful for attach, status probing, and fast discovery, but they are not final proof that work completed or that a Pod's state changed durably.
|
||||
|
||||
A reachable pending Pod should be visible even if durable logs have not materialized yet. Missing restore labels should degrade labels and diagnostics, not hide a live attachable Pod.
|
||||
|
||||
## Spawned children and delegation
|
||||
|
||||
Parent-visible children are sourced from Pod metadata, not from a transient runtime mirror. Restoring a parent should reconstruct reachable children where possible and keep stopped-but-restorable children visible when metadata supports it.
|
||||
|
||||
Delegated write scope is a capability loan. Stopping, shutting down, or pruning a child must reclaim the parent's effective write permissions while preserving explicit base denies.
|
||||
|
||||
## Peer Pods
|
||||
|
||||
Peer visibility is also Pod metadata, but it is distinct from spawned-child delegation. A TUI user can run `:peer <pod-name>` while attached to an idle Pod to register reciprocal peer metadata with another existing Pod. This is a metadata-level registration, not live target-controller consent.
|
||||
|
||||
A peer relationship only makes the Pods mutually visible through `ListPods` with visibility source `peer`. It does not grant filesystem scope, create a child output cursor, make either Pod the other's parent, or imply child completion notifications. Peer messages use `SendToPeerPod`, which delivers a labeled notification into the target Pod's normal durable notification/history path. `SendToPeerPod` requires the peer to be live and fails clearly for non-live peers rather than auto-restoring them.
|
||||
|
||||
## Notifications are not authority
|
||||
|
||||
Pod completion notifications are UX hints. Before treating delegated work as complete, inspect queryable evidence: child output, session/log state, worktree status, diffs, and validation output.
|
||||
|
||||
This is why orchestration code should expose state-aware operations such as `ListPods` and `RestorePod`, rather than letting a background alert decide workflow state by itself.
|
||||
@@ -4,11 +4,11 @@ Profiles are reusable recipes. Resolved Manifests are runtime contracts. Prompt
|
||||
|
||||
## Profiles
|
||||
|
||||
A Profile describes how a Pod should normally be built: worker language, model/provider selectors, prompt choices, tool policy defaults, and other reusable preferences.
|
||||
A Profile describes how a Worker should normally be built: worker language, model/provider selectors, prompt choices, tool policy defaults, and other reusable preferences.
|
||||
|
||||
A Profile should not contain runtime-bound fields:
|
||||
|
||||
- `pod.name`
|
||||
- `worker.name`
|
||||
- concrete delegated `scope.allow`
|
||||
- sockets or process identifiers
|
||||
- session pointers
|
||||
@@ -21,13 +21,13 @@ Yoi is Lua Profile first. Lua gives project/user authors a controlled recipe lay
|
||||
|
||||
## Manifests
|
||||
|
||||
A resolved Manifest is the concrete contract used to create or restore a Pod. It carries defaults, resolved paths, permissions, scope, prompt references, provider/model decisions, and runtime identity.
|
||||
A resolved Manifest is the concrete contract used to create or restore a Worker. It carries defaults, resolved paths, permissions, scope, prompt references, provider/model decisions, and runtime identity.
|
||||
|
||||
Source/partial layers may omit fields. Resolved manifests should be explicit enough that Pod creation does not depend on ambient configuration later changing under it.
|
||||
Source/partial layers may omit fields. Resolved manifests should be explicit enough that Worker creation does not depend on ambient configuration later changing under it.
|
||||
|
||||
`--manifest <path>` exists as an explicit low-level escape hatch. Normal fresh startup should select a Profile through `profiles.toml` / builtin defaults rather than ambient manifest cascades.
|
||||
|
||||
For normal Profile/default startup, a workspace may add `.yoi/override.local.toml` as a final local manifest layer. Yoi discovers the nearest ancestor `.yoi/override.local.toml` from the workspace base used for profile resolution, resolves relative paths in that file against its containing `.yoi` directory, and applies it after the selected Profile and builtin defaults. This file is intended for machine-local choices such as provider/model, worker language, prompt pack, and permission policy tweaks; it is ignored by git via the repository `*.local.*` rule. It is not applied in explicit `--manifest <path>` mode, and it cannot set `pod.name` because Pod identity remains a runtime input.
|
||||
For normal Profile/default startup, a workspace may add `.yoi/override.local.toml` as a final local manifest layer. Yoi discovers the nearest ancestor `.yoi/override.local.toml` from the workspace base used for profile resolution, resolves relative paths in that file against its containing `.yoi` directory, and applies it after the selected Profile and builtin defaults. This file is intended for machine-local choices such as provider/model, worker language, prompt pack, and permission policy tweaks; it is ignored by git via the repository `*.local.*` rule. It is not applied in explicit `--manifest <path>` mode, and it cannot set `worker.name` because Worker identity remains a runtime input.
|
||||
|
||||
## Local stdio MCP server declarations
|
||||
|
||||
@@ -62,7 +62,7 @@ Local stdio MCP servers are ordinary local executables running with the user's O
|
||||
|
||||
## Spawned Pods
|
||||
|
||||
`SpawnPod.profile` is optional and resolves through defaults when omitted. The only concrete capability delegation in the tool call is `SpawnPod.scope`, and it must be a subset of the parent's effective scope.
|
||||
`SpawnWorker.profile` is optional and resolves through defaults when omitted. The only concrete capability delegation in the tool call is `SpawnWorker.scope`, and it must be a subset of the parent's effective scope.
|
||||
|
||||
`inherit` derives reusable settings from the parent's resolved Manifest while replacing child identity and delegated scope. It should not blindly reuse the parent's original Profile source or runtime state.
|
||||
|
||||
@@ -76,6 +76,6 @@ Builtin resources should be embedded at compile time. User/project profiles, exp
|
||||
|
||||
## Why this separation matters
|
||||
|
||||
Without this split, configuration becomes unreproducible: a Profile might accidentally depend on a parent Pod's socket, a prompt override might act like hidden state, or a restored Pod might observe different defaults than the run that created it.
|
||||
Without this split, configuration becomes unreproducible: a Profile might accidentally depend on a parent Worker's socket, a prompt override might act like hidden state, or a restored Worker might observe different defaults than the run that created it.
|
||||
|
||||
The boundaries make it clear which information is reusable authoring, which is resolved runtime contract, and which is durable run history.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Tool permissions and scope
|
||||
|
||||
Yoi treats tools as explicit capabilities. Model-visible tool names are not permission by themselves; the resolved Manifest and Pod scope decide whether a call is allowed.
|
||||
Yoi treats tools as explicit capabilities. Model-visible tool names are not permission by themselves; the resolved Manifest and Worker scope decide whether a call is allowed.
|
||||
|
||||
## Permission policy
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# Worker, session, and state authority
|
||||
|
||||
Yoi separates replayable history from current Worker identity because they answer different questions.
|
||||
|
||||
A session log answers: "what happened and what can be replayed?" Worker metadata answers: "what does this Worker name currently refer to?" Live sockets and registries answer only: "what seems reachable right now?"
|
||||
|
||||
## Session logs
|
||||
|
||||
Session JSONL is the durable replay record. It contains committed user inputs, assistant items, tool results, system/runtime events that must explain later behavior, segment boundaries, and persisted effective snapshots needed to understand a run.
|
||||
|
||||
The session log should be append-oriented and schema drift should be compile-visible. Compatibility shims that silently reinterpret old plural/current entries make future readers less safe.
|
||||
|
||||
Session logs do not own current Worker-name state. A historical session can be replayable without being the active session for a Worker name.
|
||||
|
||||
## Worker metadata
|
||||
|
||||
Worker metadata is the current-state layer keyed by Worker name. It records active/pending session pointers, resolved manifest snapshots, current delegation metadata, spawned-child visibility, and restoration information.
|
||||
|
||||
This avoids reconstructing current Worker state by scanning every session log. It also gives `--worker <name>`, TUI resume, `ListWorkers`, and `RestoreWorker` a single current authority.
|
||||
|
||||
Worker metadata should stay thin. It is not a second transcript, and it should not duplicate model conversation content.
|
||||
|
||||
## Live runtime hints
|
||||
|
||||
Sockets, process registries, and runtime files are liveness hints. They are useful for attach, status probing, and fast discovery, but they are not final proof that work completed or that a Worker's state changed durably.
|
||||
|
||||
A reachable pending Worker should be visible even if durable logs have not materialized yet. Missing restore labels should degrade labels and diagnostics, not hide a live attachable Worker.
|
||||
|
||||
## Spawned children and delegation
|
||||
|
||||
Parent-visible children are sourced from Worker metadata, not from a transient runtime mirror. Restoring a parent should reconstruct reachable children where possible and keep stopped-but-restorable children visible when metadata supports it.
|
||||
|
||||
Delegated write scope is a capability loan. Stopping, shutting down, or pruning a child must reclaim the parent's effective write permissions while preserving explicit base denies.
|
||||
|
||||
## Peer Workers
|
||||
|
||||
Peer visibility is also Worker metadata, but it is distinct from spawned-child delegation. A TUI user can run `:peer <worker-name>` while attached to an idle Worker to register reciprocal peer metadata with another existing Worker. This is a metadata-level registration, not live target-controller consent.
|
||||
|
||||
A peer relationship only makes the Workers mutually visible through `ListWorkers` with visibility source `peer`. It does not grant filesystem scope, create a child output cursor, make either Worker the other's parent, or imply child completion notifications. Peer messages use `SendToPeerPod`, which delivers a labeled notification into the target Worker's normal durable notification/history path. `SendToPeerPod` requires the peer to be live and fails clearly for non-live peers rather than auto-restoring them.
|
||||
|
||||
## Notifications are not authority
|
||||
|
||||
Worker completion notifications are UX hints. Before treating delegated work as complete, inspect queryable evidence: child output, session/log state, worktree status, diffs, and validation output.
|
||||
|
||||
This is why orchestration code should expose state-aware operations such as `ListWorkers` and `RestoreWorker`, rather than letting a background alert decide workflow state by itself.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Workspace Kanban to backend Orchestrator runtime
|
||||
|
||||
Workspace Kanban operations are control-plane requests. They may change Ticket state and request orchestration, but they must not directly execute shell, git, filesystem work, or send authority-bearing messages to raw local Pod sockets. The durable boundary is an orchestration event consumed by a backend-internal Orchestrator Worker.
|
||||
Workspace Kanban operations are control-plane requests. They may change Ticket state and request orchestration, but they must not directly execute shell, git, filesystem work, or send authority-bearing messages to raw local Worker sockets. The durable boundary is an orchestration event consumed by a backend-internal Orchestrator Worker.
|
||||
|
||||
This document records the design boundary for connecting Kanban operations, Tickets, the Workspace backend, `WorkerRuntimeRegistry`, and filesystem-capable Workers. It is intentionally a planning artifact: it does not require the Workspace backend to implement every table, API, remote protocol, or spawn adapter immediately.
|
||||
|
||||
@@ -22,7 +22,7 @@ The minimum chain for implementation work is:
|
||||
|
||||
## Durable orchestration events
|
||||
|
||||
Orchestration events are immutable control-plane records derived from Ticket operations. They are not raw LLM messages, Pod notifications, or socket writes.
|
||||
Orchestration events are immutable control-plane records derived from Ticket operations. They are not raw LLM messages, Worker notifications, or socket writes.
|
||||
|
||||
Initial event kinds:
|
||||
|
||||
@@ -94,8 +94,8 @@ Non-responsibilities:
|
||||
- No `Bash` authority.
|
||||
- No raw workspace `Read`/`Write`/`Edit` authority.
|
||||
- No direct git/worktree/build execution.
|
||||
- No raw local Pod socket or session path authority.
|
||||
- No use of browser-supplied local paths, executable paths, runtime registry paths, `display_ref`, `pod_name`, or runtime display names as operation authority.
|
||||
- No raw local Worker socket or session path authority.
|
||||
- No use of browser-supplied local paths, executable paths, runtime registry paths, `display_ref`, `worker_name`, or runtime display names as operation authority.
|
||||
- No raw session transcript full ingest into the Workspace database.
|
||||
- No permission/auth, remote runtime protocol, Ticket DB migration, Kanban UI completion, or Coder/Reviewer spawn implementation completion in this design step.
|
||||
|
||||
@@ -103,7 +103,7 @@ If routing needs evidence that only filesystem access can provide, the Orchestra
|
||||
|
||||
## Domain-specific tool surface
|
||||
|
||||
The internal Orchestrator should receive backend tools, not generic Pod tools. The tools should be narrow enough to enforce lifecycle and authority rules and broad enough to let future Orchestrator prompts reason without hidden context injection.
|
||||
The internal Orchestrator should receive backend tools, not generic Worker tools. The tools should be narrow enough to enforce lifecycle and authority rules and broad enough to let future Orchestrator prompts reason without hidden context injection.
|
||||
|
||||
Required operation groups:
|
||||
|
||||
@@ -144,7 +144,7 @@ Forbidden operation groups for the internal Orchestrator:
|
||||
- raw filesystem read/write/edit over repository paths;
|
||||
- raw Unix socket connects or socket path notification;
|
||||
- raw session full transcript ingest;
|
||||
- local Pod metadata path or session path access as authority;
|
||||
- local Worker metadata path or session path access as authority;
|
||||
- browser-provided display labels, paths, or executable strings as authority.
|
||||
|
||||
## WorkerRuntime registry and spawn intents
|
||||
@@ -171,12 +171,12 @@ worker_spawn_intent {
|
||||
}
|
||||
```
|
||||
|
||||
The browser must not provide raw workspace roots, child cwd, executable paths, raw profile files, socket paths, local Pod names, or runtime display names in this intent. API callers can request high-level operations such as "queue this Ticket" or "open this canonical Worker"; the backend and runtime adapters resolve launch details from trusted workspace records, runtime configuration, and capability policy.
|
||||
The browser must not provide raw workspace roots, child cwd, executable paths, raw profile files, socket paths, local Worker names, or runtime display names in this intent. API callers can request high-level operations such as "queue this Ticket" or "open this canonical Worker"; the backend and runtime adapters resolve launch details from trusted workspace records, runtime configuration, and capability policy.
|
||||
|
||||
Runtime adapters are responsible for translating an accepted intent:
|
||||
|
||||
- A backend-internal runtime may create routing-only/intake/dashboard-assistant Workers with backend tools and no filesystem scope.
|
||||
- A local Pod runtime may resolve a Coder/Reviewer intent into Pod launch arguments, scope, delegated filesystem paths, branch/worktree policy, prompt/profile/workflow selection, and acceptance evidence.
|
||||
- A local Worker runtime may resolve a Coder/Reviewer intent into Worker launch arguments, scope, delegated filesystem paths, branch/worktree policy, prompt/profile/workflow selection, and acceptance evidence.
|
||||
- A remote runtime may perform the same adaptation on a different machine without exposing local paths to the browser or storing them as API authority.
|
||||
|
||||
Dispatch success means the runtime accepted the typed intent and returned durable acceptance evidence. It does not by itself prove the Ticket is done. Worker progress is projected through lifecycle, overview, review, and Ticket state records.
|
||||
@@ -198,7 +198,7 @@ External API identity is runtime-scoped and opaque:
|
||||
- Worker detail: `GET /api/runtimes/{runtime_id}/workers/{worker_id}`.
|
||||
- Cross-runtime list: `GET /api/workers`, with each item carrying `runtime_id`, `worker_id`, and display fields.
|
||||
|
||||
`worker-name@runtime-name` is a display label (`display_ref`) only. It is not unique enough for authority and must not be accepted as the target of mutating operations. Similarly, local Pod `pod_name`, runtime display names, raw runtime registry paths, and socket/session paths are implementation diagnostics, not API authority.
|
||||
`worker-name@runtime-name` is a display label (`display_ref`) only. It is not unique enough for authority and must not be accepted as the target of mutating operations. Similarly, local Worker `worker_name`, runtime display names, raw runtime registry paths, and socket/session paths are implementation diagnostics, not API authority.
|
||||
|
||||
A browser-safe Worker summary can expose:
|
||||
|
||||
@@ -215,7 +215,7 @@ worker_summary {
|
||||
implementation: {
|
||||
kind,
|
||||
display_hint,
|
||||
pod_name? # local Pod runtime only; diagnostic/display hint, not authority
|
||||
worker_name? # local Worker runtime only; diagnostic/display hint, not authority
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -250,7 +250,7 @@ The Workspace backend durable projection should center on:
|
||||
- Ticket state/relation/plan projections;
|
||||
- usage aggregates.
|
||||
|
||||
Raw session JSONL, provider traces, verbose event streams, local sockets, and local Pod metadata files remain runtime-local source/debug logs. The backend may expose bounded debug reads later, but that surface must be explicit, purpose-limited, permissioned, size-limited, and never treated as the normal Kanban/Orchestration UI data model.
|
||||
Raw session JSONL, provider traces, verbose event streams, local sockets, and local Worker metadata files remain runtime-local source/debug logs. The backend may expose bounded debug reads later, but that surface must be explicit, purpose-limited, permissioned, size-limited, and never treated as the normal Kanban/Orchestration UI data model.
|
||||
|
||||
This keeps dashboard views stable across local/remote runtimes and prevents raw transcript contents from becoming hidden durable authority for why a control-plane decision happened. If a decision matters, it must be written as a decision/audit/overview record.
|
||||
|
||||
@@ -279,7 +279,7 @@ This design suggests the following order without making any of it part of this T
|
||||
2. Add event delivery tools and decision/audit append tools for a backend-internal Orchestrator Worker.
|
||||
3. Add runtime-scoped Worker detail APIs and backend worker projection records with surrogate ids and `UNIQUE(runtime_id, worker_id)`.
|
||||
4. Add spawn intent persistence and registry dispatch stubs that preserve authority boundaries.
|
||||
5. Implement local Pod runtime adaptation for Coder/Reviewer/helper intents.
|
||||
5. Implement local Worker runtime adaptation for Coder/Reviewer/helper intents.
|
||||
6. Add remote runtime protocol only after the local typed-intent boundary is stable.
|
||||
|
||||
At every step, keep the invariant that durable control-plane records explain why the system acted, while runtime-specific sockets, sessions, paths, and process launch details remain adapter-local implementation details.
|
||||
@@ -17,7 +17,7 @@ A report is useful when it explains:
|
||||
|
||||
After rebuilding and restarting during dogfooding, `current_exe()` can point at a deleted binary path. Use typed runtime-command configuration and the development-only `YOI_POD_RUNTIME_COMMAND` executable override rather than reviving shell-command overrides.
|
||||
|
||||
## Multi-Pod work
|
||||
## Multi-Worker work
|
||||
|
||||
Use child Pods for scoped tasks and reviews, but keep orchestration decisions in visible project records. Do not merge, close, or clean up merely because a child notification arrived.
|
||||
|
||||
|
||||
@@ -14,11 +14,11 @@ Yoi keeps environment variables for narrow bootstrap and development cases, whil
|
||||
- Prefer embedded builtin resources over installed runtime resource directories.
|
||||
- Use explicit secret refs for provider and WebSearch credentials.
|
||||
- Keep dev-only executable overrides clearly named and documented.
|
||||
- Avoid shell-command parser overrides for runtime Pod launch.
|
||||
- Avoid shell-command parser overrides for runtime Worker launch.
|
||||
- Tests should prefer typed fixtures/injection and mutate process environment only around thin env-reader behavior.
|
||||
|
||||
## Current surface
|
||||
|
||||
Use `YOI_*` for current environment variables. Old project prefixes should not be reintroduced.
|
||||
|
||||
`YOI_POD_RUNTIME_COMMAND` is a development-only executable-path override for typed `yoi pod` launch. It is not a general shell-command override.
|
||||
`YOI_POD_RUNTIME_COMMAND` is a legacy-named development-only executable-path override for typed `yoi worker` launch. It is not a general shell-command override.
|
||||
|
||||
@@ -8,7 +8,7 @@ Yoi Plugins are intentionally explicit. The Plugin system is designed around the
|
||||
- a Profile/config entry must explicitly enable each Plugin package by source-qualified id, version, and digest;
|
||||
- Plugin grants must allow each surface and host API before registration or execution can use it;
|
||||
- Plugin code runs only through the configured sandbox runtime;
|
||||
- Plugin packages do not inherit Pod workspace filesystem, network, environment, or Ticket authority;
|
||||
- Plugin packages do not inherit Worker workspace filesystem, network, environment, or Ticket authority;
|
||||
- Tool calls and Tool results use the ordinary Yoi Tool/Engine history path;
|
||||
- Plugin metadata, output, and diagnostics are untrusted unless Yoi host policy says otherwise.
|
||||
|
||||
@@ -426,7 +426,7 @@ Yoi checks scheme (`ws`/`wss`), host, optional port, and path prefix against bot
|
||||
|
||||
## `fs` host API
|
||||
|
||||
The `fs` host API is Plugin-scoped and grant-gated. Plugins do not inherit the Pod/workspace filesystem authority automatically.
|
||||
The `fs` host API is Plugin-scoped and grant-gated. Plugins do not inherit the Worker/workspace filesystem authority automatically.
|
||||
|
||||
Example grant shape:
|
||||
|
||||
|
||||
@@ -44,4 +44,4 @@ Use work item review to verify that the implementation satisfies the ticket, not
|
||||
|
||||
## Current limitation
|
||||
|
||||
End-to-end tests that spawn real processes are not yet designed. When changing Pod restoration, socket behavior, or orchestration, compensate with targeted unit/integration tests and concrete manual evidence in the implementation report.
|
||||
End-to-end tests that spawn real processes are not yet designed. When changing Worker restoration, socket behavior, or orchestration, compensate with targeted unit/integration tests and concrete manual evidence in the implementation report.
|
||||
|
||||
@@ -4,14 +4,14 @@ Yoi project work is tracked through Tickets. For normal use, interact with Ticke
|
||||
|
||||
The current local backend stores each Ticket in the flat `.yoi/tickets/<ticket-id>/` layout. The directory name is the canonical opaque Ticket id: a fixed-width Crockford base32 Unix epoch millisecond timestamp. Slugs and frontmatter `id`/`slug` fields are not current-state authority. That storage detail matters for maintainers and backend compatibility, but it is not the primary user-facing workflow.
|
||||
|
||||
Do not treat ad-hoc chat summaries, memory records, or Pod notifications as the final source of project state. Notifications are hints to inspect concrete state, not proof of completion.
|
||||
Do not treat ad-hoc chat summaries, memory records, or Worker notifications as the final source of project state. Notifications are hints to inspect concrete state, not proof of completion.
|
||||
|
||||
## Concepts
|
||||
|
||||
- `Ticket`: durable project/orchestration record. It contains requirements, decisions, plans, implementation reports, reviews, artifacts, and resolution history.
|
||||
- `Objective`: first-class medium-term goal record. It stores goal, motivation/background, strategy/design direction, success criteria/exit conditions, decision context, current Objective lifecycle, and canonical Ticket links under `.yoi/objectives/<objective-id>/item.md`. Objective context is judgment/background context; it is not implementation authority and does not replace reading each Ticket body/thread/artifacts.
|
||||
- `Task`: session-local progress tracking inside a Pod. It is not the project record.
|
||||
- `Assignment`: a concrete delegation from an Orchestrator to a coder/reviewer Pod or task-specific helper Pod.
|
||||
- `Task`: session-local progress tracking inside a Worker. It is not the project record.
|
||||
- `Assignment`: a concrete delegation from an Orchestrator to a coder/reviewer Worker or task-specific helper Worker.
|
||||
- `IntentPacket`: the short implementation/review contract derived from a Ticket and handed to an Assignment.
|
||||
- `LocalTicketBackend`: the current `.yoi/tickets/` markdown/thread/artifacts storage backend.
|
||||
- `Ticket relation`: durable project-level Ticket-to-Ticket metadata stored as forward canonical-id relations (`depends_on`, `blocks`, `related`, `supersedes`, `duplicate_of`). Inverse views such as `blocked_by` are derived, not stored.
|
||||
@@ -46,9 +46,9 @@ Pods with the Ticket built-in feature can use typed Ticket tools:
|
||||
|
||||
These tools operate through the typed Ticket backend. They are not arbitrary filesystem write permission to `.yoi/tickets/`.
|
||||
|
||||
Relation tools are for non-hierarchical project metadata only. Use canonical opaque Ticket ids, store forward relations only, and keep runtime execution planning (capacity, ordering decisions, do-not-parallelize notes, Pod/session/worktree ownership) in OrchestrationPlan or session-local records instead of relation metadata. Unresolved `depends_on` and incoming unresolved `blocks` are queue/acceptance blockers; `related` is not blocking, and `supersedes` / `duplicate_of` are diagnostics rather than automatic lifecycle transitions.
|
||||
Relation tools are for non-hierarchical project metadata only. Use canonical opaque Ticket ids, store forward relations only, and keep runtime execution planning (capacity, ordering decisions, do-not-parallelize notes, Worker/session/worktree ownership) in OrchestrationPlan or session-local records instead of relation metadata. Unresolved `depends_on` and incoming unresolved `blocks` are queue/acceptance blockers; `related` is not blocking, and `supersedes` / `duplicate_of` are diagnostics rather than automatic lifecycle transitions.
|
||||
|
||||
Use them when a Pod needs to materialize or update project records:
|
||||
Use them when a Worker needs to materialize or update project records:
|
||||
|
||||
- Intake creates a new Ticket after user agreement.
|
||||
- Orchestrator records routing decisions and intent packets.
|
||||
@@ -59,7 +59,7 @@ Do not bypass workflow gates just because Ticket tools are available. Ticket mut
|
||||
|
||||
## Objective records
|
||||
|
||||
Objectives are lightweight medium-term project records, not Tickets, Ticket relations, OrchestrationPlan execution records, or Pod/session claims. Use them when a goal spans several concrete Tickets and the durable motivation, design direction, success criteria, or decision context would otherwise be repeated or lost.
|
||||
Objectives are lightweight medium-term project records, not Tickets, Ticket relations, OrchestrationPlan execution records, or Worker/session claims. Use them when a goal spans several concrete Tickets and the durable motivation, design direction, success criteria, or decision context would otherwise be repeated or lost.
|
||||
|
||||
The local Objective surface stores records under:
|
||||
|
||||
@@ -90,7 +90,7 @@ The Markdown body should include these sections:
|
||||
- `## Success criteria / exit conditions`
|
||||
- `## Decision context`
|
||||
|
||||
Linked Tickets must be canonical opaque Ticket ids that exist in the configured Ticket backend root. Objective-to-Ticket links are context links only: they are not dependency, blocking, ordering, ownership, or scheduling relations. Use typed Ticket relations for Ticket-to-Ticket dependency/blocking/related metadata, OrchestrationPlan records for routing/execution plans, and Pod/session claims for runtime ownership hints.
|
||||
Linked Tickets must be canonical opaque Ticket ids that exist in the configured Ticket backend root. Objective-to-Ticket links are context links only: they are not dependency, blocking, ordering, ownership, or scheduling relations. Use typed Ticket relations for Ticket-to-Ticket dependency/blocking/related metadata, OrchestrationPlan records for routing/execution plans, and Worker/session claims for runtime ownership hints.
|
||||
|
||||
Objective lifecycle is only Objective lifecycle. `active`, `paused`, `done`, and `archived` do not drive Ticket `state`, do not authorize implementation, and do not close linked Tickets. A role reading Objective context must still inspect each Ticket body, thread, artifacts, explicit Ticket relations, and OrchestrationPlan records before acting.
|
||||
|
||||
@@ -146,9 +146,9 @@ Fixed roles are:
|
||||
|
||||
This is not an arbitrary role registry. The fixed roles are the roles required by Ticket orchestration.
|
||||
Stale `[roles.investigator]` config is rejected as an unsupported fixed role; remove it and,
|
||||
when a spike is useful, let the Orchestrator create an ordinary task-specific read-only helper Pod.
|
||||
when a spike is useful, let the Orchestrator create an ordinary task-specific read-only helper Worker.
|
||||
|
||||
`profile` selects the Pod runtime Profile for that role. The selected Profile owns durable role/system behavior. `ticket.config.toml` does not have a role-level `system_instruction` field.
|
||||
`profile` selects the Worker runtime Profile for that role. The selected Profile owns durable role/system behavior. `ticket.config.toml` does not have a role-level `system_instruction` field.
|
||||
|
||||
`launch_prompt` is a per-action first-run prompt reference for future prompt resolution. Current launcher behavior exposes the ref but does not treat it as system instruction.
|
||||
|
||||
@@ -243,7 +243,7 @@ The Orchestrator should prepare an `IntentPacket` with:
|
||||
- current code map;
|
||||
- critical risks.
|
||||
|
||||
Implementation normally happens in a child git worktree created by the Orchestrator, not by the coder Pod. The coder Pod receives narrow write scope to the worktree and must report changed files, implementation summary, validation, unresolved risks, and review readiness.
|
||||
Implementation normally happens in a child git worktree created by the Orchestrator, not by the coder Worker. The coder Worker receives narrow write scope to the worktree and must report changed files, implementation summary, validation, unresolved risks, and review readiness.
|
||||
|
||||
### 5. Review
|
||||
|
||||
@@ -259,7 +259,7 @@ Unless explicitly authorized otherwise, final merge, cleanup, design-boundary de
|
||||
|
||||
Before closing, verify concrete evidence:
|
||||
|
||||
- child Pod output via `ReadPodOutput`;
|
||||
- child Worker output via `ReadWorkerOutput`;
|
||||
- worktree state and diff;
|
||||
- validation command output;
|
||||
- review result;
|
||||
@@ -270,7 +270,7 @@ Close with a resolution that summarizes what changed, key commits, validation, r
|
||||
|
||||
## Workspace Dashboard Ticket role actions
|
||||
|
||||
`yoi panel` is the active Ticket/Intake/Orchestrator Dashboard. It owns fixed Ticket role-launch actions and uses the shared client Ticket role launcher. The single-Pod Console no longer supports `:ticket ...` commands; typing them in command mode is treated like any other unknown command.
|
||||
`yoi panel` is the active Ticket/Intake/Orchestrator Dashboard. It owns fixed Ticket role-launch actions and uses the shared client Ticket role launcher. The single-Worker Console no longer supports `:ticket ...` commands; typing them in command mode is treated like any other unknown command.
|
||||
|
||||
Role actions map to the same fixed roles configured in `.yoi/ticket.config.toml`:
|
||||
|
||||
@@ -279,7 +279,7 @@ Role actions map to the same fixed roles configured in `.yoi/ticket.config.toml`
|
||||
- implement launches the coder role for an implementation assignment.
|
||||
- review launches the reviewer role for review.
|
||||
|
||||
All actions are explicit and user-triggered. They are not a scheduler, queue, spawned-Pod Dashboard, or automatic maintainer loop.
|
||||
All actions are explicit and user-triggered. They are not a scheduler, queue, spawned-Worker Dashboard, or automatic maintainer loop.
|
||||
|
||||
### Dashboard execution path
|
||||
|
||||
@@ -290,13 +290,13 @@ User triggers a Ticket action in yoi panel
|
||||
-> Dashboard builds a TicketRoleLaunchContext
|
||||
-> client Ticket role launcher reads .yoi/ticket.config.toml
|
||||
-> launcher selects the role Profile and workflow
|
||||
-> launcher spawns the role Pod
|
||||
-> launcher spawns the role Worker
|
||||
-> launcher sends Method::Run with WorkflowInvoke + Text segments
|
||||
-> launcher waits for run-acceptance evidence
|
||||
-> Dashboard reports success/failure
|
||||
```
|
||||
|
||||
The launched Pod receives dynamic Ticket/action context as its first committed run input. The Dashboard does not inject hidden context, does not write Ticket files directly, and does not construct prompt/workflow segments by hand.
|
||||
The launched Worker receives dynamic Ticket/action context as its first committed run input. The Dashboard does not inject hidden context, does not write Ticket files directly, and does not construct prompt/workflow segments by hand.
|
||||
|
||||
The first run input contains:
|
||||
|
||||
@@ -343,7 +343,7 @@ If a role still uses `profile = "inherit"`, the Dashboard fails closed with a di
|
||||
- `profile = "inherit"`: configure a concrete role Profile in `.yoi/ticket.config.toml`.
|
||||
- malformed `.yoi/ticket.config.toml`: fix the config and retry.
|
||||
- missing Ticket id for route, implement, or review actions: provide the target Ticket.
|
||||
- launch success but no visible completion: attach to or inspect the launched Pod; completion notifications are hints, not authority.
|
||||
- launch success but no visible completion: attach to or inspect the launched Worker; completion notifications are hints, not authority.
|
||||
|
||||
## Granularity
|
||||
|
||||
@@ -383,7 +383,7 @@ Do not store secrets, credentials, private prompt contents, or raw logs containi
|
||||
|
||||
## Backend/maintainer CLI: `yoi ticket`
|
||||
|
||||
The product CLI exposes the typed Ticket backend for repository maintenance and validation. It operates on the configured `.yoi/tickets/` storage and is the preferred command-line surface when editing Tickets outside a Pod.
|
||||
The product CLI exposes the typed Ticket backend for repository maintenance and validation. It operates on the configured `.yoi/tickets/` storage and is the preferred command-line surface when editing Tickets outside a Worker.
|
||||
|
||||
```sh
|
||||
yoi ticket create --title "..." [--priority P2]
|
||||
|
||||
@@ -14,7 +14,7 @@ Current workflow themes include:
|
||||
- Orchestrator routing from Tickets to the next workflow/action
|
||||
- planning/requirements synchronization when concrete missing decisions or information block routing
|
||||
- worktree setup and cleanup
|
||||
- sibling coder/reviewer Pod orchestration
|
||||
- sibling coder/reviewer Worker orchestration
|
||||
- human-gated maintenance and merge readiness
|
||||
|
||||
## Child Pods
|
||||
@@ -23,8 +23,8 @@ Spawned Pods are useful for scoped implementation, review, or exploration. They
|
||||
|
||||
A parent/orchestrator must verify:
|
||||
|
||||
- child output via `ReadPodOutput`
|
||||
- live/restorable state via Pod tools when relevant
|
||||
- child output via `ReadWorkerOutput`
|
||||
- live/restorable state via Worker tools when relevant
|
||||
- worktree state and diff
|
||||
- validation command output
|
||||
- Ticket requirements and acceptance criteria
|
||||
|
||||
+14
-14
@@ -1,15 +1,15 @@
|
||||
# ============================================================================
|
||||
# Pod Manifest リファレンス
|
||||
# Worker Manifest リファレンス
|
||||
# ============================================================================
|
||||
# Pod の宣言的設定 (`PodManifest` / `PodManifestConfig`)。
|
||||
# Worker の宣言的設定 (`WorkerManifest` / `WorkerManifestConfig`)。
|
||||
#
|
||||
# このファイル形式は低レベル runtime manifest。通常起動は profile discovery/default
|
||||
# (`profiles.toml` と bundled builtin profile) から manifest を生成する。
|
||||
# `yoi pod --manifest <path>` の one-file compatibility/debug mode では、
|
||||
# `yoi worker --manifest <path>` の one-file compatibility/debug mode では、
|
||||
# 指定した TOML 1 枚に builtin defaults を merge し、required validation を行う。
|
||||
# user/project `manifest.toml` を暗黙に merge する通常起動 cascade は使わない。
|
||||
#
|
||||
# `PodManifestConfig` の merge 規則: 上の層が同名フィールドを上書き、scope rule と
|
||||
# `WorkerManifestConfig` の merge 規則: 上の層が同名フィールドを上書き、scope rule と
|
||||
# skills.directories は累積マージ、tool_output.per_tool は key 単位でマージ。
|
||||
#
|
||||
# パス解決: `--manifest <path>` では相対パスはその manifest ファイルの親ディレクトリ
|
||||
@@ -23,11 +23,11 @@
|
||||
# ----------------------------------------------------------------------------
|
||||
|
||||
|
||||
# ===== [pod] ================================================================
|
||||
# Pod メタデータ。
|
||||
[pod]
|
||||
# ===== [worker] ================================================================
|
||||
# Worker メタデータ。
|
||||
[worker]
|
||||
|
||||
# 必須。Pod の表示名 (ResolveError::MissingField("pod.name") の対象)。
|
||||
# 必須。Worker の表示名 (ResolveError::MissingField("worker.name") の対象)。
|
||||
name = "example-agent"
|
||||
|
||||
# 任意。デフォルト: なし。
|
||||
@@ -91,9 +91,9 @@ ref = "anthropic/claude-sonnet-4-6"
|
||||
# prompt_caching = { kind = "explicit", max_breakpoints = 4 }
|
||||
|
||||
|
||||
# ===== [worker] =============================================================
|
||||
# ===== [engine] =============================================================
|
||||
# ワーカーの生成パラメータ等。セクション自体省略可 (全フィールド任意)。
|
||||
[worker]
|
||||
[engine]
|
||||
|
||||
# 任意。デフォルト: "$yoi/default" (`defaults::DEFAULT_INSTRUCTION`)。
|
||||
# システムプロンプト本体の `PromptLoader` 参照。
|
||||
@@ -148,7 +148,7 @@ ref = "anthropic/claude-sonnet-4-6"
|
||||
|
||||
|
||||
# ===== [scope] ==============================================================
|
||||
# Pod がアクセスできるディレクトリ／ファイル範囲。
|
||||
# Worker がアクセスできるディレクトリ／ファイル範囲。
|
||||
# - allow: 最低 1 件必要 (空だと ResolveError / ScopeError::EmptyAllow)。
|
||||
# 複数 allow がマッチした場合は最大の permission が採用される。
|
||||
# - deny : 任意。マッチした deny の最小 permission *未満* に effective を
|
||||
@@ -202,7 +202,7 @@ permission = "write"
|
||||
# compact_threshold = 80000
|
||||
#
|
||||
# # 任意。デフォルト: なし (safety-net compact 無効)。
|
||||
# # ターン中チェック (PodInterceptor::pre_llm_request)。期待される関係:
|
||||
# # ターン中チェック (WorkerInterceptor::pre_llm_request)。期待される関係:
|
||||
# # compact_threshold < compact_request_threshold (proactive を先に発火)。
|
||||
# # 逆順設定は許容するが warn ログを出す。
|
||||
# compact_request_threshold = 90000
|
||||
@@ -233,12 +233,12 @@ permission = "write"
|
||||
# Memory subsystem の opt-in。
|
||||
# - セクションが *ある* … memory tools (MemoryRead/Write/Edit) を登録、
|
||||
# `<workspace>/memory/` と `<workspace>/knowledge/`
|
||||
# の通常 write を Pod 自体に対して deny する。
|
||||
# の通常 write を Worker 自体に対して deny する。
|
||||
# - セクションが *無い* … 何も起きない (legacy 動作)。
|
||||
# `[memory]` だけ書いて中身を省略するのも有効 (全フィールド既定値で有効化)。
|
||||
# [memory]
|
||||
#
|
||||
# # 任意。デフォルト: Pod の pwd (構築時)。
|
||||
# # 任意。デフォルト: Worker の pwd (構築時)。
|
||||
# # 必ず絶対パス (相対なら manifest base 起点で resolve)。
|
||||
# workspace_root = "/abs/path/to/workspace"
|
||||
#
|
||||
|
||||
Reference in New Issue
Block a user