dominds 1.6.5 → 1.6.7

package/README.md

@@ -122,7 +122,7 @@ Examples:
 dominds install @longrun-ai/web-dev --enable
 
 # Install a local app under development into the current rtws
-dominds install ./dominds-apps/web-dev --local --enable
+dominds install ./dominds-apps/@longrun-ai/web-dev --local --enable
 ```
 
 Important distinctions:

package/README.zh.md

@@ -77,7 +77,7 @@ npx -y dominds@latest
 dominds install @longrun-ai/web-dev --enable
 
 # 安装本地开发中的 app 到当前 rtws
-dominds install ./dominds-apps/web-dev --local --enable
+dominds install ./dominds-apps/@longrun-ai/web-dev --local --enable
 ```
 
 几个关键区别：

package/dist/apps/app-id.js

@@ -0,0 +1,36 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.normalizeDomindsAppId = normalizeDomindsAppId;
+exports.isValidDomindsAppId = isValidDomindsAppId;
+exports.domindsAppIdToPathParts = domindsAppIdToPathParts;
+exports.resolveDomindsAppRtwsDirAbs = resolveDomindsAppRtwsDirAbs;
+exports.resolveDomindsAppLocalPackageRootAbs = resolveDomindsAppLocalPackageRootAbs;
+exports.formatDomindsAppRtwsDirRel = formatDomindsAppRtwsDirRel;
+const node_path_1 = __importDefault(require("node:path"));
+const DOMINDS_APP_ID_RE = /^(?:@[a-z0-9][a-z0-9._-]*\/)?[a-z0-9][a-z0-9._-]*$/;
+function normalizeDomindsAppId(value) {
+    return value.trim();
+}
+function isValidDomindsAppId(value) {
+    const normalized = normalizeDomindsAppId(value);
+    return normalized !== '' && DOMINDS_APP_ID_RE.test(normalized);
+}
+function domindsAppIdToPathParts(appId) {
+    const normalized = normalizeDomindsAppId(appId);
+    if (!isValidDomindsAppId(normalized)) {
+        throw new Error(`Invalid Dominds app id: '${appId}'`);
+    }
+    return normalized.split('/');
+}
+function resolveDomindsAppRtwsDirAbs(rtwsRootAbs, appId) {
+    return node_path_1.default.resolve(rtwsRootAbs, '.apps', ...domindsAppIdToPathParts(appId));
+}
+function resolveDomindsAppLocalPackageRootAbs(rootAbs, appId) {
+    return node_path_1.default.resolve(rootAbs, ...domindsAppIdToPathParts(appId));
+}
+function formatDomindsAppRtwsDirRel(appId) {
+    return node_path_1.default.posix.join('.apps', ...domindsAppIdToPathParts(appId));
+}

package/dist/apps/enabled-apps.js

