@zenuml/core 3.47.9 → 3.48.1

package/.claude/commands/handoff.md

@@ -1,146 +0,0 @@
-You are concluding work on the VR Language Learning App project and need to create a comprehensive handoff for the next AI session. This command intelligently analyzes your current session achievements and updates the handoff document with both auto-detected progress and user-provided context.
-
-## Auto-Loaded Project Context:
-@docs/ai-context/HANDOFF.md
-@/CLAUDE.md
-
-## Step 1: Process User Arguments
-
-Handle the arguments flexibly:
-- **With Arguments**: `$ARGUMENTS` provides user context about what was accomplished or attempted
-- **Without Arguments**: Focus purely on auto-detection from session analysis
-
-User provided context: "$ARGUMENTS"
-
-## Step 2: Analyze Current Session Achievements
-
-Think about what was accomplished in this session and how to best capture it for handoff. Review your recent conversation and tool usage to identify significant work:
-
-**Auto-Detect Evidence of:**
-- **File Operations** (Write, Edit, MultiEdit tools) - what files were modified and why
-- **New Features** - functionality added or implemented
-- **Bug Fixes** - issues resolved or debugging attempts
-- **Architecture Changes** - structural improvements or refactoring
-- **Configuration Updates** - settings, dependencies, or environment changes
-- **Documentation Work** - updates to documentation files
-- **Incomplete Work** - attempts that didn't reach completion
-- **Blockers Encountered** - issues that prevented completion
-
-**Generate Session Summary:**
-```
-Session Analysis:
-- Primary work area: [component/domain affected]
-- Main accomplishments: [key achievements]
-- Files modified: [list of changed files]
-- Status: [completed/in-progress/blocked]
-- User context: [if $ARGUMENTS provided]
-```
-
-## Step 3: Analyze Auto-Loaded HANDOFF.md
-
-Analyze the auto-loaded `docs/ai-context/HANDOFF.md` to understand:
-- **Existing sections** and their current status
-- **Related ongoing work** that might connect to your session
-- **Structure and formatting** patterns to maintain consistency
-- **Unrelated content** that should be preserved
-
-## Step 4: Determine Update Strategy
-
-Think about how to best update the handoff based on this session's work. Based on your session analysis and the auto-loaded existing handoff content, decide:
-
-**If Current Work Relates to Existing Task:**
-- Update the existing section with new progress
-- Add accomplishments to "What Was Accomplished"
-- Update "Current Status" and "Current Issue" if resolved
-- Modify "Next Steps" based on new state
-
-**If Current Work is New/Unrelated:**
-- Create a new section with descriptive title
-- Include timestamp for session identification
-- Follow existing document structure and formatting
-
-**If Work Completed an Existing Task:**
-- Mark the task as completed
-- Summarize final outcome
-- Consider archiving or removing if fully resolved
-
-## Step 5: Update HANDOFF.md Intelligently
-
-Make targeted updates to the auto-loaded HANDOFF.md:
-
-### For New Sections, Include:
-```markdown
-## [Task Title] - [Status]
-
-### Current Status
-[Brief description of current state]
-
-### What Was Accomplished
-[Bulleted list of concrete achievements with file paths]
-
-### Current Issue (if applicable)
-[Any blockers or unresolved problems]
-
-### Next Steps to [Objective]
-[Actionable items for continuation]
-
-### Key Files to Review
-[List of relevant files organized by category]
-
-### Context for Next Session
-[Important notes for continuity]
-```
-
-### For Updates to Existing Sections:
-- **Add to accomplishments** without duplicating existing content
-- **Update status** if progress changed the situation
-- **Modify current issues** if problems were resolved or new ones discovered
-- **Refresh next steps** based on new progress
-
-## Step 6: Maintain Document Quality
-
-Ensure your updates follow these guidelines:
-
-**Content Quality:**
-- **Specific**: Include exact file paths and technical details
-- **Actionable**: Provide clear next steps for continuation
-- **Contextual**: Explain the reasoning behind decisions
-- **Current**: Reflect the actual state after your session
-
-**Formatting Consistency:**
-- Follow existing markdown structure and patterns
-- Use consistent heading levels and formatting
-- Maintain bullet point styles and organization
-- Preserve the document's overall structure
-
-**Information Management:**
-- **Don't duplicate** existing information unless updating it
-- **Preserve unrelated** sections that weren't part of your work
-- **Consolidate** related information rather than fragmenting it
-- **Archive completed** work appropriately
-
-## Step 7: Final Verification
-
-Before completing, verify that your handoff:
-- **Accurately reflects** what was accomplished in the session
-- **Combines** auto-detected technical changes with user-provided context
-- **Provides clear direction** for the next AI session
-- **Maintains continuity** with existing handoff content
-- **Is immediately actionable** for someone picking up the work
-
-## Quality Standards
-
-**Be Comprehensive But Concise:**
-- Include all relevant technical details
-- Focus on actionable information
-- Avoid redundancy with existing content
-
-**Maintain Professional Handoff Quality:**
-- Clear problem statements and current status
-- Specific file references and technical context
-- Logical next steps that build on current progress
-- Helpful context that speeds up the next session
-
-This intelligent handoff approach ensures smooth continuity between AI sessions while capturing both the technical reality of what was accomplished and the user's perspective on the work.
-
-Now analyze your session, combine it with the user context "$ARGUMENTS", and update the handoff document accordingly.

