wogiflow 2.6.4 → 2.7.0

package/lib/workspace-routing.js

@@ -479,6 +479,146 @@ function getExecutionOrder(manifest, targetRepos) {
   return order;
 }
 
+// ============================================================
+// Cross-Repo Dependency-Aware Task Blocking
+// ============================================================
+
+/**
+ * Block consumer-side tasks until their provider dependencies are complete.
+ * Reads workspace-level ready.json and each member's ready.json to find
+ * cross-repo dependencies.
+ *
+ * @param {string} workspaceRoot
+ * @param {Object} manifest
+ * @returns {{ blockedTasks: Array<Object>, unblockedTasks: Array<Object> }}
+ */
+function updateCrossRepoBlocking(workspaceRoot, manifest) {
+  const configPath = path.join(workspaceRoot, 'wogi-workspace.json');
+  let config;
+  try {
+    config = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
+  } catch (_err) {
+    return { blockedTasks: [], unblockedTasks: [] };
+  }
+
+  const blockedTasks = [];
+  const unblockedTasks = [];
+  const memberTasks = {};
+
+  // Collect all tasks from all member repos
+  for (const [name, memberConfig] of Object.entries(config.members || {})) {
+    const memberPath = path.resolve(workspaceRoot, memberConfig.path);
+    const readyPath = path.join(memberPath, '.workflow', 'state', 'ready.json');
+    try {
+      if (fs.existsSync(readyPath)) {
+        const ready = JSON.parse(fs.readFileSync(readyPath, 'utf-8'));
+        memberTasks[name] = {
+          path: memberPath,
+          readyPath,
+          ready,
+          inProgress: ready.inProgress || [],
+          readyItems: ready.ready || [],
+          completed: ready.recentlyCompleted || []
+        };
+      }
+    } catch (_err) {
+      // Skip
+    }
+  }
+
+  // For each member's ready tasks, check if they depend on workspace tasks
+  const executionOrder = getExecutionOrder(manifest, Object.keys(config.members));
+
+  for (const [name, data] of Object.entries(memberTasks)) {
+    const memberPhase = executionOrder.find(o => o.name === name);
+    if (!memberPhase) continue;
+
+    for (const task of data.readyItems) {
+      // Check if this task has workspace source and blockedBy
+      if (!task.source?.startsWith('workspace:')) continue;
+
+      const blockedBy = task.blockedBy || [];
+      let isBlocked = false;
+
+      for (const depId of blockedBy) {
+        // Check if the blocking task is completed in any member
+        let depCompleted = false;
+        for (const [depName, depData] of Object.entries(memberTasks)) {
+          if (depData.completed.some(t => t.id === depId)) {
+            depCompleted = true;
+            break;
+          }
+        }
+
+        if (!depCompleted) {
+          isBlocked = true;
+          break;
+        }
+      }
+
+      if (isBlocked) {
+        blockedTasks.push({ repo: name, task, blockedBy });
+      } else if (blockedBy.length > 0) {
+        unblockedTasks.push({ repo: name, task });
+      }
+    }
+  }
+
+  return { blockedTasks, unblockedTasks };
+}
+
+/**
+ * Build a visual dependency tree for workspace tasks.
+ *
+ * @param {string} workspaceRoot
+ * @param {Object} manifest
+ * @returns {string} formatted tree
+ */
+function formatDependencyTree(workspaceRoot, manifest) {
+  const configPath = path.join(workspaceRoot, 'wogi-workspace.json');
+  let config;
+  try {
+    config = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
+  } catch (_err) {
+    return 'No workspace config found.';
+  }
+
+  const lines = ['Workspace Task Dependencies:'];
+  const order = getExecutionOrder(manifest, Object.keys(config.members || {}));
+
+  for (const entry of order) {
+    const memberConfig = config.members[entry.name];
+    if (!memberConfig) continue;
+
+    const memberPath = path.resolve(workspaceRoot, memberConfig.path);
+    const readyPath = path.join(memberPath, '.workflow', 'state', 'ready.json');
+
+    try {
+      if (!fs.existsSync(readyPath)) continue;
+      const ready = JSON.parse(fs.readFileSync(readyPath, 'utf-8'));
+      const wsTasks = [...(ready.inProgress || []), ...(ready.ready || []), ...(ready.blocked || [])]
+        .filter(t => t.source?.startsWith('workspace:'));
+
+      if (wsTasks.length === 0) continue;
+
+      lines.push(`\n  ${entry.name} (${entry.role}, phase ${entry.order}):`);
+      for (const task of wsTasks) {
+        const status = task.status === 'completed' ? '\u2713' :
+          (ready.inProgress || []).some(t => t.id === task.id) ? '\u25B6' :
+            task.blockedBy?.length ? '\u2718' : '\u25CB';
+        const blockedNote = task.blockedBy?.length
+          ? ` [blocked by: ${task.blockedBy.join(', ')}]`
+          : '';
+        lines.push(`    ${status} ${task.id} — ${task.title}${blockedNote}`);
+      }
+    } catch (_err) {
+      // Skip
+    }
+  }
+
+  return lines.join('\n');
+}
+
 // ============================================================
 // Channel-Based Dispatch (wf-d4b98f60)
 // ============================================================
