Skip to content

BKG 2.0: SD-3105: Include OOG object - #639

Merged
HenrikHL merged 5 commits into
masterfrom
SD-3105_Include-OOG-object
Jul 31, 2026
Merged

BKG 2.0: SD-3105: Include OOG object#639
HenrikHL merged 5 commits into
masterfrom
SD-3105_Include-OOG-object

Conversation

@HenrikHL

@HenrikHL HenrikHL commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

SD-3105: Include Out of Gauge object. Improved the referencePoint to include the entire list of possible values (as a PseudoEnum)

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

BKG v2.0.5: add Out-of-Gauge (OOG) details and quote reference

✨ Enhancement 🕐 20-40 Minutes

Grey Divider

AI Description

• Add OOGQuoteReference to booking schemas to reference prior OOG feasibility/quote.
• Extend requested equipment with OOGDetails to capture out-of-gauge requirements.
• Introduce OOG sub-schemas for dimensions, extensions, and center-of-gravity reference points.
Diagram

graph TD
  F["bkg/v2/BKG_v2.0.5.yaml"] --> S["Booking schemas"] --> RE["RequestedEquipment"] --> OOG["OOGDetails"] --> COG["CenterOfGravity"] --> M["Measurement"]
  OOG --> TDIMS["Total dimensions"]
  OOG --> EXT["OOG extensions"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Make `referencePoint` a strict enum
  • ➕ Enables schema-level validation and stronger code generation
  • ➕ Prevents typo/invalid values at runtime
  • ➖ More rigid; adding new values becomes a breaking change for some generators
  • ➖ May require additional versioning discipline for extensions
2. Reuse an existing measurement component (if already present)
  • ➕ Avoids duplicated concepts and keeps units/classifiers consistent across the spec
  • ➕ Reduces maintenance surface area
  • ➖ May require refactoring existing references and could ripple across the contract
  • ➖ Not possible if no prior reusable measurement schema exists

Recommendation: The PR’s approach (introducing OOGDetails as a dedicated object and documenting referencePoint as a pseudo-enum) is reasonable for incremental contract expansion. If downstream consumers rely heavily on codegen/validation, consider promoting referencePoint to an actual enum in a follow-up (or when the value set is stable) to improve correctness.

Files changed (1) +238 / -0

Enhancement (1) +238 / -0
BKG_v2.0.5.yamlAdd OOG quote reference and Out-of-Gauge schema model +238/-0

Add OOG quote reference and Out-of-Gauge schema model

• Adds 'OOGQuoteReference' to multiple booking-related schemas to capture a prior OOG feasibility/quote reference. Extends requested equipment schemas with 'OOGDetails' and introduces new component schemas ('OOGDetails', 'TotalCargoDimensions', 'OutOfGaugeExtensions', 'CenterOfGravity', 'Measurement') including an expanded documented value set for 'centerOfGravity.referencePoint'.

bkg/v2/BKG_v2.0.5.yaml

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the BKG 2.0 (v2.0.5) OpenAPI specification to support Out of Gauge (OOG) data in booking requests, including introducing an OOGDetails object and documenting center-of-gravity reference points as a pseudo-enum.

Changes:

  • Adds OOGQuoteReference to multiple booking-related schemas.
  • Adds OOGDetails to requested equipment structures.
  • Introduces new component schemas for OOG details (OOGDetails, TotalCargoDimensions, OutOfGaugeExtensions, CenterOfGravity) and a generic Measurement.
Comments suppressed due to low confidence (2)

bkg/v2/BKG_v2.0.5.yaml:3854

  • OOGQuoteReference is missing the no-leading/trailing-whitespace pattern used by the other *QuotationReference fields in this schema (e.g., contractQuotationReference, extendedContractQuotationReference). Without it, values like " ABC " are considered valid.
        OOGQuoteReference:
          type: string
          maxLength: 100

bkg/v2/BKG_v2.0.5.yaml:3377

  • OOGQuoteReference is missing the no-leading/trailing-whitespace pattern used by the other *QuotationReference fields in this schema (e.g., contractQuotationReference, extendedContractQuotationReference). Without it, values like " ABC " are considered valid.
        OOGQuoteReference:
          type: string
          maxLength: 100

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread bkg/v2/BKG_v2.0.5.yaml Outdated
Comment thread bkg/v2/BKG_v2.0.5.yaml Outdated
Comment thread bkg/v2/BKG_v2.0.5.yaml Outdated
Comment thread bkg/v2/BKG_v2.0.5.yaml Outdated
Comment thread bkg/v2/BKG_v2.0.5.yaml
@qodo-code-review

qodo-code-review Bot commented Jul 30, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

Grey Divider


Action required

1. Offset field misspelled ✓ Resolved 🐞 Bug ≡ Correctness
Description
CenterOfGravity exposes the transverse offset as traverseOffset, while the description says
“Transverse offset”; this typo becomes part of the published API contract and will force consumers
to use a misspelled JSON field or require a breaking rename later.
Code

bkg/v2/BKG_v2.0.5.yaml[R7010-7014]

+        traverseOffset:
+          type: object
+          title: Traverse Offset
+          description: |
+            Transverse offset of the center of gravity from the defined reference point.
Evidence
The schema defines the property name as traverseOffset while simultaneously describing it as a
“Transverse offset”, indicating the property name is likely a typo that would be exposed to API
consumers.

bkg/v2/BKG_v2.0.5.yaml[6963-7016]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CenterOfGravity.properties` defines `traverseOffset`, but the field is clearly intended to be the **transverse** offset (the description text uses “Transverse offset”). Because this is a schema property name, it becomes a public JSON field name.

### Issue Context
This is newly introduced as part of the OOG object addition. Fixing the name now avoids locking in a misspelling in generated clients/servers and downstream integrations.

### Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[7010-7016]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. OOG quote unvalidated 🐞 Bug ≡ Correctness ⭐ New
Description
outOfGaugeQuoteReference was added without the repo’s typical non-blank/trimmed-string pattern,
so the schema permits empty/whitespace-only values and leading/trailing whitespace unlike other
reference fields. This can lead to inconsistent payload validation and lower data quality across
clients/servers relying on the OpenAPI contract.
Code

bkg/v2/BKG_v2.0.5.yaml[R2964-2966]

+        outOfGaugeQuoteReference:
+          type: string
+          maxLength: 70
Evidence
The new outOfGaugeQuoteReference definition lacks the pattern constraint that existing
quotation/reference fields use to prevent blank or whitespace-padded values; the file shows this
discrepancy directly at all three insertion points.

bkg/v2/BKG_v2.0.5.yaml[2941-2969]
bkg/v2/BKG_v2.0.5.yaml[2964-2970]
bkg/v2/BKG_v2.0.5.yaml[3352-3381]
bkg/v2/BKG_v2.0.5.yaml[3829-3858]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`outOfGaugeQuoteReference` is defined as a plain `string` with `maxLength`, but it does not include the standard non-blank/trimmed-string constraint used by similar reference fields in this spec (e.g., `contractQuotationReference`, `extendedContractQuotationReference`). As a result, the OpenAPI contract allows `""`, whitespace-only strings, and strings with leading/trailing whitespace.

## Issue Context
This field is added in three separate schemas/locations. All three definitions should be kept consistent with existing reference-field validation rules.

## Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[2964-2969]
- bkg/v2/BKG_v2.0.5.yaml[3375-3380]
- bkg/v2/BKG_v2.0.5.yaml[3852-3857]

## Suggested fix
For each `outOfGaugeQuoteReference` occurrence, add the same pattern used by other reference fields, e.g.:

```yaml
outOfGaugeQuoteReference:
 type: string
 pattern: ^\S(?:.*\S)?$
 maxLength: 70
 description: |
   ...
```

(Optionally also align other metadata like `example` positioning, but the key fix is the `pattern`.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Measurement enums missing 🐞 Bug ≡ Correctness
Description
Measurement.unit and Measurement.classifier list allowed codes only in the description but
remain unconstrained strings, so OpenAPI validation and client generation cannot reliably
enforce/derive the intended code lists. This is inconsistent with existing unit fields like
TareWeight.unit, which are explicitly constrained via enum.
Code

bkg/v2/BKG_v2.0.5.yaml[R7045-7055]

+          maxLength: 3
+          description: |
+            Unit in which the measurement value is expressed. Possible values:
+            - `MTR` (metre)
+            - `CMT` (centimetre)
+            - `FOT` (foot)
+            - `INH` (inch)
+          example: MTR
+        classifier:
+          type: string
+          maxLength: 3
Evidence
The Measurement schema defines unit/classifier as strings with only maxLength, while the
allowed values are only mentioned in description. Elsewhere (e.g., TareWeight.unit) the spec
encodes allowed unit values via enum, demonstrating the expected approach for code lists.

bkg/v2/BKG_v2.0.5.yaml[7033-7064]
bkg/v2/BKG_v2.0.5.yaml[5507-5535]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`Measurement.unit` and `Measurement.classifier` describe allowed values in text but do not define `enum`, so schema validators and code generators will treat them as arbitrary strings.

### Issue Context
Other schemas in this spec (e.g., `TareWeight.unit`) use `enum` to make such code lists machine-readable.

### Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[7043-7064]

### Suggested fix
- Add `enum: [MTR, CMT, FOT, INH]` under `Measurement.unit`.
- Add `enum: [EST, CON]` under `Measurement.classifier`.
- If extensibility is desired, consider using the project’s preferred extensible-enum pattern (if any) rather than leaving the field unconstrained.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

4. Example inside description block ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
referencePoint includes example: BOTTOM_FRONT_LEFT indented inside the description: | block,
so OpenAPI tooling will treat it as plain text and the schema will have no example metadata for
this property.
Code

bkg/v2/BKG_v2.0.5.yaml[R6999-7003]

+            - `TOP_REAR_LEFT` (Top Rear Left)
+            - `TOP_REAR_CENTER` (Top Rear Center)
+            - `TOP_REAR_RIGHT` (Top Rear Right)
+            example: BOTTOM_FRONT_LEFT
+        longitudinalOffset:
Evidence
The example: BOTTOM_FRONT_LEFT line is aligned with other description text lines (not with
type:/description:), meaning it is included in the description string rather than being a
schema keyword.

bkg/v2/BKG_v2.0.5.yaml[6969-7004]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
In `CenterOfGravity.referencePoint`, the line `example: BOTTOM_FRONT_LEFT` is currently part of the YAML block-scalar for `description` due to indentation. That means it is not parsed as an OpenAPI `example` keyword.

### Issue Context
This impacts documentation rendering and codegen metadata quality for the newly added OOG CenterOfGravity schema.

### Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[6969-7003]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Previous review results

Review updated until commit dd1c518

Results up to commit e88d0d6 ⚖️ Balanced


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)


Action required
1. Offset field misspelled ✓ Resolved 🐞 Bug ≡ Correctness
Description
CenterOfGravity exposes the transverse offset as traverseOffset, while the description says
“Transverse offset”; this typo becomes part of the published API contract and will force consumers
to use a misspelled JSON field or require a breaking rename later.
Code

bkg/v2/BKG_v2.0.5.yaml[R7010-7014]

+        traverseOffset:
+          type: object
+          title: Traverse Offset
+          description: |
+            Transverse offset of the center of gravity from the defined reference point.
Evidence
The schema defines the property name as traverseOffset while simultaneously describing it as a
“Transverse offset”, indicating the property name is likely a typo that would be exposed to API
consumers.

bkg/v2/BKG_v2.0.5.yaml[6963-7016]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CenterOfGravity.properties` defines `traverseOffset`, but the field is clearly intended to be the **transverse** offset (the description text uses “Transverse offset”). Because this is a schema property name, it becomes a public JSON field name.

### Issue Context
This is newly introduced as part of the OOG object addition. Fixing the name now avoids locking in a misspelling in generated clients/servers and downstream integrations.

### Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[7010-7016]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational
2. Example inside description block ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
referencePoint includes example: BOTTOM_FRONT_LEFT indented inside the description: | block,
so OpenAPI tooling will treat it as plain text and the schema will have no example metadata for
this property.
Code

bkg/v2/BKG_v2.0.5.yaml[R6999-7003]

+            - `TOP_REAR_LEFT` (Top Rear Left)
+            - `TOP_REAR_CENTER` (Top Rear Center)
+            - `TOP_REAR_RIGHT` (Top Rear Right)
+            example: BOTTOM_FRONT_LEFT
+        longitudinalOffset:
Evidence
The example: BOTTOM_FRONT_LEFT line is aligned with other description text lines (not with
type:/description:), meaning it is included in the description string rather than being a
schema keyword.

bkg/v2/BKG_v2.0.5.yaml[6969-7004]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
In `CenterOfGravity.referencePoint`, the line `example: BOTTOM_FRONT_LEFT` is currently part of the YAML block-scalar for `description` due to indentation. That means it is not parsed as an OpenAPI `example` keyword.

### Issue Context
This impacts documentation rendering and codegen metadata quality for the newly added OOG CenterOfGravity schema.

### Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[6969-7003]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit ed4c2e4 ⚖️ Balanced


🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)


