@vibe-forge/workspace-assets 3.1.0 → 3.2.0

package/__tests__/__snapshots__/workspace-assets-rich.snapshot.json

@@ -467,7 +467,7 @@
       ]
     },
     "options": {
-      "systemPrompt": "<system-prompt>\nThe project system rules are:\n# review\n\n> 必须检查发布改动的回归风险。\n\n# demo/security\n\n> Use when: 插件安全规则\n> Rule file path: node_modules/@vibe-forge/plugin-demo/rules/security.md\n> Only read this rule file when the task matches the scenario above.\n</system-prompt>\n\n\n<system-prompt>\nThe following skill modules are loaded for the project:\n# research\n\n> Skill description: 检索资料\n> Skill file path: .ai/skills/research/SKILL.md\n> Resolve relative paths in the resource content relative to the directory containing this skill file.\n\n<skill-content>\n先阅读 README.md，再补充结论。\n</skill-content>\n</system-prompt>\n\n\n<system-prompt>\nThe project includes the following entities:\n  - architect: 负责拆解方案的实体\n\nWhen solving user problems, you may specify entities through `VibeForge.StartTasks` as needed and have them coordinate multiple entity types to complete the work; use `VibeForge.GetTaskInfo` and `wait` to track progress.\nTask tool guide:\n- Use `VibeForge.StartTasks` to start a new child task when the work should run in a separate entity or workspace, or when it needs to continue independently from the current turn.\n- After starting a task, use `VibeForge.GetTaskInfo` with `{ taskId }` to inspect one task. It is also the right tool when a task seems stalled, failed, or might be waiting for input.\n- By default, `GetTaskInfo` returns the 10 most recent log entries in descending order, so newer entries appear earlier in the `logs` array. Pass `logLimit` to inspect a different number of recent logs, and set `logOrder` to `\"asc\"` when you want the selected log window in oldest-to-newest order.\n- Use `VibeForge.ListTasks` with the same `logLimit` and `logOrder` fields when you need to find a taskId or inspect multiple tasks at once.\n- Use `VibeForge.SendTaskMessage` with `{ taskId, message }` when you need to give a task another instruction. Running tasks continue immediately; completed or failed tasks resume the same conversation instead of forcing a replacement task.\n- Use `VibeForge.SubmitTaskInput` only when `VibeForge.GetTaskInfo` or `VibeForge.ListTasks` shows `pendingInput` or `pendingInteraction`, or the task status is `waiting_input`. Do not use it for ordinary follow-up instructions.\n- If a task is `completed` or `failed` but you want to keep working in that same thread of execution, prefer `VibeForge.SendTaskMessage` to resume it. Start a new task only when you actually want a replacement task.\n- When a task is still making progress, use `wait` between checks instead of repeatedly restarting it.\n</system-prompt>\n\n\n<system-prompt>\nYou are a professional project execution manager who can skillfully direct other entities to work toward your goal. Expectations:\n\n- Never complete code development work alone\n- You must coordinate other developers to complete tasks\n- You must keep them aligned with the goal and verify that their completion reports meet the requirements\n\nChoose the appropriate workflow based on the user's needs and the actual development goal, and use the workflow identifier to locate and load the corresponding definition.\n- Pass the identifier based on the actual need. This is not a path; use the standard workflow loading capability to resolve it.\n- Decide how to pass parameters based on their descriptions and actual usage scenarios.\nThe project includes the following workflows:\n- Workflow name: release\n  - Description: 正式发布流程\n  - Identifier: release\n  - Parameters:\n    - None\n\n- Workflow name: demo/release\n  - Description: 插件发布流程\n  - Identifier: demo/release\n  - Parameters:\n    - None\n\n</system-prompt>\n\n\n执行正式发布，并整理变更摘要。",
+      "systemPrompt": "<system-prompt>\nThe project system rules are:\n# review\n\n> 必须检查发布改动的回归风险。\n\n# demo/security\n\n> Use when: 插件安全规则\n> Rule file path: node_modules/@vibe-forge/plugin-demo/rules/security.md\n> Only read this rule file when the task matches the scenario above.\n</system-prompt>\n\n\n<system-prompt>\nThe following skill modules are loaded for the project:\n# research\n\n> Skill description: 检索资料\n> Skill file path: .ai/skills/research/SKILL.md\n> Resolve relative paths in the resource content relative to the directory containing this skill file.\n\n<skill-content>\n先阅读 README.md，再补充结论。\n</skill-content>\n</system-prompt>\n\n\n<system-prompt>\nThe project includes the following entities:\n  - architect: 负责拆解方案的实体\n\nWhen solving user problems, you may start child runtime sessions with `vf run --input-format stream-json --output-format stream-json` and a `session.start` protocol envelope as needed; use `session.status`, `session.events`, and `wait` to track progress.\nAgent runtime guide:\n- Use unified CLI protocol mode, `vf run --input-format stream-json --output-format stream-json`, to start a child runtime session when the work should run in a separate entity or continue independently from the current turn.\n- Send typed runtime protocol envelopes such as `session.start`, `session.message`, `session.status`, `session.events`, `session.submit`, and `session.stop`; do not treat dedicated `vf agent ...` subcommands as the standard integration surface.\n- Ordinary new sessions stay session-scoped. A room is created or discovered only when a unified CLI runtime protocol start command launches a child runtime session from a server-managed host session and the server projects runtime store metadata/events.\n- Do not use MCP task tools, `vf agent ...`, legacy StartTasks, hand-written DB edits, or ad-hoc TS scripts as the task consumer surface. Use CLI protocol mode and the runtime protocol/store for start, status, events, follow-up messages, input submission, and cancellation.\n- Server-managed host sessions inject the current adapter, model, effort, and permission mode as runtime protocol defaults. Omit these fields to inherit the host selection, or set them explicitly only when a child task must use a different runtime profile.\n- Copyable JSONL example; write one `session.start` line per child task, and use multiple lines for multiple subtasks:\n```bash\ncat <<'JSONL' | vf run --input-format stream-json --output-format stream-json\n{\"commandId\":\"start-planner\",\"type\":\"session.start\",\"payload\":{\"title\":\"Plan Agent Room UI fix\",\"message\":\"Plan the frontend changes and tests for the Agent Room UI fix.\",\"entity\":\"dev-planner\",\"background\":true},\"title\":\"Plan Agent Room UI fix\",\"message\":\"Plan the frontend changes and tests for the Agent Room UI fix.\",\"entity\":\"dev-planner\",\"background\":true}\n{\"commandId\":\"start-reviewer\",\"type\":\"session.start\",\"payload\":{\"title\":\"Review Agent Room UI fix\",\"message\":\"Review the implemented Agent Room UI fix for regressions and missing tests.\",\"entity\":\"dev-reviewer\",\"background\":true},\"title\":\"Review Agent Room UI fix\",\"message\":\"Review the implemented Agent Room UI fix for regressions and missing tests.\",\"entity\":\"dev-reviewer\",\"background\":true}\nJSONL\n```\n- Keep `payload.title`, `payload.message`, `payload.entity`, and `payload.background: true` explicit in each start envelope. The mirrored top-level fields make the JSONL executable by the current `vf run` protocol reader.\n- Include a short `title` when the task prompt is long; it becomes the child session title and room run label. Put any room or workspace context in the title and initial message.\n- Read the returned `sessionId` and use it for follow-up protocol commands. Read the latest runtime snapshot from the runtime store or a `session.status` protocol command, and read progress from runtime events or a `session.events` protocol command.\n- Use a follow/read-events workflow when you need to watch progress instead of repeatedly restarting work.\n- Use a `session.message` protocol command to give an existing session another instruction. Running sessions continue immediately; completed or failed sessions resume the same conversation when the runtime allows resume.\n- When the chat UI sends a `[ROOM_TASK_MESSAGE] ... [/ROOM_TASK_MESSAGE]` block, treat it as a runtime relay envelope instead of ordinary prose. Parse the `sessionId` or legacy `taskId`, `message`, and optional `mode` / `request` fields. If the envelope indicates `mode: interaction`, or runtime status shows `waiting_input` / pending input, use a `session.submit` protocol command. Otherwise use `session.message`. Do not reply inline instead of routing the relay.\n- Use `session.submit` only when a runtime session is waiting for an explicit input or approval request. Do not use it for ordinary follow-up instructions.\n- Use a `session.stop` protocol command for graceful cancellation and set `mode` to `force` only when stop cannot recover the session.\n- Compatibility aliases such as `vf agent start/status/events/send/submit/stop` may exist for debugging or legacy scripts, but they are not the primary guidance for new agent workflows.\n- When a session is still making progress, use `wait` between checks and inspect status/events instead of starting a replacement session.\n</system-prompt>\n\n\n<system-prompt>\nYou are a professional project execution manager who can skillfully direct other entities to work toward your goal. Expectations:\n\n- Never complete code development work alone\n- You must coordinate other developers to complete tasks\n- You must keep them aligned with the goal and verify that their completion reports meet the requirements\n\nChoose the appropriate workflow based on the user's needs and the actual development goal, and use the workflow identifier to locate and load the corresponding definition.\n- Pass the identifier based on the actual need. This is not a path; use the standard workflow loading capability to resolve it.\n- Decide how to pass parameters based on their descriptions and actual usage scenarios.\nThe project includes the following workflows:\n- Workflow name: release\n  - Description: 正式发布流程\n  - Identifier: release\n  - Parameters:\n    - None\n\n- Workflow name: demo/release\n  - Description: 插件发布流程\n  - Identifier: demo/release\n  - Parameters:\n    - None\n\n</system-prompt>\n\n\n执行正式发布，并整理变更摘要。",
       "tools": {
         "include": [
           "Edit",

package/__tests__/prompt-builders.spec.ts

@@ -174,20 +174,35 @@ describe('workspace asset prompt builders', () => {
     ])
 
     expect(prompt).toContain('reviewer: 负责代码审查')
-    expect(prompt).toContain('`VibeForge.StartTasks`')
-    expect(prompt).toContain('`VibeForge.GetTaskInfo`')
-    expect(prompt).toContain('Task tool guide:')
-    expect(prompt).toContain('After starting a task')
-    expect(prompt).toContain('10 most recent log entries')
-    expect(prompt).toContain('`logLimit`')
-    expect(prompt).toContain('`logOrder`')
-    expect(prompt).toContain('`VibeForge.SendTaskMessage`')
-    expect(prompt).toContain('`{ taskId, message }`')
-    expect(prompt).toContain('`VibeForge.SubmitTaskInput`')
+    expect(prompt).toContain('Agent runtime guide:')
+    expect(prompt).toContain('`vf run --input-format stream-json --output-format stream-json`')
+    expect(prompt).toContain("cat <<'JSONL' | vf run --input-format stream-json --output-format stream-json")
+    expect(prompt).toContain('"commandId":"start-planner"')
+    expect(prompt).toContain('"type":"session.start"')
+    expect(prompt).toContain('"payload":{"title":"Plan Agent Room UI fix"')
+    expect(prompt).toContain('"entity":"dev-planner"')
+    expect(prompt).toContain('"background":true')
+    expect(prompt).toContain('write one `session.start` line per child task')
+    expect(prompt).toContain('typed runtime protocol envelopes')
+    expect(prompt).toContain('do not treat dedicated `vf agent ...` subcommands as the standard integration surface')
+    expect(prompt).toContain('Read the returned `sessionId`')
+    expect(prompt).toContain('Ordinary new sessions stay session-scoped')
+    expect(prompt).toContain('Do not use MCP task tools, `vf agent ...`, legacy StartTasks')
+    expect(prompt).toContain('hand-written DB edits')
+    expect(prompt).toContain('ad-hoc TS scripts')
+    expect(prompt).toContain('server-managed host session')
+    expect(prompt).toContain('server projects runtime store metadata/events')
+    expect(prompt).toContain('`session.status` protocol command')
+    expect(prompt).toContain('`session.events` protocol command')
+    expect(prompt).toContain('`session.message` protocol command')
+    expect(prompt).toContain('[ROOM_TASK_MESSAGE]')
+    expect(prompt).toContain('`mode: interaction`')
+    expect(prompt).toContain('`waiting_input`')
+    expect(prompt).toContain('`session.submit` protocol command')
     expect(prompt).toContain('Do not use it for ordinary follow-up instructions')
-    expect(prompt).toContain('completed or failed tasks resume the same conversation')
-    expect(prompt).toContain('keep working in that same thread of execution')
+    expect(prompt).toContain('completed or failed sessions resume the same conversation')
     expect(prompt).toContain('`wait`')
+    expect(prompt).not.toContain('VibeForge.StartTasks')
     expect(prompt).not.toContain('run-tasks')
     expect(prompt).not.toContain('需要关注变更风险')
     expect(prompt).not.toContain('hidden')
@@ -207,14 +222,19 @@ describe('workspace asset prompt builders', () => {
 
     expect(prompt).toContain('The project includes the following registered workspaces')
     expect(prompt).toContain('Identifier: billing')
-    expect(prompt).toContain('`VibeForge.StartTasks`')
-    expect(prompt).toContain('type: "workspace"')
-    expect(prompt).toContain('Task tool guide:')
-    expect(prompt).toContain('`VibeForge.GetTaskInfo`')
-    expect(prompt).toContain('`VibeForge.ListTasks`')
-    expect(prompt).toContain('`VibeForge.SendTaskMessage`')
-    expect(prompt).toContain('`VibeForge.SubmitTaskInput`')
+    expect(prompt).toContain('workspace identifier and path')
+    expect(prompt).toContain('Agent runtime guide:')
+    expect(prompt).toContain('`vf run --input-format stream-json --output-format stream-json`')
+    expect(prompt).toContain('"payload":{"title":"Plan Agent Room UI fix"')
+    expect(prompt).toContain('"payload":{"title":"Review Agent Room UI fix"')
+    expect(prompt).toContain('payload.background: true')
+    expect(prompt).toContain('multiple subtasks')
+    expect(prompt).toContain('`session.status` protocol command')
+    expect(prompt).toContain('`session.events` protocol command')
+    expect(prompt).toContain('`session.message` protocol command')
+    expect(prompt).toContain('`session.submit`')
     expect(prompt).toContain('Do not directly edit files inside a registered workspace')
+    expect(prompt).not.toContain('VibeForge.StartTasks')
   })
 
   it('builds skill route prompts without preloading content', () => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vibe-forge/workspace-assets",
-  "version": "3.1.0",
+  "version": "3.2.0",
   "description": "Workspace asset resolution and adapter asset planning for Vibe Forge",
   "imports": {
     "#~/*.js": {
@@ -29,10 +29,10 @@
     "fast-glob": "^3.3.3",
     "front-matter": "^4.0.2",
     "js-yaml": "^4.1.1",
-    "@vibe-forge/types": "3.1.0",
-    "@vibe-forge/config": "3.1.0",
-    "@vibe-forge/utils": "3.1.0",
-    "@vibe-forge/definition-core": "3.1.0"
+    "@vibe-forge/types": "3.2.0",
+    "@vibe-forge/definition-core": "3.2.0",
+    "@vibe-forge/utils": "3.2.0",
+    "@vibe-forge/config": "3.2.0"
   },
   "devDependencies": {
     "@types/js-yaml": "^4.0.9"

package/src/prompt-builders.ts

@@ -5,7 +5,7 @@ import {
   resolveSpecIdentifier
 } from '@vibe-forge/definition-core'
 import type { Definition, Entity, Rule, Skill, Spec } from '@vibe-forge/types'
-import { CANONICAL_VIBE_FORGE_MCP_SERVER_NAME, resolvePromptPath } from '@vibe-forge/utils'
+import { resolvePromptPath } from '@vibe-forge/utils'
 
 import { buildManagedTaskToolGuidance } from './task-tool-guidance'
 
@@ -167,7 +167,7 @@ export const generateSpecRoutePrompt = (
 }
 
 export const generateEntitiesRoutePrompt = (entities: Definition<Entity>[]) => {
-  const taskToolGuidance = buildManagedTaskToolGuidance(CANONICAL_VIBE_FORGE_MCP_SERVER_NAME)
+  const taskToolGuidance = buildManagedTaskToolGuidance()
   return (
     '<system-prompt>\n' +
     'The project includes the following entities:\n' +
@@ -181,7 +181,7 @@ export const generateEntitiesRoutePrompt = (entities: Definition<Entity>[]) => {
         })
         .join('')
     }\n` +
-    `When solving user problems, you may specify entities through \`${CANONICAL_VIBE_FORGE_MCP_SERVER_NAME}.StartTasks\` as needed and have them coordinate multiple entity types to complete the work; use \`${CANONICAL_VIBE_FORGE_MCP_SERVER_NAME}.GetTaskInfo\` and \`wait\` to track progress.\n` +
+    'When solving user problems, you may start child runtime sessions with `vf run --input-format stream-json --output-format stream-json` and a `session.start` protocol envelope as needed; use `session.status`, `session.events`, and `wait` to track progress.\n' +
     `${taskToolGuidance}\n` +
     '</system-prompt>\n'
   )

package/src/task-tool-guidance.ts

@@ -1,13 +1,27 @@
-export const buildManagedTaskToolGuidance = (serverName: string) => {
+export const buildManagedTaskToolGuidance = () => {
   return [
-    'Task tool guide:',
-    `- Use \`${serverName}.StartTasks\` to start a new child task when the work should run in a separate entity or workspace, or when it needs to continue independently from the current turn.`,
-    `- After starting a task, use \`${serverName}.GetTaskInfo\` with \`{ taskId }\` to inspect one task. It is also the right tool when a task seems stalled, failed, or might be waiting for input.`,
-    '- By default, `GetTaskInfo` returns the 10 most recent log entries in descending order, so newer entries appear earlier in the `logs` array. Pass `logLimit` to inspect a different number of recent logs, and set `logOrder` to `"asc"` when you want the selected log window in oldest-to-newest order.',
-    `- Use \`${serverName}.ListTasks\` with the same \`logLimit\` and \`logOrder\` fields when you need to find a taskId or inspect multiple tasks at once.`,
-    `- Use \`${serverName}.SendTaskMessage\` with \`{ taskId, message }\` when you need to give a task another instruction. Running tasks continue immediately; completed or failed tasks resume the same conversation instead of forcing a replacement task.`,
-    `- Use \`${serverName}.SubmitTaskInput\` only when \`${serverName}.GetTaskInfo\` or \`${serverName}.ListTasks\` shows \`pendingInput\` or \`pendingInteraction\`, or the task status is \`waiting_input\`. Do not use it for ordinary follow-up instructions.`,
-    `- If a task is \`completed\` or \`failed\` but you want to keep working in that same thread of execution, prefer \`${serverName}.SendTaskMessage\` to resume it. Start a new task only when you actually want a replacement task.`,
-    '- When a task is still making progress, use `wait` between checks instead of repeatedly restarting it.'
+    'Agent runtime guide:',
+    '- Use unified CLI protocol mode, `vf run --input-format stream-json --output-format stream-json`, to start a child runtime session when the work should run in a separate entity or continue independently from the current turn.',
+    '- Send typed runtime protocol envelopes such as `session.start`, `session.message`, `session.status`, `session.events`, `session.submit`, and `session.stop`; do not treat dedicated `vf agent ...` subcommands as the standard integration surface.',
+    '- Ordinary new sessions stay session-scoped. A room is created or discovered only when a unified CLI runtime protocol start command launches a child runtime session from a server-managed host session and the server projects runtime store metadata/events.',
+    '- Do not use MCP task tools, `vf agent ...`, legacy StartTasks, hand-written DB edits, or ad-hoc TS scripts as the task consumer surface. Use CLI protocol mode and the runtime protocol/store for start, status, events, follow-up messages, input submission, and cancellation.',
+    '- Server-managed host sessions inject the current adapter, model, effort, and permission mode as runtime protocol defaults. Omit these fields to inherit the host selection, or set them explicitly only when a child task must use a different runtime profile.',
+    '- Copyable JSONL example; write one `session.start` line per child task, and use multiple lines for multiple subtasks:',
+    '```bash',
+    "cat <<'JSONL' | vf run --input-format stream-json --output-format stream-json",
+    '{"commandId":"start-planner","type":"session.start","payload":{"title":"Plan Agent Room UI fix","message":"Plan the frontend changes and tests for the Agent Room UI fix.","entity":"dev-planner","background":true},"title":"Plan Agent Room UI fix","message":"Plan the frontend changes and tests for the Agent Room UI fix.","entity":"dev-planner","background":true}',
+    '{"commandId":"start-reviewer","type":"session.start","payload":{"title":"Review Agent Room UI fix","message":"Review the implemented Agent Room UI fix for regressions and missing tests.","entity":"dev-reviewer","background":true},"title":"Review Agent Room UI fix","message":"Review the implemented Agent Room UI fix for regressions and missing tests.","entity":"dev-reviewer","background":true}',
+    'JSONL',
+    '```',
+    '- Keep `payload.title`, `payload.message`, `payload.entity`, and `payload.background: true` explicit in each start envelope. The mirrored top-level fields make the JSONL executable by the current `vf run` protocol reader.',
+    '- Include a short `title` when the task prompt is long; it becomes the child session title and room run label. Put any room or workspace context in the title and initial message.',
+    '- Read the returned `sessionId` and use it for follow-up protocol commands. Read the latest runtime snapshot from the runtime store or a `session.status` protocol command, and read progress from runtime events or a `session.events` protocol command.',
+    '- Use a follow/read-events workflow when you need to watch progress instead of repeatedly restarting work.',
+    '- Use a `session.message` protocol command to give an existing session another instruction. Running sessions continue immediately; completed or failed sessions resume the same conversation when the runtime allows resume.',
+    '- When the chat UI sends a `[ROOM_TASK_MESSAGE] ... [/ROOM_TASK_MESSAGE]` block, treat it as a runtime relay envelope instead of ordinary prose. Parse the `sessionId` or legacy `taskId`, `message`, and optional `mode` / `request` fields. If the envelope indicates `mode: interaction`, or runtime status shows `waiting_input` / pending input, use a `session.submit` protocol command. Otherwise use `session.message`. Do not reply inline instead of routing the relay.',
+    '- Use `session.submit` only when a runtime session is waiting for an explicit input or approval request. Do not use it for ordinary follow-up instructions.',
+    '- Use a `session.stop` protocol command for graceful cancellation and set `mode` to `force` only when stop cannot recover the session.',
+    '- Compatibility aliases such as `vf agent start/status/events/send/submit/stop` may exist for debugging or legacy scripts, but they are not the primary guidance for new agent workflows.',
+    '- When a session is still making progress, use `wait` between checks and inspect status/events instead of starting a replacement session.'
   ].join('\n')
 }

package/src/workspace-prompt.ts

@@ -1,5 +1,5 @@
 import type { WorkspaceDefinitionPayload } from '@vibe-forge/types'
-import { CANONICAL_VIBE_FORGE_MCP_SERVER_NAME, resolvePromptPath } from '@vibe-forge/utils'
+import { resolvePromptPath } from '@vibe-forge/utils'
 
 import { buildManagedTaskToolGuidance } from './task-tool-guidance'
 
@@ -8,7 +8,7 @@ export const generateWorkspaceRoutePrompt = (
   workspaces: WorkspaceDefinitionPayload[]
 ) => {
   if (workspaces.length === 0) return ''
-  const taskToolGuidance = buildManagedTaskToolGuidance(CANONICAL_VIBE_FORGE_MCP_SERVER_NAME)
+  const taskToolGuidance = buildManagedTaskToolGuidance()
 
   const workspaceList = workspaces
     .map((workspace) => {
@@ -25,7 +25,7 @@ export const generateWorkspaceRoutePrompt = (
     '<system-prompt>\n' +
     'The project includes the following registered workspaces:\n' +
     `${workspaceList}\n` +
-    `When a user request targets one of these workspaces, start a child task with \`${CANONICAL_VIBE_FORGE_MCP_SERVER_NAME}.StartTasks\` using \`type: "workspace"\` and \`name\` set to the workspace identifier. ` +
+    'When a user request targets one of these workspaces, start a child runtime session with `vf run --input-format stream-json --output-format stream-json` and a `session.start` envelope; include the workspace identifier and path in the title and message. ' +
     'Do not directly edit files inside a registered workspace from the current session unless the user explicitly asks this session to work in that directory.\n' +
     `${taskToolGuidance}\n` +
     '</system-prompt>\n'