feat: implement GTK Storybook functionality

.cursor/rules/app-architecture.mdc

@@ -1,6 +1,6 @@
 ---
 description: Architecture standards for end-user applications
-globs: apps/**/*.ts, apps/**/*.tsx
+globs: apps/**/*.ts
 alwaysApply: false
 ---
 # Application Architecture

.cursor/rules/blueprint-templates.mdc

@@ -0,0 +1,118 @@
+---
+description: Guidelines for Blueprint UI templates
+globs: **/*.blp
+alwaysApply: false
+---
+
+> See also: [@gobject-patterns](mdc:.cursor/rules/gobject-patterns.mdc)
+
+# Blueprint Templates (TL;DR)
+
+**Goal:** Declarative UI in `.blp`; logic in TypeScript. Bind data, don’t hardcode.
+
+## Basics
+- Use Blueprint for all GTK UI; follow GNOME HIG.
+- Keep structure declarative; avoid programmatic widget construction.
+- Namespaces: `using Gtk 4.0; using Adw 1;` etc.
+- Prefix template names with `$` and extend proper base classes (`Adw.Window`, `Adw.Bin`, …).
+
+## Binding (default choice)
+- `bind template.prop` for one-way display.
+- `bind template.prop bidirectional` for editable fields.
+- Prefer expressions over ad-hoc callbacks for simple transforms.
+- Avoid magic constants; bind instead.
+
+```blp
+template $MyWidget : Gtk.Box {
+  Label title { label: bind template.title; visible: bind template.title as <bool>; }
+  Entry  edit  { text: bind template.title bidirectional; }
+}
+```
+
+## Signals (wire in .blp, implement in TS)
+
+* Connect in `.blp`: `clicked => $_on_action();`
+* Implement in class; annotate with `@Gtk.Template.Callback()` when needed.
+* Use consistent `_onXxx()` naming.
+
+```blp
+Button save { action-name: "app.save"; clicked => $_on_save(); }
+```
+
+```ts
+_on_save() { this.emit('save-requested'); }
+```
+
+## TypeScript Registration (minimal pattern)
+
+```ts
+import GObject from '@girs/gobject-2.0';
+import Gtk from '@girs/gtk-4.0';
+import Template from './my-widget.blp';
+
+export class MyWidget extends Gtk.Box {
+  static {
+    GObject.registerClass({
+      GTypeName: 'MyWidget',
+      Template,
+      InternalChildren: ['title', 'save'],
+      Properties: {
+        title: GObject.ParamSpec.string('title','Title','', GObject.ParamFlags.READWRITE,''),
+      },
+    }, this);
+  }
+  declare _title: Gtk.Label;
+  declare _save: Gtk.Button;
+}
+```
+
+## Actions, Menus & State
+
+* Prefer `GAction`/`action-name` over manual `clicked` where possible.
+* Bind action targets to template state.
+* Use menu models via `MenuButton.menu-model`.
+
+```blp
+Button { action-name: "app.export"; action-target: bind template.doc_id; }
+MenuButton { icon-name: "open-menu-symbolic"; menu-model: template.menu; }
+```
+
+## Conditional UI
+
+* Toggle with boolean binds; compute labels inline.
+
+```blp
+Label err { label: bind template.error; visible: bind template.has_error; styles: ["error"]; }
+Button submit { sensitive: bind template.form_valid; label: bind template.loading ? "Loading…" : "Submit"; }
+```
+
+## Layout (pragmatic defaults)
+
+* Prefer shallow hierarchies; use spacing/margins instead of nested boxes.
+* Use `hexpand/halign/valign` intentionally for responsiveness.
+
+```blp
+Box root {
+  orientation: vertical; spacing: 12; margin-top: 24; margin-bottom: 24; margin-start: 24; margin-end: 24;
+  Box header {
+    orientation: horizontal; spacing: 6;
+    Label title { label: bind template.title; hexpand: true; xalign: 0; styles: ["title-1"]; }
+    Button close { icon-name: "window-close-symbolic"; clicked => $_on_close(); }
+  }
+}
+```
+
+## Accessibility (must-haves)
+
+* Meaningful labels/`accessible-name` for interactives.
+* Keyboard navigation preserved; avoid focus traps.
+* Tooltips only for non-obvious controls.
+
+## Best Practices (checklist)
+
+* ✅ Bind > hardcode; actions > ad-hoc handlers.
+* ✅ Split complex UIs into multiple templates; keep names meaningful.
+* ✅ Use `InternalChildren` only for elements you must touch in code.
+* ✅ Keep margins/spacing consistent; prefer Adwaita styles.
+* ❌ No deep container nesting; no business logic in `.blp`.
+* ❌ Don’t connect signals in code when `.blp` can do it.

.cursor/rules/comprehensive-documentation-creation.mdc

@@ -0,0 +1,98 @@
+---
+description: Comprehensive documentation creation expert for clear, accurate, and user-focused documentation across all project types and technologies.
+alwaysApply: false
+---
+# Comprehensive Documentation Creation Expert
+
+You are an expert technical writer creating clear, accurate, and user-focused documentation across all project types.
+
+## Core Principles
+
+- **Clarity**: Write for your audience's technical level using clear, concise language
+- **Accuracy**: Test all code examples and verify technical details before publishing
+- **Consistency**: Maintain uniform tone, terminology, and formatting throughout
+- **User-Centered**: Focus on what users need to accomplish, not system capabilities
+
+## Documentation Types
+
+### User Documentation
+- Step-by-step instructions with action-oriented titles ("How To Deploy Application")
+- Prerequisites, expected results, and troubleshooting for each guide
+- Convert technical information to user-friendly language
+- Reference UI elements as users see them
+
+### Technical Documentation
+- Code documentation focusing on why, not what
+- API documentation with usage examples and parameter descriptions
+- Project documentation with architecture diagrams and decision logs
+- Installation, configuration, and deployment instructions
+
+### Code Standards by Language
+- **Python**: Google-style docstrings for functions, methods, classes
+- **TypeScript/JavaScript**: JSDoc comments for functions, classes, complex types
+- **Solidity**: NatSpec comments for smart contracts
+- Keep inline comments concise and meaningful
+
+## Document Structure
+
+**Standard Format:**
+1. Clear, descriptive title
+2. Brief introduction (1-3 sentences)
+3. Prerequisites
+4. Main content with logical headings
+5. Working examples
+6. Troubleshooting
+7. Related information
+
+**Organization:**
+- Logical hierarchy with appropriate headings
+- Numbered lists for sequential steps
+- Bullet points for non-sequential information
+- Cross-references to related sections
+
+## Writing Standards
+
+- Use active voice and grammatically correct English
+- Define technical jargon when necessary
+- Include code blocks with syntax highlighting
+- Add diagrams/screenshots for complex concepts
+- Ensure proper markdown formatting
+
+## Specialized Guidelines
+
+### API Documentation
+- Document all endpoints with request/response examples
+- Include parameters, headers, error responses
+- Cover authentication and rate limiting
+
+### Project Documentation
+- Up-to-date README with setup and usage examples
+- Document project structure and architectural decisions
+- Include contribution guidelines and dependencies
+
+## Quality Assurance
+
+- Test all procedures and code examples
+- Verify links and references work correctly
+- Get user feedback and incorporate improvements
+- Update documentation with feature changes
+- Use version control and collaborative review processes
+
+## Content Conversion
+
+When converting technical specs to user documentation:
+1. Identify user-facing functionality
+2. Determine target audience technical level
+3. Extract main user actions
+4. Translate technical terms appropriately
+5. Organize in logical sequence
+6. Add expected outcomes
+7. Include troubleshooting
+
+## Output Formats
+
+- **Markdown**: Standard syntax with proper front matter
+- **Static Sites**: Optimized navigation, search, mobile accessibility
+- **Interactive**: Runnable examples, tutorials, user feedback mechanisms
+
+Remember: Great documentation helps people accomplish their goals efficiently and confidently.

.cursor/rules/excalibur-packages.mdc

@@ -1,6 +1,6 @@
 ---
 description: Guidelines for Excalibur packages (engine-excalibur, data-excalibur)
-globs: packages/*-excalibur/**/*.ts, packages/excalibur*/**/*.ts
+globs: packages/*-excalibur/**/*.ts,packages/excalibur-*/**/*.ts
 alwaysApply: false
 ---
 # Excalibur Packages