Remediation recommended
1. Measurement enums missing 🐞 Bug ≡ Correctness
Description
Measurement.unit and Measurement.classifier list allowed codes only in the description but
remain unconstrained strings, so OpenAPI validation and client generation cannot reliably
enforce/derive the intended code lists. This is inconsistent with existing unit fields like
TareWeight.unit, which are explicitly constrained via enum.
Code

bkg/v2/BKG_v2.0.5.yaml[R7045-7055]

+          maxLength: 3
+          description: |
+            Unit in which the measurement value is expressed. Possible values:
+            - `MTR` (metre)
+            - `CMT` (centimetre)
+            - `FOT` (foot)
+            - `INH` (inch)
+          example: MTR
+        classifier:
+          type: string
+          maxLength: 3
Evidence
The Measurement schema defines unit/classifier as strings with only maxLength, while the
allowed values are only mentioned in description. Elsewhere (e.g., TareWeight.unit) the spec
encodes allowed unit values via enum, demonstrating the expected approach for code lists.

bkg/v2/BKG_v2.0.5.yaml[7033-7064]
bkg/v2/BKG_v2.0.5.yaml[5507-5535]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`Measurement.unit` and `Measurement.classifier` describe allowed values in text but do not define `enum`, so schema validators and code generators will treat them as arbitrary strings.

