matelab-python-sdk 0.1.0a16__tar.gz → 0.1.0a17__tar.gz

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/CHANGELOG.md

@@ -3,6 +3,19 @@
 This file records release-to-release changes and migration impact. It is not the authority for the current interface;
 see [README.md](README.md) for current behavior and [AGENTS.md](AGENTS.md) for maintenance policy.
 
+## 0.1.0a17 - 2026-08-20
+
+- Adopts immutable `matelab-spec v0.4.1` at commit `6f8ab3d14797385d0075d0aba38bf3bf529e674d` and OpenAPI
+  SHA-256 `73d899c9e60b59f9521062ffcfaaae5f073eea36f24f3e535fcb53f12242581c`. The standard wire structure is
+  unchanged from v0.4.0. PVD-041 and PCG-015 confirm that optional code-4 `errs` remains opaque, potentially sensitive
+  and unsafe to expose as a stable typed SDK interface without stronger Provider evidence and a future Contract release.
+- Breaking: `MatelabProviderError` construction now requires `provider_code`, `provider_message`, and `category`.
+  Transport and download errors preserve the Provider envelope's numeric `code` and expose an SDK-owned safe summary
+  instead of copying Provider-authored diagnostics into exceptions. The stable recovery interface remains `category`
+  plus conservative `retryable=False`; raw Provider codes are diagnostic rather than stable routing identifiers.
+  Exceptions exclude the response body, top-level `msg`, legacy `errmsg`, opaque `errs`, uncontracted debug fields, and
+  request payloads because Provider text may contain stack traces, credentials, or submitted values.
+
 ## 0.1.0a16 - 2026-08-14
 
 - Breaking: `UserSummary.display_name` is renamed to `name`; the SDK exposes the Provider's raw nullable real name

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: matelab-python-sdk
-Version: 0.1.0a16
+Version: 0.1.0a17
 Summary: Reusable async Python client for the Matelab Integration Contract
 Author-email: 朱天念 <zhutiannian@gmail.com>
 License-Expression: Apache-2.0
@@ -35,10 +35,10 @@ This README describes the current SDK interface, integration semantics, examples
 [AGENTS.md](AGENTS.md) for durable maintenance rules, and `docs/operation-coverage.yaml` for the machine-readable
 operation inventory.
 
-The current alpha is `0.1.0a16`. `[project].version` in `pyproject.toml` is the sole SDK version source;
+The current alpha is `0.1.0a17`. `[project].version` in `pyproject.toml` is the sole SDK version source;
 `uv.lock` only mirrors that source.
 
-The SDK is pinned to the immutable `matelab-spec v0.4.0` Contract Release. The sole release pin is
+The SDK is pinned to the immutable `matelab-spec v0.4.1` Contract Release. The sole release pin is
 `contracts/matelab-integration-v1.lock.json`, which records
 the source tag, commit, OpenAPI path, local snapshot path, and SHA-256.
 
@@ -64,7 +64,7 @@ To test the same artifact a downstream Consumer will install, build and install
 
 ```bash
 uv build --no-build-isolation --out-dir dist/release
-python -m pip install dist/release/matelab_python_sdk-0.1.0a16-py3-none-any.whl
+python -m pip install dist/release/matelab_python_sdk-0.1.0a17-py3-none-any.whl
 ```
 
 Do not infer Provider compatibility from the SDK version alone. A release is also bound to the Contract
@@ -93,29 +93,37 @@ explicitly when needed, for example `AsyncMatelab("https://custom.example/api")`
 ### Error handling
 
 Catch `MatelabError` once at an integration seam. Every instance exposes a stable `category: MatelabErrorCategory` and
-`retryable: bool`, so an integration can copy the message, category, and retry flag without inspecting subclasses or
-Provider details:
+`retryable: bool`. `MatelabProviderError` additionally exposes `provider_code: int` and `provider_message: str`, so a
+gateway can retain a stable diagnostic code and safe summary while routing recovery through the integration-level
+category:
 
 | Error | Category | Retryable | Meaning and normal response |
 |---|---|---:|---|
 | `MatelabAuthenticationError` | `AUTHENTICATION` | No | The Session or credentials cannot authenticate; obtain valid authentication before making a new call. |
 | `MatelabUsageError` | `VALIDATION` | No | The call cannot be represented safely; correct its arguments. |
