@starlove/orbit 1.4.1 → 2.0.0

package/docs/ORBIT_DISPATCH.md

@@ -1,280 +0,0 @@
-# Orbit Dispatch
-
-`orbit dispatch` is the Orbit-to-Hermes handoff command. It turns an Orbit ticket into a bounded agent run without relying on a temporary prompt file as the source of truth.
-
-The design intent is simple:
-
-- Git remains canonical for code.
-- Orbit remains canonical for planning, handoff, run records, and implementation notes.
-- The ticket becomes the shared communication surface between the human, orchestrator, and dispatched agent.
-
-## Local and remote board contract
-
-Local dispatch resolves boards through the local Orbit registry and mutates the local SQLite board file.
-
-Remote dispatch targets a hosted Orbit server through the HTTP API. It accepts either a full hosted ticket URL or an explicit server/board/ticket tuple:
-
-```bash
-# Full hosted Orbit ticket URL. The board slug and ticket id are parsed from the hash route.
-orbit dispatch 'http://orbit.example/#/b/my-app/t/<ticket-id>' --profile nova --worktree
-
-# Equivalent explicit form.
-orbit dispatch \
-  --server-url http://orbit.example \
-  --board my-app \
-  --ticket <ticket-id-or-number> \
-  --profile nova \
-  --worktree
-```
-
-Remote dispatch uses hosted Orbit API state for ticket reads, blockers, AI Plan/plan artifact updates, run-record comments, and lane moves. It still uses the local `--cwd` repo as the code/worktree root, because hosted board paths may belong to another machine.
-
-Safe preview forms work in remote mode too:
-
-```bash
-# Reads hosted board/ticket/blocker state, then exits with no writes.
-orbit dispatch 'http://orbit.example/#/b/my-app/t/<ticket-id>' --profile nova --dry-run
-
-# Writes handoff/run record/worktree and comments the hosted ticket, but does not spawn Hermes or move the card.
-orbit dispatch 'http://orbit.example/#/b/my-app/t/<ticket-id>' --profile nova --worktree --no-spawn
-```
-
-## Basic local use
-
-From the code repository you are working in, target the local Orbit board explicitly:
-
-```bash
-orbit dispatch \
-  --board my-app \
-  --ticket 12 \
-  --profile agent \
-  --worktree
-```
-
-Common variants:
-
-```bash
-# Preview only. No files, worktrees, ticket fields, comments, or agents change.
-orbit dispatch --board my-app --ticket 12 --dry-run
-
-# Prepare the handoff/comment/worktree, but do not spawn Hermes and do not move the card to In Progress.
-orbit dispatch --board my-app --ticket 12 --profile agent --worktree --no-spawn
-
-# Attach the Hermes child process to the current terminal instead of detaching it.
-orbit dispatch --board my-app --ticket 12 --profile agent --worktree --foreground
-
-# Use an explicit branch/worktree name.
-orbit dispatch --board my-app --ticket 12 --profile agent --worktree \
-  --branch orbit/my-app-12-search \
-  --worktree-path .worktrees/my-app-12-search
-
-# Declare ticket-specific verification expectations in the handoff/run record.
-orbit dispatch --board my-app --ticket 12 --profile agent --worktree \
-  --verify-command "node --test test/orbit-cli.test.mjs" \
-  --verify-command "git diff --check"
-```
-
-## Preflight order
-
-Before filesystem writes, worktree creation, ticket mutation, or agent spawn, dispatch now:
-
-1. Parses local vs remote target (`--server-url`, `--remote`, or hosted ticket URL select remote mode).
-2. Resolves the board from `--board`, hosted URL, or local repo context.
-3. Resolves the ticket from `--ticket` by number/id or from the hosted URL.
-4. Refuses archived/missing tickets.
-5. Refuses blocked tickets unless `--force` is passed.
-6. Rejects missing or flag-looking `--verify-command` values during CLI argument parsing.
-7. For spawn mode, checks that the Hermes binary exists and the requested profile is plausible.
-8. Handles `--dry-run` as a true no-write preview.
-
-Only after those checks does dispatch create run artifacts/worktrees, write the handoff/comment, move the ticket, or spawn Hermes.
-
-## What dispatch does
-
-In normal spawn mode:
-
-1. Builds a run id such as `orbit-12-agent-abc123def0`.
-2. Creates a run directory for run metadata and policy wrappers. Local board mode uses `<DATA_DIR>/dispatch-runs/<board>/<run-id>/`; remote mode uses `<repo>/.orbit/dispatch-runs/<run-id>/` so the handoff stays with the source checkout.
-3. Creates and preserves a git worktree/branch when `--worktree` is used. Remote mode defaults to `<repo-parent>/.worktrees/<repo-name>/<run-id>/`.
-4. Generates a full agent handoff.
-5. Writes an initial durable `run-record.json` with status `prepared` before ticket mutation or agent spawn.
-6. Writes the canonical handoff as a linked markdown artifact and stores a terse plan summary in AI Plan.
-7. Moves the ticket to **In Progress**.
-8. Starts Hermes.
-9. Updates `run-record.json` to status `launched` with the child process id.
-10. Comments a run record back onto the ticket.
-
-In `--no-spawn` mode, dispatch writes the handoff artifact, initial `run-record.json`, and compact run-record comment but leaves the ticket in its current lane.
-
-The run record includes profile, policy, ticket, branch, worktree, base commit, policy-bin path, child process id, command, declared verification commands, mode, transport (`local` or `remote`), and a `run-record.json` path. This makes the card the visible cockpit for the run while preserving a machine-readable artifact for later review/repair automation.
-
-## Structured run record
-
-Every non-dry-run dispatch writes `run-record.json` with schema `orbit.dispatch.run.v1`.
-
-The JSON record currently captures:
-
-- run id, board id/slug, ticket id/number, profile, policy, transport, mode, and status (`prepared` for `--no-spawn`, `launched` for spawned runs)
-- prompt/handoff path, repo root, worktree, branch, and base commit
-- process id when a Hermes child was spawned
-- declared verification commands
-- empty `commit_shas` and `residual_risks` arrays for completion/review tooling to fill in later slices
-- a small environment-variance snapshot: platform, Node version, cwd, path format, and relevant `HOME`, `PROJECT_ROOT`, `DATA_DIR`, and `ORBIT_*` env vars
-
-URL-bearing values are presence-only redacted in `run-record.json`. `ORBIT_API_URL`, `ORBIT_SERVER_URL`, and the top-level `server_url` field are recorded as `[redacted-url-present]` when present, rather than persisting usernames, passwords, query tokens, fragments, hostnames, or paths. Non-URL environment checklist values such as `HOME`, `PROJECT_ROOT`, `DATA_DIR`, `ORBIT_MODE`, and `ORBIT_DEFAULT_BOARD` remain visible for variance debugging.
-
-Operators can override the default verification contract by repeating `--verify-command <cmd>` or using `--verify-command=<cmd>`. Bare `--verify-command`, `--verify-command=` and `--verify-command` followed by another flag are rejected before dispatch side effects. If omitted, dispatch declares the standard local-safe checklist: `npm test`, conditional `npm run build`, `node src/cli/orbit.js dispatch --help`, `git diff --check`, and `git diff --cached --check before commit`.
-
-## Structured review verdict records
-
-Sentinel/agent review results are first-class board data in `review_verdicts`, not prose-only comments. Each record belongs to one ticket and stores:
-
-- `verdict`: one of `PASS`, `BLOCK`, or `QUESTION`
-- `blocking_findings`: JSON array for issues that must be repaired before approval
-- `optional_findings`: JSON array for non-blocking review notes
-- `evidence_commands`: JSON array of commands or probes the reviewer used as evidence
-- `reviewer_profile` and `reviewer_session_id`: optional reviewer identity/session metadata
-- `reviewed_commit_sha`: optional commit SHA under review
-- `dispatch_run_id`: optional dispatch run id tying the verdict back to `run-record.json`
-- `supersedes_prior_review_id`: optional link to an earlier verdict on the same ticket
-
-HTTP API:
-
-```text
-POST /api/tickets/:ticket_id/review-verdicts
-GET  /api/tickets/:ticket_id/review-verdicts?limit=50
-GET  /api/review-verdicts/:review_id?board=<slug-or-id>
-```
-
-MCP tools:
-
-```text
-board_create_review_verdict
-board_list_review_verdicts
-board_get_review_verdict
-```
-
-Comments may mirror verdict summaries for human scanning, but comments are not the source of truth for review automation. Later repair and re-review tooling should read these records directly.
-
-## The linked markdown handoff
-
-Dispatch stores the generated handoff as a linked markdown artifact and keeps only a terse AI Plan summary visible on the ticket. The artifact includes:
-
-- mission and ticket metadata
-- repository root, worktree, branch, and run id
-- required reading order: `AGENTS.md`, `SKILL-ORBIT.md`, then the handoff
-- ticket description
-- terse AI Plan / Work Summary text, Revisions, and any linked artifact paths
-- board-level agent instructions
-- board Journal lessons/decisions when available
-- recent remote comments when remote dispatch uses the lean dispatch packet
-- parent/child ticket context
-- unresolved blockers
-- scope boundaries
-- autonomous policy
-- declared verification commands and environment-variance checklist
-- completion protocol
-
-The short prompt passed to `hermes chat -q` is intentionally small. The ticket is the source of truth; the CLI argument is only a bootstrap pointer.
-
-Board journal entries are framed as project constraints and lessons, not persona or roleplay instructions. Keep durable board entries focused on mechanisms, architectural/product boundaries, workflow invariants, public-product implications, and reusable pitfalls; use ticket fields/comments for run-specific chronology.
-
-## Preserved worktrees
-
-Use `--worktree` when the agent will edit code. Dispatch creates a normal git worktree and gives the agent that directory as its working directory.
-
-This solves the ephemeral-agent problem: humans can test the branch/worktree before cleanup.
-
-Default local shape:
-
-```text
-<repo>/.worktrees/<board>-<ticket>-<profile>-<shortid>
-orbit/<board>-<ticket>-<profile>-<shortid>
-```
-
-Default remote shape:
-
-```text
-<repo-parent>/.worktrees/<repo-name>/<run-id>
-orbit/<ticket>-<profile>-remote-<shortid>
-```
-
-`.worktrees/` is ignored by git.
-
-## Safe autonomous policy
-
-The default policy prepends the run directory’s `policy-bin` to the child agent's `PATH`. That directory contains wrappers for commands that should be restricted during an autonomous run.
-
-Allowed:
-
-- file reads/searches and local edits
-- `git status`, `git diff`, `git log`, `git show`, `git add`, local `git commit`, safe branch inspection/creation
-- package test/build/lint/check/typecheck scripts
-
-Blocked or requiring human approval:
-
-- Docker
-- `git push`
-- destructive git commands such as reset, clean, rebase, merge, checkout/switch/restore, tag, cherry-pick, worktree mutation
-- package install/publish/version/deploy/release commands
-- recursive or force `rm`
-- SSH/SCP/rsync
-- GitHub CLI
-- direct curl/wget network calls
-- cloud/deploy CLIs
-- `sudo`
-
-Use `--policy none` only when you intentionally want to dispatch without wrappers.
-
-## Agent completion protocol
-
-The dispatched agent should:
-
-1. Run relevant tests and focused manual/API checks.
-2. Commit locally on the dispatch branch.
-3. Put a terse human-readable result in **Work Summary** (`implementation_summary`).
-4. If full detail matters, write a markdown report artifact and link it with `implementation_artifact_path`.
-5. Leave Revisions (`implementation_updates`) blank unless this is a later change/correction after initial implementation; promote the most important code/pattern/project lessons and decisions to board Journal entries.
-6. Add a compact completion comment/run receipt.
-7. Move the card to **Review**, not Done, unless the human explicitly asked for auto-completion.
-
-## Installing / enabling the command
-
-For source installs:
-
-```bash
-cd /path/to/ss-orbit
-pnpm install
-pnpm run build:bundle
-pnpm link --global
-```
-
-Then from a project repo with an Orbit board:
-
-```bash
-orbit init            # if the repo does not have a board yet
-orbit dispatch --board my-app --ticket 12 --profile agent --worktree --no-spawn
-```
-
-For support, bug reports, and reproducibility notes, human users can print the installed CLI version with either form:
-
-```bash
-orbit -v
-orbit --version
-```
-
-## Operator notes for orchestrators
-
-- Prefer `orbit dispatch` over writing a temporary handoff prompt file when targeting an Orbit ticket.
-- Use a full hosted Orbit ticket URL for the fastest remote path; dispatch will parse the server, board slug, and ticket id.
-- Use `--cwd` to point remote dispatch at the local code checkout when the hosted board records another machine’s repo path.
-- Use `--dry-run` when you want proof of what would happen without any side effects.
-- Use `--no-spawn` when you want to inspect the generated handoff/worktree/comment before starting an agent.
-- Use `--worktree` for code edits so the human can test before cleanup.
-- Treat the ticket fields as human-visible surfaces:
-  - AI Plan: terse visible plan summary; full handoff/plan doc lives in human-editable `plan_artifact_path`
-  - Work Summary: terse visible result summary; full report/evidence doc lives in human-editable `implementation_artifact_path`
-  - Revisions: terse later corrections/changes after initial implementation only
-  - Comments: compact run receipts and transient breadcrumbs
-  - Board Journal: durable reusable project lessons/decisions
-- Do not push, deploy, or open PRs from the dispatched agent unless the human explicitly asked for that run to do so.