@@ -772,6 +912,10 @@ module.exports = {
   // Ordering
   getExecutionOrder,
 
+  // Cross-repo blocking
+  updateCrossRepoBlocking,
+  formatDependencyTree,
+
   // Channel dispatch
   dispatchToChannel,
   dispatchCrossRepoPlan,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wogiflow",
-  "version": "2.6.4",
+  "version": "2.7.0",
   "description": "AI-powered development workflow management system with multi-model support",
   "main": "lib/index.js",
   "bin": {

package/scripts/flow-done-gates.js

@@ -57,6 +57,19 @@ function getRegistryManager() {
   return _registryManagerModule;
 }
 
+// Workspace gates — lazy-loaded (only active when workspace mode is detected)
+let _workspaceGatesModule = undefined;
+function getWorkspaceGates() {
+  if (_workspaceGatesModule === undefined) {
+    try {
+      _workspaceGatesModule = require('../lib/workspace-gates');
+    } catch (_err) {
+      _workspaceGatesModule = null;
+    }
+  }
+  return _workspaceGatesModule;
+}
+
 // ============================================================
 // Gate Handlers
 // ============================================================
@@ -717,6 +730,60 @@ function unknownGate(ctx, gateName) {
 // Gate Registry
 // ============================================================
 
+// ============================================================
+// Workspace Quality Gates (conditional — only when workspace active)
+// ============================================================
+
+/**
+ * Workspace gate handler. Delegates to workspace-gates.js for each
+ * sub-gate (crossRepoImpactCheck, contractCompliance, peerNotification,
+ * cascadeVerification, integrationMapFreshness).
+ *
+ * This is a single gate entry in GATE_REGISTRY that runs all applicable
+ * workspace sub-gates based on task type.
+ */
+function workspaceGate(ctx, gateName) {
+  const wsGates = getWorkspaceGates();
+  if (!wsGates) {
+    return { passed: true, skipped: true };
+  }
+
+  const ws = wsGates.workspaceActive();
+  if (!ws.active) {
+    return { passed: true, skipped: true };
+  }
+
+  const context = wsGates.loadWorkspaceContext(ws.root);
+  const taskMeta = {
+    taskId: ctx.taskId,
+    taskTitle: ctx.taskTitle || '',
+    taskType: ctx.normalizedType || 'feature',
+    impactAssessed: ctx.impactAssessed || false
+  };
+
+  const results = wsGates.runAllWorkspaceGates(ws.root, context, taskMeta);
+
+  // Display results
+  for (const r of results.results) {
+    if (r.passed) {
+      ctx.success(`workspace/${r.gate}: ${r.message}`);
+    } else if (r.severity === 'warning') {
+      console.log(`  ${ctx.color('yellow', '\u25CB')} workspace/${r.gate}: ${r.message}`);
+    } else {
+      ctx.error(`workspace/${r.gate}: ${r.message}`);
+    }
+  }
+
+  if (!results.passed) {
+    return {
+      passed: false,
+      errorOutput: `${results.errors} workspace gate(s) failed, ${results.warnings} warning(s)`
+    };
+  }
+
+  return { passed: true };
+}
+
 const GATE_REGISTRY = {
   tests: testsGate,
   lint: lintGate,
@@ -737,6 +804,8 @@ const GATE_REGISTRY = {
   uiVerification: verificationGate,
   apiVerification: verificationGate,
   testDiscovery: testDiscoveryGate,
+  // Workspace gates (conditional — auto-skip when not in workspace)
+  workspaceCompliance: workspaceGate,
 };
 
 /**
@@ -782,5 +851,6 @@ module.exports = {
   generatedTestsPassGate,
   verificationGate,
   testDiscoveryGate,
+  workspaceGate,
   unknownGate,
 };

package/.claude/rules/_internal/README.md

@@ -1,64 +0,0 @@
----
-alwaysApply: false
-description: "Meta-documentation about how project rules are organized"
----
-# Project Rules
-
-This directory contains coding rules and patterns for this project, organized by category.
-
-## Structure
-
-```
-.claude/rules/
-├── code-style/           # Naming conventions, formatting
-│   └── naming-conventions.md
-├── security/             # Security patterns and practices
-│   └── security-patterns.md
-├── architecture/         # Design decisions and patterns
-│   ├── component-reuse.md
-│   └── model-management.md
-└── README.md
-```
-
-## How Rules Work
-
-Rules are automatically loaded by Claude Code based on:
-- **alwaysApply: true** - Rule is always loaded
-- **alwaysApply: false** - Rule is loaded based on `globs` or `description` relevance
-- **globs** - File patterns that trigger rule loading
-
-## Adding New Rules
-
-1. Choose the appropriate category subdirectory
-2. Create a `.md` file with frontmatter:
-
-```yaml
----
-alwaysApply: false
-description: "Brief description for relevance matching"
-globs: src/**/*.ts  # Optional: only load for these files
----
-```
-
-3. Write the rule content in markdown
-
-## Categories
-
-| Category | Purpose |
-|----------|---------|
-| code-style | Naming conventions, formatting, file structure |
-| security | Security patterns, input validation, safe practices |
-| architecture | Design decisions, component patterns, system organization |
-
-## Auto-Generation
-
-Some rules can be auto-generated from `.workflow/state/decisions.md`:
-
-```bash
-node scripts/flow-rules-sync.js
-```
-
-The sync script will route rules to appropriate category subdirectories.
-
----
-Last updated: 2026-01-12

package/.claude/rules/_internal/document-structure.md

@@ -1,77 +0,0 @@
----
-alwaysApply: false
-description: "All AI-context documents must use PIN markers for targeted context loading"
-globs: ".workflow/**/*.md"
----
-
-# Document Structure for AI Context
-
-All documents in `.workflow/` that are used as AI context MUST follow the PIN standard.
-
-## Required Structure
-
-### 1. Header with PIN List
-Every document starts with a comment listing all pins in the document:
-```markdown
-<!-- PINS: pin1, pin2, pin3 -->
-```
-
-### 2. Section PIN Markers
-Each major section has a PIN marker comment:
-```markdown
-### Section Title
-<!-- PIN: section-specific-pin -->
-[Content]
-```
-
-### 3. PIN Naming Convention
-- Use kebab-case: `user-authentication`, not `userAuthentication`
-- Use semantic names: `error-handling`, not `eh`
-- Use compound names for specificity: `json-parse-safety`
-
-## Why PINs Matter
-
-The PIN system enables:
-1. **Targeted context loading**: Only load sections relevant to current task
-2. **Cheaper model routing**: Haiku can fetch only relevant sections for Opus
-3. **Change detection**: Hash sections independently for smart invalidation
-4. **Cross-reference**: Link sections by PIN across documents
-
-## Example Document
-
-```markdown
-# Config Reference
-
-<!-- PINS: database, authentication, api-keys, environment -->
-
-## Database Settings
-<!-- PIN: database -->
-| Setting | Default | Description |
-|---------|---------|-------------|
-
-## Authentication
-<!-- PIN: authentication -->
-| Setting | Default | Description |
-|---------|---------|-------------|
-```
-
-## Parsing
-
-The PIN system automatically parses documents with:
-- `flow-section-index.js` - Generates section index with pins
-- `flow-section-resolver.js` - Resolves sections by PIN lookup
-- `getSectionsByPins(['auth', 'security'])` - Fetch only relevant sections
-
-## Files That Must Have PINs
-
-| File | Required PINs |
-|------|---------------|
-| `decisions.md` | Per coding rule/pattern |
-| `app-map.md` | Per component/screen |
-| `product.md` | Per product section |
-| `stack.md` | Per technology |
-
-## Validation
-
-Run `node scripts/flow-section-index.js --force` to regenerate the index.
-Check `.workflow/state/section-index.json` for indexed sections and their pins.

package/.claude/rules/_internal/dual-repo-management.md

@@ -1,174 +0,0 @@
----
-alwaysApply: false
-description: "Dual-repo management rules for wogi-flow and wogiflow-cloud"
-globs: "package.json,lib/installer.js,lib/extension-points.js"
----
-# Dual-Repo Management: wogi-flow + wogiflow-cloud
-
-**Added**: 2026-02-28
-**Source**: User directive — formalize dual-repo architecture decisions
-
-## Repository Ownership
-
-| Repo | Package | Visibility | Purpose |
-|------|---------|-----------|---------|
-| `wogi-flow` | `wogiflow` (npm) | Public (AGPL-3.0) | Free CLI, workflow engine, all local-only features |
-| `wogiflow-cloud` | `@wogiflow/teams` (client), `wogiflow-cloud-server` (server) | Private | Teams backend, client hooks, dashboard, portal logic |
-| `wogiflow-portal` | N/A (static site) | Public | wogi.ai — landing page, login, signup, knowledge base |
-
-## Hard Rule: No Teams Code in the Free Repo
-
-Team-specific logic MUST NEVER appear in `wogi-flow`. This includes:
-- Auth/login UI beyond the thin `wogi login`/`wogi logout` adapter
-- Sync engines, presence, real-time features
-- Team CRUD, roles, permissions
-- Dashboard pages
-- Server-side API routes
-
-The free repo provides **extension points** (hooks in `lib/extension-points.js`) that the cloud client plugs into. The adapter pattern is:
-- `wogi-flow` exports hook interfaces and config schema
-- `@wogiflow/teams` imports those interfaces and adds team behavior
-- All team logic executes from `@wogiflow/teams`, never from `wogiflow` core
-
-## Version Management
-
-### Independent Versions, Mutual Awareness
-
-Each repo has its own semver version. They are NOT locked together.
-
-- `wogi-flow` → `package.json` version (currently 1.6.0)
-- `wogiflow-cloud` server → `packages/server/package.json` version (currently 0.1.0)
-- `@wogiflow/teams` client → `packages/client/package.json` version (currently 0.1.0)
-
-### Cross-Repo Version File
-
-Each repo maintains a `.workflow/state/partner-versions.json` that records the last-known version of the other repo:
-
-```json
-// In wogi-flow:
-{
-  "self": { "package": "wogiflow", "version": "1.6.0" },
-  "partners": {
-    "wogiflow-cloud-server": { "version": "0.1.0", "checkedAt": "2026-02-28" },
-    "wogiflow-teams-client": { "version": "0.1.0", "minCompatible": "1.5.0", "checkedAt": "2026-02-28" }
-  }
-}
-
-// In wogiflow-cloud:
-{
-  "self": { "package": "wogiflow-cloud", "version": "0.1.0" },
-  "partners": {
-    "wogiflow": { "version": "1.6.0", "checkedAt": "2026-02-28" }
-  }
-}
-```
-
-**Update rule**: When releasing either repo, update `partner-versions.json` in BOTH repos.
-
-### Compatibility Contract
-
-The `@wogiflow/teams` client declares its minimum compatible `wogiflow` version via peerDependencies:
-
-```json
-"peerDependencies": {
-  "wogiflow": ">=1.5.0"
-}
-```
-
-**When to bump the minimum**:
-- When the free repo removes or renames an exported function that the client uses
-- When the free repo changes the shape of config.json, ready.json, or other state files
-- When the free repo changes hook interfaces (entry point signatures, event payloads)
-
-**When NOT to bump**:
-- New features added to the free repo (additive changes are always compatible)
-- Internal refactoring that doesn't change exports
-
-## Interface Contract (Public API Surface)
-
-The cloud client depends on these interfaces from `wogi-flow`. Changes to any of these require updating the client:
-
-### Exported Functions (from scripts/)
-- `flow-utils.js`: `getConfig()`, `safeJsonParse()`, `writeJson()`, `generateTaskId()`, `validateTaskId()`, `PATHS`, `getReadyData()`, `saveReadyData()`
-- `flow-session-state.js`: `trackTaskStart()`, `trackBypassAttempt()`
-- `flow-memory-blocks.js`: `setCurrentTask()`
-
-### Hook Interfaces (entry point contracts)
-- `PreToolUse` hooks receive: `{ tool, toolInput }` via stdin JSON
-- `PostToolUse` hooks receive: `{ tool, toolInput, toolResult }` via stdin JSON
-- `TaskCompleted` hooks receive: `{ taskId }` via stdin JSON
-- `SessionStart`/`SessionEnd` hooks receive: `{}` via stdin JSON
-
-### State File Formats
-- `ready.json`: `{ inProgress: [], ready: [], blocked: [], recentlyCompleted: [], backlog: [] }`
-- `config.json`: Schema documented in `config.schema.json`
-- `decisions.md`: Markdown with `## Section` / `### Rule` structure
-- `session-state.json`: `{ taskId, status, lastBriefingAt, ... }`
-
-### Config Keys Used by Cloud
-- `hooks.rules.*` — all hook toggle keys
-- `enforcement.*` — strict mode, task gating
-- `semanticMatching.*` — reuse detection thresholds
-
-**When modifying any of the above**: Check wogiflow-cloud for consumers BEFORE releasing.
-
-## Change Propagation Rules
-
-### OSS Change → Does Cloud Need Updating?
-
-| Change Type | Cloud Impact | Action Required |
-|-------------|-------------|-----------------|
-| New feature (additive) | None | No action needed |
-| Bug fix (internal) | None | No action needed |
-| Exported function renamed/removed | BREAKING | Update client, bump peerDep minimum |
-| State file format changed | BREAKING | Update client parsers |
-| Hook interface changed | BREAKING | Update client hooks |
-| Config key renamed/removed | BREAKING | Update client config readers |
-| New config key added | None (additive) | Client can optionally use it |
-
-### Cloud Change → Does OSS Need Updating?
-
-| Change Type | OSS Impact | Action Required |
-|-------------|-----------|-----------------|
-| New server feature | None | No action needed |
-| New client hook | None | No action needed |
-| Client needs new OSS export | REQUIRES | Add export to OSS, release OSS first |
-| Dashboard changes | None | Entirely separate |
-
-### Release Order
-
-1. **OSS first**: If the cloud needs a new OSS feature, release OSS first
-2. **Cloud follows**: Cloud releases independently, referencing the OSS version in peerDeps
-3. **Never**: Release cloud with a dependency on an unreleased OSS version
-
-```
-OSS v1.7.0 (adds new export)
-    ↓
-Cloud client v0.2.0 (uses new export, peerDep bumped to >=1.7.0)
-    ↓
-Cloud server v0.2.0 (may or may not change)
-```
-
-## Web Properties
-
-| Property | Repo | Purpose |
-|----------|------|---------|
-| wogi.ai (main site) | `wogiflow-portal` | Landing, login, signup, knowledge base |
-| Dashboard (admin UI) | `wogiflow-cloud/packages/dashboard/` | Team admin — served by cloud server |
-
-The portal is a separate deployment from the dashboard. The portal is public-facing (marketing + auth). The dashboard is authenticated (team management).
-
-## Verification Checklist (Before Any Release)
-
-### Releasing wogi-flow (OSS):
-1. Check `partner-versions.json` — is cloud version current?
-2. If any exported function/interface changed: grep wogiflow-cloud for consumers
-3. Run `node --check` on all modified scripts
-4. Follow GitHub Release Workflow (decisions.md)
-5. After release: update `partner-versions.json` in wogiflow-cloud
-
-### Releasing wogiflow-cloud:
-1. Check `partner-versions.json` — is OSS version current?
-2. Verify `peerDependencies.wogiflow` range includes current OSS version
-3. If client needs new OSS export: release OSS first
-4. After release: update `partner-versions.json` in wogi-flow

package/.claude/rules/_internal/feature-refactoring-cleanup.md

@@ -1,87 +0,0 @@
----
-alwaysApply: false
-description: "Cleanup checklist when refactoring or renaming features"
-globs:
-  - "scripts/*.js"
-  - ".claude/skills/**/*"
----
-
-# Feature Refactoring Cleanup
-
-When refactoring, renaming, or replacing a feature, ensure complete cleanup of the old implementation.
-
-## Mandatory Cleanup Checklist
-
-When a feature is refactored or renamed, you MUST:
-
-### 1. Remove Old Code
-- [ ] Delete old script files (e.g., `flow-old-feature.js`)
-- [ ] Remove old skill directories (e.g., `.claude/skills/old-feature/`)
-- [ ] Remove old hook files if applicable
-
-### 2. Update Configuration
-- [ ] Rename config keys (e.g., `oldFeature` → `newFeature`)
-- [ ] Remove from `skills.installed` array if skill was removed
-- [ ] Update any feature flags
-
-### 3. Update Documentation
-- [ ] Rename/update doc files in `.claude/docs/`
-- [ ] Update command references in `commands.md`
-- [ ] Update skill-matching.md if skill changed
-- [ ] Search for old name in all `.md` files
-
-### 4. Clean References
-- [ ] Search codebase: `grep -r "old-feature-name" .`
-- [ ] Update imports in dependent scripts
-- [ ] Update any hardcoded references
-
-### 5. Update State Files
-- [ ] Clean `.workflow/state/` of old state files
-- [ ] Update `ready.json` if tasks reference old feature
-- [ ] Archive old change specs
-
-## Search Commands
-
-Run these to find lingering references:
-
-```bash
-# Find all references to old feature
-grep -r "old-feature-name" --include="*.js" --include="*.md" --include="*.json" .
-
-# Find in config
-grep "oldFeatureName" .workflow/config.json
-
-# Find skill references
-grep -r "old-feature" .claude/
-```
-
-## Why This Matters
-
-Incomplete cleanup causes:
-- **Confusion**: Old commands/skills appear to work but don't
-- **Bloat**: Dead code accumulates
-- **Errors**: Old references cause runtime failures
-- **Documentation drift**: Docs describe non-existent features
-
-## Example: transcript-digestion → long-input-gate
-
-When this refactoring happened without proper cleanup:
-
-| Artifact | Status | Should Have Been |
-|----------|--------|------------------|
-| `.claude/skills/transcript-digestion/` | Left behind | Deleted |
-| `config.transcriptDigestion` | Left as-is | Renamed to `longInputGate` |
-| `skills.installed` array | Still listed | Removed |
-| `skill-matching.md` | Old references | Updated |
-| `transcript-digestion.md` doc | Still existed | Renamed/rewritten |
-
-## Automation Opportunity
-
-Consider adding a `flow refactor-cleanup <old-name> <new-name>` command that:
-1. Searches for all references
-2. Shows what needs updating
-3. Optionally auto-updates simple cases
-
----
-
-Last updated: 2026-01-14