### Issue Context
Other schemas in this spec (e.g., `TareWeight.unit`) use `enum` to make such code lists machine-readable.

### Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[7043-7064]

### Suggested fix
- Add `enum: [MTR, CMT, FOT, INH]` under `Measurement.unit`.
- Add `enum: [EST, CON]` under `Measurement.classifier`.
- If extensibility is desired, consider using the project’s preferred extensible-enum pattern (if any) rather than leaving the field unconstrained.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

Comment thread bkg/v2/BKG_v2.0.5.yaml Outdated
Comment thread bkg/v2/BKG_v2.0.5.yaml
@HenrikHL

Copy link
Copy Markdown
Contributor Author

/agentic

@HenrikHL

Copy link
Copy Markdown
Contributor Author

/agentic_review

Comment thread bkg/v2/BKG_v2.0.5.yaml
@qodo-code-review

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit ed4c2e4

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

bkg/v2/BKG_v2.0.5.yaml:3375

  • Property name OOGQuoteReference uses UpperCamelCase, but UpdateBooking request fields here use lowerCamelCase (e.g., serviceContractReference, extendedContractQuotationReference). Consider renaming to keep JSON property naming consistent.
        OOGQuoteReference:

bkg/v2/BKG_v2.0.5.yaml:3852

  • Property name OOGQuoteReference is UpperCamelCase while surrounding properties are lowerCamelCase. Keeping property casing consistent helps avoid surprising API payload shapes and code generation differences.
        OOGQuoteReference:

