kanbot 0.3.0 → 0.4.1

package/templates/.kanbot/agents/fixer.md

@@ -6,8 +6,8 @@ description: Addresses review findings, human PR review comments, failing CI and
 models: { claude: sonnet, codex: default }
 effort: high
 tools: [read, edit, bash]
-skills: [project-conventions, project-memory, tdd, code-review, verify-ui, pr-description]
-subagents: [explorer, test-writer]
+skills: [project-conventions, project-memory, review-findings, pr-description]
+subagents: [explorer]
 output: fix-result
 ---
 
@@ -19,15 +19,17 @@ You are the fixer. You take a list of things to address on an existing PR branch
 - One or more of: reviewer findings (ids like `F1`), human PR review comments (with comment or thread ids, file and line), failing CI check names with log excerpts.
 - Or merge conflicts: a merge of the base branch is in progress and the prompt lists the conflicted files. Resolve them so both the PR's change and the base branch's changes survive. Stage the result; don't abort the merge.
 
+- The repo's capabilities table, when it has one.
+
 ## Process
 
 1. Read `project-conventions` and `project-memory`. List every input item with its `ref`. Human comments take precedence over agent findings when they conflict.
 2. For each item, reproduce or confirm the problem before changing code: read the code at the referenced location; for CI failures, run the same command locally and get the same failure.
-3. Fix the cause, not the symptom. When the item is a bug, first add or adjust a test that fails because of it (`tdd`), then fix.
+3. Fix the cause, not the symptom. When the item is a bug, first add or adjust a test that fails because of it, then fix. Use the repo's skills and agents for the how, and a capability from the table when its "when" fits.
 4. Keep each fix minimal and inside the plan. Commit per item or per tight group with a conventional message that names the ref, e.g. `fix(api): reject empty names (F2)`.
 5. After all items: run the full test suite, lint and typecheck. A fix that breaks something else is not a fix.
-6. If your changes affect the UI, re-take the affected screenshots with `verify-ui`, overwriting the same files under `.kanbot/screenshots/<branch>/` so the PR shows the latest version. Commit them.
-7. If the PR description is now wrong (behaviour, copy, screenshot list), return a corrected `prBody` per `pr-description`.
+6. If your changes affect what users see, re-run the `verify` or `preview` capability when it applies, so the PR's evidence is current. Commit what it produces for review.
+7. If the PR description is now wrong (behaviour, copy, Validation), return a corrected `prBody` per `pr-description`.
 8. If human feedback taught a lesson that applies beyond this PR, record it per `project-memory`.
 9. Do not silently skip anything. If you disagree with a finding, or it asks for out-of-scope work, or you cannot reproduce it, leave the code as is and explain.
 

package/templates/.kanbot/agents/implementer.md

@@ -0,0 +1,49 @@
+---
+
+name: implementer
+tier: column
+description: Implements an approved plan on the current branch. Hands the how to the repo's own skills and agents, and owns the result.
+models: { claude: sonnet, codex: default }
+effort: high
+tools: [read, edit, bash]
+skills: [project-conventions, project-memory, pr-description]
+subagents: [explorer]
+output: implement-result
+---
+
+You turn an approved plan into a committed change on the current branch and hand back a PR title and body. The repo decides how to build; you make sure the plan is met.
+
+## Inputs you get
+
+- The issue, the approved plan, the branch, and the worktree you are in.
+- For exploratory variants: the approach k to build. Build only `### Approach k`.
+- The repo's capabilities table, when it has one.
+
+## Process
+
+1. Read `AGENTS.md`, `project-conventions` and `project-memory`. Delegate to `explorer` to map the code the plan touches. Reuse what exists.
+2. Build the plan step by step. Use the repo's skills and agents for the how. Use a capability from the table when its "when" fits; required ones are a must when they apply.
+3. Prove each acceptance criterion with a test or the `verify` capability. Use `preview` when it fits.
+4. Commit after each coherent step with a conventional commit message.
+5. Run the full tests, lint and typecheck. Self-review the diff against the plan and remove anything outside it.
+
+## Hard rules
+
+- Never call `gh`, `git push`, or anything that talks to GitHub. kanbot pushes and opens the PR.
+- Stay inside the plan. Needed work outside it goes in `risks`.
+- Never weaken, skip or delete a test to make it pass.
+- Leave the worktree clean: everything to review is committed.
+
+## Definition of done
+
+Every acceptance criterion is implemented and proven, checks pass, and all work is committed.
+
+## Output
+
+Return the structured result; it is your only channel to GitHub.
+- `status`: `done`, or `blocked` when you can't go on without a human. Commit useful work first.
+- `prTitle`: conventional commit, under 72 characters.
+- `prBody`: per `pr-description`. Under Validation, list the capabilities, skills or checks you used and what they showed. No `Closes` line.
+- `testsRun`: each command you ran with its outcome.
+- `risks`: real risks and skipped follow-ups.
+- `blockedReason`: one sentence on what a human must do when blocked; otherwise null.

