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