labtasker-webui 0.1.1__tar.gz

labtasker_webui-0.1.1/.agents/skills/release/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: release
+description: Prepare or validate Labtasker WebUI release versions, artifacts, tags, or PyPI publication; not for routine frontend builds.
+---
+
+# Release Labtasker WebUI
+
+Follow root `AGENTS.md` and `.agents/sops/releasing.md`. This is a single WebUI distribution,
+not the three-package Labtasker workspace; do not copy its Worker/distributed test gate.
+
+1. Establish the requested version and authorized stage: preparation, commit, tag, push,
+   GitHub Release or publication. Authorization for preparation is not publication.
+2. Inspect branch, remotes, tags and dirty work. Preserve unrelated changes.
+3. Update the Python metadata/runtime and frontend manifest/lockfile versions together.
+   Run `uv lock`, then `uv run python scripts/check_versions.py --tag vVERSION`.
+4. Run the ordinary gate in `.agents/sops/development.md`. Verify wheel-from-sdist installation,
+   bundled assets and no Node.js runtime dependency. Do not replace tested artifacts.
+5. Write Labtasker-style user-facing release notes. Report compatibility actions precisely;
+   do not invent release history or a version-only changelog.
+6. Only when explicitly authorized, publish the matching GitHub Release. The workflow
+   rechecks the gate and publishes through the protected `pypi` OIDC environment.
+7. Report actual release/workflow URLs or explicitly state which external steps remain.

labtasker_webui-0.1.1/.agents/skills/ui-change/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: ui-change
+description: Reproduce and fix a Labtasker WebUI interaction, state, or layout defect; use for UI behavior changes and browser regressions.
+---
+
+# Change Labtasker WebUI behavior
+
+Read root `AGENTS.md`, `docs/reference/specification.md`, and the relevant section of
+`.agents/sops/qa.md`. Preserve real workloads; use the synthetic fixture. Inspect the current
+diff and do not include unrelated changes.
+
+1. Reproduce using the current frontend build. Record viewport, browser, trigger and
+   expected result. For focus/menu behavior include WebKit.
+2. Trace the responsible state and event/request order. Distinguish draft versus applied
+   filters, local versus persisted settings, and connection/Queue/view scopes.
+3. Add a regression for the failure, then fix the owning component. Prefer existing
+   anchored-panel, Select, tooltip and persistence helpers over parallel implementations.
+4. Build assets before browser tests. Run one Playwright invocation at a time. Exercise
+   the affected cases from the QA matrix; inspect screenshots/traces for visual failures.
+5. Update the contract/docs when behavior changes. Run proportional final checks from
+   `.agents/sops/development.md`; report results and limitations without claiming zero defects.
+
+Do not add confirmation prompts to routine view switching, mutate lingbot queues,
+reintroduce forced Apply for dropdowns, or weaken tests to accept a broken interaction.

labtasker_webui-0.1.1/.agents/sops/development.md