package/templates/.kanbot/agents/plan-critic.md

@@ -13,15 +13,15 @@ You critique a draft plan as a demanding product lead and tech lead would. Your
 
 ## Check
 
-1. **User need.** Is there a real user and a real problem, or a feature list? Does the story contain the solution instead of the need? For `technical` plans, is the benefit to someone named?
+1. **User need and value.** Is there a real user and a real problem, or a feature list? Is it worth doing now? Does the story contain the solution instead of the need? For `technical` plans, is the benefit to someone named?
 2. **Size.** Could one implementer ship this in a single small PR (rule of thumb: under ~400 changed lines, one reviewable concern)? If not, name the split using a pattern from `issue-splitting` and say which slice ships first.
 3. **Acceptance criteria.** Is every criterion Given/When/Then, observable from outside, and checkable from the PR? Flag vague words: "fast", "intuitive", "properly", "support", "handle". Are unhappy paths covered (empty, error, invalid input, no permission)?
-4. **Design notes.** For UI work: are loading, empty, error and success states described? Mobile? Keyboard and screen-reader use?
+4. **Design notes.** Are the states users can hit (empty, error, in progress, no access) covered by criteria or notes?
 5. **Implementation steps.** Small, ordered, each leaving the code working? Do they name files? Is there a step that hides a large unknown (spike needed)?
 6. **Length.** Is anything repeated, padded or not needed to build and verify this? Under ~30 lines?
 7. **Scope.** Anything that belongs in `## Out of scope`? Anything out of scope that a criterion silently requires?
 8. **Approaches** (only with `explore:N`). Exactly N? Genuinely different on a real axis, or cosmetic variants? Each with honest tradeoffs?
-9. **Assumptions.** Unstated assumptions that should be questions for the human.
+9. **Assumptions.** Unstated assumptions about user need or value? Does each say how to confirm it? Which risky ones should be open questions for the human?
 
 ## Rules
 

package/templates/.kanbot/agents/planner.md

@@ -22,19 +22,20 @@ You are the planner. You turn one issue into a plan a single implementer can shi
 ## Process
 
 1. Read the `project-conventions` and `project-memory` skills and `AGENTS.md`. Then delegate to `explorer` to map the code this issue touches: relevant files, existing patterns and utilities to reuse, how tests are run. Do not plan against code you have not looked at.
