dominds 1.15.3 → 1.15.5

package/dist/apps/assigned-port.d.ts

@@ -1,4 +1,4 @@
-import type { DomindsAppInstallJsonV1 } from '@longrun-ai/kernel/app-json';
+import type { DomindsAppInstallJson } from '@longrun-ai/kernel/app-json';
 import type { AppsResolutionEntry } from './resolution-file';
 export type AssignedPortResolutionReason = 'no_frontend' | 'kept_existing' | 'selected_default' | 'allocated_stable_range' | 'reassigned_from_existing_conflict' | 'reassigned_from_existing_unbindable';
 export type AssignedPortResolution = Readonly<{
@@ -16,13 +16,13 @@ export type AssignedPortResolution = Readonly<{
  */
 export declare function resolveStableAssignedPort(params: {
     appId: string;
-    installJson: DomindsAppInstallJsonV1;
+    installJson: DomindsAppInstallJson;
     existingApps: ReadonlyArray<AppsResolutionEntry>;
     existingAssignedPort: number | null;
 }): Promise<number | null>;
 export declare function resolveStableAssignedPortWithReason(params: {
     appId: string;
-    installJson: DomindsAppInstallJsonV1;
+    installJson: DomindsAppInstallJson;
     existingApps: ReadonlyArray<AppsResolutionEntry>;
     existingAssignedPort: number | null;
 }): Promise<AssignedPortResolution>;

package/dist/apps/resolution-file.d.ts

@@ -1,4 +1,4 @@
-import { type DomindsAppInstallJsonV1 } from '@longrun-ai/kernel/app-json';
+import { type DomindsAppInstallJson } from '@longrun-ai/kernel/app-json';
 export type AppsResolutionSchemaVersion = 1;
 export type AppsResolutionSource = Readonly<{
     kind: 'npx';
@@ -12,7 +12,7 @@ export type AppsResolutionEntry = Readonly<{
     enabled: boolean;
     source: AppsResolutionSource;
     assignedPort: number | null;
-    installJson: DomindsAppInstallJsonV1;
+    installJson: DomindsAppInstallJson;
 }>;
 export type AppsResolutionFile = Readonly<{
     schemaVersion: AppsResolutionSchemaVersion;

package/dist/apps/run-app-json.d.ts

@@ -1,8 +1,8 @@
-import { type DomindsAppInstallJsonV1 } from '@longrun-ai/kernel/app-json';
+import { type DomindsAppInstallJson } from '@longrun-ai/kernel/app-json';
 export declare function runDomindsAppJsonViaNpx(params: {
     spec: string;
     cwdAbs: string;
-}): Promise<DomindsAppInstallJsonV1>;
+}): Promise<DomindsAppInstallJson>;
 export declare function runDomindsAppJsonViaLocalPackage(params: {
     packageRootAbs: string;
-}): Promise<DomindsAppInstallJsonV1>;
+}): Promise<DomindsAppInstallJson>;

package/dist/apps-host/client.d.ts

@@ -1,12 +1,12 @@
 import type { DomindsAppDynamicToolsetsContext, DomindsAppReminderOwnerApplyContext, DomindsAppReminderOwnerRenderContext, DomindsAppReminderOwnerUpdateContext, DomindsAppRunControlContext, DomindsAppRunControlResult } from '@longrun-ai/kernel/app-host-contract';