@@ -0,0 +1,102 @@
+# Development and debugging SOP
+
+## Setup
+
+Use Python 3.11+ and Node.js 22 (`.nvmrc`). From the repository root:
+
+```sh
+npm ci --prefix frontend
+npm --prefix frontend run build
+uv sync --group dev --frozen
+uv run pre-commit install
+cd frontend
+npx playwright install chromium firefox webkit
+cd ..
+```
+
+Install Playwright's OS dependencies on Linux with `npx playwright install --with-deps`
+from `frontend/`. Do not reinstall or upgrade dependencies merely to fix a CSS rule
+when the existing environment already works.
+
+## Run and rebuild
+
+```sh
+uv run labtasker-webui --host 127.0.0.1 --port 8080
+```
+
+The CLI serves built `frontend/dist` assets. After frontend edits, run
+`npm --prefix frontend run build` and refresh the browser. Python changes require a
+WebUI restart. Confirm the working directory, command, PID and listening port before
+stopping a process; restart only that WebUI process, never the connected Labtasker.
+If a process is owned by another task or supervisor, use its normal restart mechanism.
+
+For an isolated manual session, use another port and `--no-profile`. The default CLI
+loads `.labtasker/` relative to its working directory, not the connected project's path.
+The connection page controls HTTP/local mode. Keep the CLI limited to host, port and
+profile persistence. Local attachment requires the Labtasker instance to be running.
+
+## Change loop
+
+1. Reproduce the issue with the current built UI or a focused backend test.
+2. Identify state ownership, request parameters and event order before editing.
+3. Add a regression for the user-visible failure. Use synthetic data for mutations.
+4. Make the smallest coherent change and run the relevant checks below.
+5. For broad changes, run the full ordinary gate; update docs and report actual results.
+
+Do not run multiple Playwright commands concurrently: port ownership, mutable fixture
+state and trace output are shared. Playwright intentionally fails on occupied test
+ports rather than silently using an unknown server. Ports are 18765 (fixture upstream)
+and 18766 (isolated WebUI). Diagnose their owner; do not use `pkill` or blanket cleanup.
+
+## Troubleshooting
+
+| Symptom | Inspect first | Recovery |
+| --- | --- | --- |
+| UI still looks unchanged | Build success, loaded asset filename, served working directory | Rebuild assets and reload |
+| Backend change has no effect | Running WebUI command and process | Restart that WebUI only |
+| Connection fails | HTTP scheme, upstream health, server logs, local socket availability | Correct the connection; do not expose the token |
+| Invalid filter | Inline error and API response | Correct the expression; invalid requests must not retry endlessly |
+| Profile cannot save | Directory permissions, disk capacity, `Retry` notification | Restore write access and retry; pending browser changes must survive reload |
+| Browser test fails before starting | Occupied fixture ports or missing browsers | Resolve the owner/install browsers, then rerun one suite |
+| Popup is clipped | Viewport size, fixed positioning, scroll container, focus events | Reproduce with the boundary/keyboard QA matrix |
+
+Never dump `.zshrc`, all environment variables, `.labtasker/`, cookies or request
+headers into logs. Inspect only the specific configuration needed and redact credentials.
+
+## Dependency changes
+
+Commit npm manifest and lockfile together; use `npm ci` elsewhere. Use `uv lock` to
+regenerate the Python lockfile and `uv sync --group dev --frozen` for ordinary installs.
+Do not edit lockfile records manually. CI uses the same lock across its Python matrix.
+Keep Actions pinned to commit SHAs and let Dependabot propose uv/npm/Action updates.
+Review migration notes and rerun affected checks.
+
+## Ordinary validation gate
+
+Run from the repository root. The project is a single distribution, so unlike the
+Labtasker workspace it does not need `--all-packages`.
+
+```sh
+uv sync --group dev --frozen
+uv run python scripts/check_versions.py
+uv run ruff format --check src tests scripts
+uv run ruff check src tests scripts
+uv run mypy
+uv run pytest -m 'not integration'
+npm --prefix frontend test
+npm --prefix frontend run build
+npm --prefix frontend run test:e2e
+uv run python scripts/check_package.py
+```
+
+The last command runs `uv build --sdist`, builds its wheel from that archive, validates
+metadata and smoke-tests a clean installation. It does not publish. For routine docs-only
+changes, validate local links and applicable examples rather than rerunning unrelated
+runtime tests. The local pre-commit hooks check whitespace/YAML/large files and run Ruff,
+matching the Labtasker series. CI remains the authoritative full gate.
+
+## Agent workflows
+
+Start with root `AGENTS.md`. Focused instructions live in `.agents/skills/ui-change/`
+and `.agents/skills/release/`; use them only for relevant work. Keep lasting product
+decisions in `docs/reference/specification.md`, not in throwaway plans.

labtasker_webui-0.1.1/.agents/sops/qa.md

