wogiflow 2.33.0 → 2.34.2

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
-- Run `npm test` — WogiFlow has a native-Node test suite (50+ files under `tests/`, 1800+ assertions) covering hooks, flow-io, security, session state, workspace gates, and more
-- 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/_internal/worker-tool-first-turn.md

@@ -1,82 +0,0 @@
----
-alwaysApply: false
-description: "Worker tool-first-turn contract — workspace worker mode only (WOGI_WORKSPACE_ROOT set, WOGI_REPO_NAME !== 'manager')"
-globs: "scripts/hooks/core/worker-tool-first-gate.js,.workflow/templates/worker-rules.md"
----
-
-# Worker Tool-First Turn Contract
-
-**Applies to**: workspace worker mode (`WOGI_WORKSPACE_ROOT` set + `WOGI_REPO_NAME !== 'manager'`).
-
-**Rule**: Every worker turn that follows a `UserPromptSubmit` (channel dispatch from the manager) MUST contain at least one tool call. In **strict mode** (default), the first assistant content block MUST be a tool call, not text.
-
-## Three violations enforced as one rule
-
-The Stop hook detects three distinct violations and labels all of them under the unified rule name `worker-tool-first-turn`:
-
-| Gate | Violation | Detection |
-|------|-----------|-----------|
-| **G1** | `silent-halt` | Zero `tool_use` blocks across the entire turn (pure-text response). |
-| **G4** | `text-before-tool-call` | First assistant content block is `text`, not `tool_use`. Strict mode only. |
-| **G6** | documented contract | The named rule referenced in block messages so the worker sees one coherent contract, not three independent gates. |
-
-## Why the contract exists
-
-Workers communicate with the manager via tool calls:
-- Channel dispatches (`curl` POST to the manager port)
-- File edits (`Edit`, `Write`)
-- Test runs (`Bash`)
-- Structured `## Results` payloads posted back to the manager channel
-
-A pure-text response from a worker is **invisible to the user** — the user only sees the manager terminal. Worker text disappears into the transcript with no downstream consumer. It also disqualifies the worker from the three-state end-of-turn contract (`ACTION` | `ESCALATION` | `IDLE`) documented in CLAUDE.md under "Workspace Autonomous-Mode Action-After-Completion Contract".
-
-## Allowed turn shapes (pass)
-
-- Pure action: `tool_use` → `tool_use` → end
-- Action with narration after: `tool_use` → `text` → `tool_use` → end
-- Escalation: `tool_use` (channel dispatch of `## QUESTION:`) → end
-- Reply: `tool_use` (channel dispatch of `## Results:`) → end
-- Idle (pre-user-message): zero assistant blocks — not gated since no dispatch happened
-
-## Blocked turn shapes (fail)
-
-- **G1**: `text` → end (no tool_use anywhere in turn)
-- **G4**: `text` → `tool_use` → end (strict mode: first block must be tool_use)
-
-## Configuration
-
-`.workflow/config.json → workspace.toolFirstTurnGate`:
-
-```json
-{
-  "enabled": true,
-  "strict": true
-}
-```
-
-- `enabled: false` — disables the gate entirely (silent-halt + text-first both allowed).
-- `strict: false` — G1 still enforced (zero-tool-call blocked), G4 relaxed (text-first allowed as long as a tool_use eventually fires).
-
-Default is `enabled: true, strict: true` — maximum worker discipline.
-
-## Fail-open behavior
-
-The gate fails open on:
-- Missing transcript path
-- Unreadable / malformed transcript file
-- Config read errors
-- Any unexpected exception
-
-Rationale: a silent-halt false-negative is recoverable (the worker will be retried on the next manager cycle via the dispatch-tracking overdue check). A false-positive block on every turn would make the worker unusable — unrecoverable without a code deploy.
-
-## Related gates (same epic, same integration point)
-
-- **Existing — "Gap B" (v2.20.0)**: blocks end-of-turn when queued dispatches exist but no task is in-progress. Complements this gate — Gap B runs at the queue boundary; tool-first runs at every turn.
-- **Existing — AI Worker Question Classifier (v2.21.0)**: Haiku classifier detects when a worker ends with a user-facing question. Complements this gate — question classifier is semantic; tool-first is structural.
-- **Existing — Worker Boundary Gate**: blocks `AskUserQuestion` in worker mode. Complements this gate — boundary gate blocks a specific tool; tool-first requires any tool.
-
-## Enforcement
-
-- Core logic: `scripts/hooks/core/worker-tool-first-gate.js`
-- Wired into: `scripts/hooks/entry/claude-code/stop.js` (after Gap B, before AI question classifier)
-- Template updated: `.workflow/templates/worker-rules.md` carries the contract verbatim so workers see it in every system prompt.

