dory-to-dory-watcher 0.4.0 → 0.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -7
- package/dist/agent.d.ts +1 -1
- package/dist/agent.d.ts.map +1 -1
- package/dist/agent.js +4 -4
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
dory-to-dory Core의 SSE wake-up 신호를 기다렸다가, 실제 처리할 work가 있을 때만 로컬 Agent CLI를 실행하는 크로스 플랫폼 Watcher입니다. SSE에는 작업 본문이 포함되지 않으며, 연결 또는 재연결 때 `/v2/watcher/status`로 실제 상태를 다시 확인합니다.
|
|
4
4
|
|
|
5
|
-
0.
|
|
5
|
+
0.5.0은 검색 증빙과 실행 담당자 규약 2, 실행 결과 보고를 지원하는 Core v2를 사용하며, MCP 0.5.0을 정확한 런타임 의존성으로 함께 설치합니다. `schedule_meeting 1.2.0`은 각 Agent의 성공·실패·결과 불명 보고로 완료를 판단하며 별도 결과 증빙·상호 캘린더 검증을 요구하지 않습니다. 기존 Skill은 저장된 receipt 계약을 유지합니다. Core에 직접 사용자 질문 API와 `owned_work` 상태 조회를 먼저 배포해야 합니다. 새 coordination 생성에는 정상 검색으로 발급받은 `skill_search_id`가 필수입니다. Core에도 검색 증빙 API와 migration이 적용되어 있어야 합니다. 기존 v1 작업은 자동 이전하지 않으며, 완료 또는 취소까지 기존 0.1.x MCP와 Watcher를 유지해야 합니다.
|
|
6
6
|
|
|
7
7
|
Watcher는 Agent를 새로 구현하지 않습니다. 사용자가 이미 로그인하고 도구를 설정한 Codex CLI, Claude Code, Gemini CLI를 headless 모드로 실행합니다. 비대화식 실행이 사람의 승인 창에서 멈추지 않도록 Agent별 안전 모드를 명시적으로 적용하며, 위험한 sandbox·권한 우회 인자는 거부합니다. dory-to-dory MCP는 Watcher의 정확한 런타임 의존성으로 함께 설치됩니다. `custom` Adapter를 통해 다른 Agent 개발자가 실행 방식을 교체할 수 있습니다.
|
|
8
8
|
|
|
@@ -37,7 +37,7 @@ Watcher는 Agent를 새로 구현하지 않습니다. 사용자가 이미 로그
|
|
|
37
37
|
일반 사용자는 Watcher를 전역 설치한 뒤 대화형 설정을 한 번 실행합니다.
|
|
38
38
|
|
|
39
39
|
```sh
|
|
40
|
-
npm install --global dory-to-dory-watcher@0.
|
|
40
|
+
npm install --global dory-to-dory-watcher@0.5.0
|
|
41
41
|
dory-watcher setup
|
|
42
42
|
```
|
|
43
43
|
|
|
@@ -81,7 +81,7 @@ Windows setup이 `Could not restrict the Windows credential ACL`로 중단되고
|
|
|
81
81
|
같은 Node 설치와 npm 전역 prefix를 유지하는 일반적인 Watcher 업데이트는 다음 순서로 진행합니다. 두 번째 명령은 새 설치 경로를 확인하고 서비스 정의를 안전하게 교체한 뒤 실행 중인 Watcher를 새 버전으로 재시작합니다.
|
|
82
82
|
|
|
83
83
|
```sh
|
|
84
|
-
npm install --global dory-to-dory-watcher@0.
|
|
84
|
+
npm install --global dory-to-dory-watcher@0.5.0
|
|
85
85
|
dory-watcher service install --replace
|
|
86
86
|
dory-watcher status
|
|
87
87
|
```
|
|
@@ -125,7 +125,7 @@ node dist/cli.js run
|
|
|
125
125
|
npm 패키지는 다음과 같이 전역 설치할 수 있습니다.
|
|
126
126
|
|
|
127
127
|
```sh
|
|
128
|
-
npm install --global dory-to-dory-watcher@0.
|
|
128
|
+
npm install --global dory-to-dory-watcher@0.5.0
|
|
129
129
|
dory-watcher doctor
|
|
130
130
|
dory-watcher run
|
|
131
131
|
```
|
|
@@ -281,8 +281,8 @@ pnpm run check
|
|
|
281
281
|
|
|
282
282
|
## v2 and the desktop Agent
|
|
283
283
|
|
|
284
|
-
Version `0.
|
|
285
|
-
contracts, and installs the exact MCP `0.
|
|
284
|
+
Version `0.5.0` requires the Core `/v2/watcher/status` and skill-search proof
|
|
285
|
+
contracts plus execution-result reporting, and installs the exact MCP `0.5.0` dependency. New `schedule_meeting 1.2.0` work reports succeeded, failed or unknown without a separate calendar verification round; pinned legacy Skills retain their receipt contract. Core must also have the
|
|
286
286
|
skill-search API and migration deployed. MCP requires a successful search proof
|
|
287
287
|
before each new coordination and stops creation after an initial search plus at
|
|
288
288
|
most three retries.
|
|
@@ -328,7 +328,7 @@ an expired lease before redelivery. CLI exit alone does not prove execution.
|
|
|
328
328
|
|
|
329
329
|
### Local development across the two repositories
|
|
330
330
|
|
|
331
|
-
`package.json` and the lockfile use the registry package `dory-to-dory-mcp@0.
|
|
331
|
+
`package.json` and the lockfile use the registry package `dory-to-dory-mcp@0.5.0`.
|
|
332
332
|
There is no local sibling-repository override. If you temporarily link an MCP
|
|
333
333
|
checkout while developing a coordinated change, remove that override, regenerate
|
|
334
334
|
the lockfile against the exact published dependency, and verify an isolated
|
package/dist/agent.d.ts
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
import type { AgentKind, WatcherConfig } from "./config.js";
|
|
2
2
|
import type { PendingWork } from "./core-client.js";
|
|
3
|
-
export declare const WAKE_PROMPT = "This is a dory-to-dory v2 background wake-up. Process at most one pending work item.\n\n1. Call d2d_claim_next_item exactly once, scoped to the supplied work_id/coordination_id when present. Pass your real current session_id or null for an Agent without persistent sessions.\n2. If no work
|
|
3
|
+
export declare const WAKE_PROMPT = "This is a dory-to-dory v2 background wake-up. Process at most one pending work item.\n\n1. Call d2d_claim_next_item exactly once, scoped to the supplied work_id/coordination_id when present. Pass your real current session_id or null for an Agent without persistent sessions.\n2. If the claim succeeds with no work, finish immediately without a user-facing message. An isError result is a failed claim, not an empty queue; do not invent a claim or report work as processed.\n3. Check delivery.work.kind first. For notification work, record the role-filtered update in the current session and call d2d_acknowledge_item with the work ID and claim ID, then finish; never execute external actions or modify business cards for a notification. Terminal updates and late recovery receipts use this path.\n4. For execution work, read the returned role, revision, request, policy, lease and claim_id. Derive the task's minimum semantic capabilities and compare them with your available tools and permissions; never invent a successful result.\n5. For a client role, only submit the final to_host result through d2d_submit_item_result using work_id, claim_id, turn_id and request_id from this delivery, with expected_revision equal to your current client card revision. Never alter state, slots, attempt, to_client, host_card or another client's card. Gather missing information and approval evidence before submitting the result; a client submission hands execution back to the host.\n6. For a host role, assess all delivered responses, update plan/slots/client states and issue the next requests using d2d_update_host_card with the active host work lease. When delivery.coordination.execution_protocol=2, use next_action=continue for intermediate saves and continue working with the SAME claim, using the latest returned coordination.revision for the top-level expected_revision and each client card revision for client_updates[].expected_revision. You may call d2d_update_host_card multiple times within this claimed work. Use next_action=dispatch to hand off to one client, or next_action=finish to settle the coordination. Never exit after only a continue checkpoint. Assess completion from the requested outcome and each required participant's actual execution result, including your own result when host_attends=true. Skill is optional; author a plan from the goal if none applies. Claims omit skill content; only a Host can fetch the stored skill, full plan and workflow slots through d2d_get_coordination. A Client receives only its own card and shared proposal; it must not repeatedly fetch hidden host context. If system_status=paused, both host and client must wait for Dashboard resume; do not update business cards or execute external actions. Only Host execution work issued by Core for cleanup in system_status=cancel_requested may preserve partial or unknown results and settle failed/cancelled without starting external work. Notification work is never cleanup execution. Terminal updates require reason and reason_code; after commit preserve partial_external_commit when any action may have succeeded or remains unknown.\n7. If user confirmation or missing information is required and delivery.coordination.execution_protocol=2, call d2d_request_user_input with the current work and claim to persist the question and park THIS work, then exit. This is runtime suspension: do not change a card to a user-waiting business state, do not submit to_host.ask_user as a partial client result, and do not hand the question to the host for permission. The reply resumes the same owner's work; use the newly claimed delivery and its answered interactions, never the previous claim. If the question tool is unavailable, report the missing capability without pretending to submit a result or falling back to a legacy partial-result flow. Only legacy coordination without execution_protocol=2 uses the structured ask_user result. Never invent an answer or prompt in this headless terminal. Use answered interactions when resuming.\n8. Only execute a calendar commit after all required participants are ready for the same proposal and the host has recorded its final decision. For result_mode=agent_report (schedule_meeting 1.2.0), report the actual tool outcome as succeeded, failed or unknown in the same execution turn: a Client submits type=committed with to_host.execution_result, and an attending Host submits host_execution_result. Each report contains the current proposal_hash, the issued execution operation_id and status, with an optional reason. These execution operation IDs differ from the top-level tool retry operation_id. The Host completes the existing registration step from all required successful reports; there is no verify phase or separate results-validation round. Do not require receipts, provider names, calendar IDs, event IDs, or access to another participant's calendar. A successful report must not become a failure because optional metadata or event read/search tools are absent. The acting Agent handles uncertain outcomes and duplicate prevention within its own calendar capabilities, preserving unknown if unresolved and never blindly creating again. Never fabricate success or discard another participant's successful report. Follow the pinned legacy skill's receipt contract for older coordinations; do not reinterpret their stored definition.\n\nDo not process unrelated work and do not include credentials in output.";
|
|
4
4
|
export interface AgentWakeContext {
|
|
5
5
|
work: PendingWork;
|
|
6
6
|
account_id?: string;
|
package/dist/agent.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"agent.d.ts","sourceRoot":"","sources":["../src/agent.ts"],"names":[],"mappings":"AAGA,OAAO,KAAK,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5D,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAGpD,eAAO,MAAM,WAAW,
|
|
1
|
+
{"version":3,"file":"agent.d.ts","sourceRoot":"","sources":["../src/agent.ts"],"names":[],"mappings":"AAGA,OAAO,KAAK,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5D,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAGpD,eAAO,MAAM,WAAW,80KAWgD,CAAC;AAEzE,MAAM,WAAW,gBAAgB;IAC/B,IAAI,EAAE,WAAW,CAAC;IAClB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,wBAAgB,cAAc,CAAC,OAAO,EAAE,gBAAgB,GAAG,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAgBjF;AAED,MAAM,WAAW,eAAe;IAC9B,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,aAAa,EAAE,MAAM,CAAC;CACvB;AAED,MAAM,WAAW,cAAc;IAC7B,QAAQ,EAAE,MAAM,CAAC;IACjB,UAAU,EAAE,MAAM,CAAC;IACnB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,cAAc,CAAC,EAAE,QAAQ,GAAG,WAAW,CAAC;CACzC;AAED,MAAM,MAAM,gBAAgB,GACxB,eAAe,GACf,yBAAyB,GACzB,uBAAuB,GACvB,kBAAkB,GAClB,iBAAiB,GACjB,SAAS,GACT,oBAAoB,GACpB,kBAAkB,GAClB,WAAW,CAAC;AAchB,qBAAa,aAAc,SAAQ,KAAK;IAIpC,QAAQ,CAAC,WAAW,EAAE,gBAAgB;IACtC,QAAQ,CAAC,OAAO,EAAE;QAChB,QAAQ,CAAC,EAAE,MAAM,CAAC;QAClB,UAAU,CAAC,EAAE,MAAM,CAAC;QACpB,KAAK,CAAC,EAAE,MAAM,CAAC;KAChB;IARM,IAAI,SAAmB;gBAGrB,WAAW,EAAE,gBAAgB,EAC7B,OAAO,GAAE;QAChB,QAAQ,CAAC,EAAE,MAAM,CAAC;QAClB,UAAU,CAAC,EAAE,MAAM,CAAC;QACpB,KAAK,CAAC,EAAE,MAAM,CAAC;KACX;CAIT;AA6BD,wBAAgB,mBAAmB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,IAAI,CAExD;AAED,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,IAAI,CAKzD;AAED,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,IAAI,CAEzD;AAED,wBAAgB,4BAA4B,CAC1C,IAAI,EAAE,SAAS,EACf,QAAQ,GAAE,MAAM,CAAC,QAA2B,GAC3C,IAAI,CAIN;AA4BD,qFAAqF;AACrF,wBAAgB,yBAAyB,CACvC,IAAI,EAAE,SAAS,EACf,WAAW,GAAE,MAAM,CAAC,UAAwB,EAC5C,QAAQ,GAAE,MAAM,CAAC,QAA2B,GAC3C,MAAM,CAAC,UAAU,CAgBnB;AAED,wBAAgB,oBAAoB,CAAC,MAAM,EAAE,MAAM,GAAG,gBAAgB,CAkCrE;AASD,wBAAgB,yBAAyB,CACvC,GAAG,EAAE,MAAM,EACX,KAAK,EAAE,OAAO,GACb;IAAE,OAAO,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,EAAE,CAAA;CAAE,CAKrC;AAED,wBAAgB,+BAA+B,CAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,GAAG,OAAO,CAEhF;AAED,wBAAgB,eAAe,CAC7B,IAAI,EAAE,SAAS,EACf,OAAO,EAAE,MAAM,EACf,SAAS,EAAE,MAAM,EAAE,EACnB,OAAO,CAAC,EAAE,gBAAgB,GACzB,eAAe,CAqDjB;AAED,wBAAsB,QAAQ,CAAC,MAAM,EAAE,aAAa,EAAE,MAAM,CAAC,EAAE,WAAW,EAAE,OAAO,CAAC,EAAE,gBAAgB,GAAG,OAAO,CAAC,cAAc,CAAC,CAyJ/H"}
|
package/dist/agent.js
CHANGED
|
@@ -4,13 +4,13 @@ import { commandForSpawn } from "./process.js";
|
|
|
4
4
|
export const WAKE_PROMPT = `This is a dory-to-dory v2 background wake-up. Process at most one pending work item.
|
|
5
5
|
|
|
6
6
|
1. Call d2d_claim_next_item exactly once, scoped to the supplied work_id/coordination_id when present. Pass your real current session_id or null for an Agent without persistent sessions.
|
|
7
|
-
2. If no work
|
|
7
|
+
2. If the claim succeeds with no work, finish immediately without a user-facing message. An isError result is a failed claim, not an empty queue; do not invent a claim or report work as processed.
|
|
8
8
|
3. Check delivery.work.kind first. For notification work, record the role-filtered update in the current session and call d2d_acknowledge_item with the work ID and claim ID, then finish; never execute external actions or modify business cards for a notification. Terminal updates and late recovery receipts use this path.
|
|
9
9
|
4. For execution work, read the returned role, revision, request, policy, lease and claim_id. Derive the task's minimum semantic capabilities and compare them with your available tools and permissions; never invent a successful result.
|
|
10
|
-
5. For a client role, only submit the final to_host result through d2d_submit_item_result using work_id, claim_id, turn_id and request_id from this delivery. Never alter state, slots, attempt, to_client, host_card or another client's card. Gather missing information and approval evidence before submitting the result; a client submission hands execution back to the host.
|
|
11
|
-
6. For a host role, assess all delivered responses, update plan/slots/client states and issue the next requests using d2d_update_host_card with the active host work lease. When delivery.coordination.execution_protocol=2, use next_action=continue for intermediate saves and continue working with the SAME claim, using the latest returned card
|
|
10
|
+
5. For a client role, only submit the final to_host result through d2d_submit_item_result using work_id, claim_id, turn_id and request_id from this delivery, with expected_revision equal to your current client card revision. Never alter state, slots, attempt, to_client, host_card or another client's card. Gather missing information and approval evidence before submitting the result; a client submission hands execution back to the host.
|
|
11
|
+
6. For a host role, assess all delivered responses, update plan/slots/client states and issue the next requests using d2d_update_host_card with the active host work lease. When delivery.coordination.execution_protocol=2, use next_action=continue for intermediate saves and continue working with the SAME claim, using the latest returned coordination.revision for the top-level expected_revision and each client card revision for client_updates[].expected_revision. You may call d2d_update_host_card multiple times within this claimed work. Use next_action=dispatch to hand off to one client, or next_action=finish to settle the coordination. Never exit after only a continue checkpoint. Assess completion from the requested outcome and each required participant's actual execution result, including your own result when host_attends=true. Skill is optional; author a plan from the goal if none applies. Claims omit skill content; only a Host can fetch the stored skill, full plan and workflow slots through d2d_get_coordination. A Client receives only its own card and shared proposal; it must not repeatedly fetch hidden host context. If system_status=paused, both host and client must wait for Dashboard resume; do not update business cards or execute external actions. Only Host execution work issued by Core for cleanup in system_status=cancel_requested may preserve partial or unknown results and settle failed/cancelled without starting external work. Notification work is never cleanup execution. Terminal updates require reason and reason_code; after commit preserve partial_external_commit when any action may have succeeded or remains unknown.
|
|
12
12
|
7. If user confirmation or missing information is required and delivery.coordination.execution_protocol=2, call d2d_request_user_input with the current work and claim to persist the question and park THIS work, then exit. This is runtime suspension: do not change a card to a user-waiting business state, do not submit to_host.ask_user as a partial client result, and do not hand the question to the host for permission. The reply resumes the same owner's work; use the newly claimed delivery and its answered interactions, never the previous claim. If the question tool is unavailable, report the missing capability without pretending to submit a result or falling back to a legacy partial-result flow. Only legacy coordination without execution_protocol=2 uses the structured ask_user result. Never invent an answer or prompt in this headless terminal. Use answered interactions when resuming.
|
|
13
|
-
8. Only execute a calendar commit after all required participants are ready for the same proposal and the host has recorded its final decision.
|
|
13
|
+
8. Only execute a calendar commit after all required participants are ready for the same proposal and the host has recorded its final decision. For result_mode=agent_report (schedule_meeting 1.2.0), report the actual tool outcome as succeeded, failed or unknown in the same execution turn: a Client submits type=committed with to_host.execution_result, and an attending Host submits host_execution_result. Each report contains the current proposal_hash, the issued execution operation_id and status, with an optional reason. These execution operation IDs differ from the top-level tool retry operation_id. The Host completes the existing registration step from all required successful reports; there is no verify phase or separate results-validation round. Do not require receipts, provider names, calendar IDs, event IDs, or access to another participant's calendar. A successful report must not become a failure because optional metadata or event read/search tools are absent. The acting Agent handles uncertain outcomes and duplicate prevention within its own calendar capabilities, preserving unknown if unresolved and never blindly creating again. Never fabricate success or discard another participant's successful report. Follow the pinned legacy skill's receipt contract for older coordinations; do not reinterpret their stored definition.
|
|
14
14
|
|
|
15
15
|
Do not process unrelated work and do not include credentials in output.`;
|
|
16
16
|
export function ingestEnvelope(context) {
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "dory-to-dory-watcher",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.5.0",
|
|
4
4
|
"description": "Cross-platform SSE watcher that wakes a configured local Agent CLI for dory-to-dory work",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -34,7 +34,7 @@
|
|
|
34
34
|
"access": "public"
|
|
35
35
|
},
|
|
36
36
|
"dependencies": {
|
|
37
|
-
"dory-to-dory-mcp": "0.
|
|
37
|
+
"dory-to-dory-mcp": "0.5.0"
|
|
38
38
|
},
|
|
39
39
|
"devDependencies": {
|
|
40
40
|
"@types/node": "^24.0.0",
|