@starlove/orbit 1.3.4 → 1.4.0

package/docs/AGENT_PROTOCOL.md

@@ -95,13 +95,13 @@ GET /api/tickets/:id/context?depth=1
 Returns:
 
 - Ticket, board identity, state, labels.
-- Dedicated implementation fields: `ai_plan`, `implementation_summary`, and `implementation_updates`.
+- Human-visible card fields: terse AI Plan (`ai_plan`), terse Work Summary (`implementation_summary`), and Revisions (`implementation_updates`); full handoffs/reports live in linked markdown artifact paths. Board Journal decisions/lessons carry the most important code/pattern/project context loaded for every agent on the board.
 - Parent epic/story ticket when present.
 - Child feature cards when the ticket is an epic/story.
 - Related tickets.
 - Blockers and blocking tickets.
 
-Project manual/journal (`agent_instructions`, `project_notes`, and board entries) and ticket comments are intentionally omitted from this default agent context. Fetch project context and comments explicitly when needed:
+Project manual/journal (`agent_instructions` and board entries) and ticket comments are intentionally omitted from this default agent context. Human-only `project_notes` are not part of agent context surfaces. Fetch project context and comments explicitly when needed:
 
 ```http
 GET /api/boards/:board_id/context?include_struck=false
@@ -192,7 +192,7 @@ Searches ticket titles, descriptions, and comments.
 GET /api/boards/:board_id/context?include_struck=false
 ```
 
-Returns the same shape as MCP `board_context`: board metadata (`agent_instructions`, `project_notes`, repository paths, default branch), `entries` (journal / decisions / lessons), and `deployment` paths. Use `include_struck=true` to include struck journal rows (default off).
+Returns the same shape as MCP `board_context`: agent-safe board metadata (`agent_instructions`, repository paths, default branch), `entries` (journal / decisions / lessons), and `deployment` paths. Human-only `project_notes` are intentionally excluded. Use `include_struck=true` to include struck journal rows (default off).
 
 MCP: `board_context` with optional `board_id` / `board_slug` / `board` and optional `include_struck`.
 
@@ -207,8 +207,7 @@ Content-Type: application/json
   "repo_url": "https://github.com/you/repo",
   "system_path": "C:/path/to/repo",
   "default_branch": "main",
-  "project_notes": "Personal reminders (optional).",
-  "agent_instructions": "Why this repo exists, capabilities, stack, constraints, and how agents should operate..."
+  "agent_instructions": "How agents should work here..."
 }
 ```
 
@@ -281,24 +280,32 @@ Content-Type: application/json
 
 Comments are for discussion and event breadcrumbs. Use the dedicated fields below for durable implementation records.
 
-### Update AI Plan / Implementation Fields
+### Ticket Field Contract
 
 ```http
 PATCH /api/tickets/:id
 Content-Type: application/json
 
 {
-  "ai_plan": "The current plan...",
-  "implementation_summary": "What shipped...",
-  "implementation_updates": "Progress notes, mistakes to avoid, discoveries..."
+  "ai_plan": "Next: implement the sync queue, add conflict tests, verify with pnpm test.",
+  "plan_artifact_path": ".orbit/dispatch-runs/.../handoff.md",
+  "implementation_summary": "Shipped sync queue + conflict tests. pnpm test passed. Risk: mobile offline smoke remains human-owned.",
+  "implementation_artifact_path": ".orbit/dispatch-runs/.../report.md",
+  "implementation_updates": "Revision: narrowed conflict retry to failed operations only."
 }
 ```
 
 Field intent:
 
-- `ai_plan`: The current plan. For epics, this should describe the high-level vision and feature breakdown. For feature/task/bug cards, this should describe the concrete implementation approach.
-- `implementation_summary`: The final concise summary of what changed, usually written when the card moves to review or done.
-- `implementation_updates`: Chronological notes, mistakes, discoveries, and "avoid this next time" material. Later this can feed a separate insights system.
+- `ai_plan`: existing AI Plan field. Store a terse visible plan summary for humans. Use `plan_artifact_path` for full markdown/text handoffs or plan docs.
+- `plan_artifact_path`: human-editable local/repo-relative or hosted-readable markdown/text path, for example `docs/plan.md` or `./docs/plan.md`. The UI resolves it when opening the artifact; if it cannot resolve, the human can edit the path.
+- `implementation_summary`: existing Work Summary field. Store a terse visible result summary for humans. Use `implementation_artifact_path` for full reports/evidence.
+- `implementation_artifact_path`: human-editable local/repo-relative or hosted-readable markdown/text path to the full report/evidence artifact, for example `docs/report.md` or `./docs/report.md`.
+- `implementation_updates`: Revisions. Use only for terse later changes/corrections after initial implementation. Leave blank for normal first completion; do not store chronology, command logs, run receipts, or durable project lessons here.
+- Comments are for compact run receipts, transient breadcrumbs, and discussion.
+- Board Journal entries are for durable reusable project decisions/lessons.
+
+Direct `PATCH /api/tickets/:id` updates the fields exactly. For normal completion, prefer `/api/agent/complete`: its `summary` writes Work Summary (`implementation_summary`), `implementation_artifact_path` links the full report, and optional `updates` writes Revisions only when the run is a later correction/change.
 
 ### Archive, Restore, and Delete
 
@@ -396,7 +403,7 @@ Content-Type: application/json
 }
 ```
 