package/.claude/rules/alternative-execpolicy-toml-command-policy.md

@@ -1,11 +0,0 @@
----
-alwaysApply: false
-description: "Alternative: execpolicy-style TOML Bash allow/deny policy layer - Rejected: 2026-04-24"
----
-
-# Alternative: execpolicy-style TOML Bash allow/deny policy layer
-
-**Rejected**: 2026-04-24
-**Reason**: The spec framed WogiFlow as owner of Bash allow/deny wildcards. It isn't — `.claude/settings.local.json → permissions.{allow,deny,ask}` are enforced by Claude Code *before* any WogiFlow hook runs, and Claude Code already supports all three modes natively (see `.claude/rules/security/security-patterns.md` §6). WogiFlow's PreToolUse Bash gates (`git-safety-gate`, `deploy-gate`, `strike-gate`, `scope-mutation-gate`, `commit-log-gate`) are content-aware — not wildcard lists — so there is nothing for a TOML allowlist to "replace." Implementing the spec as written would duplicate Claude Code's native permission system with a strictly worse version (no UI integration, no session-scope memory, no settings-source hierarchy).
-**Chose instead**: Lean on Claude Code's native `permissions.{allow,deny,ask}` for allow/deny semantics. The only genuinely-additive piece of the D2 spec — **per-phase command overlay** (AC3) — should be re-specced as a small feature that reads phase-scoped overrides from `.workflow/config.json` and augments the existing `pre-tool-orchestrator.js`, if the need resurfaces from a real incident. Don't build it speculatively.
-**Source**: wf-ac2a8074 scope-confidence audit (user chose option A: drop the story entirely)

package/.claude/rules/alternative-hand-edit-ready-json-to-register-orpha.md

@@ -1,11 +0,0 @@
----
-alwaysApply: false
-description: "Alternative: Hand-edit ready.json to register orphaned specs - Rejected: 2026-04-15"
----
-
-# Alternative: Hand-edit ready.json to register orphaned specs
-
-**Rejected**: 2026-04-15
-**Reason**: CLAUDE.md memory-hierarchy rule forbids hand-editing `.workflow/state/` files to create tasks. Doing so bypasses routing telemetry and breaks the bypass-counter signal that surfaces actual workflow gaps.
-**Chose instead**: One-off script using `flow-utils` `getReadyData` / `saveReadyData` API. The script is self-documenting (kept in `.workflow/scratch/` for the auto-cleanup pass) and uses the same write path the runtime uses.
-**Source**: wf-a3cc5f2a session, state-sync between progress.md and ready.json after epic-episodic-memory wave.

package/.claude/rules/alternative-hook-args-exec-form.md

@@ -1,6 +0,0 @@
-# Alternative: Migrate generated hook registrations to the `args: string[]` exec form
-
-**Rejected**: 2026-05-12
-**Reason**: Claude Code 2.1.139 added an `args: string[]` field for hook entries that spawns the command directly without a shell, so path placeholders never need quoting. WogiFlow's generated hook registrations (`generateConfig()` in `scripts/hooks/adapters/claude-code.js`) already emit `command: \`node "${absolutePath}"\`` — the absolute script path is double-quoted, which already handles spaces in the project path. Switching to `args` would buy only marginal robustness (paths containing a literal `"` or shell metacharacters — vanishingly rare for real project directories) while introducing a real regression: `args` is silently ignored on Claude Code < 2.1.139, and since it *replaces* `command` rather than augmenting it, a hook entry that emits only `args` would do nothing on older Claude Code — breaking task gating, validation, routing enforcement, etc. for any user not yet on 2.1.139. WogiFlow does not currently require a minimum Claude Code version that high (`postinstall.js` version-gates individual hook *events*, but the base hook set must work on much older CC). The shell-chain commands that actually have gnarly quoting (the `&&`/`2>/dev/null`/`$(...)` one-liners) live in the **permissions allow-list**, not in hook registrations, and cannot use exec form at all (no shell = no `&&`).
-**Chose instead**: Keep `command: \`node "${path}"\``. If WogiFlow's minimum supported Claude Code version ever reaches 2.1.139, revisit — at that point `buildHookEntry()` could emit `args: ["node", scriptPath]` for the `command` transport and drop the manual quoting. Until then, the double-quoted `command` form is correct and maximally compatible.
-**Source**: wf-cb951e91 — "Respond to Claude Code v2.1.139 changelog" (AC2).

package/.claude/rules/alternative-permission-ruleset-per-phase.md

