Skip to content

CS 1.0: SD-3385: Add Waterways to CS Vessel Schedules - #656

Open
HenrikHL wants to merge 3 commits into
masterfrom
SD-3385_Waterways
Open

HenrikHL wants to merge 3 commits into
masterfrom
SD-3385_Waterways

Conversation

@HenrikHL

@HenrikHL HenrikHL commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

SD-3385: In Vessel Schedules - add waterways like in OVS

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Support SMDG Waterway Calls in CS Vessel Schedules

✨ Enhancement 📝 Documentation 🕐 20-40 Minutes

Grey Divider

AI Description

• Adds SMDG waterway entry points to Vessel Schedule TransportCalls.
• Defines references, timestamps, and cargo-operation rules for waterway calls.
• Generalizes endpoint documentation and provides port-only and waterway response examples.
Diagram

graph TD
  A["Vessel Schedule API"] --> B["TransportCall"] --> C{"Location kind"}
  C -->|Port| D["Port call"] --> E["Cargo default true"]
  C -->|Waterway code| F["Waterway point"] --> G["No port reference"] --> H["Cargo false"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Introduce dedicated waterway location schema
  • ➕ Enforces waterway-specific required and forbidden fields through OpenAPI validation.
  • ➕ Makes port and waterway variants explicit to generated clients.
  • ➖ Would introduce oneOf or discriminator complexity into the existing location model.
  • ➖ Could disrupt generated clients and exceed the compatibility expectations of a patch release.
2. Add an explicit locationType property
  • ➕ Aligns classification more directly with the OVS waterway model.
  • ➕ Allows waterways to be identified independently of an entry-point code.
  • ➖ Adds another field that producers and consumers must coordinate.
  • ➖ Creates a risk of inconsistent locationType and waterway code combinations.

Recommendation: Retain the PR's optional-property approach for CS 1.0.4 because it adds waterway support without restructuring the established TransportCallLocation schema or breaking generated clients. A discriminated location model would improve machine validation, but is better reserved for a future major version because this patch expresses conditional requirements primarily through documentation.

Files changed (2) +229 / -18

Enhancement (1) +195 / -18
CS_v1.0.4.yamlDefine waterway TransportCalls in the CS 1.0.4 specification +195/-18

Define waterway TransportCalls in the CS 1.0.4 specification

• Adds waterwaySMDGEntryPointCode to TransportCallLocation and defines its required pairing with UNLocationCode. Documents waterway-specific reference, cargo-operation, ordering, and timestamp semantics; generalizes endpoint wording and adds response examples with and without waterways.

cs/v1/CS_v1.0.4.yaml

Documentation (1) +34 / -0
README.mdDocument CS 1.0.4 waterway schedule behavior +34/-0

Document CS 1.0.4 waterway schedule behavior

• Adds release notes covering SMDG waterway entry points, cargo-operation requirements, references, timestamps, sequencing, compatibility considerations, and generalized TransportCall terminology.

cs/v1/README.md

@qodo-code-review

qodo-code-review Bot commented Sep 21, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

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

Grey Divider


Action required

1. Departure times may miss date filters 📎 Requirement gap ≡ Correctness ⭐ New
Description
The startDate and endDate descriptions define any Timestamp with an exhaustive-looking list of
only ATA, ETA, and PTA, omitting the corresponding departure timestamps. When a waterway call
publishes only DEPA, as the contract permits, the filter documentation does not establish whether
its actual, estimated, or planned departure date participates in matching.
Code

cs/v1/CS_v1.0.4.yaml[R722-723]

+            The start date of the period for which schedule information is requested. If the date of any Timestamp (ATA, ETA or PTA) within a TransportCall is on or after (`>=`) the `startDate`, the entire Voyage (import and export Voyage) containing that TransportCall will be included in the result. Matching is performed using the local date at the TransportCall location.
+
Evidence
Compliance rule 3 requires Timestamp documentation to permit ARRI, DEPA, or both for waterways.
Both updated filter descriptions characterize any timestamp using only arrival combinations, while
the Timestamp schema permits DEPA.

Document WWAY TransportCall and event semantics
cs/v1/CS_v1.0.4.yaml[722-723]
cs/v1/CS_v1.0.4.yaml[732-733]
cs/v1/CS_v1.0.4.yaml[1251-1261]

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

## Issue description
The date-filter descriptions list only arrival timestamps even though a waterway TransportCall may publish only a departure event.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[722-723]
- cs/v1/CS_v1.0.4.yaml[732-733]

## Recommended Fix
Update both filter descriptions to include `ATD`, `ETD`, and `PTD`, or remove the restrictive parenthetical and state unambiguously that timestamps derived from either `ARRI` or `DEPA` participate in matching.

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


2. Port calls are declared nonconformant 📎 Requirement gap ≡ Correctness ⭐ New
Description
The final sentence in TransportCall.description applies the preceding waterway-only conditions to
every TransportCall instead of limiting them to calls represented as waterways. Ordinary port
calls intentionally include portVisitReference and may set isCargoOperationalCall to true, so
the specification's supported port branch and its own port examples also reach this unconditional
conformance check.
Code

cs/v1/CS_v1.0.4.yaml[1146]

+        A TransportCall that does not satisfy these conditions does not conform to this specification.
Evidence
Compliance rule 7 requires the schedule documentation to accommodate both port and waterway
TransportCall objects, but the listed conditions require omission of portVisitReference and a
false cargo-operation flag even though portVisitReference is explicitly applicable to ports. The
specification's port example supplies portVisitReference and sets the cargo flag to true, and
because line 1146 says “A TransportCall” without restricting the statement to waterways, that valid
example fails the stated conditions.

Remove port-only assumptions from schedule documentation
cs/v1/CS_v1.0.4.yaml[1141-1146]
cs/v1/CS_v1.0.4.yaml[1152-1157]
cs/v1/CS_v1.0.4.yaml[1140-1146]
cs/v1/CS_v1.0.4.yaml[509-520]

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

## Issue description
The conformance sentence applies waterway-specific requirements to every `TransportCall`, unintentionally making supported ordinary port calls appear nonconformant.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[1140-1146]

## Recommended Fix
Rewrite the final sentence so it applies only to a `TransportCall` identified as representing a waterway location, leaving ordinary port calls outside these waterway-only conditions. For example: “A waterway TransportCall that does not satisfy these conditions does not conform to this specification.”

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


3. Waterways require point-level precision ✗ Dismissed 📎 Requirement gap ≡ Correctness
Description
TransportCallLocation and the new example use the presence of waterwaySMDGEntryPointCode to
distinguish waterways, so omitting that optional code makes the same UN location a non-waterway
location. Carriers therefore cannot represent a waterway at waterway-only precision, and consumers
receive no semantics explaining the loss of point-level precision when the code is absent.
Code

cs/v1/CS_v1.0.4.yaml[R431-433]

+                  summary: Vessel schedule containing only port TransportCalls
+                  description: |
+                    A vessel schedule containing ordinary port TransportCalls. The locations do not contain `waterwaySMDGEntryPointCode`, so they are not waterway locations.
Evidence
The example explicitly says that locations without waterwaySMDGEntryPointCode are not waterways,
while the schema likewise makes the property's presence the waterway marker. This contradicts the
required optional entry-point representation and omitted-code precision semantics.

Model Waterway Identification Fields Correctly
Document Precision When Entry-Point Code Is Omitted
Preserve One-Location-Per-WWAY-TransportCall Semantics
cs/v1/CS_v1.0.4.yaml[431-433]
cs/v1/CS_v1.0.4.yaml[2041-2047]
cs/v1/CS_v1.0.4.yaml[2097-2108]

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

## Issue description
Waterway identity currently depends on `waterwaySMDGEntryPointCode`, although the entry-point code must remain optional and its omission should identify the waterway without a specific point.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[431-433]
- cs/v1/CS_v1.0.4.yaml[2036-2047]
- cs/v1/CS_v1.0.4.yaml[2097-2108]
- cs/v1/README.md[26-35]

## Recommended Fix
Add an explicit way to identify a waterway independently of `waterwaySMDGEntryPointCode`. Require `UNLocationCode` for such locations, keep the entry-point code optional, and document that omission identifies only the waterway and cannot imply a point for arrival or departure events.

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


View high (2)
4. Date filters still assume port calls ✓ Resolved 📎 Requirement gap ≡ Correctness
Description
The updated startDate and endDate descriptions use TransportCall as the timestamp container
but still define voyage matching through a PortCall and calculate the local date at the place of
the port call. When the timestamp belongs to a waterway TransportCall, there is no port call to
supply either concept, so consumers and providers lack complete guidance for voyage matching and
date boundaries.
Code

cs/v1/CS_v1.0.4.yaml[722]

+            The start date of the period for which schedule information is requested. If a date of any Timestamp (ATA, ETA or PTA) inside a TransportCall matches a date on or after (≥) the `startDate` the entire Voyage (import- and export-Voyage) matching the PortCall will be included in the result. All matching is done towards local Date at the place of the port call.
Evidence
Both modified date-filter descriptions include every TransportCall but then describe voyage
matching and local-date handling only in terms of port calls, even though the updated
TransportCall definition explicitly permits waterway locations and the checklist requires the
filter and response documentation to accommodate waterways.

Remove Port-Only Wording from Schedule Documentation
cs/v1/CS_v1.0.4.yaml[722-722]
cs/v1/CS_v1.0.4.yaml[731-731]
cs/v1/CS_v1.0.4.yaml[787-789]
cs/v1/CS_v1.0.4.yaml[719-732]
cs/v1/CS_v1.0.4.yaml[1128-1137]

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

## Issue description
The date-filter documentation retains port-only terminology after adding waterway `TransportCall`s, leaving voyage matching and local-date handling undefined for waterway timestamps.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[719-732]
- cs/v1/CS_v1.0.4.yaml[787-789]

## Recommended Fix
Replace the remaining `PortCall`, `Port`, and `port call` references in both date filters with `TransportCall` and location-neutral terminology where the behavior also applies to waterways. Explicitly define matching and date calculation using the local date at the location represented by the `TransportCall`, while preserving port-specific language only where the behavior genuinely depends on a port.

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


5. Validators accept invalid waterway calls ✗ Dismissed 🐞 Bug ≡ Correctness
Description
TransportCallLocation adds waterwaySMDGEntryPointCode as an independently optional property,
while the related UNLocationCode, false cargo flag, and absent port reference are required only by
prose. OpenAPI validators therefore accept a code without its location, an omitted default-true
cargo flag, or a port reference on a waterway call, allowing generated consumers to process payloads
that violate the published contract.
Code

cs/v1/CS_v1.0.4.yaml[R2097-2100]

+        waterwaySMDGEntryPointCode:
+          type: string
+          maxLength: 6
+          description: |
Evidence
The property schema only limits the code's maximum length, while all co-occurrence and TransportCall
restrictions are prose. The cargo property remains optional with a true default, and the port
reference remains an unrestricted optional property.

cs/v1/CS_v1.0.4.yaml[1138-1148]
cs/v1/CS_v1.0.4.yaml[1207-1216]
cs/v1/CS_v1.0.4.yaml[2033-2047]
cs/v1/CS_v1.0.4.yaml[2097-2108]

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

## Issue description
Waterway constraints are expressed only in descriptions, so OpenAPI validation accepts calls that violate the published contract.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[1131-1216]
- cs/v1/CS_v1.0.4.yaml[2033-2109]

## Recommended Fix
Introduce explicit waterway and non-waterway schema branches using `oneOf` or equivalent OpenAPI 3.0-compatible composition. Require `UNLocationCode` whenever `waterwaySMDGEntryPointCode` is present, require `isCargoOperationalCall: false`, reject `portVisitReference` for that branch, and prevent an empty entry-point code.

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



Remediation recommended

6. Release links become ambiguous ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
README.md adds a second v104 anchor and complete v1.0.4 release block instead of extending the
block already at the top. The changelog now repeats the release and cargo-call notes, while #v104
links cannot uniquely address the new waterway section.
Code

cs/v1/README.md[R15-17]

+<a name="v104"></a>[Release v1.0.4](https://app.swaggerhub.com/apis-docs/dcsaorg/DCSA_CS/1.0.4)
+---
+This patch adds support for identifying cargo-operational calls and representing SMDG waterway entry points in Vessel Schedules.
Evidence
The file already declares the v104 anchor and v1.0.4 release at line 5, and the added block
repeats that exact anchor, release link, and the existing cargo-call bullets.

cs/v1/README.md[5-14]
cs/v1/README.md[15-24]

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

## Issue description
The changelog contains two v1.0.4 sections with the same HTML anchor, producing duplicated content and an ambiguous fragment target.

## Fix Focus Areas
- cs/v1/README.md[5-48]

## Recommended Fix
Keep one `v104` anchor and release heading, then merge the waterway notes into the existing v1.0.4 section without repeating the cargo-operational-call introduction.

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


Grey Divider

Context sources
Review mode: ⚖️ Balanced: This push changes public API specification semantics for waterway TransportCalls and date filtering, creating contract-level correctness risk that warrants a complete review.

Grey Divider

Tip of the day
💡 Did you know, you can choose which labels appear on a finding, and whether they show icons or text

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Previous reviews

Review updated until commit f91824c

Results up to commit 539c1d9 ⚖️ Balanced


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


Action required
1. Waterways require point-level precision ✗ Dismissed 📎 Requirement gap ≡ Correctness
Description
TransportCallLocation and the new example use the presence of waterwaySMDGEntryPointCode to
distinguish waterways, so omitting that optional code makes the same UN location a non-waterway
location. Carriers therefore cannot represent a waterway at waterway-only precision, and consumers
receive no semantics explaining the loss of point-level precision when the code is absent.
Code

cs/v1/CS_v1.0.4.yaml[R431-433]

+                  summary: Vessel schedule containing only port TransportCalls
+                  description: |
+                    A vessel schedule containing ordinary port TransportCalls. The locations do not contain `waterwaySMDGEntryPointCode`, so they are not waterway locations.
Evidence
The example explicitly says that locations without waterwaySMDGEntryPointCode are not waterways,
while the schema likewise makes the property's presence the waterway marker. This contradicts the
required optional entry-point representation and omitted-code precision semantics.

Model Waterway Identification Fields Correctly
Document Precision When Entry-Point Code Is Omitted
Preserve One-Location-Per-WWAY-TransportCall Semantics
cs/v1/CS_v1.0.4.yaml[431-433]
cs/v1/CS_v1.0.4.yaml[2041-2047]
cs/v1/CS_v1.0.4.yaml[2097-2108]

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

## Issue description
Waterway identity currently depends on `waterwaySMDGEntryPointCode`, although the entry-point code must remain optional and its omission should identify the waterway without a specific point.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[431-433]
- cs/v1/CS_v1.0.4.yaml[2036-2047]
- cs/v1/CS_v1.0.4.yaml[2097-2108]
- cs/v1/README.md[26-35]

## Recommended Fix
Add an explicit way to identify a waterway independently of `waterwaySMDGEntryPointCode`. Require `UNLocationCode` for such locations, keep the entry-point code optional, and document that omission identifies only the waterway and cannot imply a point for arrival or departure events.

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


2. Date filters still assume port calls ✓ Resolved 📎 Requirement gap ≡ Correctness
Description
The updated startDate and endDate descriptions use TransportCall as the timestamp container
but still define voyage matching through a PortCall and calculate the local date at the place of
the port call. When the timestamp belongs to a waterway TransportCall, there is no port call to
supply either concept, so consumers and providers lack complete guidance for voyage matching and
date boundaries.
Code

cs/v1/CS_v1.0.4.yaml[722]

+            The start date of the period for which schedule information is requested. If a date of any Timestamp (ATA, ETA or PTA) inside a TransportCall matches a date on or after (≥) the `startDate` the entire Voyage (import- and export-Voyage) matching the PortCall will be included in the result. All matching is done towards local Date at the place of the port call.
Evidence
Both modified date-filter descriptions include every TransportCall but then describe voyage
matching and local-date handling only in terms of port calls, even though the updated
TransportCall definition explicitly permits waterway locations and the checklist requires the
filter and response documentation to accommodate waterways.

Remove Port-Only Wording from Schedule Documentation
cs/v1/CS_v1.0.4.yaml[722-722]
cs/v1/CS_v1.0.4.yaml[731-731]
cs/v1/CS_v1.0.4.yaml[787-789]
cs/v1/CS_v1.0.4.yaml[719-732]
cs/v1/CS_v1.0.4.yaml[1128-1137]

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

## Issue description
The date-filter documentation retains port-only terminology after adding waterway `TransportCall`s, leaving voyage matching and local-date handling undefined for waterway timestamps.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[719-732]
- cs/v1/CS_v1.0.4.yaml[787-789]

## Recommended Fix
Replace the remaining `PortCall`, `Port`, and `port call` references in both date filters with `TransportCall` and location-neutral terminology where the behavior also applies to waterways. Explicitly define matching and date calculation using the local date at the location represented by the `TransportCall`, while preserving port-specific language only where the behavior genuinely depends on a port.

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


3. Validators accept invalid waterway calls ✗ Dismissed 🐞 Bug ≡ Correctness
Description
TransportCallLocation adds waterwaySMDGEntryPointCode as an independently optional property,
while the related UNLocationCode, false cargo flag, and absent port reference are required only by
prose. OpenAPI validators therefore accept a code without its location, an omitted default-true
cargo flag, or a port reference on a waterway call, allowing generated consumers to process payloads
that violate the published contract.
Code

cs/v1/CS_v1.0.4.yaml[R2097-2100]

+        waterwaySMDGEntryPointCode:
+          type: string
+          maxLength: 6
+          description: |
Evidence
The property schema only limits the code's maximum length, while all co-occurrence and TransportCall
restrictions are prose. The cargo property remains optional with a true default, and the port
reference remains an unrestricted optional property.

cs/v1/CS_v1.0.4.yaml[1138-1148]
cs/v1/CS_v1.0.4.yaml[1207-1216]
cs/v1/CS_v1.0.4.yaml[2033-2047]
cs/v1/CS_v1.0.4.yaml[2097-2108]

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

## Issue description
Waterway constraints are expressed only in descriptions, so OpenAPI validation accepts calls that violate the published contract.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[1131-1216]
- cs/v1/CS_v1.0.4.yaml[2033-2109]

## Recommended Fix
Introduce explicit waterway and non-waterway schema branches using `oneOf` or equivalent OpenAPI 3.0-compatible composition. Require `UNLocationCode` whenever `waterwaySMDGEntryPointCode` is present, require `isCargoOperationalCall: false`, reject `portVisitReference` for that branch, and prevent an empty entry-point code.

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



Remediation recommended
4. Release links become ambiguous ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
README.md adds a second v104 anchor and complete v1.0.4 release block instead of extending the
block already at the top. The changelog now repeats the release and cargo-call notes, while #v104
links cannot uniquely address the new waterway section.
Code

cs/v1/README.md[R15-17]

+<a name="v104"></a>[Release v1.0.4](https://app.swaggerhub.com/apis-docs/dcsaorg/DCSA_CS/1.0.4)
+---
+This patch adds support for identifying cargo-operational calls and representing SMDG waterway entry points in Vessel Schedules.
Evidence
The file already declares the v104 anchor and v1.0.4 release at line 5, and the added block
repeats that exact anchor, release link, and the existing cargo-call bullets.

cs/v1/README.md[5-14]
cs/v1/README.md[15-24]

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

## Issue description
The changelog contains two v1.0.4 sections with the same HTML anchor, producing duplicated content and an ambiguous fragment target.

## Fix Focus Areas
- cs/v1/README.md[5-48]

## Recommended Fix
Keep one `v104` anchor and release heading, then merge the waterway notes into the existing v1.0.4 section without repeating the cargo-operational-call introduction.

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


Grey Divider

Qodo Logo

Comment thread cs/v1/CS_v1.0.4.yaml
Comment thread cs/v1/CS_v1.0.4.yaml Outdated
Comment thread cs/v1/CS_v1.0.4.yaml
Comment thread cs/v1/README.md
@HenrikHL

Copy link
Copy Markdown
Contributor Author

/agentic_review

Comment thread cs/v1/CS_v1.0.4.yaml
Comment on lines +722 to +723
The start date of the period for which schedule information is requested. If the date of any Timestamp (ATA, ETA or PTA) within a TransportCall is on or after (`>=`) the `startDate`, the entire Voyage (import and export Voyage) containing that TransportCall will be included in the result. Matching is performed using the local date at the TransportCall location.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

1. Departure times may miss date filters 📎 Requirement gap ≡ Correctness

The startDate and endDate descriptions define any Timestamp with an exhaustive-looking list of
only ATA, ETA, and PTA, omitting the corresponding departure timestamps. When a waterway call
publishes only DEPA, as the contract permits, the filter documentation does not establish whether
its actual, estimated, or planned departure date participates in matching.
Agent Prompt
## Issue description
The date-filter descriptions list only arrival timestamps even though a waterway TransportCall may publish only a departure event.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[722-723]
- cs/v1/CS_v1.0.4.yaml[732-733]

## Recommended Fix
Update both filter descriptions to include `ATD`, `ETD`, and `PTD`, or remove the restrictive parenthetical and state unambiguously that timestamps derived from either `ARRI` or `DEPA` participate in matching.

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

Comment thread cs/v1/CS_v1.0.4.yaml
- `isCargoOperationalCall` **MUST** be present and **MUST** be set to `false`.
- `portVisitReference` **MUST** be omitted.

A TransportCall that does not satisfy these conditions does not conform to this specification.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

2. Port calls are declared nonconformant 📎 Requirement gap ≡ Correctness

The final sentence in TransportCall.description applies the preceding waterway-only conditions to
every TransportCall instead of limiting them to calls represented as waterways. Ordinary port
calls intentionally include portVisitReference and may set isCargoOperationalCall to true, so
the specification's supported port branch and its own port examples also reach this unconditional
conformance check.
Agent Prompt
## Issue description
The conformance sentence applies waterway-specific requirements to every `TransportCall`, unintentionally making supported ordinary port calls appear nonconformant.

## Fix Focus Areas
- cs/v1/CS_v1.0.4.yaml[1140-1146]

## Recommended Fix
Rewrite the final sentence so it applies only to a `TransportCall` identified as representing a waterway location, leaving ordinary port calls outside these waterway-only conditions. For example: “A waterway TransportCall that does not satisfy these conditions does not conform to this specification.”

ⓘ 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 5eaa30c

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.

Copilot review overview

🟡 Changes recommended

Documentation inconsistencies remain in CS_v1.0.4.yaml.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 Low severity

Open (1)
What changed in this PR

Adds SMDG waterway entry-point support to CS Vessel Schedules.

Changes:

  • Documents waterway location and TransportCall semantics.
  • Adds waterway examples and schema updates.
  • Generalizes endpoint descriptions beyond ports.
File Summary
cs/​v1/​README.md Documents waterway support and semantics.
cs/​v1/​CS_v1.0.4.yaml Updates schemas, examples, and endpoint descriptions.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread cs/v1/CS_v1.0.4.yaml
The filter parameters `startDate` and `endDate` MUST always be used in combination with any of the other available parameters.

The resulting payload returned in the responses will always include **entire voyage(s) being matched**, unless otherwise specified (see `responseScope` query parameter). This means that even though a filter only matches a single `Port` (`UNLocationCode`) in a `Voyage` or a single `Timestamp` within a `Port` in a `Voyage` - **the entire Voyage matched** is returned. If the `carrierImportVoyageNumber` of the `Port` differs from the `carrierExportVoyageNumber` of the `Port` then the **entire Voyage** for both these Voyage numbers are included. An example of this is when `&UNLocationCode=DEHAM` is used as a filter parameter. In this case **entire Voyages** would be listed where `DEHAM` is a `Port`.
The resulting payload returned in the responses will always include **entire voyage(s) being matched**, unless otherwise specified (see `responseScope` query parameter). This means that even though a filter only matches a single TransportCall identified by (`UNLocationCode`) in a `Voyage` or a single `Timestamp` within a `Port` in a `Voyage` - **the entire Voyage matched** is returned. If the `carrierImportVoyageNumber` of the `Port` differs from the `carrierExportVoyageNumber` of the `Port` then the **entire Voyage** for both these Voyage numbers are included. An example of this is when `&UNLocationCode=DEHAM` is used as a filter parameter. In this case **entire Voyages** would be listed containing a TransportCall with `UNLocationCode=DEHAM`.

This branch has not been deployed

No deployments
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