package/.claude/commands/implement.md

@@ -1,56 +0,0 @@
----
-description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
----
-
-The user input 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
-
-1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
-
-2. Load and analyze the implementation context:
-   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
-   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
-   - **IF EXISTS**: Read data-model.md for entities and relationships
-   - **IF EXISTS**: Read contracts/ for API specifications and test requirements
-   - **IF EXISTS**: Read research.md for technical decisions and constraints
-   - **IF EXISTS**: Read quickstart.md for integration scenarios
-
-3. Parse tasks.md structure and extract:
-   - **Task phases**: Setup, Tests, Core, Integration, Polish
-   - **Task dependencies**: Sequential vs parallel execution rules
-   - **Task details**: ID, description, file paths, parallel markers [P]
-   - **Execution flow**: Order and dependency requirements
-
-4. Execute implementation following the task plan:
-   - **Phase-by-phase execution**: Complete each phase before moving to the next
-   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
-   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
-   - **File-based coordination**: Tasks affecting the same files must run sequentially
-   - **Validation checkpoints**: Verify each phase completion before proceeding
-
-5. Implementation execution rules:
-   - **Setup first**: Initialize project structure, dependencies, configuration
-   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
-   - **Core development**: Implement models, services, CLI commands, endpoints
-   - **Integration work**: Database connections, middleware, logging, external services
-   - **Polish and validation**: Unit tests, performance optimization, documentation
-
-6. Progress tracking and error handling:
-   - Report progress after each completed task
-   - Halt execution if any non-parallel task fails
-   - For parallel tasks [P], continue with successful tasks, report failed ones
-   - Provide clear error messages with context for debugging
-   - Suggest next steps if implementation cannot proceed
-   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
-
-7. Completion validation:
-   - Verify all required tasks are completed
-   - Check that implemented features match the original specification
-   - Validate that tests pass and coverage meets requirements
-   - Confirm the implementation follows the technical plan
-   - Report final status with summary of completed work
-
-Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.

package/.claude/commands/plan.md