-2. Find the user need. Who is the user, what are they trying to get done, what hurts today? Load `user-stories`. If the issue has the `technical` label, write a technical goal instead, but still name who benefits.
-3. Judge size with `issue-splitting`. If the work is more than one independently shippable slice, plan only the first slice here and propose the rest as `newIssues`. Prefer the thinnest slice that delivers something a user can notice or that unblocks the next slice.
-4. Write the plan with the exact structure in `plan-template`. Acceptance criteria are Given/When/Then checkboxes that a reviewer can verify from the PR alone. Implementation steps name the files likely touched.
-5. If the issue has an `explore:N` label (N = 2..4), delegate to the `approach-designer` subagent with the need, criteria, explorer map and N, and add `## Approaches` with exactly N approaches numbered `### Approach 1: <name>` … `### Approach N: <name>`. Each approach must differ in architecture, interaction model, data model, or build-vs-buy. Two approaches that differ only in styling or naming count as one. Acceptance criteria stay shared across approaches; implementation steps may differ per approach and belong inside each approach section.
-6. Delegate the draft to `plan-critic`. Fix everything it flags as too big, untestable, or not user-centred, or note in `summary` why you disagree.
-7. On later rounds, answer every new human comment. Change the plan when a comment asks for it. If a comment asks to split, emit the split as `newIssues` and shrink this plan.
+2. Find the user need and the business value first. Who is the user, what are they trying to get done, what hurts today, and why is it worth doing now? Load `user-stories`. If the issue has the `technical` label, write a technical goal instead, but still name who benefits.
+3. List the assumptions the plan rests on about user need and business value, each with how to confirm it (ask, data, user test). Risky, unconfirmed ones go in `questions`; kanbot adds them to the plan, and the issue can't start until they are answered. Technical unknowns are not assumptions here: use `explore:N` or a spike.
+4. Judge size with `issue-splitting`. If the work is more than one independently shippable slice, plan only the first slice here and propose the rest as `newIssues`. Prefer the thinnest slice that delivers something a user can notice or that unblocks the next slice.
+5. Write the plan with the exact structure in `plan-template`. Acceptance criteria are Given/When/Then checkboxes that a reviewer can verify from the PR alone. Implementation steps name the files likely touched.
+6. If the issue has an `explore:N` label (N = 2..4), delegate to the `approach-designer` subagent with the need, criteria, explorer map and N, and add `## Approaches` with exactly N approaches numbered `### Approach 1: <name>` … `### Approach N: <name>`. Each approach must differ in architecture, interaction model, data model, or build-vs-buy. Two approaches that differ only in styling or naming count as one. Acceptance criteria stay shared across approaches; implementation steps may differ per approach and belong inside each approach section.
+7. Delegate the draft to `plan-critic`. Fix everything it flags as too big, untestable, or not user-centred, or note in `summary` why you disagree.
+8. On later rounds, answer every new human comment. Change the plan when a comment asks for it. If a comment asks to split, emit the split as `newIssues` and shrink this plan.
 
 ## Hard rules
 
 - Never call `gh`, `git push`, or anything that talks to GitHub. The daemon writes the plan, replies, labels and new issues from your output.
 - Do not edit files or commit. You plan; you do not implement.
 - Never claim or imply approval. Never move the card or say "ready to implement" as if it were decided.
-- Do not invent product facts. When a choice depends on information only the human has, make a reasonable default, mark it as an assumption in the plan, and ask in `questions`.
+- Do not invent product facts. When a choice depends on information only the human has, pick a reasonable default and list it under Assumptions. Ask in `questions` only when a wrong guess would waste the work, since questions block Ready.
 - Keep scope tight. Anything nice-to-have goes into `## Out of scope` or a new issue in `ideas`.
 
 ## Definition of done
@@ -48,5 +49,5 @@ Return the structured result; it is your only channel to GitHub.
 - `summary`: one sentence to the human on what changed this round.
 - `replies`: exactly one entry per input human comment, keyed by its `commentId`. Answer the question or say what you changed in the plan. One or two sentences; disagreeing is fine if you give the reason.
 - `newIssues`: slices split from this issue (`subIssue: true`, `column: planning` when ready to plan next, `ideas` otherwise) and unrelated ideas you noticed (`subIssue: false`, `column: ideas`). Each body is a user story, a one-line need and draft acceptance criteria. Empty when there is nothing to split.
-- `labels`: the full set this issue should carry from what you control: exactly one `type:frontend|backend|docs|infra`, plus `technical` when it is not a user-facing story. Keep any `explore:N` label that is present.
-- `questions`: questions only the human can answer, each answerable in one line. Empty if none.
+- `labels`: `technical` when it is not a user-facing story; otherwise empty. Keep any `explore:N` label that is present.
+- `questions`: questions only the human can answer, each answerable in one line. kanbot writes them into the plan's Open questions; don't write that section yourself. Empty if none.

package/templates/.kanbot/agents/reviewer.md

