@zenuml/core 3.47.9 → 3.48.1

package/.claude/commands/code-review.md

@@ -1,322 +0,0 @@
-# /code-review
-
-*Performs focused multi-agent code review that surfaces only critical, high-impact findings for solo developers using AI tools.*
-
-## Core Philosophy
-
-This command prioritizes **needle-moving discoveries** over exhaustive lists. Every finding must demonstrate significant impact on:
-- System reliability & stability
-- Security vulnerabilities with real exploitation risk
-- Performance bottlenecks affecting user experience
-- Architectural decisions blocking future scalability
-- Critical technical debt threatening maintainability
-
-### 🚨 Critical Findings Only
-Issues that could cause production failures, security breaches, or severe user impact within 48 hours.
-
-### 🔥 High-Value Improvements
-Changes that unlock new capabilities, remove significant constraints, or improve metrics by >25%.
-
-### ❌ Excluded from Reports
-Minor style issues, micro-optimizations (<10%), theoretical best practices, edge cases affecting <1% of users.
-
-
-## Auto-Loaded Project Context:
-@/CLAUDE.md
-@/docs/ai-context/project-structure.md
-@/docs/ai-context/docs-overview.md
-
-
-## Command Execution
-
-User provided context: "$ARGUMENTS"
-
-### Step 1: Understand User Intent & Gather Context
-
-#### Parse the Request
-Analyze the natural language input to determine:
-1. **What to review**: Parse file paths, component names, feature descriptions, or commit references
-2. **Review focus**: Identify any specific concerns mentioned (security, performance, etc.)
-3. **Scope inference**: Intelligently determine the breadth of review needed
-
-Examples of intent parsing:
-- "the authentication flow" → Find all files related to auth across the codebase
-- "voice pipeline implementation" → Locate voice processing components
-- "recent changes" → Parse git history for relevant commits
-- "the API routes" → Identify all API endpoint files
-
-#### Read Relevant Documentation
-Before allocating agents, **read the documentation** to understand:
-1. Use `/docs/ai-context/docs-overview.md` to identify relevant docs
-2. Read documentation related to the code being reviewed:
-   - Architecture docs for subsystem understanding
-   - API documentation for integration points
-   - Security guidelines for sensitive areas
-   - Performance considerations for critical paths
-3. Build a mental model of risks, constraints, and priorities
-
-This context ensures intelligent agent allocation based on actual project knowledge.
-
-### Step 2: Define Mandatory Coverage Areas
-
-Every code review MUST analyze these core areas, with depth determined by scope:
-
-#### 🎯 Mandatory Coverage Areas:
-
-1. **Critical Path Analysis**
-   - User-facing functionality that could break
-   - Data integrity and state management
-   - Error handling and recovery mechanisms
-
-2. **Security Surface**
-   - Input validation and sanitization
-   - Authentication/authorization flows
-   - Data exposure and API security
-
-3. **Performance Impact**
-   - Real-time processing bottlenecks
-   - Resource consumption (memory, CPU)
-   - Scalability constraints
-
-4. **Integration Points**
-   - API contracts and boundaries
-   - Service dependencies
-   - External system interactions
-
-#### 📊 Dynamic Agent Allocation:
-
-Based on review scope, allocate agents proportionally:
-
-**Small to medium Scope (small set of files or small feature)**
-- 2-3 agents covering mandatory areas
-- Each agent handles 1-2 coverage areas
-- Focus on highest-risk aspects
-
-**Large Scope (many files, major feature or subsystem)**
-- 4-6 agents with specialized focus
-- Each mandatory area gets dedicated coverage
-- Additional agents for cross-cutting concerns
-
-### Step 3: Dynamic Agent Generation
-
-Based on scope analysis and mandatory coverage areas, dynamically create specialized agents:
-
-#### Agent Generation Strategy:
-
-**With your documentation knowledge from Step 1, think deeply** about optimal agent allocation:
-- Leverage your understanding of the project architecture and risks
-- Consider the specific documentation you read about this subsystem
-- Apply insights about critical paths and security considerations
-- Use documented boundaries and integration points to partition work
-- Factor in any performance or scalability concerns from the docs
-
-Use your understanding of the project to intuitively determine:
-1. **How many agents are needed** - Let the code's complexity and criticality guide you
-2. **How to partition the work** - Follow natural architectural boundaries
-3. **Which specializations matter most** - Focus agents where risk is highest
-
-**Generate Specialized Agents**
-
-   For each allocated agent, create a focused role:
-
-   **Example for 6-agent allocation:**
-   - Agent 1: Critical_Path_Validator (user flows + error handling)
-   - Agent 2: Security_Scanner (input validation + auth)
-   - Agent 3: API_Security_Auditor (data exposure + boundaries)
-   - Agent 4: Performance_Profiler (bottlenecks + resource usage)
-   - Agent 5: Scalability_Analyst (constraints + growth paths)
-   - Agent 6: Integration_Verifier (dependencies + contracts)
-
-   **Example for 3-agent allocation:**
-   - Agent 1: Security_Performance_Analyst (security + performance areas)
-   - Agent 2: Critical_Path_Guardian (functionality + integrations)
-   - Agent 3: Risk_Quality_Assessor (technical debt + code quality)
-
-#### Dynamic Focus Areas:
-
-Each agent receives specialized instructions based on:
-- **File characteristics**: API endpoints → security focus
-- **Code patterns**: Loops/algorithms → performance focus
-- **Dependencies**: External services → integration focus
-- **User touchpoints**: UI/voice → critical path focus
-
-### Step 4: Execute Dynamic Multi-Agent Review
-
-**Before launching agents, pause and think deeply:**
-- What are the real risks in this code?
-- Which areas could cause the most damage if they fail?
-- Where would a solo developer need the most help?
-
-Generate and launch agents based on your thoughtful analysis:
-
-```
-For each dynamically generated agent:
-  Task: "As [Agent_Role], analyze [assigned_coverage_areas] in [target_scope].
-
-  MANDATORY COVERAGE CHECKLIST:
-  ☐ Critical Path: [assigned aspects]
-  ☐ Security: [assigned aspects]
-  ☐ Performance: [assigned aspects]
-  ☐ Integration: [assigned aspects]
-
-  HIGH-IMPACT REVIEW MANDATE:
-  Focus ONLY on findings that significantly move the needle for a solo developer.
-
-  Review workflow:
-  1. Review auto-loaded project context (CLAUDE.md, project-structure.md, docs-overview.md)
-  2. Analyze your assigned coverage areas with deep focus
-  3. For complex issues, use:
-     - mcp__gemini__consult_gemini for architectural analysis
-     - mcp__context7__get-library-docs for framework best practices
-  4. Cross-reference with other coverage areas for systemic issues
-  5. Document ONLY high-impact findings:
-
-     ## [Coverage_Area] Analysis by [Agent_Role]
-
-     ### 🚨 Critical Issues (Production Risk)
-     - Issue: [description]
-     - Location: [file:line_number]
-     - Impact: [quantified - downtime hours, users affected, data at risk]
-     - Fix: [specific code snippet]
-     - Consequence if ignored: [what happens in 48 hours]
-
-     ### 🎯 Strategic Improvements (Capability Unlocks)
-     - Limitation: [what's currently blocked]
-     - Solution: [architectural change or implementation]
-     - Unlocks: [new capability or scale]
-     - ROI: [effort hours vs benefit quantified]
-
-     ### ⚡ Quick Wins (Optional)
-     - Only include if <2 hours for >20% improvement
-     - Must show measurable impact
-
-  REMEMBER: Every finding must pass the 'so what?' test for a solo developer."
-```
-
-#### Parallel Execution Strategy:
-
-**Launch all agents simultaneously** for maximum efficiency
-
-
-### Step 5: Synthesize Findings with Maximum Analysis Power
-
-After all sub-agents complete their analysis:
-
-**ultrathink**
-
-Activate maximum cognitive capabilities to:
-
-1. **Filter for Impact**
-   - Discard all low-priority findings
-   - Quantify real-world impact of each issue
-   - Focus on production risks and capability unlocks
-
-2. **Deep Pattern Analysis**
-   - Identify systemic issues vs isolated problems
-   - Find root causes across agent reports
-   - Detect subtle security vulnerabilities
-
-3. **Strategic Prioritization**
-   - Calculate ROI for each improvement
-   - Consider solo developer constraints
-   - Create actionable fix sequence
-   ```markdown
-   # Code Review Summary
-
-   **Reviewed**: [scope description]
-   **Date**: [current date]
-   **Overall Quality Score**: [A-F grade with justification]
-
-   ## Key Metrics
-   - Security Risk Level: [Critical/High/Medium/Low]
-   - Performance Impact: [description]
-   - Technical Debt: [assessment]
-   - Test Coverage: [if applicable]
-   ```
-
-### Step 6: Present Comprehensive Review
-
-Structure the final output as:
-
-```markdown
-# 🔍 Code Review Report
-
-## Executive Summary
-[High-level findings and overall assessment]
-
-## 🚨 Production Risks (Fix Within 48 Hours)
-[Only issues that could cause downtime, data loss, or security breaches]
-
-## 🎯 Strategic Improvements (High ROI)
-[Only changes that unlock capabilities or improve metrics >25%]
-
-## ⚡ Quick Wins (Optional)
-[Only if <2 hours effort for significant improvement]
-
-## Detailed Analysis
-
-### Security Assessment
-[Detailed security findings from Security_Auditor]
-
-### Performance Analysis
-[Detailed performance findings from Performance_Analyzer]
-
-### Architecture Review
-[Detailed architecture findings from Architecture_Validator]
-
-### Code Quality Evaluation
-[Detailed quality findings from Quality_Inspector]
-
-[Additional sections based on sub-agents used]
-
-## Action Plan
-1. Critical fixes preventing production failures
-2. High-ROI improvements unlocking capabilities
-
-## Impact Matrix
-| Issue | User Impact | Effort | ROI |
-|-------|-------------|--------|-----|
-| [Only high-impact issues with quantified metrics] |
-```
-
-### Step 7: Interactive Follow-up
-
-After presenting the review, offer interactive follow-ups. For example:
-- "Would you like me to fix any of the critical issues?"
-- "Should I create a detailed refactoring plan for any component?"
-- "Do you want me to generate tests for uncovered code?"
-- "Should I create GitHub issues for tracking these improvements?"
-
-## Implementation Notes
-
-1. **Use parallel Task execution** for all sub-agents to minimize review time
-2. **Include file:line_number references** for easy navigation
-3. **Balance criticism with recognition** of good practices
-4. **Provide actionable fixes**, not just problem identification
-5. **Consider project phase** and priorities when recommending changes
-6. **Use MCP servers** for specialized analysis when beneficial
-7. **Keep security findings sensitive** - don't expose vulnerabilities publicly
-
-## Error Handling
-
-### Coverage Verification
-
-Before presenting results, verify complete coverage:
-
-```
-☑ Critical Path Analysis: [Covered by agents X, Y]
-☑ Security Surface: [Covered by agents Y, Z]
-☑ Performance Impact: [Covered by agents X, Z]
-☑ Integration Points: [Covered by agents W, X]
-```
-
-If any area lacks coverage, deploy additional focused agents.
-
-## Error Handling
-
-If issues occur during review:
-- **Ambiguous input**: Use search tools to find relevant files before asking for clarification
-- **File not found**: Search for similar names or components across the codebase
-- **Large scope detected**: Dynamically scale agents based on calculated complexity
-- **No files found**: Provide helpful suggestions based on project structure
-- **Coverage gaps**: Deploy supplementary agents for missed areas