-| `MatelabProviderError` | `BUSINESS`, `VALIDATION`, or `UPSTREAM` | No | The Provider rejected the request; route directly by `category`. |
+| `MatelabProviderError` | `BUSINESS`, `VALIDATION`, or `UPSTREAM` | No | The Provider rejected the request; record `provider_code` and route recovery by `category`; `provider_message` is an SDK-owned safe summary. |
 | `MatelabTransportError` | `UPSTREAM` | No | The HTTP exchange failed; `status_code` is present for HTTP failures, and a mutation outcome may be unknown. |
 | `MatelabProtocolError` | `UPSTREAM` | No | The response violates the pinned Contract; treat it as Provider drift or an SDK defect. |
 
 For `MatelabProviderError`, the SDK maps Provider wire code `2` to `BUSINESS`, `4` to `VALIDATION`, and `3` or an
-unknown code to `UPSTREAM`. Authentication codes are hidden behind `MatelabAuthenticationError`; raw Provider codes
-are not part of the public error interface. Code `5` triggers at most one refresh and replay only for authenticated
-operations that explicitly enable `retry_on_access_expired`; otherwise codes `1` and `5` raise
-`MatelabAuthenticationError` directly.
+unknown code to `UPSTREAM`. `provider_code` is diagnostic metadata, not a stable routing identifier, and integrations
+must not reinterpret it instead of `category`. `provider_message` and the exception string are SDK-owned safe summaries
+selected from the code mapping; they do not reproduce Provider-authored text. Authentication codes remain hidden behind
+`MatelabAuthenticationError`; code `5`
+triggers at most one refresh and replay only for authenticated operations that explicitly enable
+`retry_on_access_expired`, otherwise codes `1` and `5` raise `MatelabAuthenticationError` directly.
 Codes `0` and `10` remain operation-specific successes selected by the pinned Contract; an operation that receives a
 success code it does not allow raises `MatelabProtocolError` rather than assigning an error category.
-`MatelabTransportError.status_code` remains available for HTTP failures. Provider response bodies and caller inputs are
-never attached to exceptions. `retryable` means the identical SDK call is safe to replay without further
-interpretation. It is conservatively `False` for every current SDK error because the Contract does not guarantee
-mutation idempotency or outcome; an integration may add a narrower operation-specific retry policy only when it owns
-that evidence.
+`MatelabTransportError.status_code` remains available for HTTP failures. Provider response bodies, top-level `msg`,
+legacy `errmsg`, opaque `errs`, uncontracted debug fields, and request payloads are not attached to exceptions because
+Provider-authored diagnostics may contain stack traces, credentials, or submitted values.
+The pinned v0.4.1 Contract also declares optional code-4 `errs`, but PVD-041 and PCG-015 record incompatible observed
+item/container shapes and insufficient evidence for requiredness, cardinality, or exclusion from other codes. The SDK
+therefore keeps those diagnostics wire-only and does not expose `errs` as stable public metadata. A typed detail
+interface remains blocked until a future Contract release can define one from stronger Provider evidence. `retryable`
+means the identical SDK call is safe to replay without further interpretation. It is conservatively `False` for every
+current SDK error because the Contract does not guarantee mutation idempotency or outcome; an integration may add a
+narrower operation-specific retry policy only when it owns that evidence.
 
 ### Session ownership
 
@@ -798,8 +806,9 @@ does not expose a signing operation, signature projection or credentials for the
 results only report whether Provider policy allows signing.
 
 Errors are separated into semantic Provider errors, authentication errors, HTTP/transport errors,
-Integration Contract response errors, and client-side usage errors. Provider response bodies and caller inputs do not
-enter exceptions.
+Integration Contract response errors, and client-side usage errors. Semantic Provider errors retain only the
+Contract-defined top-level code plus an SDK-owned safe summary; Provider-authored messages, response bodies, legacy
+aliases, and unrelated fields do not enter exceptions.
 
 ## Development
 
