@deriest/ai-engineering-company 1.15.2

package/LICENSE

@@ -0,0 +1,8 @@
+UNLICENSED
+
+This package is not licensed for public use.
+
+All rights reserved. This software and its source code are proprietary.
+No permission is granted to use, copy, modify, merge, publish, distribute,
+sublicense, and/or sell copies of this software without explicit written
+permission from the copyright holder.

package/README.md

@@ -0,0 +1,291 @@
+# AI Engineering Company
+
+Management layer that orchestrates AI agents for engineering tasks.
+
+AI Engineering Company routes natural-language tasks to the right office and worker automatically — no configuration required.
+
+## Installation
+
+### Prerequisites
+
+- OpenClaw installed and running (see [OpenClaw](https://github.com/openclaw/openclaw))
+- Node.js 22.19+
+
+### Install Plugin
+
+```bash
+# Install from local source (recommended for development)
+openclaw plugins install /path/to/ai-engineering-company --link
+
+# Or install from git
+git clone https://github.com/YOUR_USERNAME/ai-engineering-company.git
+openclaw plugins install ./ai-engineering-company --link
+```
+
+### Verify Installation
+
+```bash
+openclaw plugins list
+```
+
+## Quick Start
+
+Start OpenClaw and use the `/aicompany` slash command:
+
+```
+/aicompany build landing page
+/aicompany fix authentication bug
+/aicompany review this repository
+/aicompany create PRD for the new feature
+```
+
+The Dispatcher automatically routes work to the correct office and worker. No manual assignment needed.
+
+## Usage
+
+### Slash Command
+
+The primary interface for dispatching tasks:
+
+```
+/aicompany <task description>
+```
+
+**Example output:**
+
+```
+🏢 AI Engineering Company
+
+Task:
+Build landing page
+
+Assigned To:
+Engineering Worker
+
+Status:
+Completed
+
+Duration:
+4.2 s
+
+────────────────────────
+
+[worker response]
+```
+
+### Agent Tools
+
+Available to the OpenClaw agent automatically:
+
+- **`ai_company_dispatch`** — Submit a task. Parameters: `message` (required), `wait` (boolean, default true), `timeout` (ms, default 900000)
+- **`ai_company_status`** — Query dispatch status or list recent dispatches. Parameters: `sessionKey` (optional — omit to list all)
+- **`ai_company_result`** — Retrieve completed dispatch results. Parameters: `sessionKey` (required), `limit` (optional)
+- **`ai_company_approve`** — Approve a pending task. Parameters: `sessionKey` (required), `reason` (optional), `operator` (optional)
+- **`ai_company_reject`** — Reject a pending task. Parameters: `sessionKey` (required), `reason` (optional), `operator` (optional)
+- **`ai_company_list_approvals`** — List all pending approval requests. No parameters.
+
+### Gateway RPC
+
+Available over the gateway WebSocket API:
+
+- `ai-company.dispatch` — `{ message, wait?, timeout? }`
+- `ai-company.status` — `{ sessionKey? }`
+- `ai-company.result` — `{ sessionKey, limit? }`
+- `ai-company.list_approvals` — `{}` (list pending approvals)
+- `ai-company.approve` — `{ sessionKey, reason?, operator? }` (approve a pending task)
+- `ai-company.reject` — `{ sessionKey, reason?, operator? }` (reject a pending task)
+
+### CLI
+
+```bash
+openclaw ai-company dispatch "fix the login bug"
+openclaw ai-company status
+openclaw ai-company result <session-key>
+openclaw ai-company approvals
+openclaw ai-company approve <session-key> [--operator <name>]
+openclaw ai-company reject <session-key> [--operator <name>]
+openclaw ai-company recover
+openclaw ai-company audit [--session <key>] [--event <type>] [--source <src>] [--from <date>] [--to <date>]
+```
+
+## Approval Workflow
+
+Engineering and security review tasks require operator approval before deployment. When the Dispatcher creates an orchestration plan, stages after VERIFY are marked with `requiresApproval: true`. The pipeline pauses at these stages and waits for the operator to approve or reject.
+
+**CLI examples:**
+
+```bash
+# List pending approvals
+openclaw ai-company approvals
+
+# Approve a task
+openclaw ai-company approve ai-company:dispatch:abc123 --reason "LGTM"
+
+# Reject a task
+openclaw ai-company reject ai-company:dispatch:abc123 --reason "Needs security review"
+```
+
+**Agent tool examples:**
+
+```
+ai_company_list_approvals
+ai_company_approve sessionKey="ai-company:dispatch:abc123" reason="Approved"
+ai_company_reject sessionKey="ai-company:dispatch:abc123" reason="Missing tests"
+```
+
+Gateway approvals automatically use your verified identity (display name or connection ID) when recording who approved or rejected a task. No configuration required.
+
+## Configuration
+
+In your OpenClaw config, the plugin accepts:
+
+```json
+{
+  "ai-engineering-company": {
+    "offices": "config/offices.json",
+    "workflows": "config/workflows.json",
+    "workers": "workers",
+    "boardId": "ai-company"
+  }
+}
+```
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `offices` | `config/offices.json` | Path to offices config |
+| `workflows` | `config/workflows.json` | Path to workflows config |
+| `workers` | `assets/workers` | Path to workers directory |
+| `boardId` | `ai-company` | Workboard board ID for task cards |
+
+## Documentation
+
+- [CHANGELOG.md](CHANGELOG.md) — Version history and release notes
+- [ROADMAP.md](ROADMAP.md) — Implementation roadmap and milestones
+- [docs/CHECKPOINT.md](docs/CHECKPOINT.md) — Current repository checkpoint
+- [docs/PROJECT-ARCHIVE.md](docs/PROJECT-ARCHIVE.md) — Complete project archive
+
+## Audit Logging
+
+All dispatch lifecycle events are recorded as append-only JSONL files in `.openclaw/audit/audit-YYYY-MM-DD.jsonl`.
+
+**15 event types**: dispatch_requested, plan_created, task_created, pipeline_started, stage_started, approval_requested, approved, rejected, stage_completed, stage_failed, pipeline_completed, pipeline_failed, dispatch_completed, lease_acquire_failed, lease_release_failed.
+
+```bash
+# Query audit log with filters
+openclaw ai-company audit --session "ai-company:dispatch:abc123"
+openclaw ai-company audit --event "approved" --source "gateway"
+openclaw ai-company audit --from "2026-07-01" --to "2026-07-04"
+```
+
+## Runtime Recovery
+
+Pipeline checkpoints persist stage-level progress to disk. On crash or restart, interrupted pipelines can be detected and reviewed.
+
+```bash
+# List interrupted pipelines
+openclaw ai-company recover
+```
+
+Stale entries (failed/completed > 24h) are automatically cleaned on startup. Running and awaiting_approval entries are preserved.
+
+## Metrics
+
+The MetricsRegistry tracks 28 operational metrics including dispatch counts, stage durations, approval wait times, and error rates. Metrics are stored in-memory and persisted to `.openclaw/metrics.json` on shutdown.
+
+## Queue Backend
+
+DecisionQueue storage is abstracted behind the `QueueBackend` interface. Default: `MemoryQueueBackend` (Map-based with JSON file persistence). Pipeline ownership is managed by the `LeaseProvider` interface with configurable TTL expiration.
+
+### Optional Redis Support
+
+For distributed deployments, Redis can be used instead of in-memory storage. Redis is fully optional — the plugin works out of the box with zero configuration.
+
+**Enable Redis via environment variable:**
+
+```bash
+export AI_COMPANY_REDIS_URL=redis://localhost:6379
+```
+
+**Or via plugin config:**
+
+```json
+{
+  "ai-engineering-company": {
+    "redis": {
+      "url": "redis://localhost:6379",
+      "prefix": "ai-company:"
+    }
+  }
+}
+```
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `AI_COMPANY_REDIS_URL` | — | Redis URL (env var takes priority) |
+| `redis.url` | — | Redis URL (plugin config) |
+| `redis.prefix` | `ai-company:` | Key prefix for Redis storage |
+
+**Fallback behavior:** If Redis is configured but unavailable at startup, the plugin falls back to in-memory mode automatically. No manual intervention required.
+
+## Troubleshooting
+
+### Plugin not loading
+
+```bash
+# Verify plugin is installed and enabled
+openclaw plugins list
+
+# Rebuild after changes
+npm run build
+openclaw plugins build
+```
+
+### Pending approvals not visible
+
+```bash
+# List all pending approvals
+openclaw ai-company approvals
+
+# Check DecisionQueue persistence file
+cat .openclaw/decisions.json
+```
+
+### Interrupted pipeline after crash
+
+```bash
+# List interrupted pipelines with stage progress
+openclaw ai-company recover
+
+# Resume an interrupted pipeline from last checkpoint
+openclaw ai-company recover --resume <session-key>
+```
+
+### Audit log inspection
+
+```bash
+# View today's audit log
+cat .openclaw/audit/audit-$(date +%Y-%m-%d).jsonl | jq .
+
+# Query specific event types
+openclaw ai-company audit --event "pipeline_failed"
+```
+
+## Development
+
+```bash
+# Install dependencies
+pnpm install
+
+# Run tests
+pnpm test
+
+# Type check
+pnpm run typecheck
+
+# Build
+pnpm run build
+```
+
+## License
+
+MIT License - see [LICENSE](LICENSE) for details.

package/assets/offices/architecture/README.md

@@ -0,0 +1,32 @@
+# Architecture Office
+
+**Purpose**: Define how to structure systems.
+
+## Authority
+- System architecture design
+- Technical standards and patterns
+- API contracts and data models
+- Technology evaluation
+
+## Restrictions
+- Cannot write implementation code
+- Cannot change requirements
+- Cannot deploy
+- Cannot assign or reassign tasks (Dispatcher only)
+
+## Roles
+| Role | Responsibility |
+|---|---|
+| Technical Architect | Design system architecture, define standards, review implementations |
+
+## How Work Arrives
+The Dispatcher agent routes architecture-type work (system design, technical reviews, ADRs) to the Technical Architect. The Architect also reviews proposals from Engineers before implementation begins.
+
+## Collaboration
+The Architect collaborates directly with:
+- **Architect ↔ PM**: Requirements feasibility, technical constraints
+- **Architect ↔ Frontend Engineer**: Component architecture, state management
+- **Architect ↔ Backend Engineer**: System structure, API design, data flow
+- **Architect ↔ Infrastructure Engineer**: Deployment architecture, scaling strategy
+
+Collaboration does NOT change task ownership. The Architect does NOT spawn other workers.

package/assets/offices/engineering/README.md

@@ -0,0 +1,53 @@
+# Engineering Office
+
+**Purpose**: Build and ship.
+
+## Authority
+- Code implementation
+- Testing
+- Deployment (with Operator approval)
+
+## Restrictions
+- Cannot change requirements
+- Cannot approve own work
+- Cannot modify knowledge base
+- Cannot assign or reassign tasks (Dispatcher only)
+
+## Roles
+| Role | Responsibility |
+|---|---|
+| Frontend Engineer | Implement user interfaces, handle client-side logic, ensure accessibility |
+| Backend Engineer | Implement server logic, APIs, database operations, integrations |
+| Infrastructure Engineer | Manage deployments, CI/CD, monitoring, cloud infrastructure |
+| QA Engineer | Write tests, validate quality, report defects, verify fixes |
+
+## Specializations
+Specializations are per-task, not permanent:
+- **Frontend**: react, vue, angular, svelte, css, accessibility, performance, testing
+- **Backend**: api, database, auth, security, performance, testing, integration
+- **Infrastructure**: cicd, monitoring, cloud, security, networking, database-ops
+
+## How Work Arrives
+The Dispatcher agent routes engineering-type work to the appropriate specialist based on required capabilities:
+- UI/Frontend work → Frontend Engineer
+- API/Backend work → Backend Engineer
+- Deployment/Infrastructure work → Infrastructure Engineer
+- Testing/QA work → QA Engineer
+
+Feature work arrives after the Product Manager defines requirements and the Architect defines system structure.
+
+## Collaboration
+The Engineers collaborate directly with:
+- **Frontend ↔ Designer**: Specifications, implementation questions, feasibility
+- **Frontend ↔ Backend**: API contracts, data formats, integration
+- **Frontend ↔ QA**: Test results, defect reports, fixes
+- **Backend ↔ PM**: Requirements clarity, scope questions
+- **Backend ↔ Architect**: System structure, API design, data flow
+- **Backend ↔ Infrastructure**: Deployment, configuration, environment
+- **Backend ↔ Governor**: Security review, compliance, rework
+- **Backend ↔ QA**: Test results, defect reports, fixes
+- **Infrastructure ↔ Architect**: Deployment architecture, scaling strategy
+- **Infrastructure ↔ QA**: Test environments, CI/CD integration
+- **QA ↔ Governor**: Compliance evidence, quality gate results
+
+Collaboration does NOT change task ownership. Engineers do NOT spawn other workers.

package/assets/offices/governance/README.md

@@ -0,0 +1,30 @@
+# Governance Office
+
+**Purpose**: Ensure safety and quality.
+
+## Authority
+- Policy enforcement
+- Gate pass/fail decisions
+- Knowledge review
+- Risk assessment
+
+## Restrictions
+- Cannot write code
+- Cannot change requirements
+- Cannot assign or reassign tasks (Dispatcher only)
+
+## Roles
+| Role | Responsibility |
+|---|---|
+| Governor | Audit completed work, enforce policies, review knowledge, assess risk |
+
+## How Work Arrives
+The Dispatcher agent routes governance-type work (policy reviews, knowledge reviews, security reviews) to the Governor. The Governor also reviews work after engineering completes security-sensitive tasks.
+
+## Collaboration
+The Governor collaborates directly with:
+- **Governor ↔ Engineer**: Review submissions, compliance findings, rework requests
+
+The Governor does NOT collaborate with PM, Researcher, or Designer. The Governor's domain is engineering output review and policy enforcement.
+
+Collaboration does NOT change task ownership. The Governor does NOT spawn other workers.

package/assets/offices/product/README.md

@@ -0,0 +1,37 @@
+# Product Office
+
+**Purpose**: Define what to build.
+
+## Authority
+- Task definitions
+- Requirements specification
+- Acceptance criteria
+- Work prioritization
+
+## Restrictions
+- Cannot write code
+- Cannot approve deployments
+- Cannot modify knowledge base
+- Cannot assign or reassign tasks (Dispatcher only)
+
+## Roles
+| Role | Responsibility |
+|---|---|
+| Product Manager | Classify requests, extract scope, determine gates, prioritize work, accept completed work |
+| Researcher | Explore codebases, investigate options, gather evidence, produce reports |
+| Designer | Design interaction flows, create specifications, review UX |
+
+## How Work Arrives
+The Dispatcher agent classifies incoming requests and routes product-type work (features, research, design) to the appropriate role in this office.
+
+## Collaboration
+Workers in this office collaborate directly with:
+- **PM ↔ Researcher**: Investigations, evidence, findings
+- **PM ↔ Designer**: Requirements, user journeys, specifications
+- **PM ↔ Architect**: Requirements feasibility, technical constraints
+- **PM ↔ Backend Engineer**: Requirements clarity, scope questions
+- **Researcher ↔ Architect**: Technical findings, architecture analysis
+- **Researcher ↔ Backend Engineer**: Technical findings, implementation analysis
+- **Designer ↔ Frontend Engineer**: Specifications, implementation questions, feasibility
+
+Collaboration does NOT change task ownership. Workers do NOT spawn other workers.