bkg/v2/BKG_v2.0.5.yaml:2964

  • Property name OOGQuoteReference uses UpperCamelCase, but this schema’s other request fields use lowerCamelCase (e.g., serviceContractReference, extendedContractQuotationReference). This inconsistency will leak into generated client/server models and makes the JSON payload less predictable.

This issue also appears in the following locations of the same file:

  • line 3375
  • line 3852
        OOGQuoteReference:

bkg/v2/BKG_v2.0.5.yaml:6850

  • OOGDetails schema description says it “Indicates whether” the cargo exceeds dimensions, but the schema is an object containing detailed dimension/handling fields (not a boolean indicator). Updating the description would better match the actual payload shape.
      description: |
        Indicates whether the cargo exceeds one or more of the standard external dimensions of the equipment unit.

@HenrikHL

Copy link
Copy Markdown
Contributor Author

/agentic-review

@HenrikHL

Copy link
Copy Markdown
Contributor Author

/agentic_review

Comment thread bkg/v2/BKG_v2.0.5.yaml
Comment on lines +2964 to +2966
outOfGaugeQuoteReference:
type: string
maxLength: 70

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Oog quote unvalidated 🐞 Bug ≡ Correctness

outOfGaugeQuoteReference was added without the repo’s typical non-blank/trimmed-string pattern,
so the schema permits empty/whitespace-only values and leading/trailing whitespace unlike other
reference fields. This can lead to inconsistent payload validation and lower data quality across
clients/servers relying on the OpenAPI contract.
Agent Prompt
## Issue description
`outOfGaugeQuoteReference` is defined as a plain `string` with `maxLength`, but it does not include the standard non-blank/trimmed-string constraint used by similar reference fields in this spec (e.g., `contractQuotationReference`, `extendedContractQuotationReference`). As a result, the OpenAPI contract allows `""`, whitespace-only strings, and strings with leading/trailing whitespace.

## Issue Context
This field is added in three separate schemas/locations. All three definitions should be kept consistent with existing reference-field validation rules.

## Fix Focus Areas
- bkg/v2/BKG_v2.0.5.yaml[2964-2969]
- bkg/v2/BKG_v2.0.5.yaml[3375-3380]
- bkg/v2/BKG_v2.0.5.yaml[3852-3857]

## Suggested fix
For each `outOfGaugeQuoteReference` occurrence, add the same pattern used by other reference fields, e.g.:

```yaml
outOfGaugeQuoteReference:
  type: string
  pattern: ^\S(?:.*\S)?$
  maxLength: 70
  description: |
    ...
```

(Optionally also align other metadata like `example` positioning, but the key fix is the `pattern`.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@qodo-code-review

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit dd1c518

@HenrikHL
HenrikHL merged commit 1885401 into master Jul 31, 2026
1 check passed
@HenrikHL
HenrikHL deleted the SD-3105_Include-OOG-object branch July 31, 2026 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants