qualia-framework 2.1.5 → 2.2.0

package/framework/teams/default/inboxes/plan-04.json

@@ -0,0 +1,9 @@
+[
+  {
+    "from": "team-lead",
+    "text": "Checkpoint approved. All verification passed:\n- Server boots clean, 96 permissions cached\n- All 9 Phase 1.4 endpoints return 401 unauthenticated (tested with /api/v1/ prefix)\n- Health endpoint returns 200\n- pnpm check-types: 5/5 workspaces pass, 0 errors\n- Route ordering confirmed: /mine before /:claimId in startup logs\n\nContinue to create SUMMARY.md and update STATE.md.",
+    "summary": "Approve checkpoint, continue SUMMARY",
+    "timestamp": "2026-03-22T01:22:15.460Z",
+    "read": false
+  }
+]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qualia-framework",
-  "version": "2.1.5",
+  "version": "2.2.0",
   "description": "Qualia Solutions — Claude Code Framework",
   "bin": {
     "qualia-framework": "./bin/cli.js"

package/framework/askpass.sh

@@ -1,2 +0,0 @@
-#!/bin/bash
-echo "pornbeast"

package/framework/commands/design.md

@@ -1,53 +0,0 @@
----
-description: Apply professional design system for websites, apps, UI/UX, components, and business documents
-argument-hint: "[website|app|dashboard|landing-page|component|document] [description or URL]"
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Glob
-  - Grep
-  - AskUserQuestion
----
-
-<objective>
-Design and build professionally styled interfaces, components, and documents using a comprehensive design system. Uses the `frontend-master` skill for consistent visual hierarchy, spacing, color tokens, and modern design patterns.
-
-**Supported contexts:**
-- **Websites & Landing Pages** — Hero sections, feature grids, pricing tables, testimonials, CTAs, footers
-- **Web Apps & Dashboards** — Sidebar nav, stat cards, data tables, charts, activity feeds, filters
-- **UI Components** — Buttons, forms, cards, modals, navigation, tables, toasts, dropdowns
-- **Mobile & Responsive** — Bottom nav, touch targets, responsive breakpoints, mobile-first layouts
-- **Business Documents** — Contracts, proposals, SOWs, NDAs, invoices, reports (docx/PDF output)
-
-**What it does:**
-- Applies design tokens: colors (light/dark mode), typography scale, 8px spacing grid
-- Implements component patterns with proper states (hover, focus, active, disabled, loading, error)
-- Ensures WCAG AA accessibility (contrast, keyboard nav, screen reader, touch targets)
-- Uses responsive breakpoints (640px → 1536px+) with mobile-first approach
-- Structures layouts using CSS Grid/Flexbox with proper max-widths
-- Outputs as HTML/React/JSX for interfaces, or .docx/.pdf for documents
-</objective>
-
-<process>
-1. Read the `frontend-master` skill from `skills/frontend-master/SKILL.md`
-2. Determine the design context from $ARGUMENTS:
-   - **Interface/component**: Identify what's being built (page, component, full app)
-   - **Document**: Identify document type (contract, proposal, invoice, etc.)
-3. If redesigning existing work, read/screenshot it and identify improvements
-4. If creating from scratch:
-   - Ask for key details (purpose, audience, features, brand preferences)
-   - Select appropriate layout pattern from the skill
-   - Choose color palette (or use defaults with primary accent)
-5. Build with the design system:
-   - Apply color tokens, typography scale, spacing grid
-   - Implement proper component patterns with all interaction states
-   - Ensure responsive behavior at all breakpoints
-   - Add accessibility features (contrast, focus indicators, ARIA)
-6. Run through the design checklist (visual, interactive, responsive, performance)
-7. Output the appropriate format:
-   - HTML/React/JSX for web interfaces
-   - .docx or .pdf for business documents
-   - Code snippets for individual components
-</process>

package/framework/commands/quick-db.md

@@ -1,22 +0,0 @@
----
-description: Quick Supabase database operation (query, migration, RLS)
----
-
-Perform a Supabase database operation using the Supabase CLI (not MCP).
-
-## Available Operations:
-1. **Query**: Run SELECT queries via `supabase db execute`
-2. **Migration**: Create schema changes via `supabase migration new`
-3. **RLS**: Set up row-level security policies
-4. **Types**: Generate TypeScript types via `supabase gen types typescript`
-
-## Process:
-1. Understand the request
-2. Use the `/supabase` skill's CLI-first approach to execute
-3. Show results or created SQL
-4. If migration, provide the SQL file content
-
-For comprehensive database operations, use `/supabase` instead.
-
-## Request:
-$ARGUMENTS

package/framework/config/retention.json

@@ -1,35 +0,0 @@
-{
-  "version": "1.0",
-  "description": "Retention policies for .claude directory state management",
-  "policies": {
-    "file-history": {
-      "max_versions": 5,
-      "max_age_days": 7,
-      "compress_after_days": 3,
-      "description": "File modification tracking"
-    },
-    "debug-logs": {
-      "max_age_days": 30,
-      "compress_after_days": 7,
-      "description": "Agent execution traces"
-    },
-    "shell-snapshots": {
-      "max_age_days": 7,
-      "description": "Bash environment snapshots"
-    },
-    "todos": {
-      "archive_after_days": 180,
-      "description": "Task tracking files"
-    },
-    "projects": {
-      "archive_after_days": 90,
-      "compress": true,
-      "description": "Per-project session state"
-    },
-    "session-env": {
-      "cleanup_empty": true,
-      "max_age_days": 30,
-      "description": "Session environment state"
-    }
-  }
-}

package/framework/core/PRINCIPLES.md

@@ -1,77 +0,0 @@
-# Software Engineering Principles
-
-**Core Directive**: Evidence > assumptions | Code > documentation | Efficiency > verbosity
-
-## Philosophy
-- **Task-First Approach**: Understand → Plan → Execute → Validate
-- **Evidence-Based Reasoning**: All claims verifiable through testing, metrics, or documentation
-- **Parallel Thinking**: Maximize efficiency through intelligent batching and coordination
-- **Context Awareness**: Maintain project understanding across sessions and operations
-
-## Engineering Mindset
-
-### SOLID
-- **Single Responsibility**: Each component has one reason to change
-- **Open/Closed**: Open for extension, closed for modification
-- **Liskov Substitution**: Derived classes substitutable for base classes
-- **Interface Segregation**: Don't depend on unused interfaces
-- **Dependency Inversion**: Depend on abstractions, not concretions
-
-### Core Patterns
-- **DRY**: Abstract common functionality, eliminate duplication
-- **KISS**: Prefer simplicity over complexity in design decisions
-- **YAGNI**: Implement current requirements only, avoid speculation
-
-### Systems Thinking
-- **Ripple Effects**: Consider architecture-wide impact of decisions
-- **Long-term Perspective**: Evaluate immediate vs. future trade-offs
-- **Risk Calibration**: Balance acceptable risks with delivery constraints
-
-## Decision Framework
-
-### Data-Driven Choices
-- **Measure First**: Base optimization on measurements, not assumptions
-- **Hypothesis Testing**: Formulate and test systematically
-- **Source Validation**: Verify information credibility
-- **Bias Recognition**: Account for cognitive biases
-
-### Trade-off Analysis
-- **Temporal Impact**: Immediate vs. long-term consequences
-- **Reversibility**: Classify as reversible, costly, or irreversible
-- **Option Preservation**: Maintain future flexibility under uncertainty
-
-### Risk Management
-- **Proactive Identification**: Anticipate issues before manifestation
-- **Impact Assessment**: Evaluate probability and severity
-- **Mitigation Planning**: Develop risk reduction strategies
-
-## Quality Philosophy
-
-### Quality Quadrants
-- **Functional**: Correctness, reliability, feature completeness
-- **Structural**: Code organization, maintainability, technical debt
-- **Performance**: Speed, scalability, resource efficiency
-- **Security**: Vulnerability management, access control, data protection
-
-### Quality Standards
-- **Automated Enforcement**: Use tooling for consistent quality
-- **Preventive Measures**: Catch issues early when cheaper to fix
-- **Human-Centered Design**: Prioritize user welfare and autonomy
-
-## Confidence-First Implementation
-
-### Pre-Execution Validation
-Before starting significant work, assess confidence level:
-
-- **≥90% Confidence**: Proceed with implementation
-- **70-89% Confidence**: Present alternatives, gather more information
-- **<70% Confidence**: STOP - Ask questions, do not proceed
-
-### Confidence Checklist
-- [ ] No duplicate implementation exists
-- [ ] Architecture patterns consulted
-- [ ] Official documentation verified
-- [ ] Root cause identified (for debugging)
-- [ ] Edge cases considered
-
-**ROI**: 100-200 token investment prevents 5,000-50,000 token waste on wrong direction