feat: add zyraXSuno ontology-driven Suno orchestration - #46
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c856e01d91
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| registerSong(batch: BatchSpec, song: SongDraft) { | ||
| const validation = this.validateSong(batch, song); |
There was a problem hiding this comment.
When /songs/register receives a batch ID that already exists, the caller can submit a different BatchSpec with dissFirst, freshness checks, or character limits disabled; this line validates against that untrusted payload and then links the song to the existing strict batch. Resolve the registered batch and its constraint node by ID for validation, and reject missing or conflicting specifications.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| registerBatch(spec: BatchSpec) { | ||
| const artist = this.addNode("Artist", spec.artist, { name: spec.artist }, `artist:${norm(spec.artist)}`); |
There was a problem hiding this comment.
After the singleton HTTP ontology registers its first batch, registering any distinct batch for the same artist throws Ontology node already exists because this deterministic artist ID is always passed to addNode; the flow node has the same problem. This prevents normal multi-batch operation and also makes same-process checkpoint resumption fail before planning, so existing canonical artist/flow nodes need to be reused rather than re-added.
Useful? React with 👍 / 👎.
|
|
||
| for (const job of jobs) { | ||
| const song = await this.provider.generate(job); | ||
| const validation = this.ontology.validateSong(spec, song); |
There was a problem hiding this comment.
When resuming with a fresh ontology instance, previous.usedTitles and previous.usedThemes are used only to filter planner seeds; generated songs are validated solely against spec and the empty ontology. A provider can therefore return a title or theme accepted before the checkpoint and have it accepted again, violating the core freshness guarantee. Merge checkpoint history into the validation state before processing resumed jobs.
Useful? React with 👍 / 👎.
| const { mkdir, writeFile } = await import("node:fs/promises"); | ||
| const { dirname } = await import("node:path"); | ||
| await mkdir(dirname(outputPath), { recursive: true }); | ||
| await writeFile(outputPath, jobs.map((job) => JSON.stringify(job)).join("\n") + "\n", "utf8"); |
There was a problem hiding this comment.
Every documented CLI export invocation writes raw GenerationJob objects, which contain planner fields such as prompt, titleSeed, and themeSeed but no generated title, style, or lyrics. This does not match the newly defined SunoExportRecord format and cannot serve as the advertised Suno-ready JSONL; the command should export generated song records through the exporter or be named and documented as a job-plan export.
Useful? React with 👍 / 👎.
1 participant
Adds the first zyraXSuno implementation inside the Zyra monorepo as an incubation app.
Includes:
This branch is structured so it can be split into a standalone
zyraXSunorepository later without changing the domain model.