feat(surface,sdk): lower postfix .gate(config) to slice-P named gates

[kjgbot]

Closes the 'typed but refused' surface oddity — Step.gate() was declared in the surface but every call threw unsupported_gate at runtime.

Now:

• gate(config: NamedGate) — attaches a slice-P named data gate (references_input, subprocess_gate, word_count_bounds, regex_match) to the step's verification: field. Journal-honest — survives replay.
• gate(predicate) — still refuses with unsupported_gate. JS closures can't be journaled without breaking covenant 1.

Test plan

• npm run typecheck clean in packages/sdk
• 25/25 tests pass in tests/authored-flow.test.ts (existing gate-predicate-not-lowered pinned; new gate-config-is-lowered proves the lowered path)

---

Note

Medium Risk
Changes step verification lowering for run/llm/agent paths; predicate gates remain refused but successful flows now enforce named gates at replay time.

Overview
Postfix .gate({ type: … }) on authored steps is now lowered into journal-honest slice-P verification instead of always failing with unsupported_gate.

The surface exports typed NamedGate configs (references_input, subprocess_gate, word_count_bounds, regex_match). AuthoredFlowOperation records config-object gates on namedGate; predicate .gate(fn) still throws unsupported_gate with a clearer message. f.run, f.llm, and f.agent hoist the operation handle so spec build reads the caller’s gate and passes it into the compiled step’s verification: field. Tests assert predicate gates still refuse and config gates reach journal.runStart (not unsupported_gate).

^{Reviewed by Cursor Bugbot for commit 0bcd7f5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 62030164-a938-40dc-967e-55ee2f3e55e9

---

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.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0bcd7f5. Configure here.}

[cursor]

Run gates ignore verification failure

High Severity

f.run().gate(config) lowers a second .gate step into the kernel spec, but the deterministic runner still only reads the producer step's step.completed. A failed named gate therefore never fails the authored f.run step, so postfix verification on f.run does not enforce.

Additional Locations (1)

• packages/sdk/src/authored-flow-executor.ts#L267-L268

 

^{Reviewed by Cursor Bugbot for commit 0bcd7f5. Configure here.}

[cursor]

Config gates skip helper steps

Medium Severity

.gate(config) now accepts a named gate on every Step, but only f.run, f.llm, and f.agent read namedGate. Slack, helper, MCP, and plugin starts ignore it, so the call succeeds and the step runs with no verification.

Additional Locations (2)

• packages/sdk/src/authored-flow-executor.ts#L212-L222
• packages/sdk/src/authored-flow-executor.ts#L225-L252

 

^{Reviewed by Cursor Bugbot for commit 0bcd7f5. Configure here.}

[kjgbot]

maintainability lens — FAIL

Maintainability review — PR #372

Blockers

1. Test does not verify the behavior it claims to.
packages/sdk/tests/authored-flow.test.ts:154-156 — the new "gate-config-is-lowered" test only asserts .rejects.not.toMatchObject({ code: 'unsupported_gate' }). That is a negative assertion: it stays green if the config path throws any other code, even one caused by a regression that silently drops the verification field before it reaches journal.runStart. The whole point of this PR — that NamedGate config lands in the compiled StepSpec.verification — has no positive test. Add an assertion that compiles the flow and inspects the emitted StepSpec.verification, or that captures the spec handed to a mock journal and checks steps[0].verification shape.

Concerns

2. Four hand-synchronized copies of the gate-kind set, none compile-checked.

• packages/surface/src/step.ts:23-55 — surface NamedGate union of 4 interfaces
• packages/sdk/src/spec.ts:59-85 — SDK NamedDataGate of 4 near-identical interfaces
• packages/sdk/src/named-gates.ts:9-14 — NAMED_GATE_KEYS map keyed by type
• packages/sdk/src/authored-flow-operation.ts:11-13 — NAMED_GATE_KINDS set

