Refactor `install:demo` to support single-author and multi-author demo template variants across Web and API

Summary

Refactor install:demo so it can generate different demo module variants based on platform and authoring profile.

The command should default to a lightweight single-author Web demo and support installing Web, API, or both using dedicated template variants for:

• DemoWebSingle
• DemoWebMulti
• DemoApiSingle
• DemoApiMulti

Why

The current install:demo command always creates a richer multi-author blogging setup by generating both:

• DemoWeb
• DemoApi

and then seeding multiple users, posts, and comments.

That is useful as a showcase, but it is too heavy as the default project experience.

More importantly, the difference between a single-author blog and a multi-author blog is not only seed data volume. It also affects the generated application surface.

For example, in the current templates:

• signup is available
• comment creation/deletion is available
• multi-user authoring flows are available immediately

A true single-author demo should not expose those multi-author features by default.

Goal

Make install:demo capable of generating different demo variants based on:

• platform selection: Web, API, or both
• authoring profile: single-author or multi-author

without introducing a new template assembly engine at this stage.

Proposed Direction

Introduce explicit demo template variants

Add dedicated templates for:

• DemoWebSingle
• DemoWebMulti
• DemoApiSingle
• DemoApiMulti

The command should resolve which template(s) to generate based on the provided flags.

Default to single-author Web demo

Running:

php qt install:demo

should install the single-author Web demo by default.

Support Web/API selection

The command should support choosing which platform surfaces to install, such as:

• Web only
• API only
• both Web and API

Support single-author vs multi-author profile selection

The command should support switching between:

• single-author profile
• multi-author profile

with single-author as the default and multi-author as an explicit opt-in mode.

Single-author profile contract

The single-author variants should behave as a real single-author blog, not just a smaller dataset.

That means:

• no signup routes
• no signup flow
• no comment routes
• no comment UI/API surface
• one seeded author
• a few seeded posts
• author can still sign in
• author can still manage posts
• author can still manage account settings
• public visitors can still browse posts and single post pages/endpoints

Multi-author profile contract

The multi-author variants should preserve the current richer showcase-oriented behavior, including:

• signup enabled
• comments enabled
• multiple seeded users
• richer seeded dataset
• Web and API surfaces consistent with the current multi-author demo direction

Implementation Direction

install:demo currently has a hardcoded static step list.

This should be refactored so the command resolves an installation plan first and then builds the execution steps dynamically based on:

• chosen platform(s)
• chosen profile

This avoids hardcoding a single demo shape in the command.

Acceptance Criteria

• install:demo defaults to generating the single-author Web demo
• the command can install Web only, API only, or both
• the command can switch between single-author and multi-author variants
• dedicated template variants exist for Web/API and single/multi author profiles
• single-author variants do not expose signup or comments
• multi-author variants preserve the current richer demo behavior
• command execution steps are built dynamically from the selected install plan rather than remaining fully hardcoded
• generated demo output matches the selected platform/profile combination

Notes

Relevant code:

• shared/Commands/DemoCommand.php in the project repo
• src/Console/Commands/ModuleGenerateCommand.php
• src/Module/ModuleManager.php
• src/Module/Templates/DemoWeb
• src/Module/Templates/DemoApi

This ticket should be treated as the first pragmatic step toward more flexible demo generation without requiring a generic template composition system yet.

Start with shared/Commands/DemoCommand.php to trace the current hardcoded installation steps, then read src/Console/Commands/ModuleGenerateCommand.php and src/Module/ModuleManager.php. Inspect the existing src/Module/Templates/DemoWeb and src/Module/Templates/DemoApi before defining the four requested variants. Done means each platform/profile combination generates the matching surfaces and seed data, with single-author output excluding signup and comments while multi-author behavior is preserved.