@@ -892,6 +901,6 @@ uv run python scripts/check_release.py dist/release/*.whl dist/release/*.tar.gz
 ```
 
 Rebuilding the same commit with the same locked environment and `SOURCE_DATE_EPOCH` must produce
-byte-identical wheel and source distribution hashes. The release is bound to `matelab-spec v0.4.0`,
-commit `7993a7bccc213f626b9cc8124423e2b2c9e48dd7`, and OpenAPI SHA-256
-`e725c9649700d5b4d1c7d75fb9422d64b04a68e0308ddec29ba274d774104c8e`.
+byte-identical wheel and source distribution hashes. The release is bound to `matelab-spec v0.4.1`,
+commit `6f8ab3d14797385d0075d0aba38bf3bf529e674d`, and OpenAPI SHA-256
+`73d899c9e60b59f9521062ffcfaaae5f073eea36f24f3e535fcb53f12242581c`.

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/README.md

@@ -7,10 +7,10 @@ This README describes the current SDK interface, integration semantics, examples
 [AGENTS.md](AGENTS.md) for durable maintenance rules, and `docs/operation-coverage.yaml` for the machine-readable
 operation inventory.
 
-The current alpha is `0.1.0a16`. `[project].version` in `pyproject.toml` is the sole SDK version source;
+The current alpha is `0.1.0a17`. `[project].version` in `pyproject.toml` is the sole SDK version source;
 `uv.lock` only mirrors that source.
 
-The SDK is pinned to the immutable `matelab-spec v0.4.0` Contract Release. The sole release pin is
+The SDK is pinned to the immutable `matelab-spec v0.4.1` Contract Release. The sole release pin is
 `contracts/matelab-integration-v1.lock.json`, which records
 the source tag, commit, OpenAPI path, local snapshot path, and SHA-256.
 
@@ -36,7 +36,7 @@ To test the same artifact a downstream Consumer will install, build and install
 
 ```bash
 uv build --no-build-isolation --out-dir dist/release
-python -m pip install dist/release/matelab_python_sdk-0.1.0a16-py3-none-any.whl
+python -m pip install dist/release/matelab_python_sdk-0.1.0a17-py3-none-any.whl
 ```
 
 Do not infer Provider compatibility from the SDK version alone. A release is also bound to the Contract
@@ -65,29 +65,37 @@ explicitly when needed, for example `AsyncMatelab("https://custom.example/api")`
 ### Error handling
 
 Catch `MatelabError` once at an integration seam. Every instance exposes a stable `category: MatelabErrorCategory` and
-`retryable: bool`, so an integration can copy the message, category, and retry flag without inspecting subclasses or
-Provider details:
+`retryable: bool`. `MatelabProviderError` additionally exposes `provider_code: int` and `provider_message: str`, so a
+gateway can retain a stable diagnostic code and safe summary while routing recovery through the integration-level
+category:
 
 | Error | Category | Retryable | Meaning and normal response |
 |---|---|---:|---|
 | `MatelabAuthenticationError` | `AUTHENTICATION` | No | The Session or credentials cannot authenticate; obtain valid authentication before making a new call. |
 | `MatelabUsageError` | `VALIDATION` | No | The call cannot be represented safely; correct its arguments. |
-| `MatelabProviderError` | `BUSINESS`, `VALIDATION`, or `UPSTREAM` | No | The Provider rejected the request; route directly by `category`. |
+| `MatelabProviderError` | `BUSINESS`, `VALIDATION`, or `UPSTREAM` | No | The Provider rejected the request; record `provider_code` and route recovery by `category`; `provider_message` is an SDK-owned safe summary. |
 | `MatelabTransportError` | `UPSTREAM` | No | The HTTP exchange failed; `status_code` is present for HTTP failures, and a mutation outcome may be unknown. |
 | `MatelabProtocolError` | `UPSTREAM` | No | The response violates the pinned Contract; treat it as Provider drift or an SDK defect. |
 
 For `MatelabProviderError`, the SDK maps Provider wire code `2` to `BUSINESS`, `4` to `VALIDATION`, and `3` or an
-unknown code to `UPSTREAM`. Authentication codes are hidden behind `MatelabAuthenticationError`; raw Provider codes
-are not part of the public error interface. Code `5` triggers at most one refresh and replay only for authenticated
-operations that explicitly enable `retry_on_access_expired`; otherwise codes `1` and `5` raise
-`MatelabAuthenticationError` directly.
+unknown code to `UPSTREAM`. `provider_code` is diagnostic metadata, not a stable routing identifier, and integrations
+must not reinterpret it instead of `category`. `provider_message` and the exception string are SDK-owned safe summaries
+selected from the code mapping; they do not reproduce Provider-authored text. Authentication codes remain hidden behind
+`MatelabAuthenticationError`; code `5`
+triggers at most one refresh and replay only for authenticated operations that explicitly enable
+`retry_on_access_expired`, otherwise codes `1` and `5` raise `MatelabAuthenticationError` directly.
 Codes `0` and `10` remain operation-specific successes selected by the pinned Contract; an operation that receives a
 success code it does not allow raises `MatelabProtocolError` rather than assigning an error category.
-`MatelabTransportError.status_code` remains available for HTTP failures. Provider response bodies and caller inputs are
-never attached to exceptions. `retryable` means the identical SDK call is safe to replay without further
-interpretation. It is conservatively `False` for every current SDK error because the Contract does not guarantee
-mutation idempotency or outcome; an integration may add a narrower operation-specific retry policy only when it owns
-that evidence.
+`MatelabTransportError.status_code` remains available for HTTP failures. Provider response bodies, top-level `msg`,
+legacy `errmsg`, opaque `errs`, uncontracted debug fields, and request payloads are not attached to exceptions because
+Provider-authored diagnostics may contain stack traces, credentials, or submitted values.
+The pinned v0.4.1 Contract also declares optional code-4 `errs`, but PVD-041 and PCG-015 record incompatible observed
+item/container shapes and insufficient evidence for requiredness, cardinality, or exclusion from other codes. The SDK
+therefore keeps those diagnostics wire-only and does not expose `errs` as stable public metadata. A typed detail
+interface remains blocked until a future Contract release can define one from stronger Provider evidence. `retryable`
+means the identical SDK call is safe to replay without further interpretation. It is conservatively `False` for every
+current SDK error because the Contract does not guarantee mutation idempotency or outcome; an integration may add a
+narrower operation-specific retry policy only when it owns that evidence.
 
 ### Session ownership
 
@@ -770,8 +778,9 @@ does not expose a signing operation, signature projection or credentials for the
 results only report whether Provider policy allows signing.
 
 Errors are separated into semantic Provider errors, authentication errors, HTTP/transport errors,
-Integration Contract response errors, and client-side usage errors. Provider response bodies and caller inputs do not
-enter exceptions.
+Integration Contract response errors, and client-side usage errors. Semantic Provider errors retain only the
+Contract-defined top-level code plus an SDK-owned safe summary; Provider-authored messages, response bodies, legacy
+aliases, and unrelated fields do not enter exceptions.
 
 ## Development
 
@@ -864,6 +873,6 @@ uv run python scripts/check_release.py dist/release/*.whl dist/release/*.tar.gz
 ```
 
 Rebuilding the same commit with the same locked environment and `SOURCE_DATE_EPOCH` must produce
-byte-identical wheel and source distribution hashes. The release is bound to `matelab-spec v0.4.0`,
-commit `7993a7bccc213f626b9cc8124423e2b2c9e48dd7`, and OpenAPI SHA-256
-`e725c9649700d5b4d1c7d75fb9422d64b04a68e0308ddec29ba274d774104c8e`.
+byte-identical wheel and source distribution hashes. The release is bound to `matelab-spec v0.4.1`,
+commit `6f8ab3d14797385d0075d0aba38bf3bf529e674d`, and OpenAPI SHA-256
+`73d899c9e60b59f9521062ffcfaaae5f073eea36f24f3e535fcb53f12242581c`.

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/contracts/matelab-integration-v1.lock.json

@@ -2,12 +2,12 @@
   "schema_version": 1,
   "contract_line": "integration-v1",
   "release": {
-    "tag": "v0.4.0",
-    "commit": "7993a7bccc213f626b9cc8124423e2b2c9e48dd7"
+    "tag": "v0.4.1",
+    "commit": "6f8ab3d14797385d0075d0aba38bf3bf529e674d"
   },
   "openapi": {
     "source_path": "openapi/matelab-integration-v1.openapi.yaml",
     "snapshot": "matelab-integration-v1.openapi.yaml",
-    "sha256": "e725c9649700d5b4d1c7d75fb9422d64b04a68e0308ddec29ba274d774104c8e"
+    "sha256": "73d899c9e60b59f9521062ffcfaaae5f073eea36f24f3e535fcb53f12242581c"
   }
 }

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/contracts/matelab-integration-v1.openapi.yaml

@@ -1,7 +1,7 @@
 openapi: 3.1.0
 info:
   title: Matelab Integration Contract
-  version: 0.4.0
+  version: 0.4.1
   description: |
     Stable PHP wire contract for the `integration-v1` contract line.
     Business failures are returned as JSON envelopes over HTTP 200.
@@ -32,6 +32,7 @@ info:
       - lib/Base.php
       - lib/Route.php
       - lib/HttpServer.php
+      - lib/MultiException.php
       - config/Channel.php
       - sql/eln.sql
       - sql/matelab.sql
@@ -172,6 +173,25 @@ info:
         pathSegments: 2
         readback: column-absent-and-table-rows-preserved
         cellLikeThreeSegmentPath: deletes-whole-column-not-cell
+  x-provider-error-diagnostics:
+    status: evidence-gap
+    tracking: [PVD-041, PCG-015]
+    typedPublicInterface: unsafe
+    code4:
+      errsRequired: unverified
+      errsMinItems: unverified
+      errsOnOtherCodes: not-observed-but-not-contracted
+      releasedContainerShape: array
+      sourceConfirmedArrayItemShapes: [string, object, nested-object]
+      sourceConfirmedContractViolations: [object-container-from-file-validator-envelope-merge]
+    responsibilities:
+      codeAndErrcode: machine-readable-envelope-status
+      msgAndErrmsg: human-oriented-summary-not-a-stable-identifier
+      errs: opaque-provider-diagnostics
+    securityBoundary:
+      trust: untrusted-potentially-sensitive
+      observedContent: [localized-validation-text, request-derived-values, stored-field-names]
+      stackTraceExclusion: not-contractually-guaranteed
 servers:
   - url: https://matelab.example.invalid
     description: Placeholder; consumers supply their Provider base URL.
@@ -1487,7 +1507,7 @@ paths:
         Consumers must split attachment-bearing imports into single-record
         requests with a distinct staged name for each request, and must not
         retry a failed finalize with the same name.
-      x-known-provider-issues: [PVD-023, PVD-024, PVD-040]
+      x-known-provider-issues: [PVD-023, PVD-024, PVD-040, PVD-041]
       security: [{bearerAuth: []}]
       requestBody:
         required: true
@@ -1627,6 +1647,11 @@ paths:
         caller-owned staging or authorized existing file quotes, and binds the
         resulting attachments while saving the record.
 
+        This operation does not modify record title or other record metadata.
+        `UpdateRecordRequest` rejects a top-level `title`; the Front uses the
+        separate, currently unsupported `/eln_items/edit` route for that use
+        case. A stable Integration metadata update remains PCG-016.
+
         Verified staged-name update shapes are enumerated by
         `info.x-record-attachment-staging.safeFinalizerShapes.update` and their
         dedicated component schemas. They cover a new form file field, setting
@@ -1649,7 +1674,7 @@ paths:
         consumption are not atomic. Once a finalizer begins, any write error,
         collaboration-pending response, response loss or failed readback leaves
         staging indeterminate and must not be retried.
-      x-known-provider-issues: [PVD-014, PVD-015, PVD-016, PVD-017, PVD-040]
+      x-known-provider-issues: [PVD-014, PVD-015, PVD-016, PVD-017, PVD-040, PVD-041]
       security: [{bearerAuth: []}]
       requestBody:
         required: true
@@ -3456,7 +3481,7 @@ paths:
         both branches must verify the stored result through
         `readLiteratureDetail`. Create-time file binding is affected by PVD-026.
       x-consumer-use-case: Create canonical personal literature with an optional staged PDF, or replace the canonical metadata of a writable item.
-      x-known-provider-issues: [PVD-011, PVD-026, PVD-027]
+      x-known-provider-issues: [PVD-011, PVD-026, PVD-027, PVD-041]
       security: [{bearerAuth: []}]
       requestBody:
         required: true
@@ -4062,12 +4087,19 @@ components:
           type: integer
         msg:
           type: string
+          description: |
+            Human-oriented envelope summary. Consumers must use `code` for
+            branching and must not parse this text as a stable identifier,
+            field location, or retry signal.
         errcode:
           type: integer
           description: Legacy alias of `code`; always present in these operations.
         errmsg:
           type: string
-          description: Legacy alias of `msg`; always present in these operations.
+          description: |
+            Legacy alias of `msg`; always present in these operations. It has
+            the same human-summary responsibility and is not a structured
+            diagnostic field.
     BasicSuccessResponse:
       allOf:
         - $ref: "#/components/schemas/ResponseEnvelope"
@@ -4083,7 +4115,14 @@ components:
             code: {enum: [0, 10]}
             errcode: {enum: [0, 10]}
     ErrorDetail:
-      description: A stable per-field or per-location error value returned when code is 4.
+      description: |
+        Intentionally unconstrained Provider diagnostic array item. Source
+        evidence includes strings, structured objects, sparse objects, and
+        nested error groups. Integration-v1 therefore does not promise a stable
+        item shape. The separate source-confirmed object-container branch
+        violates ErrorResponse and is tracked by PVD-041 and PCG-015.
+      x-contract-status: evidence-gap
+      x-tracking: [PVD-041, PCG-015]
     ErrorResponse:
       allOf:
         - $ref: "#/components/schemas/ResponseEnvelope"
@@ -4106,11 +4145,23 @@ components:
               type: array
               items:
                 $ref: "#/components/schemas/ErrorDetail"
-              description: Present for multi-error code 4; absent from ordinary errors.
+              description: |
+                Optional array of opaque, untrusted Provider diagnostics
+                observed on code 4. Integration-v1 does not constrain its
+                requiredness, cardinality, item shape, order, or absence on
+                other codes. Values can contain localized validation text,
+                request-derived values, or stored field names and must not be
+                broadly logged or displayed without sanitization. No
+                stack-trace exclusion is contractually guaranteed. The
+                Provider's source-confirmed object-container branch violates
+                this released array contract; see PVD-041 and PCG-015.
+          x-known-provider-issues: [PVD-041]
       description: |
         Stable HTTP 200 error envelope. Codes observed in the common router are:
         1 authentication, 2 input/permission/business failure, 3 server failure,
-        4 multiple errors (`errs` present), and 5 expired access token.
+        4 multiple errors (normally with `errs`), and 5 expired access token.
+        `msg`/`errmsg` summarize the envelope for people; `errs`, when present,
+        carries opaque diagnostics and is not a stable public detail interface.
     Sha256:
       type: string
       pattern: "^[0-9a-f]{64}$"

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/docs/operation-coverage.yaml

@@ -3,7 +3,7 @@
 schema_version: 1
 contract:
   line: integration-v1
-  release: v0.4.0
+  release: v0.4.1
   operation_count: 71
 
 operations:
@@ -259,7 +259,7 @@ operations:
     state: implemented
     stability: experimental
     public_interface: AsyncMatelab.records.import_dataset
-    known_issues: [PCG-008, PCG-014, PVD-023, PVD-024, PVD-040]
+    known_issues: [PCG-008, PCG-014, PVD-023, PVD-024, PVD-040, PVD-041]
 
   - operation_id: exportRecords
     method: POST
@@ -286,7 +286,7 @@ operations:
     state: implemented
     stability: experimental
     public_interface: AsyncMatelab.records.update
-    known_issues: [PCG-001, PCG-002, PCG-014, PVD-014, PVD-015, PVD-016, PVD-017, PVD-040]
+    known_issues: [PCG-001, PCG-002, PCG-014, PVD-014, PVD-015, PVD-016, PVD-017, PVD-040, PVD-041]
 
   - operation_id: deleteRecordsByUid
     method: POST
@@ -540,7 +540,7 @@ operations:
     state: implemented
     stability: experimental
     public_interface: AsyncMatelab.literature.create / AsyncMatelab.literature.update
-    known_issues: [PCG-010, PVD-011, PVD-026, PVD-027]
+    known_issues: [PCG-010, PVD-011, PVD-026, PVD-027, PVD-041]
 
   - operation_id: replaceLiteraturePdf
     method: POST

{matelab_python_sdk-0.1.0a16 → matelab_python_sdk-0.1.0a17}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "matelab-python-sdk"
-version = "0.1.0a16"
+version = "0.1.0a17"
 description = "Reusable async Python client for the Matelab Integration Contract"
 readme = "README.md"
 requires-python = ">=3.11"