The surface's "kept in sync with NamedDataGate" comment (step.ts:31) is aspirational — nothing enforces it. Adding a fifth gate kind means editing four places, one of which (the operation's kind set) silently downgrades an unknown gate to the predicate branch and throws unsupported_gate — the same error real predicate closures throw, so the failure mode is indistinguishable from author error. At minimum: derive NAMED_GATE_KINDS from NAMED_GATE_KEYS (already exported from the SDK), and add a type-level assertion that surface NamedGate extends SDK NamedDataGate.

3. Object.freeze(step) no longer carries its old meaning.
packages/sdk/src/authored-flow-operation.ts:96-99 — the freeze is kept, but gate() now mutates operation.namedGate on the enclosing object. A reader who spots the freeze reasonably infers the handle is inert; it isn't. The comment on lines 96-98 hints at this but frames it as intentional. Consider making namedGate explicitly guarded (write-once or throw on late writes) — see next.

4. Silent late/duplicate .gate() calls.
gate() unconditionally overwrites namedGate. There's no check that the operation is still in 'created', and no rejection of .gate(a).gate(b). Once .then() fires (begin() queued), a later .gate() mutation is a dead write — no error, no journal entry. Given the covenant-1 framing ("journal-honest"), silently accepting a mutation that will not appear in the journal is exactly the failure mode this design is supposed to prevent. Throw on second-write or post-begin write.

5. _because argument silently dropped.
step.ts:16 still advertises gate(predicate, because?), and the config overload doesn't take one. Authors migrating a predicate gate to a config gate will drop their rationale on the floor with no warning. Either accept because on the config overload and thread it into the compiled spec, or delete the second parameter from the surface.

Notes

6. Hoist pattern's invariant is implicit.
authored-flow-executor.ts:185-201, 263-270, 279-286 — the let llmOp!: … ; llmOp = new … pattern works only because AuthoredFlowOperation never invokes start during construction. The comment on 185-187 asserts this; the enforcement lives silently in begin() being called only from .then(). If someone reorders the constructor to eagerly kick off, all three hoists fire with undefined.namedGate and blow up at runtime, not at compile time. A one-line assert in the constructor (state === 'created' after wiring) would make the invariant load-bearing where a reader can see it.

REVIEW_FAILED

[kjgbot]

history lens — PASS

Blockers: none identified under the three HISTORY criteria.

The diff builds on 358107b7 (“named data gates v1,” #353). In packages/sdk/src/authored-worker-step.ts:125–169, the new arguments feed verification into the existing compilation path. packages/sdk/src/authored-flow-executor.ts:182–205,260–286 connects that path to authored run, LLM, and agent operations. I found no reintroduced pattern matching the relevant DRIVE-LOG incidents, and no new contradiction with settled decisions #5, #9, or #13: this remains surface/SDK lowering into the existing protocol.

Concerns:

• packages/sdk/tests/authored-flow.test.ts:150–159 asserts only that execution rejects with something other than unsupported_gate. It does not assert that journal.runStart was reached, inspect the submitted verification, or demonstrate enforcement or resume behavior. The PR body’s stronger description exceeds what this assertion establishes. The commit message itself makes the narrower claim: “proves the config branch bypasses the unsupported_gate refusal.” That distinction matters under this lens; I do not classify the commit’s test description as false.
• packages/sdk/src/authored-flow-operation.ts:62–68 accepts a gate without checking operation state. Attaching one after execution starts can update namedGate after the spec has been constructed. This deserves lifecycle coverage, but I found no documented prior fix that this specifically reverses.

Notes:

packages/surface/src/step.ts:4–15 incorrectly attributes “journal-as-truth” to covenant 1, which actually concerns authoring clarity. Correct the reference; this wording does not introduce a forbidden architecture. Predicate refusal remains intact.

I inspected history and source; I did not execute tests or independently verify the PR’s reported pass counts. The RFC’s referenced sibling charter was absent from this checkout.

REVIEW_PASSED

[kjgbot]

structure lens — MISSING

[kjgbot]

🎯 review-swarm: FAILED (M:fail H:pass S:missing)

Lens transcripts posted as sibling comments above.