package/docs/mcp-client.example.json

@@ -1,13 +0,0 @@
-{
-  "mcpServers": {
-    "minimal-agent-board": {
-      "command": "node",
-      "args": [
-        "C:/path/to/minimal-agent-board/src/cli/orbit.js",
-        "mcp",
-        "--cwd",
-        "C:/path/to/your/project"
-      ]
-    }
-  }
-}

package/docs/setup/orbit-init-wizard.md

@@ -1,174 +0,0 @@
-# Orbit init wizard
-
-Status: focused implementation spec for ticket #61.
-
-This replaces the older Mission Control-shaped setup-mode design from Orbit tickets #26 and #27. Keep the useful lesson: `orbit init` should make the first board choice clear. Cut the rest. Orbit setup creates a project board and, optionally, the agent-ready affordances around that board. Suite and Sync concerns stay out.
-
-## Goal
-
-`orbit init` supports two first-pass modes:
-
-1. Local board / no AI
-2. AI-assisted board
-
-Anything beyond those modes belongs to Starscape Suite, Starscape Sync, or an app-specific integration ticket.
-
-## Command contract
-
-These commands must work:
-
-```bash
-orbit init
-orbit init --ai
-orbit init --no-ai
-```
-
-| Command | Mode | Contract |
-| --- | --- | --- |
-| `orbit init` | AI-assisted board | Backwards-compatible default. |
-| `orbit init --ai` | AI-assisted board | Explicit alias for the default. |
-| `orbit init --no-ai` | Local board / no AI | No AI collaboration assumptions. |
-
-Keep existing init flags:
-
-- `--cwd <dir>` selects the project root.
-- `--example` creates onboarding example tickets.
-
-`SKILL-ORBIT.md` is managed Orbit guidance: `orbit init` writes it, and `orbit run` refreshes registered repo copies on startup. Repo/team customization belongs in `AGENTS.md` or board `agent_instructions`, not in `SKILL-ORBIT.md`.
-
-Do not add `--multi-ai`, `--output=starlog-authored`, `--starlog`, `--suite`, `--forge`, `--sync`, hosted-service flags, agent-guidance refresh flags, or remote-sync flags in this pass.
-
-## Wizard rules
-
-The first implementation should be clear without breaking scripts:
-
-- If `--ai` or `--no-ai` is present, do not prompt.
-- If running non-interactively, default to AI-assisted board.
-- If an interactive prompt is added, Enter chooses AI-assisted board.
-- Ask only for local/no-AI vs AI-assisted. Do not ask about Starlog, Suite dashboard, Nebula, Forgejo, Auth, hosted service, Sync links, artifacts, events, or remote sync.
-
-Suggested prompt:
-
-```text
-Initialize Orbit for this repo
-
-Orbit keeps a project board next to your code. Git stays the truth for code;
-Orbit becomes the truth for tickets, planning state, handoff, and implementation notes.
-
-Choose a first-run mode:
-
-  1. Local board / no AI
-     A local kanban board. No AI Ready lane or MCP setup step.
-
-  2. AI-assisted board (recommended)
-     Adds AI Ready, agent handoff fields, generated agent instructions, and MCP setup guidance.
-
-Select a mode [2]:
-```
-
-## Mode behavior
-
-### Local board / no AI
-
-Triggered by `orbit init --no-ai`.
-
-Behavior:
-
-- Create or repair the board database and registry row for the selected project root.
-- Persist `ai_enabled = 0`.
-- Do not create the `AI Ready` lane.
-- Keep ordinary lanes: `Backlog`, `Todo`, `In Progress`, `Review`, `Done`, `Cancelled`.
-- Keep Orbit usable for human planning, ticket history, blockers, comments, and implementation notes.
-- Generate `AGENTS.md` and `SKILL-ORBIT.md`, but do not present MCP connection as a required next step.
-- If `--example` is used, keep example tickets out of AI Ready.
-
-Success copy should say the board path returned by init, the selected mode, and the next `orbit run` step. It should not imply AI is required.
-
-### AI-assisted board
-
-Triggered by `orbit init` and `orbit init --ai`.
-
-Behavior:
-
-- Create or repair the board database and registry row for the selected project root.
-- Persist `ai_enabled = 1`.
-- Ensure `AI Ready`, `In Progress`, and `Review` exist for agent flow.
-- Create/update `AGENTS.md` as the repo-owned pointer and write the managed `SKILL-ORBIT.md` so agents know to read board context, respect blockers, use MCP/API tools, and update `ai_plan`, `implementation_summary`, and `implementation_updates`.
-- Print MCP setup guidance after init, including project-root-specific `orbit mcp --cwd <repo>` / `PROJECT_ROOT=<repo>` guidance or the generated client snippet.
-- If `--example` is used, stage the stable MCP exercise ticket in `AI Ready`.
-
-Success copy should say AI collaboration lanes are present and the next step is connecting an agent through MCP.
-
-## Generated guidance files
-
-`orbit init` preserves generation of:
-
-- `AGENTS.md`
-- `SKILL-ORBIT.md`
-
-`AGENTS.md` should stay terse and repo-owned: when work mentions Orbit/tickets/boards, read `SKILL-ORBIT.md` first. `SKILL-ORBIT.md` is Orbit-managed durable protocol and may be overwritten by `orbit init` or refreshed by `orbit run`; it tells agents to read board context, check blockers, use Orbit API/MCP instead of editing SQLite directly, update implementation fields, and hand off through Review.
-
-For local/no-AI boards, these files are still useful if an agent later opens the repo, but init output should not frame MCP as mandatory.
-
-## MCP setup guidance
-
-For AI-assisted boards, keep the current guidance:
-
-- MCP config tells the AI client how to spawn Orbit's helper.
-- `AGENTS.md` and `SKILL-ORBIT.md` are normal repo files, not streamed through MCP.
-- Persistent MCP configs should use explicit `--cwd <repo>` / `PROJECT_ROOT=<repo>` so the helper attaches to the right board.
-
-For local/no-AI boards, omit MCP guidance or label it optional later setup.
-
-## Board mode metadata
-
-First pass can keep `boards.ai_enabled` as the source of truth:
-
-```text
-ai_enabled = 0 -> local board / no AI
-ai_enabled = 1 -> AI-assisted board
-```
-
-If a mode field is added, keep it deliberately small:
-
-```json
-{
-  "setup_mode": "ai-assisted",
-  "setup_schema_version": 1
-}
-```
-
-Allowed `setup_mode` values: `local`, `ai-assisted`.
-
-Compatibility:
-
-```text
-missing setup_mode + ai_enabled = 0 -> local
-missing setup_mode + ai_enabled = 1 -> ai-assisted
-```
-
-Do not persist Starlog output mode, Suite profile, Forge mode, Sync mode, hosted Auth state, or remote-sync configuration in Orbit setup metadata.
-
-## Explicitly out of scope
-
-| Deferred concern | Route |
-| --- | --- |
-| Starscape Suite dashboard, module/plugin setup, unified launcher, ecosystem settings | `ss-suite` #1 |
-| Nebula / whiteboard setup | `ss-suite` #1 or the Nebula board |
-| Starlog output/reporting mode, authored HTML outputs, templates | Suite/app integration work, not Orbit init |
-| Forgejo/Gitea suite mode, local forge provisioning, themed forge navigation | `ss-suite` #1 |
-| Starscape Auth, hosted service, cloud accounts, managed hosting | `ss-suite` #1 / hosted-service follow-up |
-| Cross-app registry, object identity, links/backrefs, artifacts, activity/events, export/import, remote sync | `ss-sync` #1 |
-| Mission Briefs, named agent ecology, wave execution, multi-agent orchestration | Later Orbit Mission Control work, not this wizard |
-
-Mapping note: Orbit keeps local project boards, generated agent guidance, agent-ready lanes, MCP setup, and ticket implementation records. Suite composition maps to `ss-suite` #1. Registry/link/artifact/event/sync semantics map to `ss-sync` #1.
-
-## Implementation checklist for the next build ticket
-
-- `orbit init`, `orbit init --ai`, and `orbit init --no-ai` all work.
-- `orbit init --ai` is an explicit alias for the default AI-assisted path.
-- Local/no-AI mode creates no `AI Ready` lane and does not require MCP setup.
-- AI-assisted mode keeps AI lanes, generated guidance files, MCP guidance, and example-ticket staging behavior.
-- Generated `AGENTS.md` / `SKILL-ORBIT.md` keep agents on Orbit API/MCP rather than direct SQLite edits.
-- Setup metadata is limited to `local` / `ai-assisted` plus schema version, or remains derived from `ai_enabled`.
-- No Suite, Sync, Starlog, Nebula, Forgejo, Auth, hosted service, artifact, link, event, or remote-sync setup enters Orbit init.

