HYPERFLEET-500 - docs: document generator decision #76
Conversation
WalkthroughThis pull request updates the generated code policy documentation with clarifications and expanded guidance on OpenAPI code generation tools. The changes specify that hyperfleet-api's .gitignore references code generated by oapi-codegen, and introduce a new comprehensive section comparing three OpenAPI code generation tools: OpenAPI Generator, ogen, and oapi-codegen. The comparison includes type system approaches, strengths, weaknesses, and recommendations. Additional references for oapi-codegen and Protocol Buffers are appended, with subsequent sections renumbered accordingly. Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
hyperfleet/standards/generated-code-policy.md (1)
349-349: Update the oapi-codegen GitHub URL to reflect the current repository location.Line 349 references the outdated repository URL (
github.com/deepmap/oapi-codegen). The project moved to the oapi-codegen organization; update tohttps://github.com/oapi-codegen/oapi-codegento match line 195 and the current correct location.
🤖 Fix all issues with AI agents
In @hyperfleet/standards/generated-code-policy.md:
- Around line 212-340: The markdown has formatting issues: add language
specifiers "go" to the three fenced code blocks that follow each "Type Style:"
example, remove extra spaces after the "####" tokens in the generator section
headings (e.g., the lines that render "#### 2. ogen/..." and the similar one
later), convert the "**Recommendation**" line into a proper heading (e.g., "###
Recommendation" or "#### Recommendation"), and dedent all bullet points in the
Strengths/Weaknesses lists so they start at column 0 (apply this to the three
generator Strengths/Weaknesses blocks and the final comparison list).
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
hyperfleet/standards/generated-code-policy.md
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
hyperfleet/standards/generated-code-policy.md
212-212: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
223-223: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
224-224: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
225-225: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
226-226: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
227-227: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
228-228: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
229-229: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
230-230: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
233-233: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
234-234: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
235-235: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
236-236: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
237-237: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
240-240: Multiple spaces after hash on atx style heading
(MD019, no-multiple-space-atx)
243-243: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
261-261: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
262-262: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
263-263: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
264-264: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
265-265: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
266-266: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
267-267: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
268-268: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
269-269: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
272-272: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
273-273: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
274-274: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
275-275: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
276-276: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
279-279: Multiple spaces after hash on atx style heading
(MD019, no-multiple-space-atx)
282-282: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
302-302: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
303-303: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
304-304: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
305-305: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
306-306: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
307-307: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
308-308: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
309-309: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
312-312: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
313-313: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
314-314: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
315-315: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
316-316: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
334-334: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
338-338: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
339-339: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
340-340: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
🔇 Additional comments (3)
hyperfleet/standards/generated-code-policy.md (3)
75-75: LGTM! Good clarification.The updated comment now explicitly identifies oapi-codegen as the generator, which aligns well with the detailed comparison in section 7.
193-340: Excellent technical comparison.The new section provides valuable decision-making context with:
- Clear comparison across multiple dimensions (code size, dependencies, type safety)
- Concrete code examples showing different approaches
- Balanced pros/cons for each option
- Actionable recommendations tied to specific use cases
The embedded struct pattern example for oapi-codegen (lines 283-298) effectively illustrates the allOf composition preservation advantage.
345-350: Correct section renumbering and relevant references added.The References section is appropriately renumbered to 8, and the new references for oapi-codegen and Protocol Buffers are relevant additions.
| ``` | ||
| type Cluster struct { | ||
| CreatedTime time.Time `json:"created_time"` | ||
| Name string `json:"name" validate:"regexp=^[a-z0-9]([-a-z0-9]*[a-z0-9])?$"` | ||
| Spec map[string]interface{} `json:"spec"` | ||
| Labels *map[string]string `json:"labels,omitempty"` // pointer for optional | ||
| Id *string `json:"id,omitempty"` | ||
| } | ||
| ``` | ||
|
|
||
| Strengths: | ||
| - ✅ No runtime dependencies - uses only stdlib (encoding/json) | ||
| - ✅ Null-safety pattern with NullableCluster wrapper types | ||
| - ✅ Constructor functions (NewCluster, NewClusterWithDefaults) | ||
| - ✅ Validation in UnmarshalJSON - checks required properties | ||
| - ✅ GetXxxOk() methods return tuple (value, bool) for presence checking | ||
| - ✅ HasXxx() methods for optional field presence | ||
| - ✅ ToMap() method for generic map conversion | ||
| - ✅ Mature tooling - widely used, extensive documentation | ||
|
|
||
| Weaknesses: | ||
| - ❌ Verbose - each model in separate file with many boilerplate methods | ||
| - ❌ Pointer-based optionals (*string) - less idiomatic for Go | ||
| - ❌ No built-in validation beyond required field checking | ||
| - ❌ Flattens allOf schemas - loses composition structure | ||
| - ❌ Java dependency - requires JVM to run generator | ||
|
|
||
| --- | ||
| #### 2. ogen/ (Go-native generator) | ||
|
|
||
| Type Style: | ||
| ``` | ||
| type Cluster struct { | ||
| ID OptString `json:"id"` // Optional type wrapper | ||
| Kind string `json:"kind"` | ||
| Labels OptClusterLabels `json:"labels"` | ||
| Name string `json:"name"` | ||
| Spec ClusterSpec `json:"spec"` | ||
| Generation int32 `json:"generation"` | ||
| Status ClusterStatus `json:"status"` | ||
| } | ||
| type OptString struct { | ||
| Value string | ||
| Set bool | ||
| } | ||
| ``` | ||
|
|
||
| Strengths: | ||
| - ✅ Opt[T] types for optionals - explicit presence tracking, no nil pointer issues | ||
| - ✅ Built-in validation (oas_validators_gen.go) with structured errors | ||
| - ✅ OpenTelemetry integration - tracing/metrics out of the box | ||
| - ✅ Enum validation with MarshalText/UnmarshalText | ||
| - ✅ High-performance JSON using go-faster/jx (no reflection) | ||
| - ✅ Generated getters/setters for all fields | ||
| - ✅ Pure Go toolchain - no JVM needed | ||
| - ✅ Server + Client generation in same package | ||
| - ✅ Type-safe response types (GetClusterByIdRes interface) | ||
|
|
||
| Weaknesses: | ||
| - ❌ Largest output (~20k lines) - more code to maintain | ||
| - ❌ Heavy runtime dependencies - ogen-go/ogen, go-faster/*, OTel | ||
| - ❌ Learning curve - Opt[T] pattern different from idiomatic Go | ||
| - ❌ Less flexibility - opinionated about patterns | ||
| - ❌ Flattens allOf - doesn't preserve schema composition | ||
|
|
||
| --- | ||
| #### 3. oapi-codegen/ (Go-native generator) | ||
|
|
||
| Type Style: | ||
| ``` | ||
| type Cluster struct { | ||
| // Preserves allOf composition! | ||
| ClusterBase `yaml:",inline"` | ||
| CreatedBy openapi_types.Email `json:"created_by"` // Typed email | ||
| CreatedTime time.Time `json:"created_time"` | ||
| Generation int32 `json:"generation"` | ||
| Status ClusterStatus `json:"status"` | ||
| } | ||
| type ClusterBase struct { | ||
| APIResource `yaml:",inline"` | ||
| Kind string `json:"kind"` | ||
| Name string `json:"name"` | ||
| Spec ClusterSpec `json:"spec"` | ||
| } | ||
| ``` | ||
|
|
||
| Strengths: | ||
| - ✅ Most compact (~2.5k lines, 2 files) - minimal footprint | ||
| - ✅ Preserves allOf composition - embedded structs match schema | ||
| - ✅ Semantic types - openapi_types.Email instead of string | ||
| - ✅ Lightweight runtime - just oapi-codegen/runtime | ||
| - ✅ Pure Go toolchain - no JVM | ||
| - ✅ ClientWithResponses - parsed response bodies with type safety | ||
| - ✅ RequestEditorFn pattern - clean auth/middleware injection | ||
| - ✅ Go-idiomatic - feels like handwritten Go code | ||
|
|
||
| Weaknesses: | ||
| - ❌ No built-in validation - must add manually or use external | ||
| - ❌ Pointer-based optionals (*string) - though less pervasive | ||
| - ❌ Fewer accessor methods - direct field access preferred | ||
| - ❌ Less observability - no OTel integration | ||
| - ❌ Returns *http.Response - need ClientWithResponses for parsed bodies | ||
|
|
||
| --- | ||
| Comparison Summary | ||
|
|
||
| | Feature | main/ | ogen/ | oapi-codegen/ | | ||
| |--------------------|-------------|--------------|---------------| | ||
| | Code Size | Medium | Large | Small ✅ | | ||
| | Runtime Deps | None ✅ | Heavy | Light | | ||
| | Optional Handling | Pointers | Opt[T] ✅ | Pointers | | ||
| | Validation | Basic | Full ✅ | None | | ||
| | Schema Composition | Flattened | Flattened | Preserved ✅ | | ||
| | Observability | None | OTel ✅ | None | | ||
| | Go Idiomaticity | Medium | Medium | High ✅ | | ||
| | Type Safety | Good | Excellent ✅ | Good | | ||
| | Maintenance | Java needed | Go | Go | | ||
|
|
||
| --- | ||
| **Recommendation** | ||
|
|
||
| For our use case (types + client only): | ||
|
|
||
| - oapi-codegen is the best fit if you want minimal, Go-idiomatic code that preserves your schema composition (allOf inheritance). The embedded struct pattern (ClusterBase → Cluster) is clean and matches your OpenAPI design. | ||
| - ogen is better if you need built-in validation, observability (OTel), or are building a complete server+client solution. The Opt[T] pattern is cleaner than nil pointers. | ||
| - OpenAPI Generator (main/) is worth keeping if you need maximum compatibility or zero runtime dependencies, though the Java requirement and verbose output are downsides. |
There was a problem hiding this comment.
Fix markdown formatting issues.
The static analysis tool identified several formatting inconsistencies that should be corrected:
- Missing language specifiers: Code blocks at lines 212, 243, and 282 should specify
goas the language - List indentation: Bullet points in Strengths/Weaknesses sections should start at column 0 (no indentation)
- Heading spacing: Lines 240 and 279 have extra spaces after
#### - Heading style: Line 334's "Recommendation" should be a proper heading (
###or####)
📝 Proposed formatting fixes
Fix code block language specifiers:
- Type Style:
-```
+ Type Style:
+```goApply this pattern to lines 212, 243, and 282.
Fix heading spacing (lines 240, 279):
-#### 2. ogen/ (Go-native generator)
+#### 2. ogen/ (Go-native generator)-#### 3. oapi-codegen/ (Go-native generator)
+#### 3. oapi-codegen/ (Go-native generator)Fix recommendation heading (line 334):
- **Recommendation**
+#### RecommendationFix list indentation - remove the 2-space indentation from all bullet points in Strengths/Weaknesses sections (lines 223-237, 261-276, 302-316, 338-340):
- Strengths:
- - ✅ No runtime dependencies - uses only stdlib (encoding/json)
+ Strengths:
+- ✅ No runtime dependencies - uses only stdlib (encoding/json)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ``` | |
| type Cluster struct { | |
| CreatedTime time.Time `json:"created_time"` | |
| Name string `json:"name" validate:"regexp=^[a-z0-9]([-a-z0-9]*[a-z0-9])?$"` | |
| Spec map[string]interface{} `json:"spec"` | |
| Labels *map[string]string `json:"labels,omitempty"` // pointer for optional | |
| Id *string `json:"id,omitempty"` | |
| } | |
| ``` | |
| Strengths: | |
| - ✅ No runtime dependencies - uses only stdlib (encoding/json) | |
| - ✅ Null-safety pattern with NullableCluster wrapper types | |
| - ✅ Constructor functions (NewCluster, NewClusterWithDefaults) | |
| - ✅ Validation in UnmarshalJSON - checks required properties | |
| - ✅ GetXxxOk() methods return tuple (value, bool) for presence checking | |
| - ✅ HasXxx() methods for optional field presence | |
| - ✅ ToMap() method for generic map conversion | |
| - ✅ Mature tooling - widely used, extensive documentation | |
| Weaknesses: | |
| - ❌ Verbose - each model in separate file with many boilerplate methods | |
| - ❌ Pointer-based optionals (*string) - less idiomatic for Go | |
| - ❌ No built-in validation beyond required field checking | |
| - ❌ Flattens allOf schemas - loses composition structure | |
| - ❌ Java dependency - requires JVM to run generator | |
| --- | |
| #### 2. ogen/ (Go-native generator) | |
| Type Style: | |
| ``` | |
| type Cluster struct { | |
| ID OptString `json:"id"` // Optional type wrapper | |
| Kind string `json:"kind"` | |
| Labels OptClusterLabels `json:"labels"` | |
| Name string `json:"name"` | |
| Spec ClusterSpec `json:"spec"` | |
| Generation int32 `json:"generation"` | |
| Status ClusterStatus `json:"status"` | |
| } | |
| type OptString struct { | |
| Value string | |
| Set bool | |
| } | |
| ``` | |
| Strengths: | |
| - ✅ Opt[T] types for optionals - explicit presence tracking, no nil pointer issues | |
| - ✅ Built-in validation (oas_validators_gen.go) with structured errors | |
| - ✅ OpenTelemetry integration - tracing/metrics out of the box | |
| - ✅ Enum validation with MarshalText/UnmarshalText | |
| - ✅ High-performance JSON using go-faster/jx (no reflection) | |
| - ✅ Generated getters/setters for all fields | |
| - ✅ Pure Go toolchain - no JVM needed | |
| - ✅ Server + Client generation in same package | |
| - ✅ Type-safe response types (GetClusterByIdRes interface) | |
| Weaknesses: | |
| - ❌ Largest output (~20k lines) - more code to maintain | |
| - ❌ Heavy runtime dependencies - ogen-go/ogen, go-faster/*, OTel | |
| - ❌ Learning curve - Opt[T] pattern different from idiomatic Go | |
| - ❌ Less flexibility - opinionated about patterns | |
| - ❌ Flattens allOf - doesn't preserve schema composition | |
| --- | |
| #### 3. oapi-codegen/ (Go-native generator) | |
| Type Style: | |
| ``` | |
| type Cluster struct { | |
| // Preserves allOf composition! | |
| ClusterBase `yaml:",inline"` | |
| CreatedBy openapi_types.Email `json:"created_by"` // Typed email | |
| CreatedTime time.Time `json:"created_time"` | |
| Generation int32 `json:"generation"` | |
| Status ClusterStatus `json:"status"` | |
| } | |
| type ClusterBase struct { | |
| APIResource `yaml:",inline"` | |
| Kind string `json:"kind"` | |
| Name string `json:"name"` | |
| Spec ClusterSpec `json:"spec"` | |
| } | |
| ``` | |
| Strengths: | |
| - ✅ Most compact (~2.5k lines, 2 files) - minimal footprint | |
| - ✅ Preserves allOf composition - embedded structs match schema | |
| - ✅ Semantic types - openapi_types.Email instead of string | |
| - ✅ Lightweight runtime - just oapi-codegen/runtime | |
| - ✅ Pure Go toolchain - no JVM | |
| - ✅ ClientWithResponses - parsed response bodies with type safety | |
| - ✅ RequestEditorFn pattern - clean auth/middleware injection | |
| - ✅ Go-idiomatic - feels like handwritten Go code | |
| Weaknesses: | |
| - ❌ No built-in validation - must add manually or use external | |
| - ❌ Pointer-based optionals (*string) - though less pervasive | |
| - ❌ Fewer accessor methods - direct field access preferred | |
| - ❌ Less observability - no OTel integration | |
| - ❌ Returns *http.Response - need ClientWithResponses for parsed bodies | |
| --- | |
| Comparison Summary | |
| | Feature | main/ | ogen/ | oapi-codegen/ | | |
| |--------------------|-------------|--------------|---------------| | |
| | Code Size | Medium | Large | Small ✅ | | |
| | Runtime Deps | None ✅ | Heavy | Light | | |
| | Optional Handling | Pointers | Opt[T] ✅ | Pointers | | |
| | Validation | Basic | Full ✅ | None | | |
| | Schema Composition | Flattened | Flattened | Preserved ✅ | | |
| | Observability | None | OTel ✅ | None | | |
| | Go Idiomaticity | Medium | Medium | High ✅ | | |
| | Type Safety | Good | Excellent ✅ | Good | | |
| | Maintenance | Java needed | Go | Go | | |
| --- | |
| **Recommendation** | |
| For our use case (types + client only): | |
| - oapi-codegen is the best fit if you want minimal, Go-idiomatic code that preserves your schema composition (allOf inheritance). The embedded struct pattern (ClusterBase → Cluster) is clean and matches your OpenAPI design. | |
| - ogen is better if you need built-in validation, observability (OTel), or are building a complete server+client solution. The Opt[T] pattern is cleaner than nil pointers. | |
| - OpenAPI Generator (main/) is worth keeping if you need maximum compatibility or zero runtime dependencies, though the Java requirement and verbose output are downsides. |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
212-212: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
223-223: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
224-224: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
225-225: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
226-226: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
227-227: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
228-228: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
229-229: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
230-230: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
233-233: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
234-234: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
235-235: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
236-236: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
237-237: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
240-240: Multiple spaces after hash on atx style heading
(MD019, no-multiple-space-atx)
243-243: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
261-261: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
262-262: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
263-263: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
264-264: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
265-265: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
266-266: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
267-267: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
268-268: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
269-269: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
272-272: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
273-273: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
274-274: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
275-275: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
276-276: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
279-279: Multiple spaces after hash on atx style heading
(MD019, no-multiple-space-atx)
282-282: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
302-302: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
303-303: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
304-304: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
305-305: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
306-306: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
307-307: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
308-308: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
309-309: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
312-312: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
313-313: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
314-314: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
315-315: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
316-316: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
334-334: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
338-338: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
339-339: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
340-340: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
🤖 Prompt for AI Agents
In @hyperfleet/standards/generated-code-policy.md around lines 212 - 340, The
markdown has formatting issues: add language specifiers "go" to the three fenced
code blocks that follow each "Type Style:" example, remove extra spaces after
the "####" tokens in the generator section headings (e.g., the lines that render
"#### 2. ogen/..." and the similar one later), convert the "**Recommendation**"
line into a proper heading (e.g., "### Recommendation" or "####
Recommendation"), and dedent all bullet points in the Strengths/Weaknesses lists
so they start at column 0 (apply this to the three generator
Strengths/Weaknesses blocks and the final comparison list).
|
|
||
| Overview | ||
|
|
||
| | Aspect | main/ (OpenAPI Generator) | ogen/ | oapi-codegen/ | |
There was a problem hiding this comment.
The naming "main/" to refer to OpenAPI Generator is confusing throughout this section. It appears to be a directory reference from the original analysis rather than the current branch name.
Consider replacing "main/" with "OpenAPI Generator" (or "openapi-gen" if a shorter form is needed) in the tables and headings for clarity
|
Wow! What awesome exploration! Congrats! Besides the comment related to the usage of main/, I don't have anything further to add. |
2 participants
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.