OVS 3.0: SD-2912: Add facilityTypeCode

[HenrikHL]

SD-2912: Add facilityTypeCode to Timestamp

[qodo-code-review]

Review Summary by Qodo

Add facilityTypeCode field to Timestamp component

✨ Enhancement

Walkthroughs

Description

• Add facilityTypeCode field to Timestamp component
• Support facility type identification with PBPL and BRTH codes
• Set BRTH as default value when not provided

Diagram

flowchart LR
  A["Timestamp Component"] -- "adds facilityTypeCode field" --> B["Facility Type Code"]
  B -- "supports values" --> C["PBPL: Pilot Boarding Place"]
  B -- "supports values" --> D["BRTH: Berth"]
  B -- "default" --> E["BRTH"]

Loading

File Changes

1. ovs/v3/OVS_v3.0.2.yaml ✨ Enhancement +11/-0

Add facilityTypeCode field with facility type support

• Added facilityTypeCode field to Timestamp component with string type and maxLength of 4
• Defined supported facility type codes: PBPL (Pilot Boarding Place) and BRTH (Berth)
• Set BRTH as the default value when no value is provided
• Added comprehensive description and example documentation

ovs/v3/OVS_v3.0.2.yaml

---

2. .stoplight/styleguide.json ⚙️ Configuration changes +1/-1

Update styleguide configuration

• Minor configuration changes to styleguide

.stoplight/styleguide.json

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Conflicting default value ✓ Resolved 🐞 Bug ≡ Correctness

Description

Timestamp.facilityTypeCode sets default: PBPL but its description states that BRTH is the
default when omitted, which is contradictory and can lead to incorrect client-generated defaults and
inconsistent implementations.

Code

ovs/v3/OVS_v3.0.2.yaml[R712-722]

+        facilityTypeCode:
+          type: string
+          maxLength: 4
+          default: PBPL
+          description: |
+            The code to identify the specific type of facility. The following values are supported:
+            - `PBPL` (Pilot Boarding Place)
+            - `BRTH` (Berth)
+
+            If no value is provided, `BRTH` is the default value.
+          example: BRTH

Evidence

The schema explicitly declares default: PBPL while the description text says the default is
BRTH, which cannot both be true.

ovs/v3/OVS_v3.0.2.yaml[712-722]

Agent prompt

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

### Issue description
`facilityTypeCode` has a contradictory default: the OpenAPI `default` keyword says `PBPL`, while the human-readable description says the default is `BRTH`.

This inconsistency can cause clients generated from the OpenAPI to default to a different value than what implementers expect from the documentation.

### Issue Context
The field was added to `components/schemas/Timestamp`.

### Fix Focus Areas
- ovs/v3/OVS_v3.0.2.yaml[712-722]

### Expected fix
Pick the intended default (`PBPL` or `BRTH`) and make **both** the `default:` value and the prose sentence match. Also consider aligning the `example` with the intended default (or explicitly state why the example differs).

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

---

2. Supported values not enforced 🐞 Bug ≡ Correctness

Description

Timestamp.facilityTypeCode claims only PBPL and BRTH are supported, but the schema allows any
string up to length 4 (no enum), so schema validation and generated clients may accept values the
spec text says are unsupported.

Code

ovs/v3/OVS_v3.0.2.yaml[R712-722]

+        facilityTypeCode:
+          type: string
+          maxLength: 4
+          default: PBPL
+          description: |
+            The code to identify the specific type of facility. The following values are supported:
+            - `PBPL` (Pilot Boarding Place)
+            - `BRTH` (Berth)
+
+            If no value is provided, `BRTH` is the default value.
+          example: BRTH

Evidence

The new field’s description lists a closed set of supported values but the schema has no enum;
elsewhere, code-like fields in Timestamp use enums, and the event domain explicitly constrains
facilityTypeCode to PBPL/BRTH with an enum.

ovs/v3/OVS_v3.0.2.yaml[651-678]
ovs/v3/OVS_v3.0.2.yaml[712-722]
domain/event/event_domain_v1.1.0.yaml[811-828]

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 new `facilityTypeCode` property states only `PBPL` and `BRTH` are supported, but the OpenAPI schema does not enforce that constraint, allowing any 1–4 character string.

This creates a mismatch between the human-readable contract and the machine-readable contract.

### Issue Context
In the same `Timestamp` schema, other “code” fields (e.g., `eventTypeCode`, `eventClassifierCode`) are machine-constrained via `enum`. Additionally, the event domain in this repo shows an explicit enum restriction for `facilityTypeCode` to `PBPL`/`BRTH`.

### Fix Focus Areas
- ovs/v3/OVS_v3.0.2.yaml[651-678]
- ovs/v3/OVS_v3.0.2.yaml[712-722]
- domain/event/event_domain_v1.1.0.yaml[811-828]

### Expected fix
Add `enum: [PBPL, BRTH]` to `Timestamp.facilityTypeCode` (and keep `maxLength: 4` if desired). If the intent is to allow additional codes, then update the description to avoid stating a closed supported set.

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

---