@@ -1,11 +0,0 @@
----
-alwaysApply: false
-description: "Alternative: Permission-ruleset-per-phase via WogiFlow hooks - Rejected: 2026-04-24"
----
-
-# Alternative: Permission-ruleset-per-phase via WogiFlow hooks
-
-**Rejected**: 2026-04-24
-**Reason**: Same root cause as wf-ac2a8074 (D2). `.claude/settings.json → permissions.{allow,deny,ask}` is Claude Code's permission system, enforced by Claude Code itself before any WogiFlow hook fires. Making it phase-aware would require Claude Code to be phase-aware — out of WogiFlow's scope. WogiFlow's PreToolUse gates are content-aware (`git-safety-gate`, `scope-mutation-gate`, etc.), not wildcard permission lists, so there's nothing to "phase-scope" at this layer either.
-**Chose instead**: If real per-phase restrictions surface as a need from incident data, extend `pre-tool-orchestrator.js` with phase-scoped content-aware checks (e.g., "block `rm -rf` during validating phase"). Build that narrow thing from a real incident, not speculative per-phase rulesets.
-**Source**: wf-c6c75841 scope-confidence batch audit (user chose "drop H2" as part of the 1+2+3 combination)

package/.claude/rules/alternative-short-name.md

@@ -1,12 +0,0 @@
----
-alwaysApply: false
-description: "Alternative: <short name> - Rejected: <YYYY-MM-DD>"
----
-
-# Alternative: <short name>
-
-**Rejected**: <YYYY-MM-DD>
-**Reason**: <why we said no — be specific>
-**Chose instead**: <what we did instead, and where it lives>
-**Source**: <task ID, audit, or session that produced this decision>
--->

package/.claude/rules/alternative-wogi-flow-as-mcp-client-oauth-manager.md

@@ -1,11 +0,0 @@
----
-alwaysApply: false
-description: "Alternative: WogiFlow-as-MCP-client OAuth manager - Rejected: 2026-04-24"
----
-
-# Alternative: WogiFlow-as-MCP-client OAuth manager (Cline McpHub pattern)
-
-**Rejected**: 2026-04-24
-**Reason**: WogiFlow is a workflow layer that runs *inside* a Claude Code session — it is not an MCP client. No `@modelcontextprotocol/sdk` dependency, no transport/stdio/server-connect code; existing `scripts/flow-mcp-*` scripts only *discover* capabilities Claude Code already exposes (`ToolSearch`, `ListMcpResourcesTool`). Cline's `McpHub` works because Cline owns the MCP client lifecycle. In our stack, Claude Code owns it — by the time a WogiFlow SessionStart hook fires, Claude Code has already loaded (or declined to load) its MCP servers, so "reconnect at session start" has no connection object to attach tokens to.
-**Chose instead**: Rely on Claude Code 2.1+ native MCP OAuth. If a future WogiFlow-as-standalone-agent runtime hosts its own MCP clients, revisit then with a fresh spec grounded in that runtime's lifecycle.
-**Source**: wf-8e97ac77 scope-confidence audit (user chose option C: drop the story entirely)

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/architecture/hook-three-layer.md

