docs: document recent package updates#373
Conversation
poe-code-agent
Bot
force-pushed
the
agent/update-documentation
branch
from
b2b7cec to
9a6b224
Compare
![poe-code-agent[bot]](https://avatars.githubusercontent.com/in/2645587?s=60&v=4){kind=small}
poe-code-agent
Bot
changed the title
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
Non-blocking: the runtime parser accepts missing kind/version, but pipelineDocumentSchema.required still includes both fields. If users validate against the exported schema, this sentence may read as too broad; consider clarifying runtime-optional vs schema-required if that split is intentional.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 038eaaac04
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
This describes kind and version as optional, but the exported pipelineDocumentSchema still has required: ["kind", "version", "tasks"] while only parsePlan tolerates omissions. Users following this README with the generated schema will omit these fields and then get validation failures, so either the schema needs to be relaxed or the docs should distinguish runner-tolerated fields from schema-required metadata.
Useful? React with 👍 / 👎.
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
The parser tolerates omitted kind/version, but the generated schema still requires them (pipelineDocumentSchema.required includes kind, version, and tasks). If this sentence is meant to describe schema-valid plan files, consider narrowing the optional metadata claim.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| | `name` | `string` | none | MCP server name exposed during initialization. | | ||
| | `version` | `string` | none | MCP server version exposed during initialization. | | ||
| | `validateToolArguments` | `boolean` | `true` | Validate tool call arguments against each tool input schema. | | ||
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | |
There was a problem hiding this comment.
Non-blocking: createHttpServer currently overwrites supportNotifications and supportResourceSubscriptions from whether sessions are enabled, so callers can't independently set these booleans. In stateless mode they are disabled; in session mode an explicit false is ignored. It may be clearer to document them as session-derived behavior rather than configurable HTTP options.
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
The runtime parser tolerates omitted kind/version, but the exported pipelineDocumentSchema still requires them (required: ["kind", "version", "tasks"]). As written, users validating against the schema will omit fields this README calls optional.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner tolerates omitted values for those fields at runtime. The runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | ||
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | |
There was a problem hiding this comment.
createHttpServer() currently overwrites these base options from session support, so callers cannot independently configure them: stateless mode disables both, and an explicit false is ignored when sessions are enabled.
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | |
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | | |
| | `supportNotifications` | session-derived | `true` with sessions, `false` stateless | HTTP transport advertises list-change notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | | |
| | `supportResourceSubscriptions` | session-derived | `true` with sessions, `false` stateless | HTTP transport enables resource subscriptions/update notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 18699d1353
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | ||
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | |
There was a problem hiding this comment.
For createHttpServer() these two options are not actually caller-controlled defaults: the implementation overwrites any supplied values with supportsSessions after spreading options, so sessionful servers always advertise them and --stateless / sessionIdGenerator: undefined servers never do. As written, users may configure or rely on prompt/resource list-change notifications or resource subscriptions in the wrong transport mode and see different capabilities during MCP initialization, so the docs should describe them as derived from session support rather than normal boolean options.
Useful? React with 👍 / 👎.
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
The runtime parser tolerates omitted kind/version, but the exported pipelineDocumentSchema still requires them (required: ["kind", "version", "tasks"]). As written, users validating against the schema will omit fields this README calls optional.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner tolerates omitted values for those fields at runtime. The runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | ||
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | |
There was a problem hiding this comment.
createHttpServer() currently derives these capabilities from session support after spreading options, so callers cannot independently configure them: stateless mode disables both, and an explicit false is ignored when sessions are enabled.
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | |
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | | |
| | `supportNotifications` | session-derived | `true` with sessions, `false` stateless | HTTP transport advertises list-change notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | | |
| | `supportResourceSubscriptions` | session-derived | `true` with sessions, `false` stateless | HTTP transport enables resource subscriptions/update notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | |
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
The parser tolerates omitted kind/version, but the exported pipelineDocumentSchema still requires them (required: ["kind", "version", "tasks"]). As written, users validating against the schema will omit fields this README calls optional.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner tolerates omitted values for those fields at runtime. The runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | ||
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | |
There was a problem hiding this comment.
createHttpServer() currently derives these capabilities from session support after spreading options, so callers cannot independently configure them: stateless mode disables both, and an explicit false is ignored when sessions are enabled.
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | |
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | | |
| | `supportNotifications` | session-derived | `true` with sessions, `false` stateless | HTTP transport advertises list-change notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | | |
| | `supportResourceSubscriptions` | session-derived | `true` with sessions, `false` stateless | HTTP transport enables resource subscriptions/update notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | |
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
The runtime parser tolerates omitted kind/version, but the exported pipelineDocumentSchema still requires them (required: ["kind", "version", "tasks"]). As written, users validating against the schema will omit fields this README calls optional.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner tolerates omitted values for those fields at runtime. The runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | ||
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | |
There was a problem hiding this comment.
createHttpServer() derives these two capabilities from session support after spreading options, so callers cannot independently configure them: stateless mode disables both, and an explicit false is ignored when sessions are enabled.
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | |
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | | |
| | `supportNotifications` | session-derived | `true` with sessions, `false` stateless | HTTP transport advertises list-change notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | | |
| | `supportResourceSubscriptions` | session-derived | `true` with sessions, `false` stateless | HTTP transport enables resource subscriptions/update notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | |
| poe-code tasks import --from ./incoming-tasks --to ./WORKFLOW.md --dry-run --keep | ||
| ``` | ||
|
|
||
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
There was a problem hiding this comment.
The import CLI only sets deleteSource when --delete-source is passed; --keep is accepted but is effectively the default. This sentence currently documents the opposite default.
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. | |
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, source files are kept. Pass `--delete-source` to delete successfully imported source files. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcea300e1f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| | `--stdin` | `false` | Read the prompt from stdin. | | ||
| | `-i, --interactive` | `false` | Launch in interactive TUI mode (inherits stdio). | | ||
| | `--mode <mode>` | `yolo` | Permission mode: `yolo` (full access), `edit` (file edits only), `read` (read-only). | | ||
| | `--mode <mode>` | Prompts (`--yes`: `yolo`) | Permission mode: `yolo` (full access), `edit` (file edits only), `read` (read-only). Non-TTY runs must pass `--mode` or `--yes`. | |
There was a problem hiding this comment.
Because resolveSpawnMode rejects any spawn with process.stdin.isTTY !== true unless --mode or --yes is supplied, the stdin examples later in this README (echo ... | poe-code spawn ... --stdin, ... -, and pipe detection) now fail immediately without reaching the agent. Please update those piped/non-TTY examples to include --mode or --yes, otherwise users following the documented stdin workflow hit the new validation error.
Useful? React with 👍 / 👎.
| poe-code tasks import --from ./incoming-tasks --to ./WORKFLOW.md --dry-run --keep | ||
| ``` | ||
|
|
||
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
There was a problem hiding this comment.
In runImport, source files are deleted only when --delete-source is provided (moveTasks receives deleteSource only for that flag), so --keep is not the inverse of a default deletion mode. As written, users may rely on this README and then re-run imports against files that were left behind by default, causing duplicate/failed creates depending on the target backend.
Useful? React with 👍 / 👎.
| | `--stdin` | `false` | Read the prompt from stdin. | | ||
| | `-i, --interactive` | `false` | Launch in interactive TUI mode (inherits stdio). | | ||
| | `--mode <mode>` | `yolo` | Permission mode: `yolo` (full access), `edit` (file edits only), `read` (read-only). | | ||
| | `--mode <mode>` | Prompts (`--yes`: `yolo`) | Permission mode: `yolo` (full access), `edit` (file edits only), `read` (read-only). Non-TTY runs must pass `--mode` or `--yes`. | |
There was a problem hiding this comment.
This new non-TTY requirement is correct, but the stdin examples below still omit --mode/--yes, so they now fail in resolveSpawnMode. Please update the cat ... --stdin and echo ... - examples to include a mode.
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
parsePlan tolerates omitted kind/version, but the exported pipelineDocumentSchema still requires them. If this README is documenting schema-valid plan files, avoid calling those schema fields optional.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner tolerates omitted values for those fields at runtime. The runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| poe-code tasks import --from ./incoming-tasks --to ./WORKFLOW.md --dry-run --keep | ||
| ``` | ||
|
|
||
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
There was a problem hiding this comment.
runImport only passes deleteSource to moveTasks when --delete-source is set; --keep is accepted but already matches the default. This paragraph currently documents the opposite default.
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. | |
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, source files are kept. Pass `--delete-source` to delete successfully imported source files. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
| | `name` | `string` | none | MCP server name exposed during initialization. | | ||
| | `version` | `string` | none | MCP server version exposed during initialization. | | ||
| | `validateToolArguments` | `boolean` | `true` | Validate tool call arguments against each tool input schema. | | ||
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | |
There was a problem hiding this comment.
createHttpServer() derives these HTTP capabilities from session support after spreading options, so callers cannot independently set this boolean: stateless mode disables it, and sessionful mode forces it on. The same applies to supportResourceSubscriptions on the next line.
…ation # Conflicts: # e2e/goose.test.ts # e2e/mcp-tool.test.ts # e2e/opencode.test.ts # packages/agent-spawn/README.md # src/providers/opencode.ts # src/providers/providers.test.ts
| | `--stdin` | `false` | Read the prompt from stdin. | | ||
| | `-i, --interactive` | `false` | Launch in interactive TUI mode (inherits stdio). | | ||
| | `--mode <mode>` | `yolo` | Permission mode: `yolo` (full access), `edit` (file edits only), `read` (read-only). | | ||
| | `--mode <mode>` | Prompts (`--yes`: `yolo`) | Permission mode: `yolo` (full access), `edit` (file edits only), `read` (read-only). Non-TTY runs must pass `--mode` or `--yes`. | |
There was a problem hiding this comment.
This new non-TTY requirement is correct, but the stdin examples below still omit --mode/--yes. Those examples pipe stdin, so resolveSpawnMode rejects them before the agent runs. Please add an explicit mode or --yes to the --stdin, -, and pipe-detection examples.
| ``` | ||
|
|
||
| Each step becomes its own agent execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | ||
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
There was a problem hiding this comment.
The parser tolerates omitted kind/version, but the exported pipelineDocumentSchema still requires them. If this README is documenting schema-valid plan files, avoid calling those schema fields optional.
| Each step becomes its own agent execution. `kind`, `version`, `name`, and `state` are optional plan metadata fields; the runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). | |
| Each step becomes its own agent execution. `name` and `state` are optional plan metadata fields; `kind: pipeline` and `version: 1` are schema metadata, and the runner tolerates omitted values for those fields at runtime. The runner uses `extends`, `tasks`, `vars`, hooks, and MCP config for execution. Steps are resolved from `.poe-code/pipeline/steps.yaml` (or `~/.poe-code/pipeline/steps.yaml`). See [Step Configuration](#step-configuration). |
| poe-code tasks import --from ./incoming-tasks --to ./WORKFLOW.md --dry-run --keep | ||
| ``` | ||
|
|
||
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
There was a problem hiding this comment.
runImport only passes deleteSource to moveTasks when --delete-source is set; --keep is accepted but already matches the default. This paragraph currently documents the opposite default.
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, successfully imported source files are deleted. Pass `--keep` to leave source files in place. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. | |
| The import source is treated as a `markdown-dir` backend with `singleList: "import"` and `frontmatterMode: "passthrough"`, so files without full task frontmatter can be imported. By default, source files are kept. Pass `--delete-source` to delete successfully imported source files. `--rate`, `--limit`, and `--dry-run` match `poe-code tasks move`. |
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | ||
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | |
There was a problem hiding this comment.
createHttpServer() derives these HTTP capabilities from session support after spreading options, so callers cannot independently set these booleans: stateless mode disables both, and sessionful mode forces them on.
| | `supportNotifications` | `boolean` | `true` | Advertise tools/prompts/resources list-change notifications. | | |
| | `supportResourceSubscriptions` | `boolean` | `true` | Advertise resource subscription support and enable resource update notifications. | | |
| | `supportNotifications` | session-derived | `true` with sessions, `false` stateless | HTTP transport advertises list-change notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | | |
| | `supportResourceSubscriptions` | session-derived | `true` with sessions, `false` stateless | HTTP transport enables resource subscriptions/update notifications when sessions are enabled; `createHttpServer()` derives this from `sessionIdGenerator`. | |
Summary
@poe-code/agent-script/core, agent-script spawn retry lifecycle events, and harness retry behavior.gatestate field.renderCatalogcomponent.Verification
git diff --checknpx prettier --check packages/agent-script/README.md packages/agent-harness/README.md packages/task-list/README.md packages/agent-maestro/README.md packages/toolcraft-openapi/README.md packages/toolcraft-design/README.md