wogiflow 2.33.0 → 2.34.2

package/.claude/rules/dual-repo-architecture-2026-02-28.md

@@ -1,18 +0,0 @@
----
-alwaysApply: false
-description: "Dual-Repo Architecture (2026-02-28) - Source: User directive — formalize dual-repo management for wogi-flow + wogiflow-cloud"
----
-
-# Dual-Repo Architecture (2026-02-28)
-
-**Source**: User directive — formalize dual-repo management for wogi-flow + wogiflow-cloud
-**Rule**: Two repos, independent versions, mutual version awareness. OSS (`wogi-flow` / npm `wogiflow`) and Cloud (`wogiflow-cloud` / `@wogiflow/teams`) are separate packages with separate release cycles.
-
-**Key constraints:**
-1. **No teams code in the free repo** — all team logic lives in `wogiflow-cloud`. The free repo provides extension points only.
-2. **Independent semver** — each repo versions independently. The client declares compatibility via peerDependencies (`wogiflow >= X.Y.Z`).
-3. **Cross-repo version file** — each repo maintains `.workflow/state/partner-versions.json` recording the other's last-known version. Updated on every release.
-4. **OSS releases first** — if cloud needs a new OSS feature/export, release OSS first, then cloud.
-5. **Interface contract** — exported functions, hook interfaces, state file formats, and config keys used by cloud are documented in `.claude/rules/_internal/dual-repo-management.md`. Changes to these require updating the cloud client.
-
-**Verification**: Before releasing either repo, check `partner-versions.json` and grep the other repo for consumers of changed interfaces.

package/.claude/rules/github-release-workflow-2026-01-30.md

@@ -1,16 +0,0 @@
----
-alwaysApply: false
-description: "GitHub Release Workflow (2026-01-30) - Source: Repeated failures (10+ times) in npm publish automation"
----
-
-# GitHub Release Workflow (2026-01-30)
-
-**Source**: Repeated failures (10+ times) in npm publish automation
-**Details**: See `.claude/rules/_internal/github-releases.md` for full procedure.
-
-**Quick reference**:
-1. `git push origin master`
-2. `git tag vX.Y.Z HEAD`
-3. `git push origin vX.Y.Z`
-4. `gh release create vX.Y.Z --title "vX.Y.Z" --notes "..."`
-5. `npm publish`

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

@@ -1,92 +0,0 @@
----
-alwaysApply: false
-description: "Git workflow rules for merge conflicts, conventional commits, and branch management. Load when committing, resolving conflicts, or managing branches."
----
-
-# 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: false
-description: "Temp files, prompts, instructions, and scratch content must go in .workflow/scratch/. Load when creating new files, drafts, or exported content."
----
-
-# 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/`)

package/.claude/skills/figma-analyzer/knowledge/learnings.md

@@ -1,11 +0,0 @@
-# Figma Analyzer Learnings
-
-Learnings captured from using the Figma Analyzer skill.
-
----
-
-## Patterns Learned
-
-<!-- Learnings will be captured automatically during skill usage -->
-
----

package/.workflow/specs/architecture.md.template

@@ -1,24 +0,0 @@
-# Architecture
-
-## Pattern
-
-<!-- Detected during onboarding -->
-<!-- Examples: MVC, Clean Architecture, DDD, Microservices, Monolith -->
-
-## Structure
-
-<!-- Project structure overview -->
-<!-- Key directories and their purposes -->
-
-## Key Decisions
-
-<!-- Architecture decisions made for this project -->
-<!-- Trade-offs and rationale -->
-
-## Dependencies
-
-<!-- Major dependencies and their purposes -->
-
----
-
-*This file is auto-populated during `flow onboard`. Update manually as architecture evolves.*

package/.workflow/specs/stack.md.template

@@ -1,33 +0,0 @@
-# Tech Stack
-
-## Framework
-
-<!-- Primary framework (e.g., Next.js, NestJS, FastAPI) -->
-
-## Language
-
-<!-- Primary language (e.g., TypeScript, Python, Go) -->
-
-## Database
-
-<!-- Database system if applicable (e.g., PostgreSQL, MongoDB) -->
-
-## Package Manager
-
-<!-- npm, yarn, pnpm, pip, etc. -->
-
-## Build Tools
-
-<!-- Build and bundling tools (e.g., Vite, Webpack, esbuild) -->
-
-## Testing
-
-<!-- Test frameworks (e.g., Jest, Vitest, pytest) -->
-
-## Other Tools
-
-<!-- Linters, formatters, CI/CD tools -->
-
----
-
-*This file is auto-populated during `flow onboard`. Update manually as stack evolves.*

package/.workflow/specs/testing.md.template

@@ -1,36 +0,0 @@
-# Testing
-
-## Test Framework
-
-<!-- Primary test framework (e.g., Jest, Vitest, pytest) -->
-
-## Test Commands
-
-```bash
-# Run all tests
-npm test
-
-# Run tests in watch mode
-npm run test:watch
-
-# Run specific test file
-npm test -- path/to/test.ts
-```
-
-## Test Structure
-
-<!-- Where tests are located -->
-<!-- Naming conventions -->
-
-## Coverage
-
-<!-- Coverage requirements if any -->
-<!-- Coverage commands -->
-
-## E2E Testing
-
-<!-- E2E framework if used (e.g., Playwright, Cypress) -->
-
----
-
-*This file is auto-populated during `flow onboard`. Update manually as testing strategy evolves.*