wogiflow 2.2.0 → 2.3.0

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

package/.claude/rules/_internal/github-releases.md

@@ -1,71 +0,0 @@
----
-description: "GitHub release workflow - prevents race conditions in npm publish"
-alwaysApply: false
-globs: package.json
----
-
-# GitHub Release Workflow
-
-**Source**: Repeated failures (10+ times) in npm publish automation
-**Priority**: Critical - prevents wasted releases and broken npm versions
-
-## Problem
-
-Running `git push` followed immediately by `gh release create` causes a race condition. The release tag gets created on the remote's HEAD before the push fully propagates, pointing to an old commit.
-
-## Pre-Release Quality Gate (MANDATORY)
-
-Before ANY release, verify the codebase is in a releasable state:
-
-1. **Check outstanding findings**: Read `.workflow/state/last-review.json` — if unresolved critical/high findings exist, STOP and fix them first
-2. **Run lint** (if configured): `npm run lint`
-3. **Run typecheck** (if configured): `npm run typecheck`
-4. **Verify no uncommitted changes**: `git status` should be clean
-
-The `preRelease` and `outstandingFindings` quality gates in `flow-done.js` enforce this automatically for `release` type tasks. For manual releases, check these yourself.
-
-## Correct Procedure
-
-```bash
-# 0. Verify codebase is releasable (pre-release gate)
-# (automated by flow-done.js for release-type tasks)
-
-# 1. Push commits first
-git push origin master
-
-# 2. Create tag LOCALLY on the correct commit
-git tag vX.Y.Z HEAD
-
-# 3. Push the tag explicitly
-git push origin vX.Y.Z
-
-# 4. THEN create the release (it will use the existing tag)
-gh release create vX.Y.Z --title "vX.Y.Z" --notes "..."
-```
-
-## Never Do This
-
-```bash
-# BAD - race condition, tag may point to wrong commit
-git push origin master && gh release create vX.Y.Z ...
-```
-
-## Recovery Procedure
-
-If a release fails with wrong version:
-
-1. Delete the bad release: `gh release delete vX.Y.Z --yes`
-2. Delete the bad remote tag: `git push origin --delete vX.Y.Z`
-3. Delete local tag if exists: `git tag -d vX.Y.Z`
-4. Follow the correct procedure above
-
-## Verification
-
-Before creating the release, verify:
-```bash
-git show vX.Y.Z --quiet --format="%H"  # Should match HEAD
-git show vX.Y.Z:package.json | grep version  # Should show X.Y.Z
-```
-
----
-Last updated: 2026-01-30

package/.claude/rules/_internal/model-management.md

@@ -1,35 +0,0 @@
----
-globs: scripts/flow-model*.js
-alwaysApply: false
-description: "Model management architecture - two separate systems for different purposes"
----
-
-# Model Management Architecture
-
-**Context**: Phase 1 introduced model registry and stats system alongside existing model-adapter.
-
-## Two Model Systems
-
-### 1. flow-model-adapter.js - Prompt Adaptation
-
-- `getCurrentModel()` returns normalized model name (string)
-- Focus: Per-model prompt adjustments, learning, and corrections
-- Imports: Used by flow-knowledge-router.js
-
-### 2. flow-models.js - Registry and Stats
-
-- `getCurrentModel()` returns `{name, info, source}` object
-- Focus: Model listing, routing recommendations, cost tracking
-- Standalone CLI commands: `flow models [subcommand]`
-
-## Design Decision
-
-**Keep them separate** because:
-- Different return types serve different consumers
-- Adapter system needs just the name for pattern matching
-- Registry system needs full model metadata for display/routing
-- Merging would create unnecessary coupling
-
-## Future Consideration
-
-Could extract shared model detection logic into a common utility if they drift apart, but avoid premature abstraction.

package/.claude/rules/_internal/self-maintenance.md