@@ -1,43 +0,0 @@
----
-description: Execute the implementation planning workflow using the plan template to generate design artifacts.
----
-
-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
-
-Given the implementation details provided as an argument, do this:
-
-1. Run `.specify/scripts/bash/setup-plan.sh --json` from the repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. All future file paths must be absolute.
-   - BEFORE proceeding, inspect FEATURE_SPEC for a `## Clarifications` section with at least one `Session` subheading. If missing or clearly ambiguous areas remain (vague adjectives, unresolved critical choices), PAUSE and instruct the user to run `/clarify` first to reduce rework. Only continue if: (a) Clarifications exist OR (b) an explicit user override is provided (e.g., "proceed without clarification"). Do not attempt to fabricate clarifications yourself.
-2. Read and analyze the feature specification to understand:
-   - The feature requirements and user stories
-   - Functional and non-functional requirements
-   - Success criteria and acceptance criteria
-   - Any technical constraints or dependencies mentioned
-
-3. Read the constitution at `.specify/memory/constitution.md` to understand constitutional requirements.
-
-4. Execute the implementation plan template:
-   - Load `.specify/templates/plan-template.md` (already copied to IMPL_PLAN path)
-   - Set Input path to FEATURE_SPEC
-   - Run the Execution Flow (main) function steps 1-9
-   - The template is self-contained and executable
-   - Follow error handling and gate checks as specified
-   - Let the template guide artifact generation in $SPECS_DIR:
-     * Phase 0 generates research.md
-     * Phase 1 generates data-model.md, contracts/, quickstart.md
-     * Phase 2 generates tasks.md
-   - Incorporate user-provided details from arguments into Technical Context: $ARGUMENTS
-   - Update Progress Tracking as you complete each phase
-
-5. Verify execution completed:
-   - Check Progress Tracking shows all phases complete
-   - Ensure all required artifacts were generated
-   - Confirm no ERROR states in execution
-
-6. Report results with branch name, file paths, and generated artifacts.
-
-Use absolute paths with the repository root for all file operations to avoid path issues.

package/.claude/commands/refactor.md