-Moves the ticket to `Review` by default and writes `summary` into `implementation_summary`. If `updates` is present, it is appended to `implementation_updates`.
+Moves the ticket to `Review` by default and writes `summary` into Work Summary (`implementation_summary`). If `updates` is present, it is appended to Revisions (`implementation_updates`) without timestamp headings; omit `updates` for normal first completion notes.
 
 ## Ticket Writing Contract
 

package/docs/ORBIT_DISPATCH.md

@@ -1,6 +1,6 @@
 # Orbit Dispatch
 
-`orbit dispatch` is the local Orbit-to-Hermes handoff command. It turns a local Orbit ticket into a bounded agent run without relying on a temporary prompt file as the source of truth.
+`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:
 
@@ -8,15 +8,38 @@ The design intent is simple:
 - 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.
 
-## Current remote-board contract
+## Local and remote board contract
 
-`orbit dispatch` is intentionally local-board only right now. It resolves boards through the local Orbit registry and mutates the local SQLite board file.
+Local dispatch resolves boards through the local Orbit registry and mutates the local SQLite board file.
 
-Because of that, `--server-url` and `--remote` are refused before side effects. They do not silently target a hosted board.
+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:
 
-For hosted/remote boards, use remote MCP/manual orchestration or run `orbit dispatch` on the board host without `--server-url`/`--remote`.
+```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:
 
-## Basic use
+```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:
 
@@ -53,12 +76,12 @@ orbit dispatch --board my-app --ticket 12 --profile agent --worktree \
 
 ## Preflight order
 
-Before any filesystem writes, worktree creation, ticket mutation, or agent spawn, dispatch now:
+Before filesystem writes, worktree creation, ticket mutation, or agent spawn, dispatch now:
 
-1. Refuses `--server-url` / `--remote`.
-2. Resolves the local board from `--board` or from `--cwd` / the current repo.
-3. Resolves the ticket from `--ticket` by number or id.
-4. Refuses archived tickets.
+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.
@@ -71,27 +94,27 @@ Only after those checks does dispatch create run artifacts/worktrees, write the
 In normal spawn mode:
 
 1. Builds a run id such as `orbit-12-agent-abc123def0`.
-2. Creates `.orbit/dispatch-runs/<run-id>/` for run metadata and policy wrappers.
-3. Creates and preserves a git worktree/branch when `--worktree` is used.
+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 copy to the ticket's **AI Written-Plan** (`ai_plan`) field.
+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, initial `run-record.json`, and run-record comment but leaves the ticket in its current lane.
+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, 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.
+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 `<DATA_DIR>/dispatch-runs/<board>/<run-id>/run-record.json` with schema `orbit.dispatch.run.v1`.
+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, mode, and status (`prepared` for `--no-spawn`, `launched` for spawned runs)
+- 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
@@ -133,17 +156,18 @@ 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 AI Written-Plan handoff
+## The linked markdown handoff
 
-Dispatch stores the generated handoff in the ticket's AI Written-Plan field. It includes:
+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
-- implementation fields (`ai_plan`, `implementation_summary`, `implementation_updates`)
-- board-level agent instructions and notes
-- board journal lessons/decisions
+- 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
@@ -157,22 +181,29 @@ Board journal entries are framed as project constraints and lessons, not persona
 
 ## Preserved worktrees
 
-Use `--worktree` when the agent will edit code. Dispatch creates a normal git worktree under `.worktrees/` by default and gives the agent that directory as its working directory.
+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 shape:
+Default local shape:
 
 ```text
