IzaraCore-SupportServices-GenerateServiceCodeV2

New implementation of the schema-driven service generator. The legacy GenerateServiceCode repository remains the behavior oracle during migration.

The first V2 seam is deliberately small:

GenerationRequest -> ProjectModel -> GenerationPlan -> Artifact[] -> committed files

test-lib-generateCode now points its local dependency at this checkout. Its V2 acceptance suites use only generate(rootPath, options). Legacy golden comparison remains an oracle review: generation and artifact paths pass, while content differences are not accepted automatically.

Current Slice

generate(rootPath, options) is the only public entrypoint. It loads the three schema directories once, emits every currently migrated schema, application, and resource slice, then commits all artifacts in one transaction and returns one GenerationResult. Managed artifacts retain their existing slice ownership, so stale files are cleaned without deleting legacy-owned output.

generate() rejects invalid project/schema/artifact input before it commits. If staging or replacing an output target fails (including a directory or symlink where a generated file belongs), it restores every affected artifact and manifest from the same transaction; callers receive the original error.

Current Cutover Boundary

V2 is generator-only for the current migration. test-lib-generateCode is the approved V2 consumer and calls the supported generate() API. Deployed services continue to use the legacy 1.x package for runtime imports; V2 does not provide legacy runtime exports such as generateCode, utils, consts, or libs.

Do not replace the legacy package in a deployed service with V2 until a separate runtime migration removes those generated-code imports and verifies the resulting service behavior. The legacy repository is read-only and non-runtime now. After the first successful V2 production deployment, 90 days and two release cycles must both complete before it is archived as a protected, read-only Git repository. Archive retains its tags, history, and fixtures; it does not delete the repository.

Generated function YAML preserves FunctionSetting hook blocks across regeneration and rollback. Completion SQS handlers retain the established callingFlow filter contract.

Internally, the custom-flow emitter owns fixture-level application artifacts for eventBridge, ownTopic, extTopic, lambdaSyncInv, lambdaSyncApi, and S3's five entry handlers. The Phase 7 contract is artifact-level (paths, JavaScript syntax, YAML and resource/IAM wiring), not an end-to-end invocation contract.

Architecture Status

The implemented V2 layout makes the pipeline ownership explicit:

src/compile/  request and local schema loading
src/plan/     GenerationPlan construction
src/emit/     schema, application, function, resource, and system emitters
src/output/   artifact validation, hook merge, and transaction commit

src/generate.js remains the high-level orchestration entrypoint. Emitter domains and their templates stay together beneath src/emit/; no pass-through modules were added only to mirror the proposed diagram. Internal modules are not part of the package API.

Development

npm test