@@ -1,188 +0,0 @@
-You are working on the VR Language Learning App project. The user has requested to refactor specific files tagged with @ symbols in their arguments: "$ARGUMENTS"
-
-## Auto-Loaded Project Context:
-@/CLAUDE.md
-@/docs/ai-context/project-structure.md
-@/docs/ai-context/docs-overview.md
-
-## Step 1: Parse Tagged Files
-Extract all @ tagged file paths from the user's arguments. Only process files that are explicitly tagged with @ symbols.
-
-**Example parsing:**
-- Input: "refactor @src/big-file.ts @components/Large.svelte"
-- Extract: ["src/big-file.ts", "components/Large.svelte"]
-
-## Step 2: Validate and Analyze Files
-For each tagged file:
-1. **Verify file exists** - If file doesn't exist, inform user and skip
-2. **Read file contents** - Understand the structure and dependencies
-3. **Analyze current directory structure** - Map existing patterns around the file
-
-## Step 3: Intelligent Analysis Strategy Decision
-Think deeply about the safest and most effective refactoring approach based on the auto-loaded project context. Based on the initial analysis from Step 2 and the auto-loaded project context, intelligently decide the optimal approach for each file:
-
-### Strategy Options:
-
-**Direct Refactoring** (0-1 sub-agents):
-- Simple files with clear, obvious split points
-- Files with minimal external dependencies
-- Standard refactoring patterns (e.g., extract utils, split large classes)
-- Low risk of breaking changes
-
-**Focused Analysis** (2-3 sub-agents):
-- Moderate complexity with specific concerns
-- Files with moderate dependency footprint
-- When one aspect needs deep analysis (e.g., complex dependencies OR intricate file structure)
-
-**Comprehensive Analysis** (3+ sub-agents):
-- High complexity files with multiple concerns
-- Extensive dependency networks
-- Novel refactoring patterns not seen in project
-- High risk of breaking changes
-- Files that are central to multiple systems
-
-## Step 4: Execute Chosen Strategy
-
-### For Direct Refactoring:
-Proceed with straightforward refactoring using the initial analysis and project context.
-
-### For Sub-Agent Approaches:
-You have complete autonomy to design and launch sub-agents based on the specific refactoring needs identified. Consider these key investigation areas and design custom agents to cover what's most relevant:
-
-**Core Investigation Areas to Consider:**
-- **File Structure Analysis**: Logical component boundaries, split points, cohesion assessment
-- **Dependency Network Mapping**: Import/export analysis, usage patterns, circular dependency risks
-- **Project Pattern Compliance**: Directory structures, naming conventions, organizational patterns
-- **Impact Assessment**: Test files, configuration files, build scripts that need updates
-- **Import Update Analysis**: All files that import from the target file and need updated import paths
-- **Technology Stack Considerations**: Language-specific patterns, framework conventions
-
-**Autonomous Sub-Agent Design Principles:**
-- **Custom Specialization**: Define agents based on the specific file's complexity and risks
-- **Flexible Agent Count**: Use as many agents as needed - scale based on actual complexity
-- **Adaptive Coverage**: Ensure critical aspects are covered without unnecessary overlap
-- **Risk-Focused Analysis**: Prioritize investigation of the highest-risk refactoring aspects
-
-**Sub-Agent Task Template:**
-```
-Task: "Analyze [SPECIFIC_INVESTIGATION_AREA] for safe refactoring of [TARGET_FILE] related to user request '$ARGUMENTS'"
-
-Standard Investigation Workflow:
-1. Review auto-loaded project context (CLAUDE.md, project-structure.md, docs-overview.md)
-2. [CUSTOM_ANALYSIS_STEPS] - Investigate the specific area thoroughly
-3. Return actionable findings that support safe and effective refactoring
-
-Return comprehensive findings addressing this investigation area."
-```
-
-**CRITICAL: When launching sub-agents, always use parallel execution with a single message containing multiple Task tool invocations.**
-
-
-## Step 5: Synthesize Analysis and Plan Refactoring
-
-Think deeply about integrating findings from all sub-agent investigations for safe and effective refactoring. Combine findings from all agents to create optimal refactoring strategy:
-
-### Integration Analysis
-- **File Structure**: Use File Analysis Agent's component breakdown
-- **Organization**: Apply Pattern Recognition Agent's directory recommendations
-- **Safety**: Implement Dependency Analysis Agent's import/export strategy
-- **Completeness**: Address Impact Assessment Agent's broader concerns
-
-### Refactoring Strategy Decision
-Based on synthesized analysis, determine:
-- **Split granularity**: How many files and what logical divisions
-- **Directory structure**: Same-level, subdirectory, or existing directory placement
-- **Import/export strategy**: How to restructure exports and update all consuming files
-- **File naming**: Following project conventions and clarity
-
-### Risk Assessment
-- **Breaking changes**: Identify and mitigate potential issues
-- **Dependency conflicts**: Plan import/export restructuring
-- **Test impacts**: Plan for test file updates
-- **Documentation needs**: Identify doc updates required
-
-## Step 6: Refactoring Value Assessment
-
-### Evaluate Refactoring Worth
-After synthesizing all analysis, critically evaluate whether the proposed refactoring will actually improve the codebase:
-
-**Positive Indicators (Worth Refactoring):**
-- File significantly exceeds reasonable size limits (500+ lines for components, 1000+ for utilities)
-- Clear separation of concerns violations (UI mixed with business logic, multiple unrelated features)
-- High cyclomatic complexity that would be reduced
-- Repeated code patterns that could be abstracted
-- Poor testability that would improve with modularization
-- Dependencies would become cleaner and more maintainable
-- Aligns with project's architectural patterns
-
-**Negative Indicators (Not Worth Refactoring):**
-- File is already well-organized despite its size
-- Splitting would create artificial boundaries that reduce clarity
-- Would introduce unnecessary complexity or abstraction
-- Dependencies would become more convoluted
-- File serves a single, cohesive purpose effectively
-- Refactoring would violate project conventions
-- Minimal actual improvement in maintainability
-
-### Decision Point
-Based on the assessment:
-
-**If Refactoring IS Worth It:**
-- Print clear summary of benefits: "✅ This refactoring will improve the codebase by: [specific benefits]"
-- Proceed automatically to Step 7 (Execute Refactoring)
-
-**If Refactoring IS NOT Worth It:**
-- Be brutally honest about why: "❌ This refactoring is not recommended because: [specific reasons]"
-- Explain what makes the current structure acceptable
-- Ask user explicitly: "The file is currently well-structured for its purpose. Do you still want to proceed with the refactoring? (yes/no)"
-- Only continue if user confirms
-
-## Step 7: Execute Refactoring
-
-Implement the refactoring based on the synthesized analysis:
-
-### File Creation Order
-1. **Create directories** - Create any new subdirectories needed
-2. **Create core files** - Start with main/index files
-3. **Create supporting files** - Types, utils, constants
-4. **Update imports** - Fix all import/export statements
-5. **Update original file** - Replace with new modular structure
-
-### Import/Export Management
-- **Update all consuming files** - Modify import statements to point to new file locations
-- **Restructure exports** - Organize exports in the new file structure
-- **Update relative imports** - Fix paths throughout the codebase
-- **Follow naming conventions** - Use project's established patterns
-
-### Quality Assurance
-- **Preserve functionality** - Ensure no breaking changes
-- **Maintain type safety** - Keep all TypeScript types intact
-- **Follow coding standards** - Apply project's style guidelines
-- **Test compatibility** - Verify imports work correctly
-
-
-## Step 8: Quality Verification
-
-For each refactored file:
-- **Check imports** - Verify all imports resolve correctly
-- **Run type checks** - Ensure TypeScript compilation passes
-- **Test functionality** - Confirm no breaking changes
-- **Validate structure** - Ensure new organization follows project patterns
-
-
-## Error Handling
-- **File not found** - Skip and inform user
-- **Not worth refactoring** - Skip files that are good as is and give users an explanation.
-- **Parse errors** - Report syntax issues and skip
-- **Import conflicts** - Resolve or report issues
-
-## Summary Format
-Provide a comprehensive summary of:
-- **Analysis Results**: Key findings from each sub-agent
-- **Refactoring Strategy**: Chosen approach and rationale
-- **Value Assessment**: Whether refactoring improves the code (from Step 6)
-- **Files Created**: New structure with explanations (if refactoring proceeded)
-- **Dependencies Fixed**: Import/export changes made (if refactoring proceeded)
-- **Issues Encountered**: Any problems and resolutions
-
-Now proceed with multi-agent analysis and refactoring of the tagged files: $ARGUMENTS

