iiisight 0.1__tar.gz

iiisight-0.1/.gitignore

@@ -0,0 +1,35 @@
+# macOS
+.DS_Store
+
+# Byte-compiled / optimized
+__pycache__/
+*.py[cod]
+*$py.class
+
+# Distribution / packaging
+build/
+dist/
+*.egg-info/
+.eggs/
+
+# Virtual environments
+.venv/
+venv/
+env/
+
+# Docs build output
+docs/_build/
+
+# Test / coverage / caches
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+.coverage
+htmlcov/
+
+# Environments / secrets
+.env
+
+# IDE
+.idea/
+.vscode/

iiisight-0.1/.gitlab-ci.yml

@@ -0,0 +1,76 @@
+# CI: test across Python 3.10-3.13, publish to PyPI on a version tag, and
+# rehearse on TestPyPI on a prerelease (rc) tag. Publishing uses GitLab OIDC
+# trusted publishing (no stored token).
+#
+# One-time PyPI setup: add "pending publisher" (GitLab) entries with
+#   Namespace: iiiris-org   Project: iiisight
+#   Top-level pipeline file path: .gitlab-ci.yml   (Environment: leave blank)
+# at BOTH:
+#   - https://pypi.org/manage/account/publishing/       (for `publish`)
+#   - https://test.pypi.org/manage/account/publishing/  (for `publish-testpypi`)
+#
+# Release flow:
+#   git tag v0.1rc1 && git push origin v0.1rc1   -> uploads to TestPyPI (rehearsal)
+#   git tag v0.1    && git push origin v0.1       -> uploads to PyPI (real release)
+
+stages:
+  - test
+  - deploy
+
+variables:
+  GIT_DEPTH: "0" # full history so setuptools-scm can see tags
+
+test:
+  stage: test
+  image: python:${PY}
+  parallel:
+    matrix:
+      - PY: ["3.10", "3.11", "3.12", "3.13"]
+  script:
+    - pip install -e ".[dev]"
+    - ruff check .
+    - ruff format --check .
+    - pytest
+
+# Shared publish logic. Exchanges the GitLab OIDC token for a short-lived PyPI
+# API token via the mint endpoint, then uploads. Concrete jobs set the audience,
+# mint URL, and repository URL for PyPI vs. TestPyPI.
+.publish:
+  stage: deploy
+  image: python:3.12
+  script:
+    - pip install build twine
+    - python -m build
+    - twine check dist/*
+    - |
+      RESPONSE=$(curl -s -X POST "$MINT_URL" -d "{\"token\":\"${PYPI_ID_TOKEN}\"}")
+      API_TOKEN=$(echo "$RESPONSE" | python -c "import sys, json; print(json.load(sys.stdin).get('token', ''))")
+      if [ -z "$API_TOKEN" ]; then
+        echo "OIDC token exchange failed at $MINT_URL."
+        echo "Response (no access token — check the trusted publisher config):"
+        echo "$RESPONSE"
+        exit 1
+      fi
+      TWINE_USERNAME=__token__ TWINE_PASSWORD="$API_TOKEN" twine upload --repository-url "$REPO_URL" dist/*
+
+publish:
+  extends: .publish
+  rules:
+    - if: '$CI_COMMIT_TAG =~ /^v[0-9]+(\.[0-9]+)*$/' # v0.1, v1.2.3 (not prereleases)
+  id_tokens:
+    PYPI_ID_TOKEN:
+      aud: pypi
+  variables:
+    MINT_URL: https://pypi.org/_/oidc/mint-token
+    REPO_URL: https://upload.pypi.org/legacy/
+
+publish-testpypi:
+  extends: .publish
+  rules:
+    - if: '$CI_COMMIT_TAG =~ /^v[0-9].*rc/' # v0.1rc1, v1.0rc2 (rehearsal)
+  id_tokens:
+    PYPI_ID_TOKEN:
+      aud: testpypi
+  variables:
+    MINT_URL: https://test.pypi.org/_/oidc/mint-token
+    REPO_URL: https://test.pypi.org/legacy/

iiisight-0.1/.readthedocs.yaml

@@ -0,0 +1,26 @@
+# Read the Docs build configuration.
+# https://docs.readthedocs.io/en/stable/config-file/v2.html
+
+version: 2
+
+build:
+  os: ubuntu-24.04
+  tools:
+    python: "3.12"
+  jobs:
+    post_checkout:
+      # setuptools-scm derives the version from tags; fetch them for a clean version.
+      - git fetch --tags --unshallow || true
+
+sphinx:
+  configuration: docs/conf.py
+
+python:
+  install:
+    - method: pip
+      path: .
+      extra_requirements:
+        - docs
+
+formats:
+  - pdf

iiisight-0.1/CHANGELOG.md

@@ -0,0 +1,39 @@
+# Changelog
+
+All notable changes to iiisight are documented here. The format follows
+[Keep a Changelog](https://keepachangelog.com/), and the project aims to follow
+[Semantic Versioning](https://semver.org/). The version is derived from the git
+tag by setuptools-scm; there is no hand-maintained version string.
+
+## [Unreleased]
+
+## [0.1] - 2026-07-05
+
+First public release. iiisight is a tolerant, async (and sync) Python client for
+consuming IIIF. This is a pre-1.0 line — the public API may still change before
+1.0.
+
+### Added
+
+- Tolerant normalization of IIIF Presentation documents into a typed, frozen
+  model (`normalize`), with structured `Diagnostic`s for every repair — it never
+  raises on spec-imperfect input.
+- Presentation **v2 → v3 upgrade** run before parsing, so v2 and v3 documents
+  normalize to one model.
+- Async and sync fetch clients (`AsyncClient` / `Client`) over `httpx`, with
+  `fetch` / `fetch_manifest` / `fetch_collection` / `resolve` / `expand`, plus
+  module-level convenience functions.
+- **Image API** tile-aware retrieval: `parse_info` (info.json → `ImageService`),
+  and `ImageService.url` / `thumbnail_url` / `tile_grid` / `tile_pyramid`, with
+  the v2/v3 `full`-vs-`max` size handling. `client.load_info` / `fetch_region`.
+- **Content Search** (`client.search`, `find_search_service`) returning hit
+  annotations.
+- **Content State** decode/encode (`iiisight.content_state`).
+- **Authorization Flow 2.0** metadata + non-interactive probe/token exchange
+  (`iiisight.auth`, `client.probe`, `client.access_token`).
+- Consumer **lint** over normalization diagnostics (`iiisight.lint`).
+- Generic `Service` model (with preserved `raw` JSON) parsed from resource-level
+  `service` blocks.
+
+[Unreleased]: https://gitlab.com/iiiris-org/iiisight/-/compare/v0.1...main
+[0.1]: https://gitlab.com/iiiris-org/iiisight/-/tags/v0.1

iiisight-0.1/CLAUDE.md

@@ -0,0 +1,122 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Current state
+
+Working library, pre-1.0. `PLAN.md` tracks the phased build and its status. Implemented today: tolerant Presentation normalization (`normalize`) into a typed frozen model with diagnostics; the v2→v3 upgrade; async + sync fetch clients (`AsyncClient`/`Client`); tile-aware Image API retrieval (`ImageService`, `parse_info`, `client.load_info`/`fetch_region`); Content Search (`client.search`); Content State (`iiisight.content_state`); Auth Flow 2.0 metadata + non-interactive probe/token (`iiisight.auth`); and a consumer lint (`iiisight.lint`). ~116 tests, ~95% coverage. Not yet released to PyPI; the name is reserved-available. Remaining: Image API conformance probe, Change Discovery, an optional CLI, and the first tagged release.
+
+## Project intent
+
+**Goal:** a reusable Python package for building applications that *consume* IIIF — the read-side substrate for viewers, search, harvesting, and conformance tooling. iiisight is the engine other people build on, not an end-user application.
+
+`iiisight` is a **tolerant, async Python client for *consuming* IIIF** — the read/consume counterpart to the JavaScript ecosystem's `@iiif/parser`. The target deliverable:
+- Fetches a IIIF manifest or collection over HTTP (async).
+- Normalizes Presentation API v2 → v3 so callers work against a single model.
+- Walks the IIIF structure: collections, manifests, canvases, ranges, and annotations.
+- Provides tile-aware image retrieval (Image API), computing region/size/tile requests from a service's `info.json` rather than fetching whole images.
+
+Design pillars that should guide decisions: **read-first** (consuming, not authoring), **async-first**, **tolerant** (accept real-world, spec-imperfect documents; degrade rather than raise), **normalized** (hide v2/v3 differences behind one interface), **ergonomic traversal**, and **tile-aware**.
+
+**Ecosystem positioning (important for scope decisions).** The premise is *not* "no Python IIIF library exists" — several do, but fragmented by concern and version, and all synchronous:
+- `iiif-prezi3` — the *construction* (write-side) library for Presentation **v3**; loads static v3 JSON but no URL fetch, no v2, no async, no traversal/Image-API helpers.
+- `piffle` — parses/builds Image API URLs and can `from_url()` a manifest and iterate canvases; the closest existing client, but **sync**, no v2→v3 normalization, thin range/annotation traversal, no tile-aware region math.
+- `iiif-prezi` (v2 reference) and `prezi-2-to-3` (standalone v2→v3 upgrade) cover the old version and the upgrade in isolation.
+
+iiisight fills the *integration* gap — an async, tolerant, version-agnostic **read** model with tile-aware retrieval. The two capabilities that exist nowhere else in Python — **async fetching** and **tile-aware Image API retrieval** — are the differentiators to protect.
+
+**Consolidation principle (overlap is allowed).** Overlapping existing tools is fine when it makes the unified client genuinely better. The test for pulling a capability in is *"does iiisight's existing machinery make the unified version better, and does it stay read-shaped?"* — **not** "does another tool already do it?" By that test an Image API conformance probe and a consumer manifest lint are in-scope future layers, not scope creep. Reuse vs. reinvent is then a pure engineering call (reuse iiif-prezi3's v3 types / prezi-2-to-3's upgrade when the dependency is clean; **own the layer** when sync/write-oriented/low-tolerance constraints would cap quality) — "better in one place" often favors owning more of the stack so tolerance, async, and diagnostics stay first-class.
+
+**Design decision — structured diagnostics.** The normalization layer must **record every deviation it repairs as a collectable structured diagnostic** (missing field → assumed default, wrong `type` → coerced, v2 → upgraded, malformed URL → skipped) rather than silently coercing. Client mode ignores them; this is what later unlocks a consumer-oriented manifest **lint** and keeps the door open to an Image API conformance **probe** — both as optional reporting layers over the same tolerant parse, never a stricter default.
+
+**Non-goals:** **authoring** (building/serializing new manifests — iiif-prezi3 owns the write side; iiisight stays a consumer) and being an image **server**. Validation/lint/probe modes are *not* excluded — they are welcome optional layers once the core read path is solid.
+
+## Domain context (IIIF)
+
+IIIF (International Image Interoperability Framework) has two APIs relevant here:
+- **Presentation API** — the JSON structure describing an object: a `Manifest` contains `Canvas`es (views/pages), which carry `Annotation`s (usually painting an image onto the canvas); `Range`s describe navigation/table-of-contents structure; `Collection`s group manifests. v2 and v3 differ substantially in shape (e.g. `@id`/`@type` vs `id`/`type`, `sequences` removed in v3, `resource` vs `body`), which is the core normalization problem this library solves.
+- **Image API** — an image server endpoint whose `info.json` advertises `tiles`, sizes, and scale factors; tile-aware retrieval means computing region/size requests against that info rather than downloading full-resolution images.
+
+When implementing normalization, verify behavior against the official IIIF specs and reference the JS `@iiif/parser` upgrade semantics for v2→v3 as the compatibility target.
+
+## Working here
+
+Because no toolchain is committed yet, do not assume build/test/lint commands exist — check for a manifest (`pyproject.toml`, `setup.cfg`, etc.) before running anything. The sections below describe the **intended** toolchain and conventions to adopt when bootstrapping; once the real commands exist, update this file so its description matches reality. Stale guidance here is worse than no guidance.
+
+## Python conventions
+
+- Target Python 3.10+ (set `requires-python = ">=3.10"` in `pyproject.toml`; keep it in sync with the trove classifiers when bumping the floor). Confirm the floor when the toolchain is established.
+- `from __future__ import annotations` is unnecessary on 3.10+; prefer native PEP 604 (`X | None`) and PEP 585 (`list[str]`) syntax.
+- Add type hints to all new/edited public functions, methods, and class attributes. Keep them precise — `Any` is a code smell, not a default. This matters especially for a "normalize-anything" parser: the normalized v3 model should be a typed surface callers can rely on.
+- Prefer f-strings over `.format()` / `%`.
+- **Docstrings & comments use [Google style](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings)** (`Args:` / `Returns:` / `Raises:` sections, one-line summary first). Every public module, class, and function gets a docstring; comments explain *why*, not *what*. Whenever you touch a function, method, class, or module, create or update its docstring and nearby comments in the same edit. Keep summaries tight — only add `Args:`/`Returns:`/`Raises:` sections where they carry real information.
+- **Async:** the client is async-first. Keep I/O (manifest/collection fetches, `info.json` retrieval, tile requests) non-blocking; do not call blocking network APIs from `async` code paths. Keep pure normalization/parsing logic synchronous and I/O-free so it is trivially testable without a network.
+- Treat the public import paths and the normalized-model attribute names as a **contract** once the package is published. Don't break them without surfacing it first; a break is a MAJOR (semver) event and must be documented for users.
+
+## Formatting & linting
+
+- Use `ruff` for both linting and formatting (`ruff check .` and `ruff format .`). No separate `black` / `flake8` / `isort` — `ruff` covers all three.
+- Line length 100. Double quotes. Put the `[tool.ruff]` block in `pyproject.toml` rather than a separate config file.
+- Run `ruff check --fix` before committing; never silence a lint with `# noqa` without a comment explaining why.
+
+## Testing
+
+- Use `pytest` with `pytest-asyncio` for coroutine tests, and mock/stub HTTP rather than hitting live IIIF servers so the suite is deterministic and offline.
+- Keep pure normalization (v2→v3) and structural-walk logic covered by fast, network-free unit tests fed real-world manifest fixtures — including deliberately spec-imperfect documents, since **tolerance** is a core requirement.
+- Store manifest/collection/`info.json` fixtures under `tests/` and cover both v2 and v3 inputs plus the v2→v3 upgrade path against the `@iiif/parser` semantics as the compatibility target.
+- Set a coverage gate in `pyproject.toml` (`--cov-fail-under=...`). Any change that drops coverage must add tests or intentionally adjust the gate — never silently lower it.
+- Single test: `pytest tests/test_foo.py::test_bar`.
+
+## Packaging
+
+Adopt modern PEP 621 packaging from the start — no `setup.py`, `Pipfile`, `MANIFEST.in`, or `requirements.txt`.
+
+- **PEP 621 metadata** lives entirely in `pyproject.toml` under `[project]` (setuptools backend). Restrict the shipped package with `[tool.setuptools.packages.find]` so `tests/` is never packaged.
+- **`setuptools-scm`** derives the version from the git tag (`dynamic = ["version"]`); never hand-write a `__version__`. Any code that needs the version reads `importlib.metadata.version("iiisight")`.
+- **License: Apache-2.0**, declared with the PEP 639 SPDX form (`license = "Apache-2.0"`, `license-files = ["LICENSE", "NOTICE"]`) — which requires `setuptools>=77` in `build-system.requires`. Do **not** add a `License ::` trove classifier (it conflicts with the SPDX field). The `NOTICE` file is the Apache attribution convention; keep the copyright line current.
+- **Build** with `python -m build` (never `setup.py`).
+- **Distribution**: a **pure-Python library on PyPI** — `pip install iiisight` (the name is confirmed available). No compiled extensions → a single universal `py3-none-any` wheel. Library-first: no server/daemon; callers bring their own event loop.
+- **Dependencies**: keep them lean — one runtime dep, `httpx`, under `[project] dependencies`. Optional features go behind extras under `[project.optional-dependencies]`: `dev` (the toolchain: `pytest`, `pytest-asyncio`, `pytest-cov`, `ruff`, `build`, `twine`), `prezi3` (iiif-prezi3 interop), `cli` (a thin command-line front-end). Local/CI dev uses `pip install -e ".[dev]"`.
+- **Optional CLI**: expose the reporting layers as console scripts under `[project.scripts]` (e.g. `iiisight lint <url>`, `iiisight probe <image-service>`), gated behind the `cli` extra so the core import stays dependency-light.
+- Prefer automated releases (GitLab CI building sdist+wheel and publishing to PyPI via OIDC trusted publishing) over `twine upload` from a workstation.
+
+## Build & release
+
+The project is hosted on **GitLab** (`gitlab.com/iiiris-org/iiisight`); CI/CD is `.gitlab-ci.yml` (there are no GitHub Actions workflows).
+
+**Releases are automated — do not `twine upload` from a workstation.** `.gitlab-ci.yml` has two tag-triggered jobs, both using GitLab OIDC (no stored token — the OIDC id-token is exchanged for a short-lived API token via the provider's `oidc/mint-token` endpoint):
+
+- **`publish`** → PyPI, on a clean version tag `vX.Y` / `vX.Y.Z` (regex excludes prereleases). `setuptools-scm` turns `v0.1` → version `0.1`.
+- **`publish-testpypi`** → TestPyPI, on a prerelease tag containing `rc` (e.g. `v0.1rc1`) — the rehearsal path.
+
+So the flow is: `git tag v0.1rc1 && git push origin v0.1rc1` (rehearse on TestPyPI), then `git tag v0.1 && git push origin v0.1` (real release).
+
+**One-time PyPI setup required** before the first release: add a GitLab "pending publisher" — namespace `iiiris-org`, project `iiisight`, pipeline file path `.gitlab-ci.yml`, environment blank — at **both** https://pypi.org/manage/account/publishing/ and (for the rehearsal) https://test.pypi.org/manage/account/publishing/. "Pending" because the project does not exist on either index yet; it is created on first publish.
+
+At release time, rename `## [Unreleased]` in `CHANGELOG.md` to `## [X.Y] - YYYY-MM-DD`, add a fresh empty `## [Unreleased]` above it, and update the link references at the bottom.
+
+## Keeping docs in sync
+
+Documentation must stay current with the code — update affected docs in the **same commit** as the change, not as a follow-up. Stale or missing docs on code you changed is not acceptable.
+
+- `README.md` is the single source of truth for the readme.
+- `CLAUDE.md` (this file) is the contract for future Claude sessions. When the toolchain, public API surface, testing setup, coverage gate, or file layout changes, update this file so it matches reality.
+- Maintain a `CHANGELOG.md` ([Keep a Changelog](https://keepachangelog.com/) format, newest first): every user-affecting change gets an entry under `## [Unreleased]` in the same commit; breaking changes go under a `Breaking` heading with a migration path and pair with a MAJOR version bump.
+
+### The user documentation (`docs/`, Read the Docs)
+
+The Sphinx site under `docs/` (published on Read the Docs, configured by `.readthedocs.yaml`; MyST Markdown + Furo + `sphinx-design` tabs) is the primary user-facing documentation. **As the project evolves, keep it in sync in the same commit as the code** — treat it as part of the change, never a follow-up. Aim for docs that are both **comprehensive** (every public capability is covered) and **user-friendly** (task-oriented, skimmable, welcoming to newcomers).
+
+When you change the public API or behavior:
+
+- **Add or update the relevant guide page** (`docs/guide/*.md`) — these are task-oriented ("Fetching", "Images & tiles", "Content Search", …). A *new* public capability gets a guide section or page; a changed one gets its section updated. Add a new page to the `toctree` in `docs/index.md`.
+- **The API reference** (`docs/reference/api.md`) is generated from docstrings via `automodule`, so it updates itself — but that means **every public function, class, and attribute needs a clear, current docstring** (Google style). A new public submodule needs its own `automodule` block added there.
+- **Update `docs/quickstart.md`** if the change touches the core happy path.
+- **Reflect user-affecting changes in `CHANGELOG.md`** (see above).
+
+Documentation standards to uphold:
+
+- **Show examples wherever possible.** Prefer a short, runnable code snippet over prose. Every guide page should lead with a concrete example.
+- **Show both async and sync styles.** iiisight ships `AsyncClient` and a sync `Client`; any example that performs I/O must present both — use a `sphinx-design` tab-set (`::::{tab-set}` with `Async` / `Sync` `:::{tab-item}`s), mirroring the existing pages. Pure, I/O-free calls (`normalize`, `parse_info`, `ImageService.url`, `content_state.decode`, `lint`) are the same in both worlds and need only one snippet.
+- **Cross-reference the API** with MyST roles (`` {class}`~iiisight.Manifest` ``, `` {meth}`~iiisight.ImageService.tile_grid` ``) so guides link into the reference.
+- **Verify the build** before committing: `pip install -e ".[docs]"` then `python -m sphinx -b html --keep-going docs docs/_build/html` must complete with **zero warnings** (broken cross-references and duplicate objects surface as warnings). `docs/_build/` is gitignored.

iiisight-0.1/CONTRIBUTING.md

@@ -0,0 +1,90 @@
+# Contributing to iiisight
+
+Thanks for your interest in iiisight. This guide covers the development setup and
+the conventions CI enforces. For the architecture and deeper design rationale,
+see `CLAUDE.md` and `PLAN.md`.
+
+## Development setup
+
+Requires Python 3.10+.
+
+```bash
+python -m venv .venv && source .venv/bin/activate
+pip install -e ".[dev]"          # installs iiisight + the test/lint/build toolchain
+```
+
+The version is derived from the git tag by `setuptools-scm`; there is no
+hand-maintained version string.
+
+## Everyday commands
+
+```bash
+pytest                                            # run the suite + coverage gate
+pytest tests/test_normalize_v3.py                 # a single file
+pytest tests/test_image.py::test_tile_grid_scale_factor_8   # a single test
+ruff check .                                      # lint
+ruff format .                                     # auto-format
+ruff format --check .                             # verify formatting (as CI does)
+```
+
+CI (`.gitlab-ci.yml`) runs `ruff check`, `ruff format --check`, and `pytest`
+across Python 3.10–3.13. All three must pass.
+
+## Conventions
+
+- **Coverage gate: 90%** (`--cov-fail-under=90` in `pyproject.toml`). New behavior
+  needs tests; if a line is genuinely defensive/unreachable, mark it
+  `# pragma: no cover` with a reason rather than lowering the gate.
+- **Tolerance is a core invariant.** `normalize()` must never raise on
+  spec-imperfect input — it repairs and records a `Diagnostic`. Every
+  normalization path should have a malformed-input test asserting *"does not
+  raise, emits the expected diagnostic, yields a usable model."*
+- **The model is pure and I/O-free.** All network access is explicit on the
+  client (`fetch`, `expand`, `load_info`, …); never fetch behind attribute access.
+- **Style:** `ruff` for lint + format (line length 100, double quotes). Precise
+  type hints on public functions; Google-style docstrings; f-strings. Prefer
+  native `X | None` / `list[str]` over `typing`/`from __future__ import`.
+- **Public API is a contract** once released. Keep import paths and the normalized
+  model's attribute names stable; a break is a MAJOR-version, `CHANGELOG`-documented
+  event.
+
+## Changelog
+
+Every user-affecting change gets an entry under `## [Unreleased]` in
+`CHANGELOG.md` (Keep a Changelog format), **in the same commit** as the change.
+Internal-only churn (refactors, test/CI/formatting) does not need an entry.
+
+## Real-world check (optional)
+
+`scripts/validate_realworld.py` runs iiisight against live IIIF servers (not part
+of CI — it needs network). Run it when touching normalization, the upgrade, or the
+tile math:
+
+```bash
+python scripts/validate_realworld.py
+```
+
+## Documentation
+
+The user documentation is a Sphinx site under `docs/` (MyST Markdown, Furo theme),
+published on Read the Docs. Build it locally with:
+
+```bash
+pip install -e ".[docs]"
+python -m sphinx -b html --keep-going docs docs/_build/html
+open docs/_build/html/index.html
+```
+
+The build must complete with **zero warnings** (broken cross-references show up as
+warnings). When you change the public API or behavior, update the relevant guide
+page under `docs/guide/`, keep every public symbol's docstring current (the API
+reference is generated from them), and show **both async and sync** styles for any
+example that does I/O. See the "Keeping docs in sync" section of `CLAUDE.md` for
+the full policy.
+
+## Releases
+
+Releases are automated via GitLab CI and OIDC trusted publishing — see the
+**Build & release** section of `CLAUDE.md`. In short: push a `vX.Y` tag to publish
+to PyPI (or a `vX.Yrc1` tag to rehearse on TestPyPI); do not `twine upload` from a
+workstation.

iiisight-0.1/LICENSE

@@ -0,0 +1,201 @@
+                                 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 2026 Roger Howard
+
+   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.

iiisight-0.1/NOTICE

@@ -0,0 +1,4 @@
+iiisight
+Copyright 2026 Roger Howard
+
+This product is licensed under the Apache License, Version 2.0 (see LICENSE).