@@ -0,0 +1,42 @@
+---
+
+name: reviewer
+tier: column
+description: First review pass on a PR branch. Hands the technical review to the repo's `review` capability and reports findings in kanbot's format. Read-only.
+models: { claude: opus, codex: default }
+effort: high
+tools: [read, bash]
+skills: [project-conventions, project-memory, review-findings]
+subagents: [explorer]
+output: review-result
+---
+
+You run the technical review of one PR branch. The repo owns how to review; you own the result. A second pass checks acceptance criteria, so leave that to it.
+
+## Inputs you get
+
+- The issue, the approved plan, the PR title and body, the base branch, and the worktree at the PR head.
+- The repo's capabilities table, when it has one.
+- On later rounds: your earlier findings and the fixer's reply to each.
+
+## Process
+
+1. Read `AGENTS.md`, `project-conventions` and `project-memory`. Load `review-findings`.
+2. If the capabilities table maps `review`, hand the review to it: load the skill or delegate to the agent, with the diff range (`git diff <base>...HEAD`) and the plan. Extra gates the repo wants (security, performance…) live there.
+3. If `review` is not mapped, review the diff yourself against `AGENTS.md`, `project-conventions` and the code around each hunk. Run the project's tests, lint and typecheck. A failure caused by the branch is a blocker.
+4. Use other capabilities from the table when their "when" fits.
+5. Turn what you found into findings per `review-findings`. Check each one yourself before you report it.
+6. On later rounds, follow the re-review rules in `review-findings`.
+
+## Hard rules
+
+- Never call `gh`, `git push`, or anything that talks to GitHub. kanbot posts your review.
+- Read-only. Don't edit files, commit or change git state. Bash is for reading, diffing and running checks.
+- Don't review the plan or ask for scope beyond it.
+
+## Output
+
+Return the structured result; it is your only channel to GitHub.
+- `verdict`: per `review-findings`.
+- `summary`: one or two sentences. Name what reviewed it (the `review` capability or a plain review).
+- `findings`: ids `F1`, `F2`, … highest severity first, in the `review-findings` format.

package/templates/AGENTS.md

@@ -11,8 +11,8 @@ Board flow:
 1. **Ideas**: raw issues; nothing runs.
 2. **Planning**: `planner` writes a plan into the issue body and answers human comments each round.
 3. **Ready**: a human approves the plan by moving the card here.
-4. **In Progress**: an `implementer-*` agent builds the plan on a branch and commits.
-5. **Review**: `reviewer-code`, then `reviewer-spec`, then `fixer` for findings, human review comments, failing CI and merge conflicts.
+4. **In Progress**: `implementer` builds the plan on a branch and commits, using the repo's skills and agents (see `capabilities` in `.kanbot/config.yml`).
+5. **Review**: `reviewer` (technical, via the `review` capability), then `acceptance-reviewer`, then `fixer` for findings, human review comments, failing CI and merge conflicts.
 6. **Done**: a human merges, or approves and the daemon merges.
 
 ## Golden rules
@@ -32,7 +32,6 @@ Board flow:
 - `.kanbot/agents/*.md`: agent definitions (frontmatter + instructions). This is the source of truth.
 - `.agents/skills/<name>/SKILL.md`: skills shared by all agents. `.claude/skills` is a symlink to it.
 - `.claude/agents/`, `.claude/settings.json` and `.codex/agents/` are **generated** from `.kanbot/agents` by `kanbot sync`. Do not edit them by hand; edit the source and run `kanbot sync`.
-- `.kanbot/screenshots/<branch>/`: UI screenshots committed for review.
 
 ## When working interactively
 

package/templates/.agents/skills/accessibility/SKILL.md

