Move docs/ package mirror into document-navigator plugin

Relocate the ~6k-file docs tree from the repo root into
plugins/document-navigator/docs/ so the plugin is self-contained and
portable. docs/superpowers/ (specs and plans) stays at the repo root.

Moved via cp+rm rather than git mv because directory rename() fails with
EPERM on this WSL /mnt DrvFs mount; git rename-detection pairs the
identical-content files at commit time.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

plugins/suaveplan-package-structure/.claude-plugin/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "suaveplan-package-structure",
+  "version": "1.0.0",
+  "description": "Library package structure patterns and code organization rules for Suaveplan monorepo"
+}

plugins/suaveplan-package-structure/skills/package-structure/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: package-structure
+description: Library package structure patterns, code organization rules, documentation requirements, and Storybook conventions for the Suaveplan monorepo
+---
+
+# Package Structure & Code Organization
+
+Use this skill when creating new packages, adding modules to existing packages, or organizing code within the Suaveplan monorepo. Covers architecture principles, file placement, documentation requirements, and component conventions.
+
+## Package Architecture Principles
+
+- **Universal packages** (`packages/<category>/<sub-category>/<pkg>` with no React/DOM imports) must have ZERO browser/React dependencies
+- **Browser packages** (`packages/<category>/<sub-category>/<pkg>` that imports React or DOM APIs) can depend on React, DOM APIs, and browser-specific libraries
+- **Server packages** (`packages/<category>/<sub-category>/<pkg>` that imports Node.js APIs) can depend on Node.js APIs and server-specific libraries
+
+Place utilities in the appropriate category:
+
+- CSS/Tailwind utilities (cn, clsx, tailwind-merge) belong in `@suaveplan/react-ui`
+- React hooks and components belong in browser or react packages
+- Platform-agnostic utilities belong in universal packages
+
+## Think Before Write
+
+Before creating any file:
+
+1. Consider WHERE to place it (correct package category)
+2. Check existing patterns and structure in the target package
+3. Use `tests/` for test files
+4. Use `scripts/` for utility scripts
+5. Use `claudedocs/` for Claude-generated documentation
+
+## Documentation Requirement
+
+**Every implementation file MUST have a corresponding .md file** co-located in the same directory with the same name (`MyClass.ts` -> `MyClass.md`).
+
+### Exclusions (no .md required)
+
+- `.test.ts` / `.test.tsx` -- test files
+- `.spec.ts` -- Playwright E2E files
+- `.types.ts` -- types files within a component directory (shared type files in `types/` DO need docs)
+- `.stories.tsx` -- Storybook stories
+- `constants/index.ts` -- simple constant exports
+
+### Content Requirements
+
+- **Minimum 200 words** of content (excluding code blocks)
+- **Both simple AND advanced examples** are mandatory in every doc
+- **Code examples must compile** -- use real types and imports from the package
+- **No marketing language** -- state capabilities honestly
+- **No placeholder text** -- every section must contain real content
+- **Update when code changes** -- documentation must stay in sync
+
+### Template
+
+Use standard template from `.claude/templates/module-docs.md`. Required sections:
+
+1. **Purpose** -- What the module does and why it exists (minimum 2 sentences)
+2. **Features** -- Bullet list of capabilities
+3. **Usage: Basic Example** -- Simple import and usage (the "happy path")
+4. **Usage: Advanced Example** -- Composition, configuration, edge cases
+5. **API Reference** -- Every public export documented with parameters and return types
+6. **Implementation Notes** -- Design decisions, performance considerations, known limitations
+
+### Example Structure
+
+````markdown
+# Module Name
+
+## Purpose
+Brief description of what this module does and why it exists.
+
+## Features
+- Feature 1
+- Feature 2
+
+## Usage
+
+### Simple Example
+```typescript
+import { MyClass } from '@suaveplan/package';
+const instance = new MyClass();
+```
+
+### Advanced Example
+```typescript
+import { MyClass } from '@suaveplan/package';
+const instance = new MyClass<CustomType>({
+  onEvent: (data) => transform(data),
+  strategy: 'optimized',
+});
+```
+
+## API Reference
+
+### MyClass
+
+#### constructor(options?: Options)
+
+...
+
+## Implementation Notes
+
+- Design decisions
+- Performance considerations
+````
+
+### Documentation Hierarchy
+
+Three-level linking structure:
+
+```text
+packages/<category>/<sub-category>/<package>/
+  README.md                              # Level 1: Package overview
+  src/
+    <category>/
+      README.md                          # Level 2: Category index
+      <feature>/
+        <feature>.md                     # Level 3: Module documentation
+```
+
+- Root `README.md` -> Category `README.md` -> Feature `.md`
+- Each level links to the next, creating discoverable documentation
+
+## Library Package Structure Pattern
+
+For library packages (especially in `packages/*/*/*`):
+
+### Category Organization
+
+- Group related features into category directories (e.g., `asymmetric/`, `symmetric/`, `core/`)
+- Each category directory MUST have a `README.md` index linking to all feature modules
+- Feature modules go in subdirectories within categories
+
+### Feature Module Pattern (four files per feature)
+
+```text
+category/
+  README.md                    # Category index
+  feature-name/
+    feature-name.ts            # Implementation
+    feature-name.test.ts       # Tests
+    feature-name.types.ts      # Type definitions
+    feature-name.md            # Documentation
+```
+
+### Special Directories
+
+- `types/`: Shared types, flat structure (`.ts` + `.md` only, no tests)
+- `utils/`: Utilities, flat structure (`.ts` + `.test.ts` + `.md`)
+- `constants/`: Just `index.ts` file (no tests or docs required)
+
+### Subpath Exports (for tree-shaking)
+
+Add granular exports in `package.json` for each feature module:
+
+```json
+{
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js"
+    },
+    "./category/feature/feature": {
+      "types": "./dist/category/feature/feature.d.ts",
+      "import": "./dist/category/feature/feature.js"
+    }
+  }
+}
+```
+
+### Full Example (from @suaveplan/crypto-keys)
+
+```text
+packages/security-stack/crypto/crypto-keys/
+  README.md                                    # Package overview
+  src/
+    factory/
+      README.md                                # Category index
+      factory.ts
+      factory.test.ts
+      factory.md
+    signer/
+      signer.ts
+      signer.test.ts
+      signer.types.ts
+      signer.md
+    hashers/
+      README.md
+      raw/
+      domain/
+      merkle/
+    codecs/
+      README.md
+      cbor/
+      tlv/
+      recursive-ed25519/
+    types/                                     # Shared types (flat)
+      codec.ts
+      codec.md
+      hasher.ts
+      hasher.md
+      chain-level.ts
+      chain-level.md
+    utils/                                     # Utilities (flat)
+      utils.ts
+      utils.test.ts
+      utils.md
+    constants/                                 # Constants (no tests/docs)
+      index.ts
+```
+
+## Storybook Stories Required for Components
+
+Every React component MUST have a corresponding `.stories.tsx` file with:
+
+- A default story
+- A playground story with controls
+- Key variant stories
+
+Storybook is the primary visual documentation for UI components. Components without stories are considered incomplete.
+
+## Naming Conventions
+
+- Follow language/framework standards (camelCase for JS/TS)
+- Files, functions, variables must clearly describe purpose
+- No mixed naming conventions within same project
+
+## Clean Workspace
+
+- Remove temporary files when done
+- Delete build artifacts and logs
+- No artifact pollution (debug.sh, test.log, temp/)