package/.claude/commands/specify.md

@@ -1,21 +0,0 @@
----
-description: Create or update the feature specification from a natural language feature description.
----
-
-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
-
-The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `$ARGUMENTS` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
-
-Given that feature description, do this:
-
-1. Run the script `.specify/scripts/bash/create-new-feature.sh --json "$ARGUMENTS"` from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute.
-  **IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
-2. Load `.specify/templates/spec-template.md` to understand required sections.
-3. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
-4. Report completion with branch name, spec file path, and readiness for the next phase.
-
-Note: The script creates and checks out the new branch and initializes the spec file before writing.

package/.claude/commands/tasks.md

@@ -1,62 +0,0 @@
----
-description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
----
-
-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
-
-1. Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
-2. Load and analyze available design documents:
-   - Always read plan.md for tech stack and libraries
-   - IF EXISTS: Read data-model.md for entities
-   - IF EXISTS: Read contracts/ for API endpoints
-   - IF EXISTS: Read research.md for technical decisions
-   - IF EXISTS: Read quickstart.md for test scenarios
-
-   Note: Not all projects have all documents. For example:
-   - CLI tools might not have contracts/
-   - Simple libraries might not need data-model.md
-   - Generate tasks based on what's available
-
-3. Generate tasks following the template:
-   - Use `.specify/templates/tasks-template.md` as the base
-   - Replace example tasks with actual tasks based on:
-     * **Setup tasks**: Project init, dependencies, linting
-     * **Test tasks [P]**: One per contract, one per integration scenario
-     * **Core tasks**: One per entity, service, CLI command, endpoint
-     * **Integration tasks**: DB connections, middleware, logging
-     * **Polish tasks [P]**: Unit tests, performance, docs
-
-4. Task generation rules:
-   - Each contract file → contract test task marked [P]
-   - Each entity in data-model → model creation task marked [P]
-   - Each endpoint → implementation task (not parallel if shared files)
-   - Each user story → integration test marked [P]
-   - Different files = can be parallel [P]
-   - Same file = sequential (no [P])
-
-5. Order tasks by dependencies:
-   - Setup before everything
-   - Tests before implementation (TDD)
-   - Models before services
-   - Services before endpoints
-   - Core before integration
-   - Everything before polish
-
-6. Include parallel execution examples:
-   - Group [P] tasks that can run together
-   - Show actual Task agent commands
-
-7. Create FEATURE_DIR/tasks.md with:
-   - Correct feature name from implementation plan
-   - Numbered tasks (T001, T002, etc.)
-   - Clear file paths for each task
-   - Dependency notes
-   - Parallel execution guidance
-
-Context for task generation: $ARGUMENTS
-
-The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.