specweave 2.2.3 → 3.0.0

package/plugins/specweave/skills/review/SKILL.md

@@ -1,102 +1,63 @@
 ---
-description: Adversarial fresh-context review of an increment before it ships. Every finding cites path:line and is re-verified. Use when saying "review", "grill this", or "critique the implementation".
-version: 2.0.0
-argument-hint: "<increment-id> [--full]"
+description: Adversarial fresh-context review and risk check of an increment before it ships; every finding cites path:line and is re-verified. Use for "review", "qa", "quality check", "critique this".
+argument-hint: "[increment-id] [--full]"
+version: 3.0.0
 ---
+<!-- Generated from skills/sw-review/SKILL.md by scripts/build/generate-skills.mjs. Edit the source, then npm run build. -->
 
-# Review Increment
+# sw-review: adversarial review with citations
 
-One review surface (it replaces the old grill / code-reviewer / judge-llm passes).
-Reads the increment's spec, its diff and the code around it, then reports what is
-actually wrong — with `path:line` for every claim. Writes
-`reports/review.md` + `reports/review.json` under the increment.
-`specweave complete` prints a notice when review.md is absent but never blocks.
+A fresh reader hunts for real failures in the increment's diff, cites `path:line` for
+each, re-checks every claim, and writes `.specweave/increments/<id>/reports/review.md`.
+This is also the quality check: its verdict says whether the increment is ready.
 
-## Usage
+## Non-negotiables
 
-```
-sw:review <increment-id>            # single adversarial pass
-sw:review <increment-id> --full     # 3 parallel lenses: correctness, security, spec-compliance
-```
-
-## Rules
-
-1. **Fresh context. The session that wrote the code never approves it.** Run the pass
-   through a subagent (Claude Code: `Task({ subagent_type: "general-purpose", … })`) or a
-   new session in any other tool. If you wrote this code in this context and cannot spawn
-   one, say so in the report instead of claiming an independent review.
-2. **Every finding cites `path:line`** and states a concrete failure: inputs or state →
-   wrong output, crash, data loss, or leak. No "consider refactoring", no style opinions.
-3. **Re-verify before reporting.** Re-open the cited lines — and run the test that would
-   fail — and drop anything that does not survive. A wrong finding costs more than a
-   missed one. Unverifiable but plausible findings are reported as `plausible`, not as fact.
-4. **Severity**: critical / high / medium / low. Only critical and high are blocking.
-5. **Nit cap 5.** At most five low findings; if there are more, report the five worst and
-   one line saying how many were dropped.
-6. **Scope is the increment's diff**, not the repository:
-   `git diff $(git merge-base HEAD <base>)...HEAD -- <the tasks' Files>`.
+- **Fresh context.** The session that wrote the code never approves it. Use a new
+  session, or a subagent if your tool supports them. If you wrote this code here and
+  cannot get a fresh context, say so in the report.
+- **Every finding cites `path:line`** and a concrete failure: input or state leads to
+  wrong output, a crash, a hang, data loss or a leak. "Consider refactoring" is not one.
+- **Re-verify.** Re-open the lines and, where a test can show it, run one. Drop what
+  does not survive; mark what you could not prove as `plausible`.
+- **Severity** is critical, high, medium or low. Critical and high block the close.
+- **At most 5 nits**, in one line at the end.
 
 ## Steps
 
