coval-agent-sdk 0.1.0__tar.gz

coval_agent_sdk-0.1.0/.python-version

@@ -0,0 +1 @@
+3.12

coval_agent_sdk-0.1.0/AGENTS.md

@@ -0,0 +1,81 @@
+# AGENTS.md
+
+Instructions for coding agents working on the Coval Agent SDK. The closest applicable `AGENTS.md` governs its directory; explicit user instructions take precedence. Follow existing authorization without asking for it again.
+
+## Before you start
+
+- Read `README.md` for the supported installation and developer API.
+- Read `CONTRIBUTING.md` before changing code or preparing a pull request.
+- Read `AGENTS.meta.md` before editing either agent-guidance file.
+- Read `docs/python-style.md` before adding modules, imports, exports, types, docstrings, or lint exceptions.
+- Read `docs/architecture.md` before changing dependency direction or moving state between modules.
+- Read `docs/runtime.md` before changing audio, retries, deadlines, cancellation, or trace cleanup.
+- Read `docs/developer-api.md` before turning a proposed interface into executable behavior.
+
+## Commands
+
+- Run `scripts/install` from the repository root to create the development environment and install the editable SDK.
+- Run `.venv/bin/ruff check --fix .` and `.venv/bin/ruff format .` to apply safe lint fixes and formatting, then review the diff.
+- Run `scripts/lint` after Python changes; it checks Ruff, formatting, architecture, and strict production types.
+- Run `scripts/check` after runtime, entry-point, dependency, or packaging changes; it also tests a wheel built from the source distribution outside the checkout.
+- Run `scripts/build` when a consumer needs a local wheel; validate the artifact without publishing it.
+- Check local links and run `git diff --check` for documentation-only changes; run broader checks only when the affected behavior warrants them.
+- Use the same commands locally and in `.github/workflows/checks.yml` instead of adding a separate CI-only validation path.
+
+## Python
+
+- Follow the Google-based conventions in `docs/python-style.md`; use four spaces, double quotes, an 80-column target, and the pinned Ruff configuration.
+- Import absolute owning modules inside the SDK; keep symbol imports limited to typing helpers and the explicit root API facade.
+- Keep `src/coval_agent_sdk/__init__.py` limited to its docstring, explicit public imports, and literal `__all__`; `scripts/check_architecture.py` checks this boundary.
+- Annotate production parameters and return values, and keep `Any` at validated JSON or dynamic adapter boundaries.
+- Write Google-style docstrings for public APIs, including meaningful `Args:`, `Returns:`, `Yields:`, `Raises:`, and `Attributes:` sections where applicable.
+- Split code by responsibility and state ownership rather than creating generic utility modules or forwarding layers to satisfy a size target.
+- Use a rule-specific suppression with its concrete reason instead of weakening a production file's lint or type policy.
+
+## Package and API
+
+- Use `coval-agent-sdk` as the distribution name, `coval_agent_sdk` as the Python package, and the library API documented in `README.md`.
+- Treat this unreleased SDK as a clean slate; update consumers alongside API changes without compatibility aliases or deprecation paths.
+- Return outcomes and raise failures without printing, logging, configuring logging, or adding CLI entry points.
+- Keep internal orchestration out of public client reexports; expose a definition through the root facade only when it is part of the reviewed developer API.
+- Keep provider frameworks, backend imports, AWS configuration, and consumer source paths outside the core SDK.
+- Keep optional integration dependencies behind extras and outside core imports; follow the dependency policy in `CONTRIBUTING.md`.
+- Add a dependency only for a concrete runtime or development requirement and keep its supported Python range consistent with `pyproject.toml`.
+- Update `README.md`, public docstrings, and affected examples when a supported interface changes.
+- Include `LICENSE` and `NOTICE` in source and wheel distributions, and keep the SPDX expression in `pyproject.toml` consistent with them.
+
+## Runtime
+
+- Expose audio connections without SDK agent classes or factories; keep application pipeline construction and lifecycle outside the SDK.
+- Bound unread input, await serialized output writes, and preserve PCM16 validation and cross-call pacing.
+- Retry only documented transient reads and unconsumed relay upgrades; do not automatically repeat run creation or a consumed connection attempt.
+- Preserve the primary session error through cancellation, application cleanup, and trace cleanup.
+- Accept a missing terminal frame only when the simulation API explicitly confirms completion.
+- Upload completed conversations separately and discard failed-session traces after closure and flush.
+- Use synthetic fixtures and deterministic local collaborators for automated tests; live simulations need an explicitly selected environment and existing authorization.
+- Never commit credentials, one-use connection tokens, customer audio, or transcripts; secret scanning cannot establish that every fixture is safe.
+
+## Tests
+
+- Follow `CONTRIBUTING.md` for behavior-focused tests and reviewable changes.
+- Keep tests outside `src/` and exercise installed-package boundaries without modifying `sys.path`.
+- Patch dependencies at the module that owns them and keep the behavior under test real.
+- Preserve assertions for failure, cancellation, cleanup, and supported public entry points when reorganizing tests.
+- Distinguish local, mocked, and hosted evidence; do not infer a completed simulation from a successful launch or connection.
+
+## Documentation and comments
+
+- Read `CONTRIBUTING.md`'s "Documentation and comments" section before writing documentation or code comments.
+- Follow its document ownership, comment purpose, placement, and review rules; keep explanations in one authoritative page and link from other pages.
+- Search README files, docs, guidance, templates, and examples for changed APIs or behavior, and update affected claims in the same change.
+- Write Markdown paragraphs on one line; keep Python comments and docstrings within the Google-based formatting conventions.
+- Keep public documentation focused on current supported behavior; retain internal delivery history in the work tracker and label proposals and unverified evidence explicitly.
+
+## Releases and security
+
+- Follow `docs/releasing.md` when preparing a version or distribution.
+- Use Conventional Commit PR titles and squash merges; release automation owns version bumps, `CHANGELOG.md`, and release tags.
+- Run `.venv/bin/python -m pytest release_tests -q` on Python 3.12 after changing release tooling; CI runs it separately from runtime tests.
+- Obtain explicit authorization before publishing packages, changing repository visibility, or adding publishing automation.
+- Preserve an existing pull request's draft state unless the user authorizes changing it.
+- Follow `SECURITY.md` for vulnerability reports and avoid putting sensitive reproduction details in public issues.

