wogiflow 2.33.0 → 2.34.2

package/scripts/hooks/core/workspace-stop-notify.js

@@ -1,76 +1,191 @@
 'use strict';
 
 /**
- * Workspace worker-stopped notification (wf-6e31850e A-3 / extracted from stop.js).
+ * Workspace worker signal emission (epic-workspace-sustained-exec / S3, wf-d3ae1717;
+ * originally wf-6e31850e A-3 / wf-d3e67abe).
  *
- * Writes a structured `worker-stopped` message to the workspace message bus
- * so the manager's overdue-check can distinguish "graceful stop" from
- * "silent death" vs "task-complete". Original: wf-d3e67abe.
+ * Two distinct signals so the manager never mistakes a pause for a stop:
+ *
+ *   notifyWorkerProgress() — a HEARTBEAT, emitted when the continuation gate (S2)
+ *     forces the worker to keep going. "Work ongoing," NOT a stop. Carries the
+ *     current sub-task progress + git HEAD so the manager can refresh the
+ *     dispatch deadline instead of polling git.
+ *
+ *   notifyWorkerTerminal() — emitted ONLY on a genuine stop (after all gates
+ *     decline to continue). Picks a precise terminal type:
+ *       worker-awaiting-approval — in-progress task sitting in spec_review/exploring
+ *                                  (waiting on the manager's GO — NOT done)
+ *       worker-stopped           — in-progress, active phase, but stopping anyway
+ *                                  (legacy mid-work stop)
+ *       worker-idle              — nothing in progress and nothing queued
+ *
+ * The old code emitted `worker-stopped` UNCONDITIONALLY at the top of the Stop
+ * sequence — before the gates ran — so the manager saw "stopped mid-work" on
+ * every turn boundary, even when the worker was about to be forced to continue.
+ * That ordering bug is fixed: emission now happens at the decision point.
+ *
+ * All emission is best-effort and fail-open; never throws into the Stop path.
  */
 