@@ -24,7 +24,7 @@ function getResolutionHint(params) {
     const filePathAbs = node_path_1.default.resolve(params.rtwsRootAbs, configuration_file_1.APPS_CONFIGURATION_REL_PATH);
     const action = params.hasConfigurationFile ? 'Edit' : 'Create';
     return (`${action} ${filePathAbs} to configure 'resolutionStrategy'. ` +
-        `Default local root is 'dominds-apps' (rtws-relative) and expects local apps at '<root>/<appId>/'.`);
+        `Default local root is 'dominds-apps' (rtws-relative) and resolves app ids under '<root>/<appId path segments>/'.`);
 }
 async function loadManifestDepsFromResolvedApp(params) {
     const pkgInfo = await (0, package_info_1.readPackageInfo)({ packageRootAbs: params.packageRootAbs });

package/dist/apps/local-package-root.js

@@ -6,6 +6,7 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.resolveLocalAppPackageRootAbs = resolveLocalAppPackageRootAbs;
 const promises_1 = __importDefault(require("node:fs/promises"));
 const node_path_1 = __importDefault(require("node:path"));
+const app_id_1 = require("./app-id");
 async function dirExists(dirPathAbs) {
     try {
         const stat = await promises_1.default.stat(dirPathAbs);
@@ -31,7 +32,7 @@ async function resolveLocalAppPackageRootAbs(params) {
     }
     for (const root of params.localRoots) {
         const rootAbs = node_path_1.default.isAbsolute(root) ? root : node_path_1.default.resolve(params.rtwsRootAbs, root);
-        candidates.add(node_path_1.default.resolve(rootAbs, trimmedAppId));
+        candidates.add((0, app_id_1.resolveDomindsAppLocalPackageRootAbs)(rootAbs, trimmedAppId));
     }
     for (const candidateAbs of candidates) {
         if (await dirExists(candidateAbs))

package/dist/apps/rtws-seed.js

@@ -6,6 +6,7 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.applyRtwsSeed = applyRtwsSeed;
 const promises_1 = __importDefault(require("fs/promises"));
 const path_1 = __importDefault(require("path"));
+const app_id_1 = require("./app-id");
 function ensureRelNoTraversal(rel) {
     const normalized = rel.replace(/\\/g, '/').replace(/^\/+/g, '');
     if (normalized.includes('..')) {
@@ -27,7 +28,7 @@ async function writeIfMissing(fileAbs, content, overwrite) {
     await promises_1.default.writeFile(fileAbs, content, 'utf-8');
 }
 async function applyRtwsSeed(params) {
-    const rtwsAppDirAbs = path_1.default.resolve(params.rtwsRootAbs, '.apps', params.appId);
+    const rtwsAppDirAbs = (0, app_id_1.resolveDomindsAppRtwsDirAbs)(params.rtwsRootAbs, params.appId);
     await promises_1.default.mkdir(rtwsAppDirAbs, { recursive: true });
     const taskdocs = params.manifest.contributes?.rtwsSeed?.taskdocs ?? [];
     for (const td of taskdocs) {

package/dist/apps/run-control.js

@@ -1,6 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.applyAppDialogRunControl = applyAppDialogRunControl;
+exports.applyRegisteredAppDialogRunControls = applyRegisteredAppDialogRunControls;
 const dialog_run_controls_1 = require("./dialog-run-controls");
 const runtime_1 = require("./runtime");
 async function applyAppDialogRunControl(params) {
@@ -15,3 +16,15 @@ async function applyAppDialogRunControl(params) {
     const hostClient = await (0, runtime_1.waitForAppsHostClient)();
     return await hostClient.applyRunControl(controlId, params.payload);
 }
+async function applyRegisteredAppDialogRunControls(payload) {
+    for (const control of (0, dialog_run_controls_1.listAppDialogRunControls)()) {
+        const result = await applyAppDialogRunControl({
+            controlId: control.id,
+            payload,
+        });
+        if (result.kind === 'reject') {
+            return result;
+        }
+    }
+    return { kind: 'continue' };
+}

package/dist/apps-host/host.js

@@ -7,6 +7,7 @@ Object.defineProperty(exports, "__esModule", { value: true });
 const path_1 = __importDefault(require("path"));
 const url_1 = require("url");
 const log_1 = require("../log");
+const app_id_1 = require("../apps/app-id");
 const ipc_types_1 = require("./ipc-types");
 const log = (0, log_1.createLogger)('apps-host');
 const dynamicImport = new Function('specifier', 'return import(specifier)');
@@ -313,7 +314,7 @@ async function initOnce(msg) {
         const mod = await dynamicImport((0, url_1.pathToFileURL)(moduleAbs).href);
         const factory = pickExportedFactory(mod, app.installJson.host.exportName, moduleAbs);
         const appId = app.appId;
-        const rtwsAppDirAbs = path_1.default.resolve(msg.rtwsRootAbs, '.apps', appId);
+        const rtwsAppDirAbs = (0, app_id_1.resolveDomindsAppRtwsDirAbs)(msg.rtwsRootAbs, appId);
         const host = validateHostInstance(await factory({
             appId,
             rtwsRootAbs: msg.rtwsRootAbs,

package/dist/apps-host/ipc-types.js

@@ -356,6 +356,8 @@ function parseAppsHostMessageFromKernel(v) {
             throw new Error('Invalid run_control_apply message: payload must be object');
         const dialog = payload['dialog'];
         const prompt = payload['prompt'];
+        const agentId = asString(payload['agentId']);
+        const taskDocPath = asString(payload['taskDocPath']);
         const genIterNoRaw = payload['genIterNo'];
         const source = asString(payload['source']);
         const input = payload['input'];
@@ -376,6 +378,12 @@ function parseAppsHostMessageFromKernel(v) {
         if (!dialogSelfId || !dialogRootId) {
             throw new Error('Invalid run_control_apply payload: dialog.selfId/rootId required');
         }
+        if (!agentId) {
+            throw new Error('Invalid run_control_apply payload: agentId required');
+        }
+        if (!taskDocPath) {
+            throw new Error('Invalid run_control_apply payload: taskDocPath required');
+        }
         const promptParsed = (() => {
             if (prompt === undefined)
                 return undefined;
@@ -435,6 +443,8 @@ function parseAppsHostMessageFromKernel(v) {
             controlId,
             payload: {
                 dialog: { selfId: dialogSelfId, rootId: dialogRootId },
+                agentId,
+                taskDocPath,
                 genIterNo,
                 prompt: promptParsed,
                 source,

package/dist/cli/uninstall.js

@@ -6,7 +6,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.main = main;
 const promises_1 = __importDefault(require("node:fs/promises"));
-const node_path_1 = __importDefault(require("node:path"));
+const app_id_1 = require("../apps/app-id");
 const app_lock_file_1 = require("../apps/app-lock-file");
 const configuration_file_1 = require("../apps/configuration-file");
 const manifest_1 = require("../apps/manifest");
@@ -16,7 +16,7 @@ function printHelp() {
   dominds uninstall <appId> [--purge]
 
 Options:
-  --purge   Also delete rtws app state directory: .apps/<appId>/
+  --purge   Also delete rtws app state directory: .apps/<appId path segments>/
 `);
 }
 function parseArgs(argv) {
@@ -92,12 +92,13 @@ async function main() {
     await (0, app_lock_file_1.writeAppLockFileIfChanged)({ rtwsRootAbs, file: nextLock });
     await (0, workspace_app_state_1.refreshAppsDerivedState)({ rtwsRootAbs });
     if (args.purge) {
-        const appDirAbs = node_path_1.default.resolve(rtwsRootAbs, '.apps', args.appId);
+        const rtwsDirRel = (0, app_id_1.formatDomindsAppRtwsDirRel)(args.appId);
+        const appDirAbs = (0, app_id_1.resolveDomindsAppRtwsDirAbs)(rtwsRootAbs, args.appId);
         await promises_1.default.rm(appDirAbs, { recursive: true, force: true });
-        console.log(`Uninstalled app '${args.appId}' (purged rtws state: .apps/${args.appId}/)`);
+        console.log(`Uninstalled app '${args.appId}' (purged rtws state: ${rtwsDirRel}/)`);
     }
     else {
-        console.log(`Uninstalled app '${args.appId}' (rtws data preserved under .apps/${args.appId}/)`);
+        console.log(`Uninstalled app '${args.appId}' (rtws data preserved under ${(0, app_id_1.formatDomindsAppRtwsDirRel)(args.appId)}/)`);
     }
 }
 if (require.main === module) {

package/dist/dialog.js

@@ -606,6 +606,9 @@ class Dialog {
     hasUpNext() {
         return this._upNext !== undefined;
     }
+    peekUpNext() {
+        return this._upNext;
+    }
     takeUpNext() {
         const next = this._upNext;
         this._upNext = undefined;

package/dist/docs/app-constitution.md

@@ -214,10 +214,10 @@ Recommended user mental model:
 
 Self-heal only works when both prerequisites hold:
 
-- root `.minds/app.yaml` still declares the correct app id (for example `web-dev`), and
-- the current resolution strategy can actually resolve that app (for example, default `localRoots=['dominds-apps']` contains `dominds-apps/web-dev/`, and that package's install handshake / manifest also declares the same app id).
+- root `.minds/app.yaml` still declares the correct app id (for example `@longrun-ai/web-dev`), and
+- the current resolution strategy can actually resolve that app (for example, default `localRoots=['dominds-apps']` contains `dominds-apps/@longrun-ai/web-dev/`, and that package's install handshake / manifest also declares the same app id).
 
-If the root manifest / team config uses the wrong app id (for example, still declaring the legacy id `web_dev` inside `dependencies[].id` or `members.<id>.from` while the app now installs as `web-dev`), refresh will still re-materialize `resolution.yaml` as empty. That means self-heal did run; it just correctly recomputed an empty result from incorrect source declarations.
+If the root manifest / team config uses the wrong app id (for example, still declaring the legacy id `web_dev` or the old unscoped id `web-dev` inside `dependencies[].id` or `members.<id>.from` while the app now installs as `@longrun-ai/web-dev`), refresh will still re-materialize `resolution.yaml` as empty. That means self-heal did run; it just correctly recomputed an empty result from incorrect source declarations.
 
 So even without `<rtws>/.apps/configuration.yaml` or `<rtws>/.apps/resolution.yaml`, as long as `.minds/app.yaml` declares dependencies, the kernel still resolves local apps via the default strategy; if the root manifest has no dependencies, the effective enabled apps set is empty.
 
@@ -249,7 +249,6 @@ It describes:
 - default toolsets/tools for those members;
 - how those members see each other and collaborate within the app.
 
-> Current prototype behavior: the kernel loads enabled app teammates YAML and **additively merges `members` into workspace `.minds/team.yaml`**.
 > Current (v0): the kernel loads enabled app teammates YAML but does **not** flatten-merge their `members` into workspace `.minds/team.yaml`.
 > You must explicitly reference a dependency app teammate via `members.<id>.from + (use|import)` in workspace `.minds/team.yaml`.
 > Loader: `dominds/main/apps/teammates.ts`; resolver/execution: `dominds/main/team.ts`.
@@ -282,38 +281,46 @@ Its goal is not to represent one specific product. Its goal is to provide a high
 
 Design stance:
 
-- `Web Dev App` is an **integrator-style app**. The important part is the packaging of team, toolsets, environment guidance, and workflow posture, not a demo business frontend.
+- `Web Dev App` is an **integrator-style app**. The important part is the packaging of team, toolsets, environment guidance, and collaboration posture, not a demo business frontend.
 - It should reuse existing capabilities where possible instead of inventing a new browser automation protocol inside the app.
-- The current upstream capability to learn from is the repo-root `playwright-interactive/` skill. That skill is better understood as a workflow/method asset, not as a ready-to-install Dominds MCP server.
+- The current upstream capability to learn from is OpenAI's `playwright-interactive` entry in the `skills` repo. It appears as a `SKILL.md` largely because the upstream product treats `js_repl` as a built-in capability and uses the skill layer to explain how to operate it. Dominds should not inherit that split directly. A more self-consistent Dominds packaging boundary is to ship **dedicated tools + toolset manual + recommended teammate definitions** as one app-level capability. In that sense, `Web Dev App` is not “wrapping a pure skill”; it is re-packaging the same capability family with a cleaner product boundary.
 
 So `Web Dev App` should make the `playwright-interactive` relationship explicit as two separate layers:
 
 1. **Product-semantic layer (in scope for this design)**
-   - define a stable toolset semantic such as `playwright_interactive`;
+   - define a stable toolset name such as `playwright_interactive`;
    - define which teammates receive it, what problem it solves, and when to use it;
-   - ship the related `.minds/team.yaml`, member persona/knowledge, `.minds/env.md`, etc.
+   - ship the related `.minds/team.yaml`, member persona/knowledge/lessons, `.minds/env.md`, toolset manual, etc.
 2. **Execution-backend layer (replaceable implementation detail)**
-   - this may wrap the `playwright-interactive` skill into app-host tools;
-   - or later be replaced by an equivalent MCP server / local host module;
+   - the app may provide its own dedicated tools and productize a browser-interaction capability in the same family as `playwright-interactive`;
+   - or later be replaced by an equivalent MCP server / local App Host module;
    - as long as the team-facing toolset contract does not drift.
 
-It must be explicit that **an app is not the same thing as a skill**:
+It must be explicit that **an app is not the same thing as a skill**, and that both are now first-class mechanisms in the current implementation:
 
 - An **app** is a Dominds install/resolve/composition unit. It has an `id`, a manifest (`.minds/app.yaml`), team-facing assets (`.minds/team.yaml`, persona/knowledge/lessons), env docs (`.minds/env.md`), and participates in rtws-level lock/configuration/resolution.
-- A **skill** is closer to a workflow asset, method asset, or low-level execution material. A skill can be reused, wrapped, or replaced by an app, but it usually does not own rtws installation, dependency graph membership, or `team.yaml` import semantics by itself.
-- `playwright-interactive/` is currently closer to a skill: it provides browser-workflow capability that Web Dev can learn from or wrap. `Web Dev App` is the installable product unit that packages those capabilities into a stable team/toolset/env contract.
+- A **skill** is a pure-Markdown capability asset inside the rtws. It is currently loaded from `.minds/skills/team_shared/**` and `.minds/skills/individual/**`, selects `SKILL.cn.md` / `SKILL.en.md` / `SKILL.md` by work language preference, and injects the body directly into the agent system prompt. It is best suited for soft guidance, checklists, decision heuristics, and team-specific methods, not for distributable product capability that depends on a stable tool contract.
+- Skill frontmatter currently supports `name`, `description`, `allowed-tools`, `user-invocable`, and `disable-model-invocation`; the last three are currently compatibility/migration metadata only. They do not automatically grant tool permissions and do not replace team/toolset runtime policy.
+- A **toolset manual / app-bundled manual** is a better place for guidance that is shipped together with tools: it is skill-like in tone, but distributed together with dedicated tools, toolsets, and app identity. That is a better fit for something like `web-dev`.
+- `playwright-interactive/` should not be classified as that pure-Markdown rtws skill category. More precisely, it represents a guidance layer on top of built-in browser execution capability. In Dominds, the cleaner move is to package dedicated tools, toolset manual, recommended teammate definitions, and runtime state together as an app such as `@longrun-ai/web-dev`.
+- In Dominds terminology, **workflow** should preferably be reserved for hard process mechanisms such as `phase-gate`, which carry phase/gate/quorum/rollback/auto-advance semantics. Skills and toolset manuals are closer to guidance layers or operating manuals than to a workflow engine.
 
-So the correct story is not “install a skill as an app”. The correct story is:
+So the correct story is not “install a pure skill as an app”. The correct story is:
 
-- the skill is absorbed as implementation material by an app,
-- the app exposes a stable team-facing contract,
-- the low-level skill / MCP / host-module backend can change later without changing the app identity or team-facing semantics.
+- if the content is **pure prompt/pure Markdown and needs no extra tool capability**, keep it directly as an rtws skill,
+- once a capability package needs dedicated tools, external binaries, MCP, App-provided tools, stable toolset naming, teammate assembly, or dependency resolution, package **tools + toolset manual + recommended teammate definitions + team-facing contract** as an app,
+- when other apps depend on that capability, they should depend on the packaged app rather than expecting each workspace to copy the skill and hand-wire tools,
+- the app exposes the stable team/toolset/env contract, while the low-level skill / MCP / local App Host backend may change later without changing the app identity or team-facing semantics.
+
+The shortest rule of thumb is:
+
+- **skills own soft guidance, toolset manuals own tool-coupled operating guidance, and apps own tool capability, dependency relationships, and the team-facing contract.**
 
 Suggested user-facing installation flow:
 
 ```bash
 # Local app under development
-dominds install ./dominds-apps/web-dev --local --enable
+dominds install ./dominds-apps/@longrun-ai/web-dev --local --enable
 
 # Published npm app (target shape)
 dominds install @longrun-ai/web-dev --enable
@@ -321,11 +328,11 @@ dominds install @longrun-ai/web-dev --enable
 
 Web Dev App needs three names kept distinct to avoid drift:
 
-- installable app id: `web-dev`
-- local development directory: `dominds-apps/web-dev/`
+- installable app id: `@longrun-ai/web-dev`
+- local development directory: `dominds-apps/@longrun-ai/web-dev/`
 - npm package name: `@longrun-ai/web-dev`
 
-That means workspace `.minds/app.yaml` `dependencies[].id`, `.minds/team.yaml` `members.<id>.from`, and `<rtws>/.apps/resolution.yaml` `apps[].id` must all use `web-dev`; the directory and package naming surfaces also stay `web-dev` so the app no longer carries two spellings.
+That means workspace `.minds/app.yaml` `dependencies[].id`, `.minds/team.yaml` `members.<id>.from`, and `<rtws>/.apps/resolution.yaml` `apps[].id` must all use `@longrun-ai/web-dev`; the local development directory and npm package should stay aligned to that same scoped identity so the app no longer carries split naming.
 
 After installation, the user should expect these files to change:
 
@@ -337,7 +344,7 @@ After installation, the user should expect these files to change:
 Suggested minimal asset shape:
 
 ```text
-web-dev/
+@longrun-ai/web-dev/
 ├── package.json
 ├── .minds/
 │   ├── app.yaml
@@ -398,10 +405,10 @@ Requirements for the `playwright_interactive` toolset design:
   - preserve the “reusable session across multiple fix iterations” mental model.
 - If the current phase does not yet ship a directly executable backend, the docs must label it as a **target contract (planned)** instead of pretending it is already built in.
 
-Current prototype note (`dominds-apps/web-dev`, as of March 8, 2026):
+Current prototype note (`dominds-apps/@longrun-ai/web-dev`, as of March 8, 2026):
 
 - The app is already installable and contributes `web_tester` / `web_developer` teammates plus a live `playwright_interactive` toolset registration.
-- The installable app id remains `web-dev`; the directory name and npm package also keep the same `web-dev` spelling so the app no longer carries split naming.
+- The installable app id remains `@longrun-ai/web-dev`; the local development directory and npm package also keep the same scoped identity so the app no longer carries split naming.
 - `playwright_session_new/list/status/eval/attach/detach/close` and cross-dialog reminder sync are already implemented.
 - `kind: "web"` sessions now create a real Playwright-backed browser/context/page runtime and report live page surfaces via session status/reminders.
 - `kind: "electron"` is **not** at the same completion level yet: it still falls back to the older prototype runtime path and should be treated as unfinished.
@@ -413,7 +420,7 @@ Current prototype note (`dominds-apps/web-dev`, as of March 8, 2026):
 Why this app shape matters:
 
 - It makes `.minds/team.yaml` collaboration semantics concrete: development and testing are two long-lived teammates, not vague temporary roles.
-- It validates whether “app provides team + toolset + env docs” is expressive enough for a real workflow.
+- It validates whether “app provides team + toolset + env docs” is expressive enough for a real collaborative capability package.
 - It gives future skill/MCP/local-host convergence a stable semantic anchor at the app layer.
 
 ## `<rtws>/.apps/override/<app-id>/`: override layer