package/.claude/commands/constitution.md

@@ -1,73 +0,0 @@
----
-description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
-
-Follow this execution flow:
-
-1. Load the existing constitution template at `.specify/memory/constitution.md`.
-   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
-   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
-
-2. Collect/derive values for placeholders:
-   - If user input (conversation) supplies a value, use it.
-   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
-   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
-   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
-     * MAJOR: Backward incompatible governance/principle removals or redefinitions.
-     * MINOR: New principle/section added or materially expanded guidance.
-     * PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
-   - If version bump type ambiguous, propose reasoning before finalizing.
-
-3. Draft the updated constitution content:
-   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
-   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
-   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
-   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
-
-4. Consistency propagation checklist (convert prior checklist into active validations):
-   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
-   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
-   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
-   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
-
-5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
-   - Version change: old → new
-   - List of modified principles (old title → new title if renamed)
-   - Added sections
-   - Removed sections
-   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
-   - Follow-up TODOs if any placeholders intentionally deferred.
-
-6. Validation before final output:
-   - No remaining unexplained bracket tokens.
-   - Version line matches report.
-   - Dates ISO format YYYY-MM-DD.
-   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
-
-7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
-
-8. Output a final summary to the user with:
-   - New version and bump rationale.
-   - Any files flagged for manual follow-up.
-   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
-
-Formatting & Style Requirements:
-- Use Markdown headings exactly as in the template (do not demote/promote levels).
-- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
-- Keep a single blank line between sections.
-- Avoid trailing whitespace.
-
-If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
-
-If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
-
-Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.