-1. **Scope**: read `spec.md` (ACs + Approach) and the `Files:` fields in `tasks.md`.
-   Collect the diff for those files plus the code they call.
-2. **Pass** — in this order:
-   - correctness: wrong logic, unhandled error paths, races, off-by-one, resource leaks;
-   - security: injection, path traversal, secret leakage, missing authz, unsafe spawn/exec;
-   - spec-compliance: ACs marked done but not implemented, tests that assert nothing,
-     behaviour that contradicts spec.md.
-   With `--full`, run those three as parallel subagents and merge their findings
-   (dedupe by `file:line + summary`).
-3. **Verify** each candidate finding as per rule 3.
-4. **Report**: write both files (shapes below).
-5. **Hand back**: fix critical/high findings yourself or hand them to `sw:do`, then re-run
-   `specweave verify <id>` and close with `sw:done`.
-
-## Report shape
-
-`reports/review.md`:
+1. **Evidence first.** `specweave verify` (or its existing `reports/verify.md`): red
+   tests, lint or build are findings before any reading.
+2. **Scope.** Read spec.md (ACs, Approach, the tasks' `Files`) and review that diff,
+   not the repository: `git diff $(git merge-base HEAD origin/HEAD)...HEAD -- <Files>`.
+3. **Pass**, in this order: correctness (logic, error paths, races, off-by-one) →
+   security (injection, path traversal, secrets, unsafe exec) → spec compliance (ACs
+   claimed but not implemented, tests that assert nothing or mock the subject) →
+   portability (bash-only commands, `\` paths, BOMs, `>>` in PowerShell).
+   `--full`: run the three lenses correctness, security and spec compliance separately
+   (in parallel if your tool has subagents) and merge, dropping duplicates.
+4. **Report** in the shape below. Optional machine form, `reports/review.json`:
+   `{"ok":false,"findings":[{"severity":"high","file":"src/a.ts","line":88,"summary":"..."}]}`.
+5. **Hand back.** Each critical or high finding becomes a task in spec.md
+   (`### T-09 Fix empty evidence` + `- AC: AC-02 | Files: ... | Test: ...`) for sw-do, or
+   is fixed and re-tested now. Then verify again and close with sw-done.
+
+## reports/review.md
 
 ```markdown
-# Review — <id> <title>
-Verdict: fix first | ship · reviewed <n> files · <n> findings (<n> critical, <n> high)
-Reviewer context: subagent | new session | same session (NOT independent)
-
-## [critical] src/core/tasks/ledger.ts:142 — stale claim never released
-Given two agents claim T-01 inside the lease window … → the second write wins and the
-first agent's `done` line is dropped.
-Fix: compare-and-append on the claim line before writing.
-```
+# Review: 0042 Ledger fold
+Verdict: fix first · risk: high · 6 files · 2 findings (1 critical, 1 high)
+Reviewer context: new session
 
-`reports/review.json` (machine-readable, same findings):
+## [critical] src/core/tasks/ledger.ts:142 lost claim under equal timestamps
+Two agents claim T-01 in the same second; the fold sorts only by `at`, so both read
+themselves as owner. Fix: break ties by `by`, then file order.
 
-```json
-{
-  "ok": false,
-  "increment": "0042",
-  "reviewedAt": "2026-09-02T12:00:00Z",
-  "mode": "single",
-  "findings": [
-    {
-      "severity": "critical",
-      "file": "src/core/tasks/ledger.ts",
-      "line": 142,
-      "summary": "stale claim never released; second writer drops the first done line",
-      "confidence": "confirmed"
-    }
-  ],
-  "droppedNits": 0
-}
+Nits: naming in ledger.ts:31.
 ```
 
-`ok` is `true` only when there is no critical or high finding.
-
-## Anti-patterns
-
-- Approving your own work in the same context — that is the one thing this skill exists to prevent.
-- Findings without a line number, or with a line number you did not re-read.
-- Padding the count with style nits (see the nit cap).
-- Reviewing the whole repo instead of the increment's diff.
+Verdict is `fix first` while any critical or high finding survives, else `ship`.
 
-## Resources
+## Manual path (no CLI)
 
-- [Official Documentation](https://verified-skill.com/docs/reference/skills#review)
+Nothing changes: `git diff` and the project's own test runner are the whole toolchain,
+and you write `reports/review.md` yourself.

package/plugins/specweave/skills/sync/SKILL.md

@@ -1,63 +1,52 @@
 ---
-description: One sync surface for GitHub, Jira and Azure DevOps: push progress, pull or import issues, check health, run setup. Use when saying "sync", "push to GitHub", or "import issues".
-version: 2.0.0
+description: Sync SpecWeave increments with GitHub, Jira or Azure DevOps - push progress, pull or import issues, check token and health, run setup. Use for "sync", "push to GitHub", "import issues".
 argument-hint: "push|pull|status|setup [increment-id]"
+version: 3.0.0
 ---
+<!-- Generated from skills/sw-sync/SKILL.md by scripts/build/generate-skills.mjs. Edit the source, then npm run build. -->
 
-# sw:sync — external tracker sync
+# sw-sync: external tracker sync
 
-Everything goes through the CLI. Never call `gh`, `curl`, or a provider REST API
-directly: the CLI owns token resolution, the rate budget, duplicate detection and
-the bidirectional links.
+Sync is opt-in and explicit. Starting, pausing or completing an increment never calls a
+tracker; only `specweave sync push` does (plus close-on-complete, when configured). Go
+through the CLI, never `gh`, `curl` or a provider API directly: the CLI owns token
+resolution, the rate budget, duplicate detection and the links in both directions.
 
 ## Commands
 
 | Intent | Command |
 |---|---|
-| Push local progress to issues | `specweave sync push [increment-id]` |
-| Preview a push | `specweave sync push <id> --dry-run` |
-| Push to one provider | `specweave sync push <id> --provider github` |
-| Fix stale/duplicate milestones first | `specweave sync push <id> --reconcile` |
+| Push progress to issues | `specweave sync push [increment-id]` |
+| Preview a push | `specweave sync push 0042 --dry-run` |
+| One provider only | `specweave sync push 0042 --provider github` |
 | Report external changes | `specweave sync pull [--since 7]` |
 | Import issues as increments | `specweave sync pull --create-increments` |
-| Tokens, health, retry queue, gaps | `specweave sync status [--json]` |
+| Token, account, health, retry queue | `specweave sync status [--json]` |
 | Connect a provider | `specweave sync setup [--provider github]` |
-| Validate an existing config | `specweave sync setup --validate` |
+| Check an existing setup | `specweave sync setup --validate` |
 
-`sync push` runs tasks.md → spec.md ACs → living docs → provider write, then
-drains the retry queue through the same entry point. Exit code of
-`sync status` is 1 when anything needs attention; `--json` prints one parsable
-report (`providers`, `github`, `health`, `resilience`, `gaps`, `hasIssues`).
-
-Not sync: `specweave doctor --fix-status` repairs metadata.json ↔ spec.md status
-desyncs, and `specweave sync-living-docs` regenerates internal living docs.
+`sync status` exits 1 when anything needs attention.
 
 ## Providers
 
-Read the provider from `.specweave/config.json` (`sync.github` / `sync.profiles`);
-never guess. GitHub is the first-class path. **Jira and Azure DevOps are
-community-maintained**: push and close work, nothing else is guaranteed — say so
-before promising Jira/ADO behaviour.
-
-Tokens resolve in one documented order: `.specweave/config.json` → `process.env`
-(`GITHUB_TOKEN`, then `GH_TOKEN`) → project `.env` → `gh auth token`.
-`sync status` prints which layer and which account won. A 404 on write means the
-token's account has no write access to `owner/repo` — fix the token, do not retry.
-
-Concept mapping tables: `plugins/specweave/reference/{github,jira,ado}/*-specweave-mapping.md`.
+Read the provider from `.specweave/config.json`; never guess. GitHub is first-class.
+Jira and Azure DevOps are supported and opt-in: push and close are covered, say so
+before promising more.
 
-## Bidirectional links (required both ways)
+Tokens resolve in one order: config, then `GITHUB_TOKEN` / `GH_TOKEN`, then the project
+`.env`, then `gh auth token`. `sync status` prints which one won and for which account.
+A 404 on write means that account cannot write to the repository: fix the token, do not
+retry. Check a token exists without printing it.
 
-- Local → external: the issue key lives in `metadata.json` under `externalLinks`.
-- External → local: the issue body carries the increment id and the commit sha.
+## Rules
 
-If either side is missing after a push, the link is broken — re-run
-`specweave sync push <id> --force` rather than editing the issue by hand.
+1. `--dry-run` first when an increment has never synced.
+2. Never edit the issue links in `metadata.json` by hand; a broken link is fixed with
+   `specweave sync push 0042 --force`.
+3. Report `sync status` output as it is when it shows problems; do not paraphrase token
+   or permission errors.
 
-## Rules
+## Manual path (no CLI)
 
-1. Push after tasks change, not on every edit.
-2. Never edit `externalLinks` by hand.
-3. `--dry-run` first when the increment has never synced.
-4. Report `sync status` output verbatim when it reports issues; do not paraphrase
-   token or permission errors.
+There is no manual sync. Update the issue yourself and put its URL in spec.md Problem so
+the next agent can find it.

package/plugins/specweave/skills/team/SKILL.md

@@ -1,89 +1,70 @@
 ---
-description: Run one increment with several agents in parallel - a worktree each, claims through the ledger, one closure. Use when the work has 3+ disjoint lanes, or when saying "team" or "parallel agents".
-version: 2.0.0
+description: Run one SpecWeave increment with several agents in parallel - any tool or account, a worktree each, claims through the ledger, one close. Use for "team", "parallel agents", 3+ disjoint lanes.
+argument-hint: "[increment-id]"
+version: 3.0.0
 ---
+<!-- Generated from skills/sw-team/SKILL.md by scripts/build/generate-skills.mjs. Edit the source, then npm run build. -->
 
-# Team
+# sw-team: several agents, one increment
 
-Run one increment with N agents in parallel — **any vendor, any subscription**
-(Claude Code, Codex, OpenCode, Cursor, Gemini, a human). Coordination happens
-only through committed files: `tasks.md` (definitions), `ledger.jsonl`
-(append-only state), `handoff.md`. No message bus, no shared memory; Claude
-Code's TeamCreate/Task tools are accelerators, never requirements.
+Agents can be Claude Code, Codex, Cursor, Grok, another account or a person. They
+coordinate only through committed files: spec.md (tasks), `ledger.jsonl` (claims and
+evidence) and handoffs. No message bus is needed; your tool's subagents or agent teams
+are an accelerator, never a requirement.
 
-## You are the orchestrator
+## You are the lead
 
-- You plan, split, spawn, watch, merge, close. You do **not** implement.
-- Fan out when domains ≥ 3 or tasks ≥ 15 or the user asked for parallel work; otherwise `sw:do` directly.
-- One increment, one `tasks.md`, one ledger. Do not create per-agent increments.
+You split, start, watch, merge and close. You do not implement. Fan out only with three
+or more disjoint lanes or 15+ tasks; otherwise use sw-do.
 
-## The 5 rules every agent gets (paste verbatim into each agent prompt)
+## 1. Split
 
-1. **One worktree per agent**: `git worktree add ../<id>-<agent> -b inc/<id>-<agent>` (Claude: `claude --worktree <id>-<agent>`). Branch name contains the increment id. Set `SPECWEAVE_AGENT=<agent>` (else id = `<tool>@<host>`).
-2. **Claim before edit**: `specweave task next <id>` → `specweave task claim T-NN <id>`. Edit only that task's `Files`. Need another file → claim its task or add a task.
-3. **Append only**: never edit or delete ledger lines, never edit another task's state line. On a ledger merge conflict keep every line from both sides (`.gitattributes` has `**/ledger.jsonl merge=union`).
-4. **Done needs evidence**: commit with the id in the subject, then `specweave task done T-NN <id> --run "<Test>"` (exit 0 required). Paste the output in your reply.
-5. **When stopping**: `specweave task release --all-mine` then `specweave handoff <id>`.
+1. `Files` is the ownership unit. Two tasks that touch one file cannot run in parallel:
+   merge them, or put `**Dependencies**: T-01` under the later one. Shared contracts
+   (types, schema, migrations) go in an early task the others depend on.
+2. Group tasks into lanes with disjoint `Files`: 2 to 5 lanes, one agent each.
+3. `specweave task list 0042` shows every task open. Commit spec.md.
 
-No CLI on that machine? The agent appends the JSON line itself:
-`{"t":"T-NN","e":"claim|done|release|block|skip","by":"<agent>","at":"<ISO UTC>","evidence":"<sha + test>","note":"…"}`.
+## 2. Start each agent
 
-## Phase 1 — Split (before spawning)
-
-1. Read `spec.md` once. Confirm `tasks.md` is in 2.0 form: `### T-NN Title` + `- AC: … | Files: … | Test: …`. If not, rewrite it (this is the only time tasks.md changes structure).
-2. **Files are the ownership unit.** Two tasks that touch the same file cannot run in parallel: merge them into one task or add `**Dependencies**: T-NN`. Shared contracts (types, API schemas, migrations) go into an early task that everything else depends on.
-3. Group tasks into lanes (backend / frontend / db / tests / docs …) so each lane's Files are disjoint. Lanes = agents. 2–5 agents; more rarely helps.
-4. Run `specweave task list <id>` — it must show every task `open`. Commit `tasks.md`.
-
-## Phase 2 — Spawn
-
-For each lane spawn one agent (Claude: `Task({ subagent_type: "general-purpose", … })` or a TeamCreate teammate; other vendors: a terminal in the lane's worktree with the prompt below). Prompt template:
+One worktree and branch per agent:
+`git worktree add ../0042-api -b inc/0042-api`. Then give that agent (a subagent, a
+terminal in the worktree, another tool or account) this brief:
 
-```
-You are agent <agent> on increment <id> (<title>). Worktree: <path>. Branch inc/<id>-<agent>.
-Your lane: <lane name>. Tasks you may claim: T-NN, T-MM (others belong to other lanes).
-Rules: <the 5 rules above>.
-Loop: specweave task next <id> → claim → implement inside Files → commit "<id>: …" → task done --run.
-Contract: <shared types / API / schema the lane must respect>.
-When your tasks are done or you are blocked: task release --all-mine, specweave handoff <id>, then reply with:
-  DONE: T-NN (sha, test output tail) | BLOCKED: T-MM (reason) | HANDOFF: <handoff.md path>
+```text
+You are agent "api" on increment 0042 in ../0042-api (branch inc/0042-api).
+Your tasks: T-01, T-02. Run the sw-do loop (`specweave task next 0042`, claim, ...)
+on your tasks only. Edit only their Files. Commit as "0042: ...". `task done --run`
+needs exit 0. When done or blocked: `specweave task release --all-mine`,
+`specweave note "api: <done | blocked: why>" 0042`, commit and push your branch.
 ```
 
-Agent templates for common lanes live in `agents/` (backend, frontend, database, security, testing, pm, architect, researcher, reviewer-security, brainstorm-*). `_protocol.md` is prepended automatically by `specweave team`.
+Set `SPECWEAVE_AGENT=api` in that agent's environment so its claims are distinct.
+In Claude Code, `specweave team` opens agent-team panes for the same setup.
 
-## Phase 3 — Watch (cheap)
+## 3. Watch cheaply
 
-- Poll `specweave task list <id>` (or read `ledger.jsonl`) instead of chatting. `blocked` rows are your queue: unblock (provide the secret, split the task, decide) and reply to that agent only.
-- Stale claim (older than `tasks.leaseHours`, default 2h) with no progress → the agent is gone: `task claim --force` by a replacement agent, or reassign the lane.
-- Do not re-read agents' full diffs; read their DONE lines and the ledger evidence.
+Poll `specweave task list 0042` instead of chatting. `blocked` rows are your queue:
+unblock (supply the secret, split the task, decide) and tell only that agent. A claim
+older than 2 hours with no progress is stale; a replacement agent claims it with
+`specweave task claim T-NN --force`. Agents' notes show in `specweave pickup --no-apply`.
+Lane agents do not use `specweave handoff`: it moves the one shared handoff pointer.
 
-## Phase 4 — Merge
+## 4. Merge and close
 
-1. Every agent has released + handed off. Merge lane branches into the increment branch in dependency order; ledger conflicts resolve by union (keep all lines). tasks.md conflicts: keep both agents' state lines, then `specweave task render <id>`.
-2. `specweave verify <id>` on the merged tree → `reports/verify.json`. Red → open a fix task, assign one agent, repeat.
-3. `sw:review` (optional, recommended) on the merged diff → `reports/review.md`.
-4. `specweave complete <id> --yes` (add `--reason` only if the user accepts a red verify). Only the lead closes.
-5. Remove worktrees: `git worktree remove ../<id>-<agent>`.
+1. Merge the lane branches in dependency order. `ledger.jsonl` conflicts resolve by
+   keeping every line from both sides.
+2. `specweave verify 0042` on the merged tree; red becomes a fix task for one agent.
+3. sw-review on the merged diff, then `specweave complete 0042`. Only the lead closes.
+4. `git worktree remove ../0042-api` for each lane.
 
-## Other modes (same skeleton, different lanes)
+## Manual path (no CLI)
 
-| Mode | Lanes | Merge artifact |
-|---|---|---|
-| brainstorm | advocate / critic / pragmatist (see `agents/brainstorm-*.md`) | `reports/brainstorm.md`, then `sw:increment` |
-| plan | pm (spec.md) + architect (Approach/plan.md) in parallel | reviewed spec.md before any task is claimed |
-| review | correctness / security / spec-compliance lenses (`sw:review --full` runs these) | `reports/review.md` |
-| research | one topic per agent | `reports/research-<topic>.md` |
-| test | unit / integration / e2e | `specweave verify` commands in `testing.commands` |
+Same split and brief; each agent appends its own `claim`, `done` and `release` lines to
+`ledger.jsonl` as in sw-do's manual path, plus a `note` line as in sw-handoff's.
 
 ## Anti-patterns
 
-- Agents editing files outside their task's `Files` ("I just fixed a typo there") — that is how merges break. Add a task.
-- Marking `[x]` in tasks.md by hand. The ledger wins; `task render` overwrites it.
-- Per-agent increments to avoid conflicts — you lose the single ledger and the single verify.
-- The lead implementing "just this small piece". Spawn an agent or finish the team first.
-- Closing while a claim is live. Wait for release/handoff or take it over explicitly.
-
-## Resources
-
-- `specweave task --help`, `specweave verify --help`, `specweave handoff --help`
-- [Official Documentation](https://verified-skill.com/docs/reference/skills#team)
+- An agent editing outside its tasks' `Files`. Add a task instead.
+- One increment per agent: you lose the single ledger and the single verify.
+- The lead implementing "just this small piece", or closing while a claim is live.

package/src/styles/fonts/ibmplexsans-OFL.txt

@@ -0,0 +1,93 @@
+Copyright © 2017 IBM Corp. with Reserved Font Name "Plex"
+
+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: http://scripts.sil.org/OFL
+
+
+-----------------------------------------------------------
+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.

package/src/styles/fonts/newsreader-OFL.txt

@@ -0,0 +1,93 @@
+Copyright 2020 The Newsreader Project Authors (http://github.com/productiontype/Newsreader)
+
+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:
+http://scripts.sil.org/OFL
+
+
+-----------------------------------------------------------
+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.