-.worktrees/<board>-<ticket>-<profile>-<shortid>
+<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 `.orbit/dispatch-runs/<run-id>/policy-bin` to the child agent's `PATH`. That directory contains wrappers for commands that should be restricted during an autonomous run.
+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:
 
@@ -201,10 +232,11 @@ The dispatched agent should:
 
 1. Run relevant tests and focused manual/API checks.
 2. Commit locally on the dispatch branch.
-3. Update **AI Implementation Summary** (`implementation_summary`) with what changed, commit SHA, branch/worktree, verification, and manual checks still needed.
-4. Add **Implementation Updates/Lessons** (`implementation_updates`) for pitfalls, remediation, and reusable guidance.
-5. Add a completion comment/run record.
-6. Move the card to **Review**, not Done, unless the human explicitly asked for auto-completion.
+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
 
@@ -213,7 +245,7 @@ For source installs:
 ```bash
 cd /path/to/ss-orbit
 pnpm install
-pnpm run build:full
+pnpm run build:bundle
 pnpm link --global
 ```
 
@@ -233,13 +265,16 @@ orbit --version
 
 ## Operator notes for orchestrators
 
-- Prefer `orbit dispatch` over writing a temporary handoff prompt file when targeting a local board.
+- 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 durable surfaces:
-  - AI Written-Plan: generated handoff
-  - AI Implementation Summary: final summary of completed work
-  - Implementation Updates/Lessons: pitfalls, remediation, future-agent guidance
-  - Comments: run records and transient breadcrumbs
+- 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/UPDATING.md