@@ -1,87 +0,0 @@
----
-description: "Patterns for modifying WogiFlow itself (scripts, templates, config)"
-alwaysApply: false
-globs: "scripts/**,*.workflow/**,.claude/**,templates/**,agents/**,lib/**"
----
-
-# WogiFlow Self-Maintenance Patterns
-
-When modifying WogiFlow's own code (scripts/, templates/, config, hooks), follow these patterns.
-
-## 1. Template-First Changes
-
-CLAUDE.md is **generated**, not hand-edited. Changes must go through the template system:
-
-```
-.workflow/templates/claude-md.hbs       # Main template
-.workflow/templates/partials/*.hbs      # Partial templates
-```
-
-After editing templates, regenerate:
-```bash
-node scripts/flow-bridge.js sync claude-code
-```
-
-**Never edit CLAUDE.md directly** - changes will be overwritten on next sync.
-
-## 2. Three-Layer Hook Architecture
-
-All hooks follow: Entry → Core → Adapter
-
-```
-scripts/hooks/entry/claude-code/<name>.js  # CLI-specific entry point
-scripts/hooks/core/<name>.js               # CLI-agnostic logic
-scripts/hooks/adapters/claude-code.js      # Transform results
-```
-
-When adding/modifying hooks:
-- Logic goes in `core/` (not entry)
-- Entry files only parse input and call core
-- Register hook in `.claude/settings.local.json`
-- Add config toggle in `.workflow/config.json` under `hooks.rules`
-
-## 3. Config Changes Need Documentation
-
-When adding config keys:
-- Use `_comment_<keyName>` for inline documentation of non-obvious settings
-- Update config.schema.json if it exists
-- Ensure `lib/installer.js` handles the new key for fresh installs
-
-## 4. State File Templates
-
-For files in `.workflow/state/` that target projects need:
-- Create both the file AND a `.template` version
-- Templates go in `.workflow/state/<name>.template` (for init/onboard)
-- Also add to `templates/` directory (for npm distribution)
-
-## 5. Slash Commands Are Flat Files
-
-Slash commands in `.claude/commands/` must be flat `.md` files:
-```
-.claude/commands/wogi-start.md     ← Correct (flat file)
-.claude/commands/wogi-start/       ← Wrong (directory)
-```
-
-## 6. Two Agent Directories
-
-| Directory | Purpose | Used By |
-|-----------|---------|---------|
-| `agents/` | 11 persona files | Health checks, CLI |
-| `.workflow/agents/` | Review checklists | wogi-review |
-
-Don't confuse them. `agents/security.md` (persona) is different from `.workflow/agents/security.md` (OWASP checklist).
-
-## 7. Regression Prevention
-
-When modifying flow-*.js scripts:
-- Run `node --check scripts/<file>.js` after edits
-- WogiFlow has no test suite - syntax checking is the safety net
-- Check for circular dependencies when moving shared functions
-
-## 8. Feature Refactoring Cleanup
-
-When renaming/replacing a feature, follow the full checklist in `.claude/rules/architecture/feature-refactoring-cleanup.md`. Key steps:
-- Remove old script files
-- Update config keys
-- Update documentation references
-- Search all `.md` files for old name

package/.claude/rules/architecture/component-reuse.md

@@ -1,38 +0,0 @@
----
-globs: src/components/**/*
-alwaysApply: false
-description: "Component reuse policy - always check app-map.md before creating components"
----
-
-# Component Reuse Policy
-
-**Rule**: Always check `app-map.md` before creating any component.
-
-## Priority Order
-
-1. **Use existing** - Check if component already exists in app-map
-2. **Add variant** - Extend existing component with a new variant
-3. **Extend** - Create a wrapper/HOC around existing component
-4. **Create new** - Only as last resort
-
-## Before Creating Components
-
-```bash
-# Check app-map first
-cat .workflow/state/app-map.md | grep -i "button"
-
-# Or search codebase
-grep -r "Button" src/components/
-```
-
-## Variant vs New Component
-
-Prefer variants when:
-- Same base functionality, different appearance
-- Same HTML structure, different styling
-- Same component, different size/color/state
-
-Create new component when:
-- Fundamentally different functionality
-- Different DOM structure
-- Different state management

package/.claude/rules/code-style/naming-conventions.md

@@ -1,52 +0,0 @@
----
-alwaysApply: true
-description: "Naming conventions for files and code variants"
-globs: "**/*.{js,ts,jsx,tsx,mjs,cjs}"
----
-
-# Naming Conventions
-
-## File Names
-
-Use **kebab-case** for all file names in this project.
-
-Examples:
-- `flow-health.js` (correct)
-- `flowHealth.js` (incorrect)
-- `flow_health.js` (incorrect)
-
-## Variant Names (UI Projects Only)
-
-When working on projects with UI components, use consistent variant names:
-
-| Category | Values |
-|----------|--------|
-| Size | `sm`, `md`, `lg`, `xl` |
-| Intent | `primary`, `secondary`, `danger`, `success`, `warning` |
-| State | `default`, `hover`, `active`, `disabled` |
-
-Skip this section for backend-only or library projects (no UI components).
-
-## Catch Block Variables
-
-Use `err` for all catch blocks in this codebase.
-
-**Avoid**: `e`, `error`, `ex`, `exception` - these cause confusion with loop variables.
-
-```javascript
-// Good
-try {
-  doSomething();
-} catch (err) {
-  console.error(err.message);
-}
-
-// Bad - 'e' conflicts with common iterator variables
-try {
-  items.map(e => e.value);  // 'e' used as iterator
-} catch (e) {
-  console.error(e.message);  // Easy to confuse with iterator 'e'
-}
-```
-
-**Reason**: Standardizing on `err` prevents mix-ups when `.map(e => ...)` is used nearby.

package/.claude/rules/operations/git-workflows.md

