apparitor 0.1.1__tar.gz

apparitor-0.1.1/.gitignore

@@ -0,0 +1,30 @@
+# Python
+__pycache__/
+*.py[cod]
+*.egg-info/
+.eggs/
+build/
+dist/
+sbom/
+.venv/
+venv/
+
+# Test / coverage
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+.hypothesis/
+.coverage
+.coverage.*
+htmlcov/
+coverage.xml
+
+# Secrets — never commit real credentials or env files
+.env
+.env.*
+!.env.example
+
+# Editors / OS
+.idea/
+.vscode/
+.DS_Store

apparitor-0.1.1/CHANGELOG.md

@@ -0,0 +1,242 @@
+# Changelog
+
+All notable changes to this project are documented here. The format follows
+[Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the project aims to follow
+[Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.1.1] - 2026-06-16
+
+### Added
+- **`request_context_scope(context)` context manager** (`apparitor.mapping`, exported from
+  `apparitor`). Mirrors `subject_scope`: binds `current_request_context` for the duration
+  of the `with` block and resets it in `finally`, so a host that forgets to reset cannot
+  leak a prior request's injected context into a later request on a reused task/loop. This
+  is now the preferred pattern over calling `.set()/.reset()` directly (documented in
+  `docs/setup.md`).
+- **Security posture & assurance document** (`docs/security-review.md`): standing
+  invariants, threat-model coverage, test citations, known limitations, and re-review
+  triggers. A continuously scannable baseline.
+
+### Security
+- **PDP response parsing now rejects duplicate JSON keys (§3.6), failing closed with
+  `MalformedPDPResponseError`.** An `object_pairs_hook` in the new `_strict_json` helper
+  raises `MalformedPDPResponseError` on any duplicate key within a JSON object, closing a
+  response-validation gap at the PDP trust boundary. The fix applies to both the AuthZEN
+  transport and the OPA backend. Sibling objects in a batch response (multiple `"decision"`
+  fields in distinct array entries) are correctly not flagged; the check is per-object.
+- **Error-path `VerdictResult.reason` is now always a generic string (§3.10).** All
+  error-path verdicts use the fixed `_DENY_REASON` constant, ensuring internal detail
+  (exception text, transport state) is never exposed to callers. Exception detail continues
+  to appear in operator logs for diagnostics. The fix also adds log lines on early-return
+  paths that previously had none (unparseable tool call, 4xx client error).
+- **`asyncio.CancelledError` is now recorded in metrics before re-propagating.** A
+  dedicated `except asyncio.CancelledError` clause in `_evaluate_guarded` records a
+  `block/error` decision metric and immediately re-raises, preserving
+  structured-concurrency invariants. The public `evaluate_normalized` and
+  `evaluate_requests` docstrings note that `CancelledError` propagates and callers must
+  treat an unfinished scan as non-authorized.
+- **Cedar `_entity_uid` hardened to reject backslash and control characters.** The
+  rejection is now explicit at the validation seam (covering double-quote, backslash, and
+  control characters), so invalid identifiers are caught before Cedar processes them. The
+  engine already failed closed on a Cedar parse error (NoDecision becomes BLOCK); this makes
+  the boundary explicit.
+- **`.env` added to `.gitignore`; `llamafirewall` extra capped at `<1`.** Prevents
+  accidental credential commits and pins the audited major version of the ML stack.
+
+### Changed
+- **`AuthZENConfigError` now also inherits `ValueError` for backward compatibility.**
+  Adapter constructors previously raised plain `ValueError` for misconfiguration (missing
+  PDP URL, reserved subject type, invalid label, now all four adapters, including the
+  scanner). Code catching `except ValueError` still catches these; code that was already
+  catching `except AuthZENConfigError` is unaffected. Pre-1.0 decision: keeping the mixin
+  avoids a breaking change for callers that only imported the public error hierarchy after
+  the fact. Update existing `except ValueError` handlers that handle only configuration
+  errors to catch `AuthZENConfigError` instead for precision. `build_engine` now also
+  rejects providing both `pdp_url` and `config` simultaneously (previously config silently
+  won; now a `AuthZENConfigError` is raised).
+- **Inline/gateway SKIP semantics and batch-item merge logic unified across all adapters.**
+  `is_allowed_inline`, `is_allowed_gateway`, `record_pre_engine_refusal`, and
+  `DUAL_PRINCIPAL_CACHE_WARNING` are shared helpers in `apparitor.decision` (lowest-common
+  import, engine-free and host-SDK-free to avoid import cycles); their divergent SKIP
+  behaviour and the `is not None` batch-item merge semantics are pinned by tests.
+
+## [0.1.0] - 2026-06-11
+
+### Added
+- **Audit-log schema frozen as a stability contract (`docs/audit-log.md`).** Logger,
+  levels, C1/C2/C3 line grammar (format strings, field tables, rendered examples),
+  fingerprint derivation, parsing guidance, timestamp/clock requirements, an EU
+  regulatory mapping (AI Act record-keeping and retention, GDPR handling, transfer
+  routing), and stability policy. Pinned by
+  `tests/unit/test_log_contract.py`. A failure there is a breaking log-schema change
+  requiring a CHANGELOG "Update log parsers" entry and a version bump.
+- **Runnable MCP authorization-gateway example (`examples/gateway/`).** A FastMCP proxy
+  fronting an unmodifiable upstream, middleware enforcing at the chokepoint: denied calls
+  proven never to reach the upstream, listing filtered to hide what the subject may not
+  call. Exercised on both supported fastmcp lines by the `gateway-demo` CI job.
+- **Runnable scenario walk-through (`examples/scenarios/`).** Dependency-free (core install
+  only) self-asserting script over the mock PDP covering seven scenarios: allow, deny
+  (2-part deny key), unparseable input fails closed, PDP unreachable with `on_error=deny`,
+  PDP unreachable with `on_error=human_review`, batch all-or-nothing aggregation, and
+  dual-principal (user AND agent boundary) evaluation. Gated in CI by the `scenarios` job.
+  Also: the mock PDP now supports a subject-scoped **3-part deny form**
+  (`"<subject_id>:<action>:<resource_id>"`) in addition to the existing 2-part form.
+- **Dual-principal evaluation (`DualPrincipalMapper`).** Emits two requests per tool
+  call (the end user's grant and the agent's own permission boundary), ANDed by the
+  engine's all-allow-or-block aggregation, so an agent can never exercise a permission
+  its boundary denies even when the human holds it. The user leg is request-scoped only
+  (no `agent_id` fallback, which would collapse the AND); either principal unresolvable
+  fails closed; `"workload"` stays reserved. Works via the `mapper=` seam in the scanner,
+  the NeMo rail and the FastMCP middleware (tools + listing). Note: dual calls always
+  evaluate as a batch, so the opt-in ALLOW cache is not consulted.
+- **Dual-principal boundary for adapter-shaped paths (closes
+  [#39](https://github.com/jhawlwut/apparitor/issues/39)).** `A2AAuthorizationExecutor`
+  and `FastMCPAuthorizationMiddleware` now accept a `boundary_subject` constructor parameter.
+  When set, every invocation (A2A) or every `resources/read` / `prompts/get` request (FastMCP)
+  is evaluated as a two-request batch (the resolved caller leg AND the boundary leg) using
+  the same AND/all-allow-or-block semantics as `DualPrincipalMapper`. For FastMCP,
+  `boundary_subject` covers the resource/prompt adapter paths only; use
+  `mapper=DualPrincipalMapper(config)` for `tools/call` and listing. A full deployment sets
+  both. The same fail-closed guards apply: `"workload"` boundary rejected at construction,
+  collapse (boundary == caller) refused before any PDP call, cache warning emitted when
+  `cache_enabled=True`. Shared helper `build_boundary_leg` in `apparitor.mapping` (exported
+  from the package) powers both adapters.
+- `ToolCallMapper.map()` may now return a **sequence** of requests that must all be
+  allowed (backward compatible; `None`/empty sequence abstains, since an empty group can
+  never read as an allow, on either the aggregate or the per-item path).
+- **A2A agent-executor enforcement point (`apparitor.a2a`, optional `[a2a]` extra).**
+  `A2AAuthorizationExecutor` wraps a deployment's `AgentExecutor` and authorizes every
+  agent-to-agent invocation before it runs (action `agent.invoke`; resource
+  `{type: "a2a_agent", id: <agent_label>}`, or `a2a_skill` with a `"<agent>/<skill>"` key
+  via the `skill_resolver` hook; segments validated, skill kept verbatim). The subject is
+  the server's **authenticated peer** (`Subject(type="agent", id=<user_name>)` by
+  default), falling back to a subject injected per request via
+  `ServerCallContext.state["subject"]` and then the opt-in static `agent_id`. An
+  unauthenticated caller is refused, and ambient contextvars are deliberately ignored
+  (the SDK's detached producer task snapshots them, so they go stale across turns). The request's A2A `tenant` is forwarded in the
+  AuthZEN context for multi-tenant policies (a caller-supplied claim for policies to
+  cross-check, not proof). Verdicts map fail-closed: only a clean
+  `ALLOW` reaches the wrapped executor; everything else raises a deliberately generic A2A
+  error (the rich reason stays in the operator log). `cancel` passes through ungated in
+  v1 (documented). Built on `AuthorizationEngine.evaluate_requests`, no core changes.
+- **Complete MCP enforcement scope for the FastMCP middleware** (closes
+  [#32](https://github.com/jhawlwut/apparitor/issues/32),
+  [#33](https://github.com/jhawlwut/apparitor/issues/33),
+  [#34](https://github.com/jhawlwut/apparitor/issues/34)):
+  - `resources/read` and `prompts/get` are now **gated by default** (actions
+    `resource.read` / `prompt.get`; resource ids: the URI verbatim for resources with the
+    server label as a property, `"<server>/<prompt>"` for prompts), with the same subject
+    chain, generic refusals (`ResourceError`/`PromptError`) and fail-closed verdict
+    mapping as tool calls; `gate_resources=False` / `gate_prompts=False` opt a hook out.
+    **Breaking (pre-alpha):** deployments without resource/prompt policies will see those
+    requests denied; write policies or opt out.
+  - Opt-in `filter_listings=True` hides tools from `tools/list` whose `tools/call` the
+    subject would be denied. One batch PDP round trip, advisory only (`tools/call`
+    remains the enforcement invariant), and fail-closed (no subject or any fault hides
+    everything).
+  - Opt-in `allow_workload_subject=True` authorizes verified client-credentials tokens
+    (no `sub` claim) as the distinct `Subject(type="workload", id=<client_id>)`, never
+    coerced into a user subject; off by default, such tokens keep refusing. The
+    `"workload"` subject type is reserved (the constructor rejects it for claim-derived
+    and static subjects). Only `tools/list` is filtered; `resources/list` and
+    `prompts/list` still advertise names/URIs even though reads/gets are gated.
+- `AuthorizationEngine.evaluate_requests()` (pre-mapped requests, e.g. adapter-shaped
+  resource/prompt tuples) and `AuthorizationEngine.evaluate_each()` (positional per-item
+  verdicts over one batch round trip, for visibility filtering, fail-closed per item).
+- **Three-PEP portability demo (`examples/three-peps/`).** The same vendored Cedar policy
+  (`examples/cedar/policies.cedar`, deny-override on `destructive == true`) enforced
+  identically at the LlamaFirewall scanner, the NeMo Guardrails rail, and the FastMCP
+  middleware over the in-process Cedar backend: no Docker, no network. Self-asserting
+  (exits non-zero on any verdict mismatch) and gated in CI by the `three-pep-demo` job,
+  which installs all three enforcement-point extras and requires every lane to run.
+- **FastMCP server-middleware enforcement point (`apparitor.fastmcp`, optional `[fastmcp]`
+  extra).** `FastMCPAuthorizationMiddleware` authorizes every MCP `tools/call` server-side,
+  before the tool executes, over the same `AuthorizationEngine` as the LlamaFirewall scanner
+  and the NeMo rail. The subject comes from the **validated** OAuth access token
+  (`claims["sub"]`, configurable) and outranks host-asserted subjects; a token without a
+  usable claim refuses, and the static `agent_id` fallback is gated behind an explicit
+  `allow_static_subject=True` opt-in (local/stdio only). Verdicts map fail-closed onto MCP:
+  only a clean `ALLOW` executes; `BLOCK` / `HUMAN_REVIEW` / mapper abstention / errors raise
+  a deliberately generic `ToolError` (the rich reason stays in the operator log). Supports
+  fastmcp 2.14 and 3.x (both exercised in CI).
+- `AuthorizationEngine.evaluate_normalized()`: a public seam for enforcement points that
+  receive tool calls in structured form (no provider-shape adapter detection).
+- `MCPResourceMapper` can now resolve its server label per call from
+  `request_context[MCP_SERVER_LABEL_KEY]`; the tool segment gets the same case/whitespace
+  normalisation as the default mapper, and `mcp_resource_id` rejects embedded `/` (an
+  ambiguous policy key), fail-closed.
+- `DecisionCache` is bounded: new `cache_max_entries` config (default 10 000, FIFO
+  eviction) so per-token subject cardinality cannot grow the ALLOW cache without limit.
+- **Docker-free OpenFGA integration backend (linux/amd64).** Set `APPARITOR_OPENFGA_NATIVE=1` to run the
+  OpenFGA E2E against a pinned, **SHA-256-verified** OpenFGA release binary launched directly
+  (only `github.com` egress needed) instead of a container, so the real-PDP test works where
+  the Docker registry is unreachable. Same vendored model + tuples and assertions; a
+  `workflow_dispatch` `integration-native` CI job exercises it.
+- **Working scan pipeline (M1).** `AuthZENScanner.scan()` authorizes an agent's tool
+  calls end-to-end: extract → map → evaluate → decide.
+- LlamaFirewall-free `AuthorizationEngine` holding all logic, so the pipeline is fully
+  unit-testable without the ML stack. The scanner is a thin adapter that converts the
+  verdict to a `ScanResult`.
+- `AuthZENClient`: async httpx transport with explicit timeouts, a request budget,
+  bounded retries (429/5xx/transport only) with jittered backoff, an SSRF/TLS guard on
+  `pdp_url`, bring-your-own-client support, and httpx→typed-error mapping.
+- `DefaultToolCallMapper` / `MCPResourceMapper`: request-scoped subject resolution
+  (never from model output), argument redaction/size-caps, MCP server-scoped resource ids.
+- Opt-in, ALLOW-only TTL `DecisionCache` with a full-tuple SHA-256 key.
+- Batch evaluation with all-allow-or-block aggregation; `review_predicate` escalation
+  (never downgrade); fail-closed `on_error` (deny / human_review).
+- AuthZEN 1.0 pydantic models; provider-aware tool-call adapters (OpenAI / Anthropic /
+  LangChain); `ScannerConfig` with secure defaults; exception hierarchy.
+- A dependency-free mock AuthZEN PDP for demos/tests.
+- Test suite: 90+ unit tests, 98% line+branch coverage on the LlamaFirewall-free
+  modules (90% gate enforced), including the security invariants.
+- **Real PDP examples (M3).** Runnable OpenFGA example (native, experimental AuthZEN API;
+  vendored model + relationship tuples) and Cedar example (policy-as-code behind a local
+  AuthZEN → Cedar gateway running the official Cedar CLI), each with a `smoke.sh` and a
+  Docker-gated `testcontainers` integration test that skips when no daemon is present.
+- `integration` optional-dependency group (`testcontainers`) and a `workflow_dispatch`
+  CI job that runs the integration suite.
+- **Observability (M2).** A dependency-free metrics sink (`MetricsSink` protocol with a
+  default `InMemoryMetrics` and a `NoopMetrics` opt-out): a decision-latency histogram and
+  a cache-hit/miss counter, surfaced on the engine and scanner. Structured audit logs now
+  carry the verdict, status, subject (decision principal), correlation id, and an argument
+  *fingerprint*; raw arguments and tokens are never logged (arguments are fingerprinted).
+- **AuthZEN 1.0 wire-conformance suite** (`tests/conformance/`): vendored canonical
+  request/response payloads driven through the models and client to prove wire
+  compatibility (request shapes, response decisions, batch aggregation, and malformed
+  responses failing closed).
+
+### Changed
+
+- **Audit-log message prefixes normalized `authzen` → `apparitor`** to match the logger
+  name and project name. Field names and grammar are unchanged. **Update log parsers**
+  anchoring on the old `authzen decision`, `authzen batch`, or `authzen per-item`
+  prefixes: replace with `apparitor decision`, `apparitor batch`,
+  `apparitor per-item`.
+- The structured decision log's resource-id field is now `resources=` (was `tools=`).
+  It can carry resource URIs and prompt keys, not just tool names. Update log parsers.
+- The structured decision log now records **every distinct principal** as `subjects=`
+  (was `subject=` with only the first leg). Under dual-principal evaluation the audit
+  trail must name both the user and the agent, and `resources=` / `fingerprints=`
+  carry one entry per evaluation request, so dual legs appear twice. Update log parsers.
+- `DefaultToolCallMapper.map()`'s return annotation is widened to the full
+  `ToolCallMapper` union; a typed subclass that delegates to `super().map()` must
+  accept the widened return (runtime behaviour of the default mapper is unchanged).
+- **Renamed to `apparitor` and repositioned.** The project is now a vendor-neutral
+  authorization layer that aggregates policy engines (AuthZEN, Cedar, OpenFGA, Rego) across
+  agentic firewalls (LlamaFirewall today; NeMo Guardrails planned), rather than an
+  AuthZEN-scanner-for-LlamaFirewall only. The Python import package and PyPI distribution
+  are now **`apparitor`** (was `authzen_llamafirewall` / `authzen-llamafirewall-scanner`):
+  `from apparitor import AuthZENScanner`. Breaking import change, acceptable pre-alpha, no
+  published release affected. Public API names (`AuthZENScanner`, `AuthorizationEngine`, …)
+  are unchanged.
+- **Spec fix:** the batch options field is now `evaluations_semantic` (plural), matching
+  AuthZEN 1.0; it was previously serialised as `evaluation_semantic`. Renames
+  `EvaluationsOptions.evaluation_semantic` → `evaluations_semantic` (pre-alpha, breaking).
+- `DefaultToolCallMapper._resource` takes the request context (so `MCPResourceMapper` can
+  resolve a per-call server label). A custom mapper subclass overriding the protected
+  `_resource` must adopt the new signature; the public `ToolCallMapper.map` contract is
+  unchanged.
+
+## [0.0.1a0]
+- Initial pre-alpha scaffold.

apparitor-0.1.1/CONTRIBUTING.md

@@ -0,0 +1,116 @@
+# Contributing
+
+Thanks for your interest! This is an Apache-2.0, public-standards-only project. Please keep
+contributions free of proprietary or confidential material.
+
+## Development setup
+
+```bash
+python -m venv .venv && source .venv/bin/activate
+pip install -e ".[dev]"            # AuthZEN client/models + tooling
+pip install -e ".[dev,llamafirewall]"   # add the scanner path (pulls the LlamaFirewall ML stack)
+```
+
+The `[llamafirewall]` extra is heavy (it brings PromptGuard's ML dependencies). The
+AuthZEN-free modules (`models`, `client`, `adapters`, `mapping`, `cache`, `config`,
+`errors`) develop and test fine **without** it.
+
+## Checks
+
+```bash
+ruff check .            # lint
+ruff format .           # format
+mypy src/               # types (strict)
+pytest                  # unit suite (integration excluded by default)
+pytest -m integration   # integration (needs Docker; auto-skips when absent)
+python -m build && twine check dist/*   # packaging
+```
+
+CI runs lint, types, the unit suite on Python 3.10 to 3.13, and a packaging check. The
+coverage gate (≥90% line+branch on the LlamaFirewall-free modules) turns on with the
+behavioural suite.
+
+## Branch naming
+
+Format: **`<type>/<short-kebab-summary>`**, optionally with an issue number:
+`<type>/<issue>-<summary>`. Lowercase, hyphen-separated, 3 to 5 words.
+
+```
+feat/authzen-client
+fix/cache-ttl-clamp
+docs/setup-guide
+feat/42-batch-evaluation
+```
+
+`<type>` matches the commit types below (`feat`, `fix`, `docs`, `refactor`, `test`,
+`chore`, `ci`, `perf`). Automated agent sessions may push to tool-managed branches like
+`claude/<slug>-<id>`. The trailing id is intentional collision-avoidance, not a naming
+choice. Human-driven branches should use the convention above.
+
+## Commit messages: [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
+
+```
+<type>(<optional scope>): <imperative summary>   # ≤72 chars, lowercase, no trailing period
+
+<body: explain *why*, not what; wrapped at 72 cols>
+
+<footers: e.g. "Closes #123", "BREAKING CHANGE: ...">
+```
+
+- **Types:** `feat` (new feature), `fix` (bug fix), `docs`, `refactor`, `perf`, `test`,
+  `build`, `ci`, `chore`, `revert`.
+- **Scope** (optional) names the area, e.g. `feat(client):`, `fix(cache):`.
+- **Breaking changes:** append `!` (`feat(config)!: ...`) and/or add a
+  `BREAKING CHANGE:` footer.
+- Imperative mood ("add", not "added"/"adds"). The subject says *what*; the body says
+  *why*.
+
+## Pull requests
+
+- One logical change per PR; keep them small and reviewable. Open as **draft** early.
+- PR **title** uses the Conventional Commits format (it usually becomes the squash-merge
+  subject).
+- PR **body** covers: context/why, what changed, how it was tested, and linked issues
+  (`Closes #N`).
+- CI must be green. Run the full check suite (see above) before pushing.
+- Add or update tests for behavioural changes; update docs in the same PR.
+
+## AI-assisted contributions
+
+AI coding assistants are **welcome** here. Many of this project's own changes are
+agent-assisted. The bar is the same as for any contribution, and a few expectations keep it
+useful rather than noisy:
+
+- **You are the author of record.** By submitting, you certify you understand, have
+  reviewed, and have tested the change: you can explain and stand behind every line,
+  whoever (or whatever) drafted it. Signing off (`git commit -s`, see below) makes that
+  explicit.
+- **Same quality bar.** The full check suite must pass, behavioural changes need tests, and
+  the [anti-slop guidance in `AGENTS.md`](AGENTS.md) applies: smallest change that solves
+  the problem, no drive-by churn, comments that explain *why*. Unreviewed or bulk
+  machine-generated PRs (mass "fix-up" sweeps, output you haven't read) will be closed.
+- **Disclosure is encouraged, not required.** If an assistant did meaningful work, note it
+  with a provenance trailer so reviewers know where to look: `Assisted-by:` when a human
+  authored with help, `Generated-by:` when a tool produced essentially all of a change
+  (e.g. `Assisted-by: <tool/model>`). The trailer names a *tool*, never an author: an
+  assistant is never listed as `Signed-off-by:` or `Co-authored-by:`. The DCO sign-off and
+  authorship are yours alone, and the change is attributed to you. (Don't name the assistant
+  anywhere else in the commit or PR text.)
+- **Agent-instruction files are security-sensitive.** Changes to `AGENTS.md`, `CLAUDE.md`,
+  `.claude/**`, and the CI/release workflows are reviewed with extra scrutiny. Coding agents
+  treat instruction files as trusted context and a compromised workflow could leak secrets,
+  so both are an injection / supply-chain surface. See [`SECURITY.md`](SECURITY.md).
+
+Working through an agent? [`AGENTS.md`](AGENTS.md) is the canonical guide (tool-specific
+files point to it), and reusable workflows live in [`.claude/skills/`](.claude/skills/).
+
+## Licensing & sign-off
+
+By contributing you agree your work is licensed under Apache-2.0. DCO-style sign-off is
+welcome: `git commit -s`.
+
+## Design
+
+Read [`docs/requirements.md`](docs/requirements.md) before proposing behavioural changes.
+Several decisions (no fail-open, subject never from message content, ALLOW-only caching)
+are deliberate security invariants, not oversights.

apparitor-0.1.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 [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.

apparitor-0.1.1/NOTICE

@@ -0,0 +1,8 @@
+apparitor
+Copyright 2026 The apparitor authors
+
+This product is licensed under the Apache License, Version 2.0 (the "License");
+you may not use this product except in compliance with the License. You may obtain
+a copy of the License in the LICENSE file or at:
+
+    http://www.apache.org/licenses/LICENSE-2.0