Skip to content

Developer Journey

This page is the end-to-end delivery map.

It does not repeat every integration option in detail. Use Integration Decision Tree for path selection, and use this page to understand the sequence from idea to publish-ready generator.

Stage 1: Define the Generator

Before implementation, confirm:

  • generator identity and appKey
  • target stack
  • whether template scenarios exist
  • which platform capabilities are required
  • whether the target is a new generator or a refactor

Stage 2: Choose the Integration Path

Decide:

  • manual engineering or AI-assisted workflow
  • official shell or custom shell
  • runtime contract now or later

This decision drives all later work, so do it before building.

Stage 3: Build or Refactor the Runtime

The runtime owns:

  • business state
  • rendering logic
  • parameter schema
  • export data production

If the generator must work across multiple hosts, this stage should converge to Runtime Contract.

Stage 4: Connect Platform Capabilities

Integrate generator-sdk for the capabilities your generator actually needs, such as:

  • authentication
  • billing and credits
  • export actions
  • cloud save and history
  • template helpers

This is the point where a standalone generator becomes a platform-connected generator.

Stage 5: Choose the Host Shell

Use Generator Workbench when you want the official shell.
Keep a custom shell when the product already has its own host layout.

Either way, keep these boundaries stable:

  • runtime owns behavior
  • SDK owns platform APIs
  • shell owns host UI

Stage 6: Verify Standardization

Before declaring the generator “standardized,” verify:

  1. the required platform capabilities are integrated
  2. the runtime contract surface exists where needed
  3. full / embed behavior works where required
  4. template scenarios are handled honestly
  5. shell behavior is stable

For existing generators, distinguish clearly between:

  • Compatibility Refactoring
  • Standardization Refactoring

They are not the same delivery milestone.

Stage 7: Prepare for Publishing

A publish-ready generator usually needs:

  • stable environment and app identity
  • validated integration behavior
  • build output ready for release operations
  • any migration or release notes required by the change

This repository focuses on integration and delivery readiness. Platform-side review and publishing happen afterward.

Stage 8: Iterate After Release

After release, work often continues in one of three directions:

  • add more platform capabilities
  • improve standardization quality
  • move from phased compatibility to full standard runtime support

Common Patterns

New Standard Generator

  1. define identity
  2. choose starter and stack
  3. integrate SDK
  4. decide on workbench
  5. expose runtime contract
  6. verify export and template behavior

Existing Generator Refactor

  1. identify compatibility vs standardization scope
  2. preserve existing behavior
  3. add SDK capabilities
  4. wrap or implement runtime contract
  5. decide whether to adopt workbench
  6. document remaining gaps honestly

Next Step

MIT Licensed