@@ -1,92 +0,0 @@
----
-alwaysApply: true
-description: "Git workflow rules for merge conflicts, conventional commits, and branch management"
----
-
-# Git Workflow Rules
-
-## Merge Conflict Resolution
-
-When encountering merge conflicts:
-
-1. **Understand both sides** before resolving. Read the full context of both changes.
-2. **Prefer the newer implementation** when both sides modify the same logic, unless the older version has test coverage the newer lacks.
-3. **Never silently discard changes** — if unsure, ask the user which side to keep.
-4. **After resolving**: Run lint and typecheck on resolved files before committing.
-5. **Conflict markers**: If you see `<<<<<<<`, `=======`, `>>>>>>>` in any file, resolve them before any other work.
-
-```bash
-# Check for unresolved conflicts
-git diff --check
-
-# After resolving
-git add <resolved-files>
-git commit -m "fix: resolve merge conflicts in <description>"
-```
-
-## Conventional Commit Format
-
-All commits MUST use conventional commit format:
-
-```
-<type>(<scope>): <description>
-
-[optional body]
-
-[optional footer]
-```
-
-### Types
-
-| Type | When to use |
-|------|------------|
-| `feat` | New feature or capability |
-| `fix` | Bug fix |
-| `docs` | Documentation only |
-| `style` | Formatting, whitespace (no logic change) |
-| `refactor` | Code change that neither fixes a bug nor adds a feature |
-| `perf` | Performance improvement |
-| `test` | Adding or updating tests |
-| `chore` | Build process, tooling, dependencies |
-
-### Examples
-
-```
-feat(hooks): add InstructionsLoaded hook for rule conflict detection
-fix(routing): clear routing flag when user invokes /wogi-* commands
-docs(readme): update installation instructions for v1.8
-refactor(bridge): extract hash comparison to shared utility
-chore(deps): bump eslint to v9.x
-```
-
-### Scope
-
-Use the module or feature area: `hooks`, `bridge`, `routing`, `skills`, `plugins`, `config`, `cli`, `docs`.
-
-## Pre-Commit Review
-
-Before committing, always:
-1. Run `git diff --staged` to review what you're about to commit
-2. Verify no secrets, credentials, or `.env` files are staged
-3. Verify no debug/console.log statements left in production code
-4. Run validation (lint, typecheck) on changed files
-
-## Stash Usage
-
-Use `git stash` when:
-- Switching context to a different task mid-work
-- Pulling changes that might conflict with local work
-- Testing something on a clean working tree
-
-```bash
-git stash push -m "WIP: description of work"  # Save with message
-git stash pop                                   # Restore and remove
-git stash list                                  # See all stashes
-```
-
-## Branch Naming
-
-When creating branches (outside worktrees):
-- Feature: `feat/<short-description>`
-- Bugfix: `fix/<short-description>`
-- WogiFlow worktrees use `wogi-task-<taskId>` automatically

package/.claude/rules/operations/scratch-directory.md

@@ -1,54 +0,0 @@
----
-alwaysApply: true
-description: "Temp files, prompts, instructions, and scratch content must go in .workflow/scratch/"
----
-
-# Scratch Directory for Temporary Files
-
-## Rule
-
-When creating temporary, scratch, or ephemeral files — such as prompts for other projects, instructions, notes, drafts, exported configs, or any content that is NOT a permanent part of the codebase — **always write them to `.workflow/scratch/`**.
-
-## Why
-
-Without this rule, Claude creates .md files, .txt files, and other scratch content in random locations (project root, src/, docs/, etc.). This pollutes the project with files that:
-- Have no designated location, so users don't know where to find them
-- Don't get cleaned up, accumulating over time
-- May accidentally get committed to version control
-- Make `git status` noisy with untracked files
-
-## How
-
-```javascript
-// Use PATHS.scratch for temp file locations
-const { PATHS } = require('./flow-paths');
-const outputPath = path.join(PATHS.scratch, 'my-temp-file.md');
-```
-
-Or in natural language: "Save this to `.workflow/scratch/filename.md`"
-
-## Auto-Cleanup
-
-The `.workflow/scratch/` directory is **automatically cleaned at session end** by the session-end hook. Files in this directory are ephemeral — they survive the current session but are removed when the session ends.
-
-If a file needs to persist beyond a session, it belongs somewhere else:
-- Specs → `.workflow/specs/`
-- Changes → `.workflow/changes/`
-- Documentation → project docs directory
-- Configuration → `.workflow/` root
-
-## What Goes in Scratch
-
-- Prompts or instructions generated for other projects
-- Draft content being reviewed before placement
-- Temporary analysis output
-- Export/import staging files
-- Any file the user explicitly asks to "save somewhere" without specifying a location
-
-## What Does NOT Go in Scratch
-
-- Task specs (use `.workflow/specs/` or `.workflow/changes/`)
-- Configuration files (use `.workflow/`)
-- Source code (use the project's source directories)
-- Documentation (use the project's docs directory)
-- State files (use `.workflow/state/`)