@@ -0,0 +1,114 @@
+# Updating Orbit
+
+Orbit checks GitHub for a newer version and surfaces it in the app:
+
+- a purple dot on the **Settings** button in the topbar,
+- a one-time toast on load (**“Orbit vX.Y.Z is available →”**), and
+- a **Version & Updates** card at the top of **Settings → Data** with the
+  current version, a **Check now** button, a **Back up all boards** button, and
+  the exact commands for your deployment.
+
+The check reads the `version` field of `package.json` on the project's default
+branch. Your board data lives in `DATA_DIR` (default `~/.orbit`, `/data` in
+Docker) — **outside** the app folder — so updating never touches it. Even so,
+the card nudges you to **back up all boards** to a ZIP first.
+
+---
+
+## Before you update: back up
+
+Settings → Data → **Version & Updates → Back up all boards**, or the Board chip
+→ **Export → Export All**. Both download a single ZIP of every board's
+`.orbit.json` snapshot.
+
+---
+
+## Update flows
+
+### Local machine or your own server (git checkout)
+
+```sh
+git pull
+pnpm install
+pnpm run build:bundle   # rebuild the production bundle dist/full
+# then restart Orbit (re-run `orbit serve` / `pnpm dev`, or your service)
+```
+
+The rebuild matters: when `dist/full` exists, Orbit serves it instead of raw
+`public/` sources, so a `git pull` alone won't show new UI.
+
+### Docker
+
+No image is published to a registry yet, so update by rebuilding from source:
+
+```sh
+git pull
+docker compose build      # or: docker build -t orbit .
+docker compose up -d      # or restart your `docker run` container
+```
+
+Your boards persist in the `/data` volume across the rebuild.
+
+### Global npm install
+
+```sh
+npm install -g @starlove/orbit@latest
+# then restart Orbit
+```
+
+---
+
+## One-click self-update (opt-in, advanced)
+
+If you run Orbit from a git checkout **under a process supervisor that
+auto-restarts it**, you can enable a **Update now** button that performs the
+pull + rebuild + restart for you.
+
+Set `ORBIT_SELF_UPDATE=1` in the server environment. The button then appears in
+the Version & Updates card whenever an update is available and calls
+`POST /api/update`, which runs [`scripts/update.sh`](../scripts/update.sh).
+Without the flag the endpoint returns `404` and the button stays hidden.
+
+The script pulls, reinstalls, runs `build:bundle`, writes a log to
+`DATA_DIR/update.log`, then signals the server process to exit so the
+supervisor restarts it on the new build. **It only works if something restarts
+the process** — otherwise Orbit simply stops and you restart it yourself.
+
+Example systemd unit (`/etc/systemd/system/orbit.service`):
+
+```ini
+[Unit]
+Description=Starscape Orbit
+After=network.target
+
+[Service]
+WorkingDirectory=/home/you/apps/ss-orbit
+ExecStart=/usr/bin/node src/server.js
+Environment=NODE_ENV=production
+Environment=ORBIT_SELF_UPDATE=1
+Restart=always
+RestartSec=2
+User=you
+
+[Install]
+WantedBy=multi-user.target
+```
+
+`Restart=always` is what turns the script's "exit" into a clean restart on the
+updated code.
+
+---
+
+## Configuration
+
+| Env var | Default | Purpose |
+| --- | --- | --- |
+| `ORBIT_UPDATE_CHECK` | on | Set `0` to disable the update check entirely. |
+| `ORBIT_UPDATE_TTL` | `60` | Minutes the server caches the GitHub result. |
+| `ORBIT_UPDATE_BRANCH` | `master` | Branch whose `package.json` version is read. |
+| `ORBIT_GITHUB_TOKEN` | — | Optional PAT for private repos / higher rate limit. |
+| `ORBIT_SELF_UPDATE` | off | Set `1` to enable the gated `POST /api/update`. |
+
+The server fetches GitHub's contents API (not the raw CDN), so the result isn't
+stale-cached upstream; freshness is governed by `ORBIT_UPDATE_TTL`, and
+**Check now** bypasses it (`/api/version?refresh=1`).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@starlove/orbit",
-  "version": "1.3.4",
+  "version": "1.4.0",
   "description": "Starscape Orbit — local-first, pretty, human-ai-first kanban system.",
   "license": "AGPL-3.0",
   "type": "module",
@@ -21,9 +21,6 @@
   "publishConfig": {
     "access": "public"
   },
-  "devDependencies": {
-    "esbuild": "^0.25.0"
-  },
   "engines": {
     "node": ">=22.13.0"
   },
@@ -44,15 +41,16 @@
     "claude-code"
   ],
   "dependencies": {
-    "@starlove/ui": "^3.3.0"
+    "@starlove/ui": "^3.3.2",
+    "esbuild": "^0.25.0"
   },
   "scripts": {
     "dev": "node src/server.js",
     "dev:site": "pnpm run build:preview && pnpm run build:site && node serve-site.mjs",
     "orbit": "node src/cli/orbit.js",
-    "build": "pnpm run build:full && pnpm run build:preview && pnpm run build:site",
+    "build": "pnpm run build:bundle && pnpm run build:preview && pnpm run build:site",
     "build:vercel": "pnpm run build:preview && pnpm run build:site",
-    "build:full": "node build.mjs --edition=full",
+    "build:bundle": "node build.mjs --edition=full",
     "build:preview": "node build.mjs --edition=preview",
     "build:site": "node build.mjs --edition=site",
     "serve:site": "node serve-site.mjs",

package/public/fonts/Chakra_Petch/OFL.txt

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