@@ -0,0 +1,75 @@
+# QA SOP
+
+## Data and environment
+
+Browser tests use `tests/fixture_server.py` and an isolated `--no-profile` WebUI.
+They must not inherit real endpoint/token configuration or mutate real workloads.
+For live manual testing, use read-only access by default. Explicitly authorized dummy
+Task changes are limited to `default`, using recognizable names/routes and exact IDs.
+Never mutate any `lingbot` queue. Do not delete a whole queue to clean up test data.
+
+## Commands
+
+```sh
+uv run pytest -m 'not integration'
+npm --prefix frontend test
+npm --prefix frontend run build
+npm --prefix frontend run test:e2e
+```
+
+Always rebuild the served assets before running browser tests. Do not rebuild while
+backend or browser tests are running: Vite replaces the assets used by the editable
+Python installation. For a focused run:
+
+```sh
+npm --prefix frontend run build
+npm --prefix frontend run test:e2e -- --grep 'audit:' --project webkit
+```
+
+The standard suite covers Chromium, Firefox and WebKit. Keep fixtures and suites serial;
+opening parallel Playwright runs can corrupt both data and diagnostic artifacts.
+A read-only real-server contract test is opt-in:
+
+```sh
+LABTASKER_REAL_SERVER_URL=http://127.0.0.1:8000 uv run pytest -m integration tests/test_real_server.py
+```
+
+Set `LABTASKER_REAL_SERVER_TOKEN` through an existing secure mechanism if needed; never
+paste it into committed scripts or captured shell output.
+
+## Interaction review matrix
+
+| Area | Cases to verify |
+| --- | --- |
+| Layout | 1440×900 desktop, 900×600 short window, 390×700 narrow window; no document-level horizontal overflow |
+| Popups | Every edge; resize while open; many options; long names; internal scrolling; Escape, outside click and Tab |
+| Keyboard | Arrow keys/Home/End follow visible active option; Enter applies; IME Enter does not submit prematurely |
+| Filters | Dropdowns/presets immediate; text blur/Enter; clear; invalid input and correction; counts match applied selectors |
+| Navigation | Queue → filter → drawer → back/forward; URL and visible state agree |
+| Selection | Empty/partial/all checkbox; sorting retains selection; filtering clears selection; append keeps existing selection |
+| Columns | Independent resize; double-click fit; drag order; missing JSON paths blank; path casing preserved; reload restoration |
+| Views | Create/save/rename/copy/reset/delete; no Task deletion on view deletion; queue and connection isolation |
+| Lists | Empty, one row, many rows; long names/routes; mixed statuses; signed priorities; virtualized scroll and retry |
+| Drawer | Switch directly between rows, including during a pending or failed action; no cross-Task errors or disabled controls; close/focus restoration; keyboard access; narrow-screen sizing |
+| Persistence | Restart/reload; failed save/retry; unsaved browser changes survive profile reload; large UTF-8 payloads; stalled saves time out; credentials never in UI responses |
+| Batch deletion | Slow submission cannot duplicate; status-read failure can retry or close; failed stop stays visible; capacity never evicts active operations |
+| Failures | Upstream timeout, invalid filter, authorization loss and slow reconnection without stale cached Tasks, failed append; useful recovery without false success |
+
+For each reported defect, record trigger, expected behavior, actual behavior, and a
+regression test. Do not replace a failing assertion with a wait unless there is an
+observable asynchronous condition to wait for. Update stale selectors when the product
+has intentionally changed, preserving the original behavior being tested.
+
+## Evidence and completion
+
+Failed browser tests retain traces/screenshots in `frontend/test-results/`; CI uploads
+these as artifacts. Open a fixture trace from `frontend/` with:
+
+```sh
+npx playwright show-trace test-results/PATH/trace.zip
+```
+
+Never upload traces from authenticated real workloads without reviewing/redacting them.
+A passing test suite only covers the listed scenarios. Report skipped integration tests,
+untested platforms, and unresolved issues explicitly; do not claim the entire product
+is defect-free. Distinguish a local verification from an actual GitHub Actions run.

labtasker_webui-0.1.1/.agents/sops/releasing.md

@@ -0,0 +1,62 @@
+# Release SOP
+
+## Preconditions
+
+A maintainer must configure the `pypi` GitHub environment and the package's PyPI
+Trusted Publisher for workflow `release.yml`. Use environment protection and branch
+protection appropriate to the repository. The workflow's `required` job is the stable
+branch-protection check; repository settings must enable it separately.
+
+Do not publish merely to test packaging. Local verification does not require GitHub or
+PyPI credentials and does not push commits, create tags, or upload distributions.
+
+## Prepare
+
+1. Update `pyproject.toml`, `src/labtasker_webui/__init__.py`,
+   `frontend/package.json`, and `frontend/package-lock.json` together. Regenerate
+   `uv.lock` for the changed project version. Use a new, unpublished version.
+2. Update user-facing docs and write release notes explaining changes and migrations.
+3. Run the ordinary gate in [development.md](development.md) from the repository root. This performs static/unit checks,
+   a fresh frontend build, three-browser regressions, and package verification.
+4. Review the diff and `git status`. Exclude `.labtasker/`, credentials, traces,
+   node_modules, caches and local build output. Do not discard unrelated work.
+5. Review and merge through the repository's normal process. Publishing requires
+   explicit maintainer authorization.
+
+`uv run python scripts/check_package.py` builds into a fresh temporary directory to avoid mixing stale versions.
+`uv build --sdist` creates the source archive; a second `uv build` builds its wheel.
+The smoke test installs that wheel into a clean environment and runs it with no Node.js
+on PATH, checks frontend assets and a synthetic upstream connection. Temporary local
+verification artifacts are removed afterwards.
+
+## Publish
+
+Create the matching `vVERSION` tag and publish its GitHub Release after approval.
+The release workflow verifies all version declarations and tag equality, calls full CI,
+and publishes only the resulting `python-dist` artifact after CI succeeds. The publishing
+job uses OIDC in the `pypi` environment; no long-lived PyPI API token is needed.
+
+Do not replace the tested artifact with a local rebuild during the publishing step.
+Manually running CI builds downloadable artifacts but does not publish.
+
+## Failure and recovery
+
+- Validation failure: fix the defect and rerun checks; do not bypass failing jobs.
+- OIDC/environment failure: check the owner/repository/workflow/environment publisher
+  configuration. Do not solve it by committing an API token.
+- Partial publish: inspect PyPI before retrying. Published files/versions are immutable;
+  do not delete/recreate a tag to disguise a different artifact as the same release.
+- Product regression after release: issue a corrected version. A maintainer may yank a
+  broken version with an explanation. Users can temporarily pin the last known good
+  version; do not overwrite their `.labtasker/` profile/token during rollback.
+
+After publication, verify installation of the released version and record the actual
+workflow/release URLs. Never claim publication solely because local packaging passed.
+
+## Release-note style
+
+Follow the Labtasker series: title the release `vVERSION`; use short `Add`, `Change`
+and `Fix` bullets ending with periods, ordered by user impact. Describe user-visible
+outcomes, not every internal test/refactor. Put an important compatibility notice first
+only when users must act. Include a comparison link after the first published release.
+Do not create a version-only changelog when no maintained changelog exists.