.cursor/rules/general-guidelines.mdc

@@ -1,7 +1,7 @@
 ---
-description: General guidelines for the project
-globs: **/*
-alwaysApply: false
+description: 
+globs: 
+alwaysApply: true
 ---
 # General Guidelines
 

.cursor/rules/git-commit-best-practices.mdc

@@ -0,0 +1,50 @@
+---
+description: Enforces consistent, frequent, and meaningful git commits following conventional commit standards. Automatically analyzes recent commit history to maintain project-specific patterns and ensures atomic, review-friendly commits during development work.
+globs: 
+alwaysApply: false
+---
+You are a meticulous developer who commits code frequently with clear, atomic commits following conventional commit standards.
+
+## Core Philosophy for AI Development
+- **Regular Commits for Large Tasks**: Break down complex changes into meaningful, logical commits
+- **Working Code Only**: Never commit broken or non-functional code - always validate before committing
+- **Continuous Validation**: Use yarn commands regularly to ensure code quality and functionality
+
+## Validation Strategy
+Before every commit, validate your code using the available yarn commands:
+
+**For regular commits (recommended):**
+- `yarn build` - Build all packages to catch compilation errors
+- `yarn check` - Run type checking across all packages
+- `yarn format` - Ensure code formatting consistency with Prettier
+
+**For major changes only:**
+- `yarn check` - ⚠️ **WARNING**: This runs type checking across ALL packages and can be slow. Only use after larger changes.
+
+**Individual package validation:**
+- `yarn workspace @pixelrpg/[package-name] run check` - Type check specific package
+- `yarn workspace @pixelrpg/[package-name] run build` - Build specific package
+
+Always fix all errors and warnings before proceeding with the commit
+
+## Commit Practices for AI Agents
+- **Atomic Changes**: Each commit represents one logical change or feature addition
+- **Conventional Format**: Use `<type>[scope]: <description>` format (feat, fix, docs, refactor, test, chore, etc.)
+- **Regular Progress Commits**: For larger tasks, commit at logical milestones, not just at completion
+- **Self-Contained**: Each commit should leave the codebase in a working state
+
+## Consistency Strategy
+Before committing:
+- **Analyze Recent History**: Check `git log --oneline -10 | cat` to match existing commit patterns
+- **Follow Project Style**: Use the same commit types and scoping patterns already established
+- **Preserve Team Patterns**: Adapt to any project-specific conventions visible in git history
+
+## Quality Standards
+- Use imperative mood in subject lines ("Add feature" not "Added feature")
+- Keep subject lines under 50 characters
+- Include scope when applicable (component, module, file area)
+- Ensure commits are review-friendly and tell a coherent development story
+- Match the established commit style of the project
+
+## Key Principle for AI Agents
+**Always ensure the codebase remains functional after each commit.** Use the [yarn workspace commands](mdc:.cursor/rules/package-management.mdc) to validate your changes before committing. This maintains a clean development history and makes debugging easier.

.cursor/rules/gjs-packages.mdc

@@ -1,6 +1,6 @@
 ---
 description: Guidelines for GJS packages (engine-gjs, data-gjs, message-channel-gjs)
-globs: packages/*-gjs/**/*.ts, apps/maker-gjs/**/*.ts
+globs: packages/*-gjs/**/*.ts,apps/*-gjs/**/*.ts
 alwaysApply: false
 ---
 # GJS Packages
@@ -20,13 +20,22 @@ GJS packages (`*-gjs`) implement core interfaces for the GNOME JavaScript (GJS)
 - Handle GJS-specific memory management concerns
 - Use GTK modern patterns (like composite templates)
 - Properly integrate with GObject-introspection
+- Prefer GObject-oriented and UI-first approach for cleaner, more declarative code
+
+## GObject Properties and Signals
+- Use GObject properties instead of regular class properties for better UI integration
+- Implement property bindings in UI templates to reduce manual widget updates
+- Leverage GObject signals for class-to-class communication
+- Design components to emit signals rather than accept callbacks
+- Use template callbacks to handle signals from child components
 
 ## UI Components
 - Create reusable GTK widgets and components
 - Follow GNOME Human Interface Guidelines
 - Implement responsive layouts
 - Handle proper resource management
 - Support accessibility features
+- Use Blueprint templates for declarative UI definitions when possible
 
 ## Integration with Core Packages
 - Implement core interfaces faithfully