[miguel-heygen]

What

When --composition points outside the project, at a missing file, or at a directory, the error now names the path it resolved to and the project directory it was checked against, next to the value that was passed:

✗  Invalid composition path
   "../x.html" resolves to /tmp/demo/x.html, outside the project directory /tmp/demo/proj.
   Pass a .html file inside the project directory, relative to it (e.g. compositions/intro.html).

Why

The old outside-project error printed only the raw value (Entry file must stay inside the project directory: ../x.html), and the not-found and directory errors said "the project directory" without naming it. Agents reading this error could not tell which directory the path was resolved against, so they retried with the same wrong path. Both resolved paths make the mistake visible in one read.

How

• CompositionEntryParseError now carries the resolved entryPath and projectDir, and compositionEntryErrorMessage is the one place that words all three cases.
• cloud render had its own missing-entry message with the raw values. It now validates through the same parseCompositionEntryArg and prints through the same message, so it also rejects an entry outside the project before uploading. It keeps its own exit path.
• The --composition helpers move from renderArgs.ts to utils/compositionEntry.ts, so cloud render can use them without loading the render engine. renderArgs.ts is otherwise unchanged.

Test plan

• renderArgs.test.ts: each of the three cases must return the resolved entry path and project directory, and its message must name both. cloud/render.test.ts: a missing entry must print both. 51 passed, 3 runs; with the old message wording and the old cloud check restored, exactly these 4 fail.
• src/commands/render plus both files: 215 passed, 3 runs. tsc --noEmit shows no errors in the changed files.
• Ran the CLI: render -c ../x.html, render -c missing.html and cloud render --composition ../x.html --dry-run print the messages above.
• oxfmt, oxlint, comment ratchet and check-cli-lazy-deps (on a fresh CLI build): clean.

Why under 100 lines

The behaviour change is about 30 lines across the error type, its message and the cloud check. The rest of the diff is the helpers moving to their own module, unchanged apart from shorter comments.

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 161 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 1 nit · head d6f78268

• nit: cloud render still sends the raw args.composition to the server (commands/cloud/render.ts:299) while the local check now accepts ././/absolute spellings and normalizes them to a project-relative entry. Not introduced here, but passing entry.value through would make the server see the path that was validated.

Scope

Read the full diff. The move into utils/compositionEntry.ts is byte-equivalent apart from the new entryPath/projectDir fields and the message wording. The cloud check now goes through parseCompositionEntryArg: default index.html, .→index.html, absolute-inside, and rejecting outside-project entries all behave as intended, and it keeps failCommand. No other importers of the moved symbols. CI on this head is green, including Windows render verification and Comments.