coval_agent_sdk-0.1.0/AGENTS.meta.md

@@ -0,0 +1,29 @@
+# AGENTS.meta.md
+
+Authoring rules for this repository's `AGENTS.md`. This file also governs edits to itself. Instruction discovery and precedence follow the [AGENTS.md standard](https://agents.md/); an explicit user instruction takes precedence.
+
+## What belongs here
+
+- Put short, actionable SDK rules and exact development commands in `AGENTS.md`.
+- Put contributor workflow in `CONTRIBUTING.md`, Python conventions in `docs/python-style.md`, and technical explanations in the relevant `docs/` page.
+- Record a recurring mistake as a rule at the boundary that owns it; avoid speculative rules and rules tied to one person's workstation.
+- Keep unreleased API proposals separate from instructions for the implemented API.
+
+## Writing a rule
+
+- Start each rule with an imperative verb; use `Never` for a hard prohibition and `Ask first` only for a decision that needs authorization.
+- Honor authorization already present in the conversation instead of asking for it again.
+- Keep each bullet to one instruction, adding one explanatory sentence only when the reason is otherwise unclear.
+- Name paths and commands exactly in backticks, including the flags needed to run a check.
+- Link the explanatory document from the section that needs it rather than repeating its prose.
+- State which check enforces a rule when enforcement exists; distinguish automated enforcement from reviewer judgment.
+- Use headings and flat bullets; keep tables, long explanations, and nested procedures in the linked documentation.
+- Avoid private issue links, pull-request narration, implementation-history notes, personal paths, and credentials.
+
+## Maintaining the guidance
+
+- Update a rule when the code, command, or supported interface changes.
+- Remove obsolete rules and duplicated instructions instead of accumulating exceptions.
+- Read `AGENTS.md`, this file, and affected linked sections after an edit; resolve contradictions before finishing.
+- Verify every referenced local path and command, and label any check that was not executed.
+- Follow `CONTRIBUTING.md` for documentation ownership, prose, and comment review; preserve Python formatting rules when adapting guidance from another language.

coval_agent_sdk-0.1.0/CHANGELOG.md

