dominds 0.1.1 → 0.2.0

package/dist/access-control.js

@@ -22,6 +22,10 @@ function isEncapsulatedTaskPath(targetPath) {
     // Matches: "foo.tsk", "foo.tsk/", "a/b/foo.tsk/x", etc.
     return /(^|\/)[^/]+\.tsk(\/|$)/.test(normalized);
 }
+function isMindsPath(targetPath) {
+    const normalized = targetPath.replace(/\\/g, '/').replace(/^\/+/, '');
+    return normalized === '.minds' || normalized.startsWith('.minds/');
+}
 /**
  * Directory-specific pattern matching for access control.
  * This function determines if a target path (file or directory) should be controlled
@@ -146,10 +150,18 @@ function hasReadAccess(member, targetPath) {
     }
     // Get relative path from workspace root
     const relativePath = path_1.default.relative(cwd, resolvedPath);
-    // Task Docs (`*.tsk/`) are encapsulated and forbidden to all general file tools.
+    // Task Docs (`*.tsk/`) are encapsulated and hard-denied for all general file tools.
     if (isEncapsulatedTaskPath(relativePath)) {
         return false;
     }
+    // Minds (`.minds/**`) is reserved workspace state.
+    // It is hard-denied for general file tools; only dedicated `.minds/`-scoped tools (team-mgmt)
+    // may bypass this via an internal-only flag.
+    const isMinds = isMindsPath(relativePath);
+    const allowMindsBypass = member.internal_allow_minds === true;
+    if (isMinds && !allowMindsBypass) {
+        return false;
+    }
     // Check blacklist first (no_read_dirs)
     const blacklist = member.no_read_dirs || [];
     for (const pattern of blacklist) {
@@ -159,6 +171,7 @@ function hasReadAccess(member, targetPath) {
     }
     // Check whitelist (read_dirs)
     const whitelist = member.read_dirs || [];
+    // Note: `.minds/**` is handled above as a hard deny (unless internal bypass is enabled).
     // If no whitelist is defined, allow access (after blacklist check)
     if (whitelist.length === 0) {
         return true;
@@ -191,10 +204,18 @@ function hasWriteAccess(member, targetPath) {
     }
     // Get relative path from workspace root
     const relativePath = path_1.default.relative(cwd, resolvedPath);
-    // Task Docs (`*.tsk/`) are encapsulated and forbidden to all general file tools.
+    // Task Docs (`*.tsk/`) are encapsulated and hard-denied for all general file tools.
     if (isEncapsulatedTaskPath(relativePath)) {
         return false;
     }
+    // Minds (`.minds/**`) is reserved workspace state.
+    // It is hard-denied for general file tools; only dedicated `.minds/`-scoped tools (team-mgmt)
+    // may bypass this via an internal-only flag.
+    const isMinds = isMindsPath(relativePath);
+    const allowMindsBypass = member.internal_allow_minds === true;
+    if (isMinds && !allowMindsBypass) {
+        return false;
+    }
     // Check blacklist first (no_write_dirs)
     const blacklist = member.no_write_dirs || [];
     for (const pattern of blacklist) {
@@ -204,6 +225,7 @@ function hasWriteAccess(member, targetPath) {
     }
     // Check whitelist (write_dirs)
     const whitelist = member.write_dirs || [];
+    // Note: `.minds/**` is handled above as a hard deny (unless internal bypass is enabled).
     // If no whitelist is defined, allow access (after blacklist check)
     if (whitelist.length === 0) {
         return true;
@@ -239,15 +261,26 @@ function getAccessDeniedMessage(operation, targetPath, language = 'en') {
     if (isEncapsulatedTaskPath(targetPath)) {
         lines.push('');
         if (language === 'zh') {
-            lines.push(`- 说明：\`*.tsk/\` 是封装差遣牒。通用文件工具不得读/写/列目录/删除其中内容。`);
+            lines.push(`- 说明：\`*.tsk/\` 是封装差遣牒。通用文件工具无法读/写/列目录/删除其中内容（硬编码无条件拒绝）。`);
             lines.push(`- 提示：写入/更新请使用函数工具 \`change_mind\`（顶层：\`change_mind({\"selector\":\"goals|constraints|progress\",\"content\":\"...\"})\`；额外章节：\`change_mind({\"category\":\"<category>\",\"selector\":\"<selector>\",\"content\":\"...\"})\`）。`);
             lines.push(`- 提示：读取额外章节请使用函数工具 \`recall_taskdoc\`：\`recall_taskdoc({\"category\":\"<category>\",\"selector\":\"<selector>\"})\`。`);
         }
         else {
-            lines.push(`- Note: \`*.tsk/\` is an encapsulated Taskdoc. General file tools must not read/write/list/delete it.`);
+            lines.push(`- Note: \`*.tsk/\` is an encapsulated Taskdoc. It is hard-denied for all general file tools.`);
             lines.push(`- Hint: For updates, use the function tool \`change_mind\` (top-level: \`change_mind({\"selector\":\"goals|constraints|progress\",\"content\":\"...\"})\`; extra sections: \`change_mind({\"category\":\"<category>\",\"selector\":\"<selector>\",\"content\":\"...\"})\`).`);
             lines.push(`- Hint: To read extra sections, use \`recall_taskdoc({\"category\":\"<category>\",\"selector\":\"<selector>\"})\`.`);
         }
     }
+    if (isMindsPath(targetPath)) {
+        lines.push('');
+        if (language === 'zh') {
+            lines.push(`- 说明：\`.minds/\` 是工作区的“团队配置/记忆/资产”目录，通用文件工具无法读写（硬编码无条件拒绝）。`);
+            lines.push(`- 提示：如需修改 \`.minds/**\`，建议使用 \`team-mgmt\` 工具集（或由团队管理员成员代管）。`);
+        }
+        else {
+            lines.push(`- Note: \`.minds/\` stores workspace team config/memory/assets and is hard-denied for general file tools.`);
+            lines.push(`- Hint: To modify \`.minds/**\`, use the \`team-mgmt\` toolset (or delegate to a team-manager member).`);
+        }
+    }
     return lines.join('\n');
 }

package/dist/docs/OEC-philosophy.md

@@ -0,0 +1,200 @@
+# Overall Every Control and Clear (OEC)
+
+> Haier: Overall Every(thing/one/day) Control/Clear
+
+The OEC Management Method is a comprehensive enterprise management framework created by Haier Group in 1989, also known as "全方位优化管理法" (Comprehensive Optimization Management Method). This philosophy has generated tremendous economic and social benefits for Haier, earning them the National Enterprise Management Innovation "Golden Horse Award" and the Enterprise Reform "Sail Cup", with Premier Zhu Rongji批示 recommending nationwide promotion of this management experience.
+
+## Core Philosophy
+
+OEC represents a systematic approach to daily management that emphasizes **"Daily work completion, daily clearance, daily improvement"** (日事日毕、日清日高). The fundamental principle is that every employee must accomplish targeted work every day, with the overall goal being to achieve a 1% improvement over the previous day's performance.
+
+## The OEC Components
+
+### **O - Overall (全方位)**
+
+- **Global Integration**: All activities, processes, and systems are interconnected
+- **Holistic Thinking**: Every element contributes to the overall organizational success
+- **Strategic Alignment**: Daily activities support long-term strategic objectives
+
+### **E - Everyone, Everything, Everyday (每人、每事、每日)**
+
+- **Everyone**: Every employee has clear responsibilities and accountability
+- **Everything**: Every task, process, and outcome is managed and controlled
+- **Everyday**: Daily operations, reviews, and improvements are non-negotiable
+
+### **C - Control and Clear (控制和清晰)**
+
+- **Clear Standards**: Defined expectations, processes, and quality benchmarks
+- **Controlled Processes**: Systematic monitoring and adjustment mechanisms
+- **Transparent Accountability**: Clear visibility into performance and outcomes
+
+## Three Fundamental Principles
+
+### 1. **Closed-Loop Management (闭环原则)**
+
+- **PDCA Cycle**: Plan-Do-Check-Act continuous improvement
+- **Complete Accountability**: Every task has clear ownership and follow-through
+- **Systematic Follow-up**: No loose ends or unaddressed issues
+
+### 2. **Comparative Analysis (比较分析原则)**
+
+- **Internal Benchmarking**: Compare current performance with past achievements
+- **External Benchmarking**: Measure against industry best practices and international standards
+- **Competitive Intelligence**: Use comparison as a driver for improvement
+
+### 3. **Continuous Optimization (不断优化原则)**
+
+- **Weakest Link Theory**: Identify and strengthen薄弱环节 (weak areas)
+- **Incremental Progress**: 1% daily improvement compounds significantly over time
+- **Systematic Enhancement**: Continuous refinement of all processes
+
+## Implementation Framework
+
+### Daily Work Completion (日事日毕)
+
+**Core Mechanisms:**
+
+- **3E Card System**: Everyone, Everything, Everyday tracking
+- **Daily Planning**: Clear daily targets and responsibilities
+- **Real-time Monitoring**: Continuous oversight throughout the workday
+
+**Practical Implementation:**
+
+- Morning briefings establish daily objectives
+- Mid-day check-ins ensure progress tracking
+- Evening reviews confirm completion and identify issues
+
+### Daily Clearance (日清日高)
+
+**The "Three Management Principles":**
+
+1. **Daily Affairs Daily Completion**
+   - Address all problems and anomalies on the same day
+   - Clarify responsibilities and implement corrective measures
+   - Prevent problem accumulation through immediate action
+
+2. **Daily Clearance with Management Support**
+   - Self-clearance by employees, complemented by organizational oversight
+   - Structured follow-up and verification processes
+
+3. **Daily Improvement Focus**
+   - Identify and address weak links in processes
+   - Implement continuous enhancements
+   - Target 1% daily improvement for exponential growth
+
+### Quality Control System
+
+**Management Process:**
+
+- **Problem Identification**: 5W3H1S Analysis
+  - **What**: What problem occurred
+  - **Where**: Where did it happen
+  - **When**: When did it occur
+  - **Who**: Who is responsible
+  - **Why**: Root cause analysis
+  - **How Many**: Scope of impact
+  - **How Much**: Cost implications
+  - **How**: Solution approach
+  - **Safety**: Safety implications
+
+**Quality Accountability Tools:**
+
+- **Quality Value Vouchers**: Red (reward) and Yellow (penalty) system
+- **Three-tier Inspection**: Self-inspection, mutual inspection, professional inspection
+- **Real-time Feedback**: Immediate correction and recognition
+
+## Real-World Case Study: Haier's Transformation
+
+### The 76 Refrigerators Moment (1985)
+
+In early 1985, CEO Zhang Ruimin gathered all employees at the Qingdao Refrigerator General Factory and publicly destroyed 76 defective refrigerators with sledgehammers. These refrigerators, worth RMB 1,100 each (equivalent to four times annual employee salary), were smashed despite having minor defects like paint chips.
+
+**Psychological Impact:**
+
+- Employees swung hammers with tears in their eyes
+- The message was crystal clear: substandard products would not be tolerated
+- This became the symbolic turning point for quality transformation
+
+### Before OEC Implementation (1984)
+
+**Company State:**
+
+- Revenue: Only 3.48 million RMB
+- 13 initial management rules included basic requirements like "don't urinate or defecate in work areas"
+- Shanghai Department Store reported all 22 purchased washing machines were defective
+- Inventory included 6,322 surplus defective washing machines
+- Defective products were sold as a separate product category
+
+### After OEC Implementation (1990s-Present)
+
+**Transformation Results:**
+
+- Global expansion to over 180 countries
+- Revenue growth to tens of billions of dollars
+- Market leadership in home appliances
+- Recognized as a model for socialist enterprise transformation
+
+**Key Success Factors:**
+
+- Cultural transformation from top management commitment
+- Systematic implementation of daily management practices
+- Employee engagement through clear accountability
+- Continuous improvement culture
+
+## Modern Applications and Adaptations
+
+### Manufacturing Excellence
+
+- **Lean Manufacturing Integration**: OEC complements and enhances lean methodologies
+- **Six Sigma Implementation**: Quality control through systematic daily management
+- **Just-in-Time Production**: Reduced waste through precise daily coordination
+
+### Service Industry Applications
+
+- **Customer Service Management**: Daily customer satisfaction tracking and improvement
+- **Quality Assurance**: Systematic review and enhancement of service delivery
+- **Employee Development**: Individual performance tracking and skill improvement
+
+### Technology and Innovation
+
+- **Agile Development**: Daily standups and sprint reviews mirror OEC principles
+- **DevOps Practices**: Continuous integration and deployment reflect daily improvement
+- **Knowledge Management**: Systematic capture and utilization of organizational learning
+
+## OEC in Agentic DevOps Context
+
+Fast-paced clearance is crucial in agentic DevOps working. OEC principles translate directly to automated system management:
+
+### **Dialog Round Management**
+
+- **Daily Reset**: Start new dialog rounds with updated task documentation and fresh chat logs
+- **Clear Context**: Ensure all agents work with optimal clarity and updated information
+- **Immediate Resolution**: Address issues and anomalies within the same operational cycle
+
+### **Agent Accountability**
+
+- **Everyone**: Each agent has clear operational parameters and success metrics
+- **Everything**: Every process, decision, and outcome is logged and traceable
+- **Everyday**: Continuous monitoring and improvement of agent performance
+
+### **System Optimization**
+
+- **1% Daily Improvement**: Automated systems can implement small but consistent enhancements
+- **Closed-Loop Feedback**: Real-time monitoring and automatic corrective actions
+- **Comparative Analysis**: Benchmark current performance against historical and industry standards
+
+### **Quality Assurance**
+
+- **Defect Prevention**: Automated quality checks prevent issues before they impact users
+- **Rapid Response**: Immediate identification and resolution of system anomalies
+- **Continuous Learning**: Machine learning algorithms improve through daily data analysis
+
+## Key Takeaways for Modern Implementation
+
+1. **Start Small, Scale Systematically**: Implement OEC principles gradually, beginning with high-impact areas
+2. **Technology Enablement**: Use digital tools to automate tracking, monitoring, and improvement processes
+3. **Cultural Integration**: Ensure leadership commitment and employee buy-in for sustainable transformation
+4. **Continuous Adaptation**: Modify OEC principles to fit specific industry and organizational needs
+5. **Measure Everything**: Establish clear metrics and accountability at all levels
+
+The OEC philosophy demonstrates that systematic daily management, coupled with continuous improvement and clear accountability, can transform any organization from chaos to excellence. Its principles remain highly relevant for modern automated and AI-driven systems, where rapid response, continuous learning, and clear accountability are essential for success.

package/dist/docs/auth.md

@@ -0,0 +1,145 @@
+# Dominds Auth (Design)
+
+This document specifies the **authentication behavior** for Dominds WebUI + API access.
+
+## Goals
+
+- **Production safety**: prevent accidental exposure of a Dominds instance (especially when bound to non-localhost).
+- **Low operational overhead**: a single shared secret, set once, used everywhere.
+- **Good UX**: the WebUI can prompt for the key when needed and remember it for future visits.
+- **Convenient “auto-auth”**: allow a one-click / copy-paste URL that pre-fills auth for the current session.
+
+## Non-goals
+
+- Multi-user accounts, roles/permissions, OAuth, SSO
+- Key rotation workflows, audit logs, or fine-grained access control
+- Authentication for development mode (explicitly disabled)
+
+## Terminology
+
+- **Auth key**: the shared secret used to authenticate requests.
+- **Dev mode**: development runtime where auth is disabled.
+- **Prod mode**: production runtime where auth behavior is enabled/controlled by environment.
+- **Auto-auth URL**: a WebUI page URL that includes the auth key as a query parameter for automatic authentication.
+
+## Mode Rules
+
+### Dev mode
+
+- **Auth is always disabled.**
+- `DOMINDS_AUTH_KEY` (if present) has **no effect** in dev mode.
+
+### Prod mode
+
+Auth behavior is controlled by the `DOMINDS_AUTH_KEY` environment variable:
+
+| `DOMINDS_AUTH_KEY` value | Effective behavior                                     |
+| ------------------------ | ------------------------------------------------------ |
+| **unset**                | **Enable auth** with a **randomly generated** auth key |
+| **empty string**         | **Disable auth**                                       |
+| **non-empty string**     | **Enable auth** using the provided string verbatim     |
+
+Notes:
+
+- The auth key is treated as an **opaque string** (no trimming, normalization, or case folding).
+- A generated auth key MUST be **cryptographically strong** and **URL-safe to embed** (after URL encoding).
+
+## Authentication Mechanism (Prod mode, when enabled)
+
+- Every API request MUST authenticate using an HTTP `Authorization` header:
+  - `Authorization: Bearer <auth-key>`
+
+- “API request” includes:
+  - HTTP endpoints that mutate or reveal workspace/dialog state
+  - WebSocket connections used by the WebUI for real-time updates
+
+Implementation note (WebUI): browsers cannot attach custom `Authorization` headers during the WebSocket handshake.
+Dominds WebUI therefore transmits the auth key via `Sec-WebSocket-Protocol` as a subprotocol of the form
+`dominds-auth.<auth-key>` (plain text), and the server accepts either mechanism.
+
+To make this work without encoding, the auth key MUST be an HTTP token-safe string (RFC 7230 `tchar` set).
+
+If auth is **disabled**, the server MUST accept requests and WebSocket connections without any auth header.
+If an auth header is present while auth is disabled, the server MUST ignore it.
+
+## Server-Side Auth Outcomes (Prod mode, when enabled)
+
+The server enforces the following outcomes:
+
+- If the auth header is **missing**, the request/connection MUST be rejected as unauthorized.
+- If the auth header is **present but incorrect**, the request/connection MUST be rejected as unauthorized.
+- If the auth header is **correct**, the request/connection proceeds normally.
+
+The server SHOULD use a consistent “unauthorized” response so that clients can reliably detect auth failures.
+
+## WebUI Behavior
+
+### Sources of an auth key
+
+The WebUI uses exactly one effective auth key at a time, chosen by this precedence order:
+
+1. **URL query parameter** `auth` (auto-auth mode)
+2. **Browser localStorage** (remembered key)
+3. **User prompt input** (interactive entry)
+
+### localStorage rules
+
+- If the WebUI uses a key sourced from **localStorage**, it MUST attach that key to all API requests as a Bearer token.
+- If the user **manually enters** a key (not sourced from the URL), the WebUI MUST:
+  - Use it immediately for API requests
+  - Persist it to **localStorage** for later use
+- If the key in **localStorage** is rejected by the server, the WebUI MUST:
+  - Prompt the user to enter a new key
+  - Replace the stored key in localStorage after confirmed success of auth
+
+### Auto-auth URL rules (`?auth=...`)
+
+When an `auth` query parameter is present in the WebUI page URL:
+
+- The WebUI MUST use the `auth` parameter value as the auth key for API requests.
+- The WebUI MUST NOT read from localStorage.
+- The WebUI MUST NOT write to localStorage.
+
+If authentication fails while `auth` is present in the URL:
+
+- The WebUI MUST remove the `auth` parameter from `window.location` (so it no longer appears in the address bar).
+- After removal, the WebUI MUST transition into the normal interactive flow:
+  - Prompt the user for an auth key (and then persist it to localStorage after success, as usual).
+
+## CLI Requirements (WebUI subcommand)
+
+### “Auto auth url” console output
+
+When starting the WebUI server in **prod mode**:
+
+- If auth is **enabled** (either generated or explicitly set), the WebUI subcommand MUST log an **“auto auth url”**
+  string to the console that includes the auth key as a query parameter.
+
+Example (illustrative):
+
+```txt
+auto auth url: http://<host>:<port>/?auth=<urlencoded-auth-key>
+```
+
+- If auth is **disabled**, the subcommand SHOULD log that auth is disabled and MUST NOT print an auth key.
+
+### `--nobrowser`
+
+By default, the WebUI subcommand opens a browser automatically.
+To opt out, use `--nobrowser`:
+
+- If auth is **enabled**, it MUST open the **auto-auth URL** in the default browser.
+- If auth is **disabled**, it MUST open the normal WebUI URL (no `auth` parameter).
+
+`--nobrowser` does not change authentication behavior; it only changes ergonomics.
+
+## Security & Privacy Notes
+
+- The auth key is a **shared secret**; anyone with the key has full access as permitted by the API surface.
+- An auto-auth URL contains the auth key in the query string; this can leak via:
+  - Copy/paste and screenshots
+  - Browser history
+  - Referrer headers (depending on navigation)
+  - Logs or monitoring that capture URLs
+
+Operators SHOULD treat the auto-auth URL as sensitive and avoid sharing it broadly.