-async function notifyWorkerStopped() {
-  if (!process.env.WOGI_REPO_NAME || process.env.WOGI_REPO_NAME === 'manager') return;
+const VALID_NAME = /^[a-zA-Z0-9_-]{1,64}$/;
+const AWAITING_PHASES = new Set(['spec_review', 'exploring', 'routing', 'idle']);
+
+function isWorker() {
+  return Boolean(process.env.WOGI_REPO_NAME &&
+    process.env.WOGI_REPO_NAME !== 'manager' &&
+    VALID_NAME.test(process.env.WOGI_REPO_NAME) &&
+    process.env.WOGI_WORKSPACE_ROOT);
+}
+
+function readState() {
+  const nodePath = require('node:path');
+  const { PATHS, safeJsonParse } = require('../../flow-utils');
+  const ready = safeJsonParse(nodePath.join(PATHS.state, 'ready.json'), {});
+  const phaseData = safeJsonParse(nodePath.join(PATHS.state, 'workflow-phase.json'), {});
+  const inProgressTask = (ready.inProgress || [])[0] || null;
+  const queued = (ready.ready || []).length;
+  let lastSha = null;
   try {
-    const nodePath = require('node:path');
-    const childProcess = require('node:child_process');
-    const VALID_NAME = /^[a-zA-Z0-9_-]{1,64}$/;
-    const repoName = process.env.WOGI_REPO_NAME;
-    if (!VALID_NAME.test(repoName)) throw new Error('Invalid WOGI_REPO_NAME');
+    lastSha = require('node:child_process').execSync('git rev-parse --short HEAD 2>/dev/null || true', {
+      cwd: PATHS.root, encoding: 'utf-8', timeout: 2000
+    }).trim() || null;
+  } catch (_err) { /* non-critical */ }
+  return { inProgressTask, queued, phase: phaseData?.phase || null, lastSha };
+}
 
-    const workspaceRoot = process.env.WOGI_WORKSPACE_ROOT;
-    if (!workspaceRoot) return;
+function emit(type, fields) {
+  const nodePath = require('node:path');
+  const workspaceRoot = process.env.WOGI_WORKSPACE_ROOT;
+  const repoName = process.env.WOGI_REPO_NAME;
+  const libMessages = nodePath.resolve(__dirname, '..', '..', '..', 'lib', 'workspace-messages');
+  const { createMessage, saveMessage } = require(libMessages);
+  const msg = createMessage({
+    from: repoName,
+    to: 'manager',
+    type,
+    subject: fields.subject,
+    body: fields.body,
+    priority: fields.priority || 'medium',
+    actionRequired: Boolean(fields.actionRequired)
+  });
+  Object.assign(msg, fields.extra || {});
+  saveMessage(workspaceRoot, msg);
 
-    const { PATHS, safeJsonParse } = require('../../flow-utils');
-    const ready = safeJsonParse(nodePath.join(PATHS.state, 'ready.json'), {});
-    const recentTask = (ready.recentlyCompleted || [])[0];
-    const inProgressTask = (ready.inProgress || [])[0];
-    const mostRecent = recentTask || inProgressTask;
+  // Real-time nudge to the manager port (best-effort) so it doesn't have to wait
+  // for its own next prompt to read the bus.
+  try {
+    const managerPort = process.env.WOGI_MANAGER_PORT;
+    if (managerPort) {
+      const http = require('node:http');
+      const payload = `[${type}] ${fields.subject}`;
+      const buf = Buffer.from(payload, 'utf-8');
+      const req = http.request({
+        hostname: '127.0.0.1', port: parseInt(managerPort, 10), path: '/', method: 'POST',
+        headers: { 'Content-Type': 'text/plain', 'Content-Length': buf.byteLength, 'X-Wogi-From': repoName }
+      });
+      req.on('error', () => {});
+      req.write(buf); req.end();
+    }
+  } catch (_err) { /* best effort */ }
+}
 
-    const hasInProgress = Boolean(inProgressTask);
-    const state = hasInProgress ? 'mid-work' : 'idle';
-    const taskInProgress = hasInProgress ? inProgressTask.id : null;
+/**
+ * Heartbeat — the continuation gate forced another turn. NOT a stop.
+ * @param {Object} info { taskId, remaining, total, attempt }
+ */
+async function notifyWorkerProgress(info = {}) {
+  if (!isWorker()) return;
+  try {
+    const { lastSha } = readState();
+    emit('worker-progress', {
+      subject: `Worker ${process.env.WOGI_REPO_NAME} working on ${info.taskId || 'task'} (${info.remaining ?? '?'} sub-task(s) left)`,
+      body: [
+        `Worker "${process.env.WOGI_REPO_NAME}" is continuing (heartbeat).`,
+        info.taskId ? `Task: ${info.taskId}` : null,
+        (info.total != null) ? `Sub-tasks: ${(info.total - (info.remaining ?? 0))}/${info.total} done, ${info.remaining ?? '?'} remaining` : null,
+        info.attempt != null ? `Continuation: ${info.attempt}` : null,
+        lastSha ? `HEAD: ${lastSha}` : null
+      ].filter(Boolean).join('\n'),
+      priority: 'low',
+      actionRequired: false,
+      extra: {
+        reason: 'continuation',
+        state: 'in-progress',
+        taskId: info.taskId || null,
+        taskInProgress: info.taskId || null,
+        remaining: info.remaining ?? null,
+        total: info.total ?? null,
+        continuation: info.attempt ?? null,
+        lastSha,
+        heartbeatAt: new Date().toISOString()
+      }
+    });
+  } catch (err) {
+    if (process.env.DEBUG) console.error(`[Stop] worker-progress emit failed: ${err.message}`);
+  }
+}
 
-    let lastSha = null;
-    try {
-      lastSha = childProcess.execSync('git rev-parse --short HEAD 2>/dev/null || true', {
-        cwd: PATHS.root,
-        encoding: 'utf-8',
-        timeout: 2000
-      }).trim() || null;
-    } catch (_err) { /* non-critical */ }
+/**
+ * Terminal — emitted at a genuine stop. Picks the precise terminal type.
+ */
+async function notifyWorkerTerminal() {
+  if (!isWorker()) return;
+  try {
+    const { inProgressTask, queued, phase, lastSha } = readState();
+    const taskId = inProgressTask?.id || null;
 
-    try {
-      const libMessages = nodePath.resolve(__dirname, '..', '..', '..', 'lib', 'workspace-messages');
-      const { createMessage, saveMessage } = require(libMessages);
-      const msg = createMessage({
-        from: repoName,
-        to: 'manager',
-        type: 'worker-stopped',
-        subject: hasInProgress
-          ? `Worker stopped mid-work on ${taskInProgress}`
-          : `Worker stopped (idle)`,
-        body: [
-          `Worker "${repoName}" is stopping.`,
-          `State: ${state}`,
-          taskInProgress ? `Task in progress: ${taskInProgress}` : null,
-          mostRecent?.title ? `Most recent task: ${mostRecent.title}` : null,
-          lastSha ? `Last commit: ${lastSha}` : null
-        ].filter(Boolean).join('\n'),
-        priority: hasInProgress ? 'high' : 'medium',
-        actionRequired: hasInProgress
-      });
-      msg.taskId = taskInProgress;
-      msg.reason = 'graceful';
-      msg.state = state;
-      msg.taskInProgress = taskInProgress;
-      msg.lastSha = lastSha;
-      saveMessage(workspaceRoot, msg);
-    } catch (err) {
-      if (process.env.DEBUG) console.error(`[Stop] Workspace message write failed: ${err.message}`);
+    let type, subject, priority, actionRequired, state;
+    if (!inProgressTask) {
+      type = 'worker-idle';
+      state = 'idle';
+      subject = `Worker ${process.env.WOGI_REPO_NAME} idle (${queued} queued)`;
+      priority = 'medium';
+      actionRequired = queued > 0; // queued-but-not-started is worth the manager's attention
+    } else if (AWAITING_PHASES.has(phase)) {
+      type = 'worker-awaiting-approval';
+      state = 'awaiting-approval';
+      subject = `Worker ${process.env.WOGI_REPO_NAME} awaiting approval on ${taskId} (phase: ${phase})`;
+      priority = 'high';
+      actionRequired = true;
+    } else {
+      type = 'worker-stopped';
+      state = 'mid-work';
+      subject = `Worker stopped mid-work on ${taskId}`;
+      priority = 'high';
+      actionRequired = true;
     }
+
+    emit(type, {
+      subject,
+      body: [
+        `Worker "${process.env.WOGI_REPO_NAME}" stopped.`,
+        `State: ${state}`,
+        taskId ? `Task in progress: ${taskId}` : `Queued: ${queued}`,
+        phase ? `Phase: ${phase}` : null,
+        lastSha ? `Last commit: ${lastSha}` : null
+      ].filter(Boolean).join('\n'),
+      priority,
+      actionRequired,
+      extra: {
+        reason: 'graceful',
+        state,
+        taskId,
+        taskInProgress: taskId,
+        phase,
+        lastSha
+      }
+    });
   } catch (err) {
-    if (process.env.DEBUG) console.error(`[Stop] Workspace notification failed: ${err.message}`);
+    if (process.env.DEBUG) console.error(`[Stop] worker terminal emit failed: ${err.message}`);
   }
 }
 
-module.exports = { notifyWorkerStopped };
+module.exports = {
+  notifyWorkerProgress,
+  notifyWorkerTerminal,
+  isWorker,
+  AWAITING_PHASES,
+  // Back-compat alias: the old single unconditional emitter. Now routes to the
+  // typed terminal notifier (callers that want a terminal stop signal).
+  notifyWorkerStopped: notifyWorkerTerminal
+};

package/scripts/hooks/entry/claude-code/post-tool-use.js

@@ -57,6 +57,32 @@ runHook('PostToolUse', async ({ parsedInput }) => {
     }
   }
 
+  // S1 (wf-e72350bf): mirror the worker's TodoWrite decomposition to the durable
+  // sub-task ledger so the continuation gate (S2) and restart-resume (S5) have a
+  // disk-readable "work remaining" signal. Worker-mode only by default (solo
+  // sessions opt in via workspace.subtaskLedger.alsoInSolo). Fail-open.
+  if (toolName === 'TodoWrite' && !toolFailed) {
+    try {
+      const { getConfig, PATHS, safeJsonParse } = require('../../../flow-utils');
+      const cfg = (() => { try { return getConfig()?.workspace?.subtaskLedger || {}; } catch (_err) { return {}; } })();
+      const ledgerEnabled = cfg.enabled !== false;
+      const isWorker = process.env.WOGI_WORKSPACE_ROOT &&
+                       process.env.WOGI_REPO_NAME &&
+                       process.env.WOGI_REPO_NAME !== 'manager';
+      if (ledgerEnabled && (isWorker || cfg.alsoInSolo === true)) {
+        const ready = safeJsonParse(require('node:path').join(PATHS.state, 'ready.json'), { inProgress: [] });
+        const taskId = ready.inProgress?.[0]?.id || null;
+        if (taskId) {
+          const subtaskState = require('../../../../lib/workspace-subtask-state');
+          const subs = subtaskState.subtasksFromTodos(toolInput);
+          if (subs.length > 0) subtaskState.write(taskId, subs);
+        }
+      }
+    } catch (err) {
+      if (process.env.DEBUG) console.error(`[post-tool-use] subtask-ledger mirror: ${err.message}`);
+    }
+  }
+
   // Track B B3 fix (2026-04-13): mark when templates are edited, so
   // session-end and the next /wogi-start can remind to run flow bridge sync.
   // Mechanical enforcement of self-maintenance.md §1.

package/.claude/rules/README.md

@@ -1,36 +0,0 @@
-# Auto-Generated Rules
-
-This directory is auto-generated from `.workflow/state/decisions.md`.
-
-**DO NOT EDIT THESE FILES DIRECTLY.**
-
-Edit `decisions.md` instead, then run:
-```bash
-node scripts/flow-rules-sync.js
-```
-
-Or rules will auto-sync when decisions.md is updated.
-
-## How It Works
-
-- Each section in decisions.md becomes a separate rule file
-- Rules are path-scoped based on section keywords (e.g., "component" rules only load for component files)
-- Claude Code automatically loads these rules for context-aware guidance
-
-## Rule Types
-
-Rules have `alwaysApply` frontmatter that determines loading behavior:
-
-- **`alwaysApply: true`** - Always loaded (rules with: general, always, project, naming, coding, standard, convention, must, never, critical, security in title)
-- **`alwaysApply: false`** - Agent-requested: Claude decides whether to load based on description relevance to current task
-
-This saves tokens by not loading React rules when working on backend code, etc.
-
-## Files
-
-- dual-repo-architecture-2026-02-28.md
-- github-release-workflow-2026-01-30.md
-- alternative-short-name.md
-- alternative-hand-edit-ready-json-to-register-orpha.md
-
-Last synced: 2026-04-24T06:42:44.238Z

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