labtasker_webui-0.1.1/.gitignore

@@ -0,0 +1,27 @@
+.venv/
+.pytest_cache/
+.tmp/
+dist/
+frontend/node_modules/
+frontend/dist/
+frontend/*.tsbuildinfo
+frontend/vite.config.js
+frontend/vite.config.d.ts
+frontend/playwright-report/
+frontend/test-results/
+**/__pycache__/
+*.pyc
+.gstack/
+
+# Local agent artifacts and development caches
+.superpowers/
+docs/superpowers/
+.gstack/
+.mypy_cache/
+.ruff_cache/
+.DS_Store
+
+**/.labtasker/webui-profile.json
+**/.labtasker/.webui-profile-*
+
+**/.labtasker/webui-token

labtasker_webui-0.1.1/AGENTS.md

@@ -0,0 +1,57 @@
+# Labtasker WebUI agent guide
+
+## Project context and boundaries
+
+- Read this file and [CONTRIBUTING.md](CONTRIBUTING.md) before changing the project.
+- Keep source comments, UI copy, documentation, and project metadata in English. There is no i18n layer yet. Preserve user-provided data and JSON-path casing.
+- This is a WebUI/BFF for an existing Labtasker v2 instance. Do not add Task submission/editing, a scheduler, database access, or automatic Labtasker lifecycle management without a product request.
+- Local mode attaches to an already-running project's Unix socket. It must not start, stop, restart, or open the database of that instance.
+- Never modify `lingbot` queues or other real workloads during testing. Use the isolated fixture by default. Live dummy mutations require explicit authorization and must stay within `default` and clearly identified test Task IDs.
+- Never print tokens, source a user's whole shell configuration, commit profiles, or upload authenticated browser traces. Credentials belong only on the backend and in `.labtasker/webui-token` with mode `0600`.
+- Preserve existing uncommitted work. Do not reset/stash it, restart unrelated processes, or publish releases merely to complete a check.
+
+## Sources of truth
+
+- `docs/reference/specification.md` records the maintained WebUI contract and state ownership. Follow the Labtasker v2 specification for upstream Task, Queue, Client and Server semantics.
+- `README.md` and `docs/` explain the product. Update them when observable behavior changes.
+- Keep internal development, QA and release SOPs in `.agents/sops/`, with focused agent workflows in `.agents/skills/`. Do not put internal operating procedures in product documentation.
+- Tests are executable invariants, not a substitute for the contract. Change implementation, tests and affected guidance together.
+- Follow the Labtasker series' terminology, uv/Ruff workflow and small product boundary. Do not recreate parallel planning/comparison documents or import unrelated Server/Worker responsibilities.
+
+## Working agreements
+
+- Use `uv sync --group dev --frozen` and `uv run` from the repository root for Python. Use the existing npm lockfile for the frontend; do not introduce another package manager or environment.
+- Keep public concepts capitalized as Task, Queue, Worker, Client and Server. Keep generated assets, lockfile records and local `.labtasker/` data owned by their tools.
+- Use `.agents/skills/ui-change` for interface regressions and `.agents/skills/release` for release readiness/publication. These are focused WebUI adaptations of the Labtasker repository workflows.
+- Do not commit, tag, push, create a release or publish unless the user explicitly authorizes that action.
+
+## Project map
+
+- `frontend/src/`: React UI; `App.tsx` contains the queue workspace and Task drawer.
+- `frontend/src/useAnchoredPanel.ts`: viewport-aware dropdown/help positioning.
+- `frontend/src/queueLayout.ts`, `Views.tsx`, `profile.ts`: layout, named views, persistence.
+- `src/labtasker_webui/`: FastAPI BFF, upstream transport, sessions, local attachment, profile persistence.
+- `tests/fixture_server.py`: synthetic upstream for browser/package tests.
+- `frontend/e2e/`: Playwright interaction regressions; `tests/`: backend contracts.
+- `.github/workflows/`: CI and gated PyPI publishing.
+
+## Interaction contracts
+
+- Preserve breadcrumbs and the compact, information-dense layout. Do not reintroduce a duplicate queue heading or large decorative spacing.
+- Queue layout and named views are scoped by connection identity **and** queue. Never reintroduce a global columns fallback.
+- Dropdowns and presets apply immediately. Text filters apply on Enter or leaving the input group; Apply is a fallback. Respect IME composition.
+- Counts describe the same applied selectors as the list. Sorting preserves selection; changing the filter range clears it.
+- Browser history restores queue, applied filters and drawer consistently. Partial selection uses the native checkbox `indeterminate` property.
+- Resizing changes only the chosen column. Double-click fits content. Reordering preserves paths and uses a drop line, not a shaded target row.
+- Every popup must fit the viewport, support scrolling and Escape/outside dismissal, and remain usable with keyboard navigation. Check Safari/WebKit focus behavior, not only Chromium.
+- Missing custom JSON-path values stay blank. Negative priorities remain valid; positive/negative arrows use red/blue.
+- Saved-view switching does not interrupt the user with an unsaved-changes prompt. Saving a view is explicit; normal profile saves stay quiet, failures offer recovery.
+
+## Validation and delivery
+
+- Run the ordinary gate in `.agents/sops/development.md`: frozen uv sync, version checks, Ruff format/lint, mypy, pytest, frontend tests/build, three-browser tests and artifact smoke verification. Run browser suites serially: fixtures and artifacts are shared.
+- For UI behavior fixes, reproduce the failure, add or update a behavior-level regression, and test the actual built UI. Do not use sleeps or weaken assertions to hide a failure.
+- Prefer existing components and tests over new dependencies. Do not mass-format unrelated files.
+- Complete that gate before release preparation or broad infrastructure changes. `uv run python scripts/check_package.py` verifies an sdist-built wheel in a clean environment without Node.js.
+- Follow [development](.agents/sops/development.md), [QA](.agents/sops/qa.md), and [release](.agents/sops/releasing.md) SOPs. Update affected docs when behavior changes.
+- Report actual checks, failures/skips, and remaining limits. A local green run does not prove that GitHub Actions ran or that a package was published.