package/public/fonts/Chakra_Petch/OFL.txt

@@ -1,93 +0,0 @@
-Copyright 2018 The Chakra Petch Project Authors (https://github.com/m4rc1e/Chakra-Petch.git)
-
-This Font Software is licensed under the SIL Open Font License, Version 1.1.
-This license is copied below, and is also available with a FAQ at:
-https://openfontlicense.org
-
-
------------------------------------------------------------
-SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
------------------------------------------------------------
-
-PREAMBLE
-The goals of the Open Font License (OFL) are to stimulate worldwide
-development of collaborative font projects, to support the font creation
-efforts of academic and linguistic communities, and to provide a free and
-open framework in which fonts may be shared and improved in partnership
-with others.
-
-The OFL allows the licensed fonts to be used, studied, modified and
-redistributed freely as long as they are not sold by themselves. The
-fonts, including any derivative works, can be bundled, embedded, 
-redistributed and/or sold with any software provided that any reserved
-names are not used by derivative works. The fonts and derivatives,
-however, cannot be released under any other type of license. The
-requirement for fonts to remain under this license does not apply
-to any document created using the fonts or their derivatives.
-
-DEFINITIONS
-"Font Software" refers to the set of files released by the Copyright
-Holder(s) under this license and clearly marked as such. This may
-include source files, build scripts and documentation.
-
-"Reserved Font Name" refers to any names specified as such after the
-copyright statement(s).
-
-"Original Version" refers to the collection of Font Software components as
-distributed by the Copyright Holder(s).
-
-"Modified Version" refers to any derivative made by adding to, deleting,
-or substituting -- in part or in whole -- any of the components of the
-Original Version, by changing formats or by porting the Font Software to a
-new environment.
-
-"Author" refers to any designer, engineer, programmer, technical
-writer or other person who contributed to the Font Software.
-
-PERMISSION & CONDITIONS
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of the Font Software, to use, study, copy, merge, embed, modify,
-redistribute, and sell modified and unmodified copies of the Font
-Software, subject to the following conditions:
-
-1) Neither the Font Software nor any of its individual components,
-in Original or Modified Versions, may be sold by itself.
-
-2) Original or Modified Versions of the Font Software may be bundled,
-redistributed and/or sold with any software, provided that each copy
-contains the above copyright notice and this license. These can be
-included either as stand-alone text files, human-readable headers or
-in the appropriate machine-readable metadata fields within text or
-binary files as long as those fields can be easily viewed by the user.
-
-3) No Modified Version of the Font Software may use the Reserved Font
-Name(s) unless explicit written permission is granted by the corresponding
-Copyright Holder. This restriction only applies to the primary font name as
-presented to the users.
-
-4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font
-Software shall not be used to promote, endorse or advertise any
-Modified Version, except to acknowledge the contribution(s) of the
-Copyright Holder(s) and the Author(s) or with their explicit written
-permission.
-
-5) The Font Software, modified or unmodified, in part or in whole,
-must be distributed entirely under this license, and must not be
-distributed under any other license. The requirement for fonts to
-remain under this license does not apply to any document created
-using the Font Software.
-
-TERMINATION
-This license becomes null and void if any of the above conditions are
-not met.
-
-DISCLAIMER
-THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
-OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE
-COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
-INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
-DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
-OTHER DEALINGS IN THE FONT SOFTWARE.