-import type { DomindsAppHostReminderUpdateResult, DomindsAppHostToolResult, DomindsAppInstallJsonV1, DomindsAppReminderApplyRequest, DomindsAppReminderApplyResult } from '@longrun-ai/kernel/app-json';
+import type { DomindsAppHostReminderUpdateResult, DomindsAppHostToolResult, DomindsAppInstallJson, DomindsAppReminderApplyRequest, DomindsAppReminderApplyResult } from '@longrun-ai/kernel/app-json';
 import type { ChatMessage } from '../llm/client';
 import type { ToolArguments } from '../tool';
 import type { AppsHostMessageToKernel } from './ipc-types';
 export type EnabledAppForHost = Readonly<{
     appId: string;
     runtimePort: number | null;
-    installJson: DomindsAppInstallJsonV1;
+    installJson: DomindsAppInstallJson;
     hostSourceVersion: string | null;
 }>;
 export type AppsHostClient = Readonly<{

package/dist/apps-host/host.js

@@ -33,12 +33,14 @@ function isStringArray(value) {
     return Array.isArray(value) && value.every((item) => typeof item === 'string');
 }
 function isToolCallOutput(value) {
-    if (typeof value === 'string')
-        return true;
     if (!isRecord(value))
         return false;
     if (typeof value['content'] !== 'string')
         return false;
+    const outcome = value['outcome'];
+    if (outcome !== 'success' && outcome !== 'failure' && outcome !== 'partial_failure') {
+        return false;
+    }
     const contentItems = value['contentItems'];
     return contentItems === undefined || Array.isArray(contentItems);
 }
@@ -183,15 +185,12 @@ function isChatMessage(value) {
     return true;
 }
 function normalizeToolResult(value) {
-    if (isToolCallOutput(value)) {
-        return { output: value };
-    }
     if (!isRecord(value)) {
-        throw new Error('Invalid app tool result: expected ToolCallOutput or structured object');
+        throw new Error('Invalid app tool result: expected { output: { content, outcome, contentItems? }, ... }');
     }
     const output = value['output'];
     if (!isToolCallOutput(output)) {
-        throw new Error('Invalid app tool result: output must be ToolCallOutput');
+        throw new Error('Invalid app tool result: output must be { content, outcome, contentItems? }');
     }
     const reminderRequestsRaw = value['reminderRequests'];
     if (reminderRequestsRaw !== undefined && !Array.isArray(reminderRequestsRaw)) {

package/dist/apps-host/ipc-types.d.ts

@@ -1,5 +1,5 @@
 import type { DomindsAppRunControlResult } from '@longrun-ai/kernel/app-host-contract';
-import type { DomindsAppDialogReminderRequestBatch, DomindsAppHostReminderUpdateResult, DomindsAppInstallJsonV1, DomindsAppReminderApplyRequest, DomindsAppReminderApplyResult, DomindsAppReminderState } from '@longrun-ai/kernel/app-json';
+import type { DomindsAppDialogReminderRequestBatch, DomindsAppHostReminderUpdateResult, DomindsAppInstallJson, DomindsAppReminderApplyRequest, DomindsAppReminderApplyResult, DomindsAppReminderState } from '@longrun-ai/kernel/app-json';
 import type { LanguageCode } from '@longrun-ai/kernel/types/language';
 import type { ChatMessage } from '../llm/client';
 import type { ToolArguments, ToolCallOutput } from '../tool';
@@ -13,7 +13,7 @@ export type AppsHostKernelInitMessage = Readonly<{
     apps: ReadonlyArray<Readonly<{
         appId: string;
         runtimePort: number | null;
-        installJson: DomindsAppInstallJsonV1;
+        installJson: DomindsAppInstallJson;
     }>>;
 }>;
 export type AppsHostKernelToolCallMessage = Readonly<{

package/dist/docs/app-constitution.md

@@ -222,7 +222,7 @@ Recommended user mental model:
 
 (Current: implemented) existing anchors:
 
-- JSON schema: `dominds/main/apps/app-json.ts` (`DomindsAppInstallJsonV1`).
+- JSON schema: `dominds/main/apps/app-json.ts` (`DomindsAppInstallJson`).
 - Apps configuration file: `dominds/main/apps/configuration-file.ts`.
 - Apps resolution file: `dominds/main/apps/resolution-file.ts`.
 

package/dist/docs/app-constitution.zh.md

@@ -221,7 +221,7 @@ Install JSON 是 app 与 Kernel/CLI 之间的**安装/运行握手载荷**。它
 
 （现状：已实现）install json schema 与 apps 配置/解析锚点仍可参考：
 
-- JSON schema：`dominds/main/apps/app-json.ts`（`DomindsAppInstallJsonV1`）。
+- JSON schema：`dominds/main/apps/app-json.ts`（`DomindsAppInstallJson`）。
 - `.apps/configuration.yaml`：`dominds/main/apps/configuration-file.ts`。
 - `.apps/resolution.yaml`：`dominds/main/apps/resolution-file.ts`。
 

package/dist/docs/team_mgmt-toolset.md

@@ -133,6 +133,9 @@ Notes:
   - For `team_mgmt`, that explicit allowlist is `.minds/**` (including `.minds/memory/**`) so the
     team manager can repair accidental corruptions made by other tools (even though `.minds/memory/**`
     already has dedicated `personal_memory` / `team_memory` tools for normal use).
+- Conversely, the denial of `.minds/**` / `*.tsk/**` for general file tools is a **built-in hard runtime
+  rule**, not a standard deny stanza you should keep repeating in `team.yaml`. Only additional
+  business-specific constraints belong in explicit `no_read_dirs` / `no_write_dirs`.
 - Require explicit `.minds/...` paths and validate them; do not support “implicitly scoped” paths
   like `team.yaml`.
 
@@ -444,19 +447,14 @@ member_defaults:
   toolsets:
     - ws_read
     - personal_memory
-  # Default posture: deny `.minds/` edits for normal members.
-  # (Team management should be done via `team_mgmt` tools, not general file tools.)
-  no_read_dirs:
-    - .minds/team.yaml
-    - .minds/llm.yaml
-    - .minds/mcp.yaml
-    - .minds/team/**
-  no_write_dirs:
-    - .minds/**
 
 default_responder: fuxi
 
 members:
+
+Note: in the normal-member example above, do **not** add `no_read_dirs` / `no_write_dirs` merely to
+restate that `.minds/**` is blocked. That boundary is already enforced by the runtime for general
+file tools; explicit deny entries should be reserved for extra constraints beyond the built-ins.
   # Example visible teammate (recommended): define at least one non-hidden responder for daily work.
   dev:
     name: Dev

package/dist/docs/team_mgmt-toolset.zh.md

@@ -110,6 +110,7 @@
   - 拒绝规范化后解析到 `.minds/` 之外的任何路径
 - 优先使用显式白名单而非" rtws 中的任何内容"
 - 对于 `team_mgmt`，该显式白名单是 `.minds/**`（包括 `.minds/memory/**`），以便团队管理者可以修复其他工具造成的意外损坏（即使 `.minds/memory/**` 已有专用的 `personal_memory` / `team_memory` 工具供正常使用）
+- 反过来，普通通用文件工具对 `.minds/**` / `*.tsk/**` 的拒绝是**系统内置硬约束**，不是需要在 `team.yaml` 里重复书写的常规 deny 项。只有额外业务约束才需要显式写入 `no_read_dirs` / `no_write_dirs`
 - 需要显式的 `.minds/...` 路径并验证它们；不支持像 `team.yaml` 这样的"隐式作用域"路径
 
 ### 为什么需要专用工具集（而不是仅 `read_dirs` / `write_dirs`）？
@@ -383,19 +384,12 @@ member_defaults:
   toolsets:
     - ws_read
     - personal_memory
-  # 默认姿态：拒绝普通成员的 `.minds/` 编辑
-  #（团队管理应通过 `team_mgmt` 工具完成，而非通用文件工具）
-  no_read_dirs:
-    - .minds/team.yaml
-    - .minds/llm.yaml
-    - .minds/mcp.yaml
-    - .minds/team/**
-  no_write_dirs:
-    - .minds/**
 
 default_responder: fuxi
 
 members:
+
+说明：上面的普通成员默认示例**不要**再额外写 `no_read_dirs` / `no_write_dirs` 去重复声明 `.minds/**` 拒绝。那是运行时内置边界，不是常规样板；只有要表达超出内置边界的额外 deny 规则时，才应显式写这些字段。
   # 示例显在成员（推荐）：至少定义一个非隐藏的响应者用于日常工作
   dev:
     name: Dev

package/dist/docs/tellask-result-unification.md

@@ -0,0 +1,280 @@
+# Tellask Result Unification
+
+## Purpose
+
+This document captures the agreed direction for the current tellask refactor so the
+implementation can stay aligned while multiple storage, runtime, provider, and frontend
+paths are being simplified at the same time.
+
+The goal is not to preserve old technical symmetry for its own sake. The goal is to make
+tellask behave as one coherent business feature with fewer special cases.
+
+## Agreed Direction
+
+- Keep `tellask_call_record` as the tellask-family call record.
+- Keep one unified tellask business result type:
+  - `tellask_result_record`
+  - `tellask_result_msg`
+  - `tellask_result_evt`
+- Keep carryover special and separate:
+  - rename `tellask_carryover_result_record` to `tellask_carryover_record`
+  - rename `tellask_carryover_result_msg` to `tellask_carryover_msg`
+  - rename `tellask_call_carryover_evt` / `tellask_carryover_result_evt` style names into a single
+    `tellask_carryover_evt`
+- Inline tellask result rendering is no longer the target model.
+- Tellask results should render as separate bubbles.
+- Call-site UI may still exist for pending / settled state, but result body should not depend on
+  inline rendering.
+- `replyTellask*` is not a separate business result family to unify on its own.
+  `replyTellask*` is a mechanism that produces a tellask result.
+- `askHuman` should move into the tellask result flow instead of being represented as a normal
+  user bubble.
+- Q4H answers should not be persisted as `human_text_record` for askHuman result rendering.
+
+## Current Problem
+
+Tellask business semantics are currently split across too many layers:
+
+- `tellask_call_record`
+  - call start
+- `tellask_call_result_record`
+  - local inline tellask business result
+- `tellask_response_record`
+  - sideline / subdialog response bubble
+- `tellask_result_record`
+  - thin technical pair record added later for call/result parity
+- `tellask_carryover_result_record`
+  - special cross-course carryover
+
+This produces several kinds of debt:
+
+- one business feature has multiple result record types
+- one business result message name has mixed semantics
+- frontend uses different event families for inline vs separate-bubble tellask results
+- `askHuman` answer flow still re-enters the generic user-message path
+- provider/runtime logic has had to invent technical projection types that are not the real
+  business model
+
+## Business Model After Refactor
+
+### Tellask Call
+
+`tellask_call_record` remains the start record for tellask-family tool invocation.
+
+It still covers:
+
+- `tellask`
+- `tellaskSessionless`
+- `tellaskBack`
+- `askHuman`
+- `freshBootsReasoning`
+- `replyTellask`
+- `replyTellaskSessionless`
+- `replyTellaskBack`
+
+### Tellask Result
+
+`tellask_result_record` becomes the single business result record for tellask outcomes.
+
+It should absorb the business payload currently split across:
+
+- `tellask_call_result_record`
+- `tellask_response_record`
+
+It should be rich enough to carry the actual tellask business context, not just a thin tool pair.
+
+### Tellask Carryover
+
+Carryover stays separate because it is not a normal call/result pair outcome.
+
+Its essence is:
+
+- cross-course continuation
+- special context anchor semantics
+- intentionally not part of standard call/result unification
+
+So it should remain independent under shorter names:
+
+- `tellask_carryover_record`
+- `tellask_carryover_msg`
+- `tellask_carryover_evt`
+
+## Message And Event Model
+
+### Result Bubble Direction
+
+Tellask business results should render as separate bubbles.
+
+That means the frontend event model should converge toward:
+
+- `tellask_call_start_evt`
+  - call-site lifecycle start
+- `tellask_result_evt`
+  - business result bubble creation / replay
+  - status updates for the related call site
+- `tellask_carryover_evt`
+  - special carryover bubble
+
+The old split:
+
+- `tellask_call_result_evt`
+- `tellask_response_evt`
+
+should be collapsed into `tellask_result_evt`.
+
+### Frontend Behavior
+
+Frontend call-site handling should become simpler:
+
+- call site shows pending / settled / carried-over state
+- tellask result body is shown in a separate bubble
+- no dependency on inline result body rendering
+
+This applies to:
+
+- local tellask failures
+- sideline/subdialog responses
+- askHuman pending/final result display
+
+## AskHuman Direction
+
+`askHuman` should behave as part of the tellask family, not as a detour into the generic user
+message path.
+
+### Desired Flow
+
+1. `askHuman` call starts as a tellask-family call.
+2. A temporary tellask-style result is shown while waiting.
+3. When the human answers, the final askHuman result is represented as a tellask result.
+4. The answer should not be kept as a normal user bubble for this purpose.
+
+### Important Clarification
+
+The runtime may still need the answer content to continue the next generation round.
+
+But that technical need must not force the product model to keep askHuman answers as
+`human_text_record` or ordinary user-style UI bubbles.
+
+The tellask business model is the source of truth.
+
+## ReplyTellask Direction
+
+`replyTellask*` should not be treated as a separate business result family.
+
+The correct business interpretation is:
+
+- `replyTellask*` is an action that produces a tellask result
+- the tellask result is the business object
+- `replyTellask*` itself does not need another parallel business-unification effort
+
+In practice this means the refactor should avoid introducing extra local-only reply result models
+just to satisfy old technical pairing assumptions.
+
+## Tellask Result Record Shape
+
+The unified `tellask_result_record` should be rich and business-oriented.
+
+It should not flatten every field at top level.
+
+Preferred shape:
+
+- keep truly global result fields at top level
+- move stable field groups into optional nested structures
+- inside a nested structure, fields should be required whenever that structure is present
+
+Suggested top-level concerns:
+
+- record identity / timestamp / course refs
+- `callId`
+- `callName`
+- `status`
+- `content`
+
+Suggested nested groups:
+
+- `call`
+  - original tellask call context
+  - example fields:
+    - `tellaskContent`
+    - `mentionList`
+    - `sessionSlug`
+- `responder`
+  - who produced the business result
+  - example fields:
+    - `responderId`
+    - `agentId`
+    - `originMemberId`
+- `route`
+  - navigation / callee metadata when applicable
+  - example fields:
+    - `calleeDialogId`
+    - `calleeCourse`
+    - `calleeGenseq`
+
+The exact final union can be refined during implementation, but the important rule is:
+
+- business grouping first
+- technical pairing concerns do not get to dictate the field model
+
+## Provider / Runtime Interpretation
+
+The unified tellask result model is the business truth.
+
+Provider/runtime projection must adapt to it, not the other way around.
+
+This means:
+
+- do not invent thin technical result types as the canonical tellask model
+- if the provider layer needs a particular call/result projection, derive it from the business
+  message
+- do not let tool-pair convenience decide what fields are allowed to exist
+
+## Files Expected To Change
+
+The refactor will likely touch at least these areas:
+
+- `packages/kernel/src/types/storage.ts`
+- `packages/kernel/src/types/chat-message.ts`
+- `packages/kernel/src/types/dialog.ts`
+- `main/persistence.ts`
+- `main/dialog.ts`
+- `main/priming.ts`
+- `main/dialog-fork.ts`
+- `main/llm/kernel-driver/tellask-special.ts`
+- `main/llm/kernel-driver/drive.ts`
+- `main/server/websocket-handler.ts`
+- `main/llm/gen/openai.ts`
+- `main/llm/gen/openai-compatible.ts`
+- `main/llm/gen/codex.ts`
+- `main/llm/gen/anthropic.ts`
+- `main/llm/gen/mock.ts`
+- `webapp/src/components/dominds-dialog-container.ts`
+- `webapp/src/components/dominds-app.tsx`
+
+Tests will also need a broad update wherever old tellask inline/result/carryover names are asserted.
+
+## Implementation Checklist
+
+- Redefine `tellask_result_record` as the single business result record.
+- Remove `tellask_call_result_record`.
+- Remove `tellask_response_record`.
+- Rename carryover record/msg/evt to shorter names.
+- Replace old tellask result event split with unified `tellask_result_evt`.
+- Update replay and restore to rebuild unified tellask result messages.
+- Update frontend to render tellask results as separate bubbles.
+- Keep call-site lifecycle status, but stop depending on inline result body.
+- Route askHuman answer flow through tellask result rendering instead of normal user-bubble
+  persistence.
+- Revisit provider projection after the business model is in place, not before.
+
+## Review Standard For This Refactor
+
+Behavior review should focus on current product semantics, not historical storage compatibility.
+
+Primary questions:
+
+- Does the user now see one coherent tellask result model?
+- Are local tellask failures and sideline tellask responses rendered the same way?
+- Does askHuman now behave like tellask instead of like an unrelated user-message path?
+- Does carryover remain special without polluting the unified tellask result model?
+- Did we remove result-path branching instead of just moving it around?