Allow generate command to add new options to an existing architecture

[willosborne]

Feature Proposal

Target Project:

CLI

Description of Feature:

Currently when you generate an architecture from a pattern you have a nice user experience.
But if you want to come back later and add more options, you have to:

• generate to a new file
• identitify the common config options and copy them over manually (or with AI)
• delete the original and rename
• fill out the new properties

This change would introduce some new logic:

• when generating to a file that already exists, before writing the new file, look at any placeholders in the document
• if there is a value in that placeholder in the current file, extract those values and pre-fill them to the new architecture

In other words it's an in-place update. This flow will trigger when the -o argument targets an existing file.

It will also pre-populate the pattern options from what was chosen in the existing file.
This means that if you run generate against an existing file and don't change any options, it will be a no-op.

Also provide a flag to ignore existing options. --ignore-existing

User Stories:

As a CLI user I want to easily add new options to my existing architecture when generating

Current Limitations:

CLI overwrites every time.

Proposed Implementation:

• When target file already exists, pre-load its options and populate the options selection page early
• When a placeholder is generated, track it and its jsonpath in a map
• Before writing, load existing file if exists
• iterate over this map and extract values
• then set on the new map to write

Alternatives Considered:

Command to copy from one file to another - but this seemed very niche.

Testing Strategy:

CLI tests, integration tests

Documentation Requirements:

Update CLI docs

Implementation Checklist:

• Design reviewed and approved
• Implementation completed
• Tests written and passing
• Documentation updated
• Relevant workflows updated (if needed)
• Performance impact assessed

Additional Context:

...add any other context, diagrams, mockups, or screenshots about the feature request here...

[russlan23]

One edge case in the proposed JSONPath copy: selectChoices rebuilds the selected node and relationship arrays before instantiate traverses them by index. If the existing nodes are [A, C] and adding an option produces [A, B, C], copying nodes[1].description would transfer the value from C to B.

I propose matching nodes and relationships by unique-id, then using a property path relative to that matched object. Only fields recorded as generated placeholders should take existing values; pattern constants should stay authoritative. Missing properties also need to remain distinct from 0, false and an empty string.

Would this matching rule fit the intended in-place update? The regression cases would cover adding an option before an existing node, retaining its edited values, preserving falsy values, and leaving new nodes with their generated placeholders. Nested arrays without stable IDs would need an explicit rule rather than assuming their indices still match.