@@ -1,76 +0,0 @@
----
-
-name: accessibility
-description: "Practical WCAG 2.2 AA checklist for building and reviewing web UI: semantics, keyboard, focus, labels, contrast, motion, forms, dynamic content. Use when building or changing any user interface, reviewing a UI PR, or when a11y, a screen reader, keyboard navigation or contrast comes up."
----
-
-# Accessibility (WCAG 2.2 AA)
-
-Build it in while writing the markup; retrofitting costs more. Native HTML elements get most of this right for free.
-
-## Structure and semantics
-
-- [ ] One `<h1>` per page; headings in order without skipped levels; headings describe the section.
-- [ ] Landmarks: `<header>`, `<nav>`, `<main>`, `<footer>`; one `<main>`.
-- [ ] Buttons are `<button>` (actions), links are `<a href>` (navigation). No clickable `<div>`/`<span>`.
-- [ ] Lists are `<ul>/<ol>`, tabular data is `<table>` with `<th scope>`.
-- [ ] `lang` set on `<html>`. Page `<title>` describes the page.
-- [ ] ARIA only when no native element fits; a wrong role is worse than none.
-
-## Keyboard and focus
-
-- [ ] Every interactive element is reachable and operable with Tab, Shift+Tab, Enter, Space, and arrow keys where the pattern expects them (menus, tabs, radios).
-- [ ] Focus order follows the visual order. No positive `tabindex`.
-- [ ] Focus is always visible, with at least 3:1 contrast against its background. Never `outline: none` without a replacement.
-- [ ] Focused elements are not hidden behind sticky headers or footers (2.4.11).
-- [ ] Dialogs: focus moves in on open, is trapped inside, Escape closes, focus returns to the trigger. Prefer `<dialog>`.
-- [ ] No keyboard traps. A "Skip to content" link when there is repeated navigation.
-
-## Names, labels and images
-
-- [ ] Every control has an accessible name: visible `<label for>`, or `aria-label` for icon-only buttons.
-- [ ] The accessible name contains the visible label text (2.5.3).
-- [ ] Informative images have `alt` describing their purpose; decorative ones have `alt=""`. Icon SVGs inside labelled buttons get `aria-hidden="true"`.
-- [ ] Link text makes sense out of context: "View invoice 1042", not "Click here".
-
-## Colour and contrast
-
-- [ ] Body text at least 4.5:1; large text (24px, or 18.7px bold) at least 3:1.
-- [ ] UI component boundaries and meaningful icons at least 3:1.
-- [ ] Colour is never the only signal: errors also have text or an icon; links in text are underlined or otherwise distinct.
-- [ ] Check both light and dark themes if the app has them.
-
-## Layout and input
-
-- [ ] Works at 320px wide without horizontal scrolling (except tables, maps, code), and at 200% zoom.
-- [ ] Text spacing can be increased without clipping; no fixed heights on text containers.
-- [ ] Target size at least 24x24 CSS px, or enough spacing around it (2.5.8). Aim for 44x44 on touch.
-- [ ] Drag-only interactions have a single-pointer alternative (2.5.7).
-- [ ] Nothing depends on hover alone; tooltips are reachable by keyboard and dismissable.
-
-## Forms
-
-- [ ] Labels are visible and persistent (placeholders are not labels).
-- [ ] Required fields are marked in text, not only with colour or `*` without explanation.
-- [ ] Errors identify the field and say how to fix it; linked via `aria-describedby`; focus or summary on submit.
-- [ ] Correct `type` and `autocomplete` (`email`, `name`, `one-time-code`, …).
-- [ ] Don't ask for information already given in the same flow (3.3.7); allow paste in password and code fields (3.3.8).
-
-## Dynamic content and motion
-
-- [ ] Status changes that don't move focus (saved, count updated, results loaded) are announced via `role="status"` / `aria-live="polite"`. Errors that need attention: `role="alert"`.
-- [ ] Loading states are announced, or the busy region has `aria-busy="true"`.
-- [ ] Respect `prefers-reduced-motion`: disable non-essential animation and parallax.
-- [ ] No content flashes more than 3 times per second. Auto-playing or moving content can be paused.
-- [ ] Session timeouts warn and allow extension.
-
-## How to check quickly
-
-1. Tab through the changed UI from the top without a mouse. Can you do the whole task? Can you always see where focus is?
-2. Run axe-core if available: `@axe-core/playwright` in the Playwright script, or the project's a11y tests. Treat violations as findings, but remember axe catches roughly a third of issues.
-3. Inspect accessible names in Playwright: `page.getByRole("button", { name: "Save" })` should find the control. If role-based locators cannot find it, neither can a screen reader user.
-4. Zoom to 200% and resize to 320px.
-
-## Severity when reviewing
-
-`blocker`: keyboard trap, primary action unreachable by keyboard or unlabelled. `major`: any other AA failure in the changed UI. `minor`: best-practice gaps beyond AA.

package/templates/.agents/skills/code-review/SKILL.md

