# SDKCare executable sample

Five Python quickstarts with repeatable checks, explicit authentication recovery and a shareable evidence report.

**This package uses an original, fictional API on your own computer.** It has no customer credentials, hosted service, analytics, external API calls or real customer results. The original matrix cannot be pointed at a remote API; the separate customer_runner supports an approved customer sandbox through a reviewed SDK adapter. The planted old-example failure demonstrates the maintenance method; it is not a discovered incident at a real company.

## Run

Requirements: Python 3.11 or newer. No third-party Python packages are needed. Open a terminal in this folder and run:

```sh
python -m sdkcare report --output reports
```

Open `reports/index.html`. The command runs all five paths against two fictional API versions and two example versions, then runs the regression tests. A nonzero exit code means an unexpected result; do not describe that report as passed. The local sandbox starts and stops automatically on an ephemeral port at `127.0.0.1`.

To run only the regression suite:

```sh
python -m unittest discover -s tests -v
```

Optional fresh environment, with no package downloads:

```sh
python -m venv --without-pip .venv
# Windows:
.venv\Scripts\python.exe -m sdkcare report --output reports-clean
# macOS / Linux:
.venv/bin/python -m sdkcare report --output reports-clean
```

Use the executable for your operating system. This sample does not install Python or change your system environment. Do not run unfamiliar customer code or install dependencies merely because they appear in an email.

## What is included

- `sdkcare/`: original sandbox, demonstration client, five executable tutorials and report command.
- `tests/`: regression checks for version drift, authentication, permissions, retries, cleanup, limited logging and endpoint restrictions.
- `reports/`: the actual sample run's HTML, JSON evidence and regression text. Regenerate after any source change.
- `docs/tutorials.md`: five copyable tutorials, with expected results and failure interpretation.
- `docs/acceptance-and-operations.md`: scope, security gates and customer handoff checklist.
- `docs/change-note.md`: precise planted version difference and maintenance record.
- `customer-intake.json`: empty, non-secret scope questions for a future customer.
- `website-copy.html`: a reusable static introduction; no form submission or publishing behavior.

Every tutorial is executed from `sdkcare/tutorials.py`. The markdown examples demonstrate the same calls, but customer-provided documentation is not automatically parsed or executed. The JSON report includes source hashes, Python version, timestamps and request metadata without headers or payloads.

## Interpreting the report

The baseline pagination tutorial must pass against fictional API v1 and fail against fictional v2. The maintained tutorial must pass against both. The expected baseline failure is highlighted separately; it is not hidden among passing tests. The maintained parser supports the two documented sample formats only. Unknown schemas fail explicitly.

401 means stop and obtain an authorized replacement credential. 403 means stop and check owner-approved permissions; the client does not escalate privileges. These tutorials use separate hard-coded **demo** tokens to illustrate those steps. Never replace them with real keys in source code. Retry demonstrations are deliberately bounded and only automatic for GET; production retry policy must follow the customer's API and idempotency semantics.

## Working customer adapter and CI handoff

See `docs/customer-runner.md`, `customer-scope-template.json`, `customer-example/` and `ci/`. Five actual SDK adapter paths have run through the guarded transport, using only original test fixtures. The subprocess runner checks approved file/runtime pins and request bounds; it does not sandbox arbitrary hostile Python. CI/Docker templates are not enabled and were not run in a customer container.

## Customer service boundary

The proposed service is one customer-owned Python SDK, one isolated sandbox, five agreed tutorial paths, at most 25 code blocks and two agreed recovery cases. A maintenance package would cover at most two scheduled release updates and two documentation/example PRs per month. This is a scope draft, not an active subscription or order.

Real customer onboarding still needs permission, dummy fixtures, API-call limits, exact version pins, business-semantic confirmation, engineering review, an approved payment arrangement and acceptance. The customer configures test secrets and merges PRs. Core SDK/backend development, production payments/messages/deletes and unlimited new examples are excluded. Existing public software that performs similar checks is not claimed to be unique here.

The current package cost $0 in additional cash to create or run in the available local environment. Time has value and has not been fully measured. Real API sandboxes, CI and independent review may cost money; no purchases are authorized by this sample.