labtasker_webui-0.1.1/CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing
+
+Read [AGENTS.md](AGENTS.md) for product boundaries and working agreements.
+This repository follows the Labtasker series: uv-managed Python environments,
+a frozen lockfile, Ruff formatting/linting, strict typing and explicit capability
+boundaries. npm and Playwright cover the WebUI-specific frontend.
+
+Use Python 3.11+ and Node.js 22 (`.nvmrc`). From the repository root:
+
+```sh
+npm ci --prefix frontend
+npm --prefix frontend run build
+uv sync --group dev --frozen
+uv run pre-commit install
+```
+
+Building the frontend first makes assets available to the editable Python package.
+Install browsers once, from `frontend/`, with
+`npx playwright install chromium firefox webkit`.
+
+- [Development and ordinary validation gate](.agents/sops/development.md)
+- [UI and integration QA](.agents/sops/qa.md)
+- [Release and rollback](.agents/sops/releasing.md)
+- [WebUI specification and state ownership](docs/reference/specification.md)
+
+## Pull requests
+
+Explain the concrete problem, resulting behavior and actual validation. Include
+behavioral regressions and screenshots for layout changes. Keep unrelated formatting
+out of the diff. Do not attach private profiles, tokens or authenticated traces.
+
+Use `uv lock` after Python dependency changes and commit the generated lockfile.
+Commit npm manifest/lockfile changes together; use `npm ci` for ordinary installs.
+CI and local development use the same frozen uv resolution.
+
+Before merge or release preparation, run the ordinary gate in `.agents/sops/development.md`.
+Configure the `required` CI job as a required branch-protection check in repository
+settings; workflow files alone do not enable branch protection.

labtasker_webui-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.