gh-venturo-id-venturo-claude-plugins-venturo-planner/commands/update-feature.md

description

description
Update an existing feature design with schema and API changes

Update Feature

You will guide the user through updating an existing feature design, regenerating ERD, DBML, PostgreSQL migration, and API contract with changes.

Workflow

This command uses an incremental 5-phase workflow to update feature documentation.

Interactive Discovery

Ask the user these questions first:

1. Feature name to update (snake_case, e.g., product_catalog)
2. What needs to be updated?
   • Add new entities
   • Modify existing entities (add/remove/change columns)
   • Add/remove relationships
   • Update API endpoints
   • Change validation rules
3. For entity changes, ask:
   • Which entity to modify?
   • What columns to add/remove/modify?
   • New relationships?
   • Index changes?
4. For API changes, ask:
   • New endpoints needed?
   • Modified request/response schemas?
   • New filters or parameters?
   • Permission changes?

Present a complete change plan and ask for confirmation before proceeding.

Implementation Phases

After confirmation, execute these phases sequentially (read each phase file when needed):

1. Load Existing Design - phases/update-feature/01-load-existing.md
2. Update ERD - phases/update-feature/02-update-erd.md
3. Update DBML - phases/update-feature/03-update-dbml.md
4. Generate Migration - phases/update-feature/04-generate-migration.md
5. Update API Contract - phases/update-feature/05-update-api-contract.md

After each phase:

• Stop and report what was updated
• Ask user to review
• Wait for "continue" before next phase

Key Implementation Rules

Database Standards:

• Read DATABASE_STANDARDS.md before starting
• Maintain all audit standards
• UUID primary keys (VARCHAR 40)
• 6 audit trail columns required
• NO foreign key constraints
• Proper indexing

Migration Strategy:

• Create new migration file (don't modify existing)
• Use ALTER TABLE for schema changes
• Add new indexes as needed
• Include rollback instructions in comments

File Naming:

• ERD: docs/database/erd/{feature_name}.mmd (overwrite)
• DBML: docs/database/dbml/{feature_name}.dbml (overwrite)
• Migration: docs/database/migrations/{timestamp}_update_{feature_name}.sql (new file)
• API: docs/api/contracts/{feature_name}.md (overwrite)

Example Usage

User: /venturo-planner:update-feature

Claude: I'll help you update an existing feature design.

        1. Which feature do you want to update?

User: product_catalog

Claude: 2. What changes do you need to make?
        - Add new entities
        - Modify existing entities
        - Update API endpoints
        - Other

User: Add a new entity "product_reviews" and add a "rating" column to products

Claude: Let me confirm the changes:
        
        **New Entity:**
        - product_reviews (id, product_id, user_id, rating, comment, ...)
        
        **Modified Entity:**
        - products: add "average_rating" column (DECIMAL 3,2)
        
        **New Relationships:**
        - products ||--o{ product_reviews
        - users ||--o{ product_reviews
        
        Proceed with these changes?

[Continues through all phases]

Output Files

• docs/database/erd/{feature_name}.mmd - Updated ERD
• docs/database/dbml/{feature_name}.dbml - Updated DBML
• docs/database/migrations/{timestamp}_update_{feature_name}.sql - New migration
• docs/api/contracts/{feature_name}.md - Updated API contract

Important Notes

Migration Strategy

DO NOT modify existing migration files! Always create a new migration:

-- Migration: 20250123170000_update_product_catalog.sql
-- Description: Add product_reviews table and average_rating to products

-- Add new table
CREATE TABLE IF NOT EXISTS product_reviews (...);

-- Modify existing table
ALTER TABLE products ADD COLUMN average_rating DECIMAL(3,2);

-- Add new indexes
CREATE INDEX idx_product_reviews_product_id ON product_reviews(product_id);

-- Rollback instructions (commented)
-- DROP TABLE product_reviews;
-- ALTER TABLE products DROP COLUMN average_rating;

Backward Compatibility

Consider backward compatibility:

• Adding columns: Use NULL or DEFAULT values
• Removing columns: Mark as deprecated first
• Changing types: May require data migration
• API changes: Version endpoints if breaking changes

Team Communication

After updating:

• Notify backend team of schema changes
• Notify frontend team of API changes
• Update both teams if breaking changes
• Frontend may need to re-verify against new OpenAPI

Integration

After completion:

1. Backend team: Create new migration with /venturo-go:new-migration
2. Frontend team: Review API contract changes
3. Both teams: Test integration with updated schemas
4. Frontend: Re-verify against updated OpenAPI when backend completes