fix(core): forward pre_output gate on_fail into compiled output

[SingleSourceStudios]

Summary

Gate carries on_fail?: OnFailAction and quality_gates.pre_output is Gate[], but the pre_output gate call sites compiled via compileGateValidator(check, message) and never forwarded on_fail. The recovery action was dropped from compiled output, so a runtime executing the compiled spec could not recover what action a failing pre_output gate should trigger. Same class as #64, different authoring site (surfaced by CodeRabbit and cubic during review of #71).

Typed shape

Mirrors #64, which carried recovery semantics as a first-class typed field on the compiled representation. For step verification that representation is the singular CompiledStep.verification (CompiledVerification). pre_output gates have no per-gate data structure; their compiled representation is the gate validator's return shape, so the recovery action is carried there:

export interface QualityGateResult {
	passed: boolean;
	message?: string;
	onFail?: OnFailAction; // recovery action authored on the gate, surfaced when the gate fails
}

compileGateValidator gains an onFail parameter; gate.on_fail is forwarded at both pre_output call sites (the per-step qualityGates list in compileStep and the globalQualityGates list in compileWorkflow). The action is surfaced on the failing result (passed: false) and omitted when the author did not specify on_fail, mirroring the optional source field with no invented default. The step.verification gate call site is unchanged; its recovery lives on CompiledStep.verification per #64.

Test (TDD, RED first)

Added a parametrised canary in compiler.test.ts matching the existing OnFailAction / ExecutionMode style: it.each over all five OnFailAction values (retry, escalate, skip, abort, revise) compiling a spec whose pre_output gate carries that on_fail, then asserting the compiled gate's failing result carries the authored onFail. A sixth case asserts onFail is absent when the author omitted on_fail.

Observed RED before the fix (all five forwarding cases failed because onFail was dropped):

× forwards on_fail: retry onto the failing pre_output gate result
× forwards on_fail: escalate onto the failing pre_output gate result
× forwards on_fail: skip onto the failing pre_output gate result
× forwards on_fail: abort onto the failing pre_output gate result
× forwards on_fail: revise onto the failing pre_output gate result

GREEN after (canary 6/6). Existing pre_output gate tests stay green because gates without an authored on_fail still return { passed, message? } unchanged.

Scope

packages/core only: types.ts, compiler.ts, compiler.test.ts. The executor and adapter are untouched; consuming the field is a separate issue.

Gates (all green, node v22.22.2)

• npm run build:core and full npm run build: success
• npm test: 482 passed, 0 failed (476 + 6 new)
• npm run typecheck: clean
• npm run lint: all three changed files clean (repo baseline of 5 errors / 22 warnings is in untouched files)
• node spec/fixtures/run-fixtures.mjs: 29 passed, 0 failed

Closes #72

---

Summary by cubic

Fixes dropped on_fail on pre_output gates by forwarding it into the compiled output. Runtimes can now see the authored recovery action on failing gate results.

• Bug Fixes
  • Forward gate.on_fail to validators via compileGateValidator(check, message, onFail) at both per-step and global pre_output call sites.
  • Extend QualityGateResult with optional onFail; set only on failed results and only when authored.
  • Leave step verification logic unchanged; no defaults added.

^{Written for commit 4a4f89e. Summary will update on new commits. Review in cubic}

[coderabbitai]

Warning

Review limit reached

@SingleSourceStudios, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 20 minutes and 3 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2abd93a7-bb4c-449b-aaff-d0d56caebc3b

📥 Commits

Reviewing files that changed from the base of the PR and between c7f6d2b and 4a4f89e.

📒 Files selected for processing (3)

• packages/core/compiler.test.ts
• packages/core/compiler.ts
• packages/core/types.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/pre-output-gate-on-fail

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}