@@ -1,68 +0,0 @@
----
-alwaysApply: false
-description: "Three-layer hook architecture: Entry → Core → Adapter. Applies to all hooks under scripts/hooks/."
-globs: scripts/hooks/**/*.js
----
-
-# Hook Three-Layer Architecture
-
-**Rule**: Every WogiFlow hook follows a strict three-layer separation: Entry → Core → Adapter. Entry files parse CLI-harness input and dispatch to core. Core files contain all business logic and are CLI-agnostic. Adapter files translate core results into the target CLI's expected output format.
-
-## Layer contract
-
-| Layer | Location | Responsibility | Dependencies allowed |
-|-------|----------|----------------|---------------------|
-| **Entry** | `scripts/hooks/entry/<cli-name>/<hook>.js` | Parse stdin JSON, delegate to core, pass result to adapter, write adapter output. Minimal logic. | `core/`, `adapters/` |
-| **Core** | `scripts/hooks/core/<hook>.js` | All business logic: gate decisions, state reads/writes, classifications, enforcement. CLI-agnostic. | `scripts/flow-*.js`, `lib/`, each other |
-| **Adapter** | `scripts/hooks/adapters/<cli-name>.js` | Transform core's uniform return shape into the CLI's expected output format (stdout JSON, exit codes, block messages). | None (pure functions) |
-
-## What belongs in each layer
-
-**Entry layer MUST**:
-- Read stdin, parse JSON
-- Call exactly one core function (the hook's entry point)
-- Wrap the core's return with the adapter
-- Write adapter output to stdout and exit
-
-**Entry layer MUST NOT**:
-- Contain business logic (gate decisions, state enforcement, classifications)
-- Import from other `core/` modules directly (only the hook's own core)
-- Call other CLI's adapters
-- Contain more than ~100 LOC total
-
-**Core layer MUST**:
-- Own all gate logic and state mutations
-- Export pure-ish functions (I/O allowed; network not)
-- Be testable without any CLI harness
-
-**Core layer MUST NOT**:
-- Import from `entry/` or `adapters/` (those import core, not vice versa)
-- Know about stdin JSON shapes or stdout formats
-- Reference specific CLI tool names (Claude Code, Cursor, etc.)
-
-**Adapter layer MUST**:
-- Accept a uniform core-return shape as input
-- Produce CLI-specific output (JSON shape, exit codes)
-
-## Why this matters
-
-Past incidents (pre-v2.26): `pre-tool-use.js` grew to 560 LOC + 84 branches with gate logic inline in the entry file. This was the origin of `arch-001` audit finding. Same pattern plagued `session-start.js` (307 LOC inline) and `stop.js` (188 LOC inline). When business logic lives in entry files:
-- It can't be unit-tested without spawning a full process
-- It's tied to one CLI harness; cross-CLI support requires copying
-- New gates drift from the established enforcement pattern
-
-The three-layer split is enforced mechanically:
-- `flow-standards-checker.js` (standards gate) flags entry files over 120 LOC
-- `flow-standards-checker.js` flags entry files that import from multiple `core/` modules (suggests orchestration logic inline)
-- `flow-standards-checker.js` flags `core/` files that reference CLI-specific shapes (e.g., `input.tool_name` vs accepting `toolName` as a normalized param)
-
-## Enforcement
-
-Standards-gate checks (added in wf-0f2e0f16):
-1. Entry files (`scripts/hooks/entry/**/*.js`) must be ≤ 120 LOC (allows room for imports + dispatch)
-2. Entry files must import from at most 2 `core/` modules (single-entry-point principle)
-3. Core files (`scripts/hooks/core/**/*.js`) must not contain strings matching known CLI-specific identifiers (`claude-code`, `cursor`, etc.) in comments or code
-
-Gate runs during `/wogi-review` and per-commit via the standards lane of `/wogi-done`.
-
-**Exemption**: If a legitimate reason requires breaking a rule (e.g., a hook that genuinely needs to fan out to 3 core modules), document it in the entry file header and add the file to `config.standardsCheck.hookThreeLayer.exemptions`.

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

@@ -1,107 +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.
-
-### Unused Catch Variables
-
-When the catch block intentionally ignores the error, prefix with underscore: `_err`.
-
-```javascript
-// Good - _err signals "intentionally unused"
-try {
-  JSON.parse(input);
-} catch (_err) {
-  return defaultValue;
-}
-
-// Bad - looks like a bug (unused variable without underscore)
-try {
-  JSON.parse(input);
-} catch (err) {
-  return defaultValue;
-}
-```
-
-This convention is used across 100+ files in the codebase and satisfies no-unused-vars lint rules.
-
-## Default Value Operators: `||` vs `??`
-
-Use **nullish coalescing (`??`)** for defaults where the left operand could legitimately be `0`, `false`, or `""`.
-
-Use **logical OR (`||`)** only when falsy values (0, false, empty string) should genuinely fall through to the default.
-
-```javascript
-// Use ?? — timeout=0 is valid (means "no timeout"), not "use default"
-this.timeout = options.timeout ?? TIMEOUTS.HTTP_DEFAULT;
-
-// Use ?? — numeric config values where 0 is meaningful
-const retries = config.maxRetries ?? 3;
-const threshold = config.similarityThreshold ?? 0.5;
-
-// Use ?? — boolean config where false is the intended value
-const strictMode = config.enforcement?.strictMode ?? false;
-
-// Use ?? — array/object defaults guarding against null/undefined
-const items = data.inProgress ?? [];
-const settings = config.hybrid ?? {};
-
-// Use || — empty string should fall through to a display default
-const branch = status.git.branch || 'unknown';
-
-// Use || — lookup fallback where undefined means "not found"
-const name = cliNames[type] || type;
-
-// Use || — join() returns "" for empty arrays, want a fallback message
-const summary = facts.join('; ') || 'No data available';
-```
-
-**Rule of thumb**: If you are defaulting a config value, numeric parameter, boolean flag, or array/object from a potentially-null source, use `??`. If you are providing a display fallback where empty string should show a placeholder, use `||`.