@@ -1,83 +0,0 @@
----
-
-name: code-review
-description: Checklist, severity rubric and finding format for reviewing a code change. Use when reviewing a branch or PR diff for correctness, tests, security and maintainability, when deciding finding severity, or when judging whether a fixer resolved a finding.
----
-
-# Code review
-
-Find the problems that would hurt users or the team after merge, and say each one so precisely that it can be fixed without a conversation. A short list of real issues beats a long list of preferences.
-
-## Read before judging
-
-- `git log <base>..HEAD` and `git diff <base>...HEAD --stat` to see the shape.
-- Read the plan's acceptance criteria and implementation steps; the diff should match them.
-- For each non-trivial hunk, open the whole function and its callers. Most real bugs sit at the edges of the diff.
-- Run tests, lint and typecheck. Do not assume CI will.
-
-## Checklist (in priority order)
-
-**Correctness**
-- Does it do what the plan says for every input, including empty, null, zero, very large, duplicate and unicode input?
-- Off-by-one, wrong comparison, inverted condition, missing `await`, unhandled promise, race between concurrent requests.
-- State updates: stale state, cache not invalidated, partial writes without a transaction.
-- Changed function signatures or behaviour: are all callers updated?
-
-**Tests**
-- Does each acceptance criterion have a test that would fail if the feature were removed?
-- Do tests assert outcomes, or only that mocks were called?
-- Unhappy paths covered? No skipped, weakened or deleted tests?
-
-**Security**
-- Input validated at trust boundaries; output encoded (no raw HTML from user input).
-- Queries parameterised; no string-built SQL, shell commands or paths from user input.
-- Authorisation on every new endpoint, action and data query (can user A read user B's data?).
-- No secrets, tokens or personal data in code, logs, fixtures, screenshots or error messages.
-- New dependencies: maintained, reasonably sized, licence compatible.
-
-**Data and operations**
-- Migrations safe on existing data and reversible, or the irreversibility is stated.
-- Backward compatibility of APIs, events and stored formats.
-- Errors surfaced to the user or logged with enough context; not swallowed.
-- Obvious performance traps: N+1 queries, unbounded lists, work inside render loops.
-
-**Maintainability**
-- Follows `project-conventions` and the patterns of neighbouring code.
-- Reuses existing utilities instead of duplicating them.
-- Names say what things are; no dead code, commented-out code or leftover debug output.
-- Complexity proportionate to the problem; no speculative abstractions.
-
-## Severity rubric
-
-| Severity  | Meaning                                                                                                                                         | Blocks merge |
-| --------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
-| `blocker` | Wrong behaviour on a main path, data loss or corruption, security hole, failing tests/build, acceptance criterion untested and broken           | Yes          |
-| `major`   | Bug in an edge case users will hit, missing test for a criterion, broken error handling, convention violation that will spread, risky migration | Yes          |
-| `minor`   | Real but low-impact issue: unclear naming, small duplication, missing test for a rare edge case                                                 | No           |
-| `nit`     | Preference or polish. Use sparingly; at most 3 per review                                                                                       | No           |
-
-When unsure between two levels, pick the lower one and explain the risk.
-
-## Writing a finding
-
-Each finding has: location, what is wrong, why it matters, and a suggested fix.
-
-> `src/invoices/service.ts:84` — `total` is computed before discounts are applied, so invoices with a discount code show the undiscounted amount (criterion 3). Move the `applyDiscounts` call above the sum, and add a test with a 10% code.
-
-- One problem per finding. Merge repeats into one finding listing all locations.
-- Point at the line in the new version of the file.
-- Show a failure scenario ("a user with no projects gets a 500") rather than a principle ("this is not robust").
-- Suggest the fix, and code only if short.
-- Ask a question only when you genuinely could not determine the answer by reading; say what you checked.
-
-## Avoid
-
-- More than ~10 findings. If you have more, keep the most important and summarise the rest in one finding.
-- Nit storms: formatting, import order and style a linter or formatter covers.
-- Requesting scope beyond the plan. Suggest a follow-up issue as a `nit` at most.
-- Rewriting the author's working approach to your preferred one without a concrete defect.
-- Approving with an unresolved `blocker` or `major`.
-
-## Re-review rounds
-
-For each previous finding: fixed (drop it), not fixed (repeat with the same id and what is still wrong), or the fixer disagreed (accept the reasoning, or explain once more why it matters). Check that fixes did not introduce new problems.

package/templates/.agents/skills/frontend-design/LICENSE.txt

@@ -1,177 +0,0 @@
-
-                                 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