Add code generation, generate tool, and Gemini integration#14
Add code generation, generate tool, and Gemini integration#14sezallagwal wants to merge 3 commits into
Conversation
…ration Add the Week 5 code generation layer and the integration glue that turns a DSL document into a runnable MCP server project: - generator/dsl-mapping.ts: bridge the flat DSL step shape to the composer's StepConfig union (the seam between the DSL front end and the workflow model) - generator/engine-bundle.ts: vendor the real engine source into generated projects (no re-authored copies) - generator/codegen.ts + scaffold.ts: emit server entry, RC client, endpoint map, per-workflow tool files, README, package.json, tsconfig, env, gitignore - generator/project.ts + pipeline.ts: assemble the file set and run the full DSL -> compose -> generate pipeline - tools/generate.ts: the `generate` MCP tool — resolves endpoints via the parser and writes the project to disk; registered in server.ts - Gemini CLI extension: gemini-extension.json, GEMINI.md (DSL reference), commands/generator/generate.toml Integration test drives DSL -> generated project, asserts the file set, and executes the embedded workflow through the engine. Generated projects compile cleanly under tsc.
dhairyashiil
left a comment
dhairyashiil
left a comment
There was a problem hiding this comment.
Hi Sezal, could we fix a few generator safety issues before this PR lands?
First, the built generator currently cannot bundle the workflow engine. engine-bundle reads files like types.ts relative to the running module, but after npm run build those source .ts files are not in dist/workflow. So generation works from source, but the built package path fails. Could we add a built/dist smoke test for generate, and copy/embed the engine sources in a way that works after build?
Second, generated TypeScript embeds DSL-controlled text inside block comments. A workflow DESCRIPTION containing */ can break out of the comment and become executable generated code. Could we escape or remove user-controlled text before putting it in comments?
Third, unresolved operationIds should fail closed. Right now generation can continue with missing endpoints, and the runtime can fall back to an empty GET path. Could we return an error when any operationId cannot be resolved, or rewrite corrected ids before generating?
These are all generator-level issues, so this feels like the right PR to fix them.
…closed on unresolved operationIds Addresses review feedback on PR #14: - engine-bundle: resolve engine sources across src/dist layouts and copy .ts sources into dist/ during build so the built package is self-contained; add a built/dist smoke test for generation - codegen/project/scaffold: escape DSL-controlled text embedded in block comments and README tables; derive safe, unique module basenames for tool files and imports so an unconstrained workflow name cannot break out - generate tool: fail closed when an operationId cannot be resolved and rewrite parser-corrected operationIds before generating so the embedded workflow and endpoint map agree - api-call runtime: throw on an unregistered operationId instead of falling back to an empty GET path (also vendored into generated servers) - tests: escaping, injection safety, fail-closed + corrected-id rewrite, missing-endpoint runtime guard, and a built/dist smoke test
…n' into feature/code-generation # Conflicts: # src/workflow/api-call.ts
2 participants
Summary
Depends on
#13