# Changelog

## Score

- CAI 63 → 60 (-3.2)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 99 → 75 (-23.8)
- Architecture 69 → 69 (+0.0)
- Maturity 50 → 47 (-2.7)
- Readiness 67 → 67 (+0.0)
- Security 97 → 95 (-2.1)

## Resolved (4)

- Ambiguous HTTP method mapping for create/update/upsert. In RESTful APIs, 'create' typically maps to POST, 'update' to PUT/PATCH, and 'upsert' to PUT/PATCH. However, the naming convention is inconsistent with standard HTTP semantics (where PUT is often idempotent create/update and PATCH is partial update). More critically, 'update' and 'upsert' are semantically distinct but share the same signature and likely similar underlying HTTP methods (PUT/PATCH), creating confusion about which to use for partial vs full resource replacement. Additionally, 'create' (POST) is distinct, but the lack of explicit HTTP method names in the API surface forces users to guess the HTTP verb based on the method name, which is error-prone.
- Duplicate functionality for reading resources. Both 'get' and 'retrieve' perform HTTP GET requests with identical signatures. This creates redundancy and confusion for users who do not know which method to prefer.
- Off-boarding risk: anonymized user #1
- Workflow token permissions not restricted

## New (5)

- Ambiguous HTTP method mapping for create/update/upsert. In RESTful APIs, 'create' typically maps to POST, 'update' to PUT/PATCH, and 'upsert' to PUT/PATCH with conditional logic. However, without explicit documentation, it is unclear if 'update' and 'upsert' differ only in behavior (idempotency/conditional) or if they map to different HTTP verbs (PUT vs PATCH). This creates confusion for users regarding which method to use for partial vs full updates.
- Duplicate HTTP method exposure across two different classes. Both 'Gibbon.APIRequest' and 'Gibbon.Request' expose methods for performing HTTP operations (get, post, put, patch, delete). 'Gibbon.Request' also exposes 'create', 'update', 'upsert', and 'retrieve'. This duplication suggests unclear separation of concerns between the two classes, leading to confusion about which class should be used for making API calls.
- Off-boarding risk: anonymized user #1
- Redundant operations for fetching data. Both 'get' and 'retrieve' accept the same parameters and likely perform the same HTTP GET request. Having two methods for the same action violates the principle of least surprise and encourages inconsistent usage.
- Workflow token permissions not restricted (.github/workflows/ci.yml)