@@ -0,0 +1,27 @@
+# CHANGELOG
+
+
+## v0.1.0 (2026-10-20)
+
+### Chores
+
+- Initial commit
+  ([`3c95020`](https://github.com/coval-ai/coval-agent-sdk/commit/3c950207a6c72738bfa9b69aebd68fbe924a4a9f))
+
+### Continuous Integration
+
+- Automate sdk versioning, changelogs, and pypi releases
+  ([#2](https://github.com/coval-ai/coval-agent-sdk/pull/2),
+  [`b036423`](https://github.com/coval-ai/coval-agent-sdk/commit/b036423abd734fad397dd4bf96c96244e741395a))
+
+### Features
+
+- Add the standalone python voice agent sdk
+  ([#1](https://github.com/coval-ai/coval-agent-sdk/pull/1),
+  [`445a752`](https://github.com/coval-ai/coval-agent-sdk/commit/445a752468537e052c05f217eed630509e305759))
+
+### Refactoring
+
+- Standardize conversation results and sdk errors
+  ([#3](https://github.com/coval-ai/coval-agent-sdk/pull/3),
+  [`336fd5b`](https://github.com/coval-ai/coval-agent-sdk/commit/336fd5b7381bc4737fba54d3914bbe8c8071f5ed))

coval_agent_sdk-0.1.0/CONTRIBUTING.md

@@ -0,0 +1,142 @@
+# Contributing
+
+The [README](README.md) introduces the SDK and its supported API. This guide describes how to make a reviewable change; [Python conventions](docs/python-style.md) define the coding standard.
+
+## Set up the project
+
+Use Python 3.12 and [uv](https://docs.astral.sh/uv/) for development. The package supports Python 3.10 and newer; CI exercises 3.10, 3.12, and 3.14.
+
+```sh
+git clone https://github.com/coval-ai/coval-agent-sdk.git
+cd coval-agent-sdk
+scripts/install
+.venv/bin/python -c "import coval_agent_sdk"
+```
+
+The editable installation makes source changes available in `.venv`. Installation, imports, static checks, and tests do not need Coval or model-provider credentials. Use `PYTHON_VERSION=3.10 scripts/install` in a fresh checkout to create a development environment for another supported interpreter.
+
+## Pull requests
+
+1. Start a focused branch from `main`. For a substantial API change, describe the proposed behavior in an issue before adding another abstraction.
+2. Identify the owning module using [architecture](docs/architecture.md). Keep provider integrations in adapters outside the core package.
+3. Implement the change and add behavior-focused coverage for affected contracts, including relevant failure and cancellation paths.
+4. Run the checks below and describe any unavailable or unrelated failing check accurately.
+5. Open a pull request explaining the problem, resulting behavior, relevant evidence, and any migration or release implications. Link the issue when one exists.
+6. Have the change reviewed before merging. Keep design experiments in draft until their scope and API are ready for review.
+
+Use squash merges with a concise Conventional Commit PR title such as `fix: preserve cancellation during trace cleanup` or `docs: clarify audio connection ownership`. Commit and PR bodies explain why the change is needed; they should not narrate every command run.
+
+## Checks
+
+```sh
+scripts/lint
+scripts/check
+```
+
+`scripts/lint` runs Ruff lint, Ruff formatting checks, the architecture policy, and strict Pyright checks for production code. `scripts/check` also builds a source distribution, builds its wheel, checks metadata, installs the wheel into an isolated environment, and runs the SDK's tests outside the checkout. CI uses the same entry points.
+
+For a focused test during iteration:
+
+```sh
+.venv/bin/python -m pytest tests/test_streaming.py -q
+```
+
+Release tooling uses Python 3.12 and the pinned `python-semantic-release` development dependency. After changing its configuration, workflow, or validator, also run `.venv/bin/python -m pytest release_tests -q`. This separate suite exercises real release tooling in isolated Git repositories without contacting GitHub or PyPI; CI runs it in a dedicated job. It is not part of the installed SDK runtime suite.
+
+For safe automated fixes:
+
+```sh
+.venv/bin/ruff check --fix .
+.venv/bin/ruff format .
+```
+
+Review generated edits before committing. Run `scripts/check` before pushing runtime, dependency, entry-point, or packaging changes. For a prose-only edit, verify links and commands that changed and run `git diff --check`; do not rerun unrelated runtime tests merely to change a paragraph.
+
+## Tests
+
+Assert on observable behavior: the audio or requests sent, returned results, typed failures, resource state, and cancellation or cleanup outcomes. Keep the owner under test real, and substitute only external boundaries needed for a deterministic test. Use populated values and otherwise-valid inputs so a rejection case fails for the intended reason.
+
+Patch collaborators at their owning modules, not through the root facade. Keep tests under `tests/`; do not insert the checkout into `sys.path`. Packaging and public API tests must also pass against an installed wheel. Preserve each distinct behavior when splitting or consolidating cases, and never hide an affected failure with a skip, weaker assertion, or broader mock.
+
+Use synthetic identifiers and audio. Do not make live API or provider calls in the automated suite. A separately authorized hosted check must record the selected environment, source/artifact identity, and terminal result; mocked checks do not establish hosted acceptance.
+
+The public wire tests use loopback HTTP and TLS WebSocket servers. They require `openssl` on `PATH` to generate a temporary certificate and key; no test credentials are committed. Only the local CA trust and polling interval are injected into the client. Discovery, the HTTP adapter, WebSocket upgrade, audio exchange, monitoring, and public result construction execute normally. These tests prove the local protocol path, not deployed Cloudflare or production behavior.
+
+## API and dependencies
+
+Add public exports deliberately and document their ownership, inputs, outputs, error behavior, and cleanup obligations. Keep the importable package independent of any particular agent framework. Put unimplemented interfaces in [API design](docs/developer-api.md), clearly marked as proposals.
+
+Expose conversation audio connections without agent classes or factories. Applications own agent/pipeline construction and cleanup; SDK connection contexts and async run handlers own only audio transport and simulation orchestration. Framework plugins belong in consumers, and application cleanup must finish before trace finalization.
+
+Keep the SDK a Python library only. Return structured results and raise failures without printing, emitting log records, configuring logging, or adding console-script or package-execution entry points. Calling applications own presentation. Preserve useful diagnostics in returned outcomes and errors as described in [runtime contracts](docs/runtime.md#returned-outcomes); test that affected public operations return the expected information without writing console output or log records.
+
+Keep `coval-sdk` and its HTTP dependency inside the private `_http.py` adapter. Do not expose dependency clients, configuration, models, raw responses, or exception types through public attributes, parameters, return values, or exports. Translate request failures into this package's errors at that boundary; orchestration owns read retries, and run creation must remain a single attempt. Do not enable dependency debug output or change application logging configuration.
+
+Derive SDK-owned failures from `CovalError` and retain useful specific subclasses. Do not wrap application exceptions or cancellation as SDK errors. Preserve the original failure through session cleanup and batch sibling cancellation; attach `RunError` snapshots only to SDK failures after launch. Completed-session trace delivery failures remain structured diagnostics.
+
+Put optional integration dependencies in a named extra and declare every external package imported directly by that integration. Keep the base SDK importable and runnable without those dependencies. OpenTelemetry belongs only in `coval_agent_sdk.tracing`; use its protobuf encoder with the private HTTP adapter rather than an exporter that emits logs or hides retry policy. Core code uses the dependency-free `TraceExporter` contract. `scripts/check` first exercises a clean base wheel installation, then installs `[tracing]` and runs the full suite.
+
+For a new dependency, explain why the SDK needs it, its Python support, and its distribution/license implications. Update the affected tests and package metadata. Review dependency upgrades as code changes; do not relax constraints solely to silence a failing check.
+
+Release automation owns the version in `pyproject.toml` and [CHANGELOG.md](CHANGELOG.md). Do not bump versions or edit the changelog in feature PRs. Squash-merged Conventional Commit titles supply the release notes: `fix:` and `perf:` produce a patch, `feat:` a minor, and `!` or `BREAKING CHANGE:` a major, including a move from `0.x` to `1.0.0`. Other types do not trigger a release on their own. Follow [releasing](docs/releasing.md) for setup, retries, and publication evidence.
+
+## Where prose lives
+
+- `README.md` introduces the SDK, installation, and a complete first-run example.
+- `AGENTS.md` contains concise coding-agent instructions and links to their explanations.
+- `AGENTS.meta.md` governs changes to the agent instructions.
+- `CONTRIBUTING.md` describes the human contribution and review workflow.
+- `docs/python-style.md` defines imports, initializers, types, docstrings, and formatting.
+- `docs/architecture.md` maps responsibilities and dependency direction.
+- `docs/runtime.md` explains audio, connection, timeout, cancellation, and trace contracts.
+- `docs/local-development.md` explains editable installs, built-wheel checks, and consumer development.
+- `docs/releasing.md` describes maintainer release preparation and publication boundaries.
+- `SECURITY.md` describes private vulnerability reporting.
+
+Keep explanations in their owning document and link to them elsewhere. Use one paragraph per line in Markdown; leave code blocks, tables, and lists structured normally. Python comments and docstrings follow the formatter and 80-column conventions instead.
+
+## Documentation and comments
+
+Document the current behavior and the decisions a developer needs to use or change it. The ownership map above determines where an explanation belongs; keep a single authoritative explanation and link to it from other pages.
+
+### Write a comment when
+
+- A value, limit, dependency pin, or protocol choice has a reason the code cannot express.
+- Changing the behavior has a consequence outside the function, such as a wire-contract change, resource leak, cancellation interaction, or broken consumer.
+- Correctness depends on ordering, concurrency, or another component's behavior.
+- A temporary workaround has a specific condition for removal.
+
+### Leave a comment out when
+
+- It repeats a name, annotation, expression, or the next statement.
+- It is a banner, divider, file-level narrative, or an explanation repeated in sibling modules.
+- It recounts a previous implementation, rejected approach, ticket, pull request, or incident; durable delivery history belongs in the work tracker.
+- It makes a claim that will drift, such as an unexplained current count or "for now" without an exit condition.
+
+### Form and review
+
+Place a comment immediately above the code it explains. Use concise plain sentences; put a longer explanation in a README or docs page and link to that path. Prefer documentation links over private issue or pull-request links. Rule-specific tool suppressions may remain inline when the checker requires it; include their concrete reason.
+
+Delete the comment mentally and read the code again. If no useful information disappears, remove it. If information does disappear, first check whether a clearer name, type, or structure can express it directly.
+
+Use one paragraph per line in Markdown and structured lists/tables where useful. Python comments and docstrings follow the Google-based 80-column conventions in [Python conventions](docs/python-style.md); the Markdown wrapping rule does not override the formatter.
+
+### Keep documentation current
+
+When changing an API, configuration value, dependency, behavior, or command, search README files, docs, contribution guidance, templates, and examples for its name and update every affected claim in the same change. Recheck "all", "every", and "only" claims against the resulting implementation.
+
+Describe supported behavior separately from proposals and release prerequisites. Verify local links and anchors, check examples and commands against the actual API, and distinguish syntax checks, offline tests, and hosted evidence. Do not imply publication, deployment, or live acceptance from a successful local build.
+
+### Docstrings
+
+Document public behavior with [Google-style docstrings](docs/python-style.md#docstrings), including meaningful arguments, results, errors, units, ownership, and cancellation where relevant. Docstrings explain the callable's contract; code comments explain constraints at the point they matter.
+
+## Security and conduct
+
+Follow [SECURITY.md](SECURITY.md) for vulnerabilities. For ordinary bugs and feature requests, use the repository's issue templates and remove credentials, customer identifiers, audio, and transcripts from reproductions.
+
+Keep discussion respectful, specific, and focused on the work. Explain tradeoffs, give actionable review feedback, and do not publish another person's private information. Maintainers may remove abusive or unsafe content.
+
+## License
+
+This project is licensed under [Apache-2.0](LICENSE). Contributions intentionally submitted for inclusion are provided under that license unless an existing written agreement states otherwise. Preserve applicable copyright and attribution notices, and disclose third-party material included with a contribution.

coval_agent_sdk-0.1.0/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

coval_agent_sdk-0.1.0/MANIFEST.in

@@ -0,0 +1,7 @@
+include AGENTS.md AGENTS.meta.md CONTRIBUTING.md SECURITY.md CHANGELOG.md
+include LICENSE NOTICE pyrightconfig.sdk.json .python-version
+recursive-include docs *.md
+recursive-include scripts *
+recursive-include tests *.py
+recursive-include release_tests *.py
+global-exclude __pycache__ *.py[cod]

coval_agent_sdk-0.1.0/NOTICE

@@ -0,0 +1,5 @@
+Coval Agent SDK
+Copyright 2026 Coval, Inc.
+
+This product includes software developed by Coval, Inc.
+Licensed under the Apache License, Version 2.0. See LICENSE.