chore: revert RestAPI options.summarize openapi hunk (bundled into #214)

[chrisli30]

Summary

PR #214 (Position D auth) regenerated packages/types/openapi/openapi.yaml from the EigenLayer-AVS staging snapshot. That refresh pulled in the RestAPINodeConfig.options.summarize block — which is unrelated to the Position D auth migration but landed in the same squash because the openapi resync is wholesale.

This PR removes just that hunk so the summarize feature can land in its own dedicated PR with the proper "feat: document RestAPI options.summarize" framing, instead of arriving silently via an auth-migration squash merge.

Why this is safe to revert

The SDK builder at packages/sdk-js/src/v4/builders/nodes.ts:119 declares its own local annotation:

options?: { summarize?: boolean };

and spreads it into the node config without referencing the generated RestAPINodeConfig.options type. So removing the openapi-side declaration doesn't break the builder's call surface, and the AAVE template test (tests/v4/templates/aave-health-factor-alert.test.ts:231) keeps typechecking + running.

Verification

• yarn workspace @avaprotocol/types build — clean
• yarn workspace @avaprotocol/sdk-js build — clean
• npx tsc --noEmit -p . — no errors on nodes.ts or AAVE test
• yarn test tests/v4/smoke.test.ts — 12/12 pass

What's next

A separate PR will re-add the RestAPINodeConfig.options.summarize schema entry alongside whatever additional SDK + test coverage the summarize feature warrants — that PR is the right home for the schema documentation since it ships the SDK-side support together.

🤖 Generated with Claude Code

[claude]

Code Review — PR #215: Revert RestAPI options.summarize openapi hunk

Overview

A clean housekeeping PR that excises the summarize field from RestAPINodeConfig in both the source YAML and the generated TypeScript, after it was accidentally bundled into the auth-migration squash (PR #214). The change is a pure deletion — no new code, no logic changes.

---

What is Good

• Minimal, surgical diff. Only the two files that needed reverting are touched; nothing else is disturbed.
• PR description is excellent. The rationale (as v4.Node assertion shields the builder), the verification checklist, and the follow-up plan are all clearly stated.
• Safety analysis is accurate. Confirmed: nodes.ts:130 spreads options into the config behind an as v4.Node cast, so the generated type no longer carrying options does not surface a compile error at the call site.

---

Issues / Observations

1. Generated file edited manually instead of regenerated (minor process note)

packages/types/src/openapi.gen.ts is a generated file. Ideally the YAML is edited first and then the generated file is produced by running the generator, not by directly editing both. The end result is identical here since it is a pure deletion, but it sets a precedent for drift if the generator and the hand-edit ever get out of sync.

Suggestion: add a CI step that runs yarn run protoc-gen && git diff --exit-code to verify the generated file stays in sync with the source YAML. At minimum, a note in the PR confirming the manual edit was verified to be equivalent to a generator run would help.

2. Latent type/runtime gap for options (by design, worth documenting)

After this PR, RestAPINodeConfig has no options field, but the builder's local annotation (options?: { summarize?: boolean } at nodes.ts:119) still accepts and spreads the value at runtime. Any consumer that constructs a RestAPINodeConfig directly (not via the builder) and passes options will do so without TypeScript safety.

This is the correct tradeoff given that the feature is not ready to ship, and the PR description acknowledges it. Recommend that the follow-up PR re-adding options.summarize also removes the builder's local annotation and relies on the generated type instead, so the two sources of truth collapse into one.

3. options?: never in discriminated-union variants (FYI — not a problem)

The generated file already uses options?: never on every other node-config variant to prevent mixing in a discriminated union. RestAPINodeConfig will now simply omit options entirely rather than declaring it never. That is consistent with the existing field being optional (options?) rather than a required discriminator, so no change is needed.

---

Verdict

Approve. The revert is correct, safe, and well-reasoned. The minor process note about generator vs manual edit is worth a follow-up but is not a blocker. Ready to merge.

Reviewed with Claude Code