@miakapp/cli 4.0.0-alpha.0 → 4.0.0-alpha.10

package/assets/agent-guide.md

@@ -10,6 +10,44 @@ Everything below is true of the code in this repository. Where a rule exists for
 a reason that is not obvious, the reason is given, because a rule whose purpose
 you cannot see is one you will optimize away.
 
+## 0. What "done" means
+
+The owner asked for a home they can use, not for a picture of one. You are done
+when the household can open the published interface, read real values from it
+and use every control the owner authorized — and you checked that yourself.
+Concretely:
+
+- **Publish, then verify.** A build that only runs on your machine, a mockup, a
+  prototype kept offline or a screenshot is an intermediate result, never the
+  deliverable. Do not stop to show one and ask whether to continue: the owner
+  asked for the home, and publication is reversible in one command (§8).
+- **Hand over a link that works.** Give the owner the `home_url` that
+  `miakapp publish` and `miakapp status` print — the Miakapp address where the
+  home opens for its members — and say what you verified there. The
+  `artifact_url` (JSON `url`) is the raw bundle, not an interface: never send it
+  as "the link". If the control plane advertises no `home_url`, say so instead of
+  inventing one, and say what `miakapp status` proved.
+- **Ask once, at the start, and only for what you cannot find.** Access comes
+  from pairing (§9), the existing installation from inventory (§3). Repeated
+  permission questions in the middle of the work are a failure of the work.
+- **You need nothing from the platform's source.** This guide and the published
+  CLI — including the app starter `miakapp init --starter app` writes — are the
+  whole toolchain for the interface. Never edit or redeploy the Miakapp
+  platform to make one house work; if a capability is missing, report it to the
+  owner as missing instead of patching around it.
+
+Two scopes must not be confused:
+
+| In scope by default | Needs the owner's explicit, separate request |
+| --- | --- |
+| reading the existing installation (§3) | changing flows, automations, brokers or devices that already run the house |
+| writing and testing a coordinator and an app | granting a physical action (heat, lock, unlock, open, close) that the owner has not named |
+| publishing, verifying and rolling back the V4 interface | anything on the owner's own machines beyond the coordinator you were asked to run |
+
+Caution about the second column is not a reason to withhold the first. A new V4
+interface that only reads is still a useful, publishable V1; say plainly which
+controls are not offered and why.
+
 ## 1. What you are building
 
 Three artifacts, and no more:
@@ -17,18 +55,36 @@ Three artifacts, and no more:
 | Artifact | Where it runs | What it owns |
 | --- | --- | --- |
 | Coordinator | the owner's machine, under Bun | state, events, functions, **authorization** |
-| Component | a sandboxed Worker in the household's browser | the interface |
-| `miakapp.yaml` | neither; it is the contract | what the component may ask for |
+| Interface | an isolated frame in the household's browser | what residents see and touch |
+| `miakapp.yaml` | neither; it is the contract | what the interface may ask for |
+
+The interface is a **whole-house application** (`app:` in `miakapp.yaml`, ABI
+`miakapp.app/1`): your own HTML, CSS, layout, navigation and libraries, bundled
+into one file. Miakapp draws nothing for you, and no longer draws the old
+semantic `component:` kind at all: a home published that way shows as having no
+interface. §5 covers the app.
 
-The coordinator is trusted. The component is not. The relay between them is
+The coordinator is trusted. The interface is not. The relay between them is
 platform-untrusted but not blind: it terminates TLS, stores plaintext state and
 enforces routing, so self-hosting it does not give end-to-end confidentiality.
 Do not tell the owner otherwise.
 
-Start from `templates/home`. It is a complete working home — one lamp, one
-temperature — with the three files already in the right relationship, and its
-own `README.md` covering the mechanics of copying it out. This guide covers the
-judgment the template cannot.
+Start the interface with the starter the CLI ships, in an empty directory:
+
+```bash
+miakapp init --starter app        # home and issuer from the paired context
+bun run build && bun run check    # Bun >= 1.2.23 bundles; Node >= 22.9 runs the CLI
+```
+
+It writes `miakapp.yaml`, `app/main.ts` (the interface to edit),
+`app/miakapp.ts` (the bridge to the home, copied from this CLI release),
+`package.json`, `tsconfig.json` and `app/README.md`. It needs no source
+repository and no unpublished package, and it refuses — writing nothing — if
+any of those files already exists. As generated it shows only what the home
+shares, with an honest empty state; it is where your work starts, never what
+you publish. Without `--starter`, `init` writes `miakapp.yaml` alone.
+
+This guide covers the judgment no starter can.
 
 ### Leave the repository readable by the next agent
 
@@ -53,7 +109,7 @@ that contradicts the CLI installed beside it is worse than no guide.
 
 **The coordinator authorizes everything.** The relay proves *who* is calling and
 attaches non-spoofable caller metadata. Deciding whether that person *may* act is
-the coordinator's job and nobody else's. In the template that decision is the
+the coordinator's job and nobody else's. In a well-built coordinator that decision is the
 first line of the function body:
 
 ```ts
@@ -65,17 +121,17 @@ if (call.source.kind !== 'user' || call.source.id !== options.ownerUserId) {
 Removing that check does not produce an error anywhere. It produces a home that
 anyone enrolled can drive. There is no second layer that will catch it for you.
 
-**The component trusts nothing it was not given.** It has no network, no storage
-and no DOM. It cannot reach the lamp except through a call the coordinator
-declared, and it cannot read a state path the coordinator did not grant. This is
-why it is safe to let a component be rewritten often and reviewed lightly, and
-why it is not safe to move a decision into it.
+**The app trusts nothing it was not given.** It has no network and no storage
+shared with anyone. It cannot reach the lamp except through a call the
+coordinator declared, and it cannot read a state path the coordinator did not
+grant. This is why it is safe to let an app be rewritten often and reviewed
+lightly, and why it is not safe to move a decision into it.
 
 **You own the UI; the coordinator owns the facts.** The coordinator exposes state
 and actions. What the household actually sees — the layout, the wording, the
-language, which controls are prominent — is yours to design from the semantic
-vocabulary in §5. Do not push presentation choices into the coordinator, and do
-not push authorization into the component.
+language, which controls are prominent — is yours to design (§5). Do not push
+presentation choices into the coordinator, and do not push authorization into
+the app.
 
 ## 3. Before you write anything: characterize the house
 
@@ -94,6 +150,37 @@ Write down what you found before you write the configuration. The state paths yo
 choose become a disclosure boundary and a public interface at the same time, and
 renaming one after the household has used it is not free.
 
+### The inventory comes before the design
+
+Commit the inventory as `docs/inventory.md` in the home repository, one line per
+datum or action, before you design a single screen:
+
+| Field | Example |
+| --- | --- |
+| source | `zigbee2mqtt/salon_thermo` over the house broker |
+| what it is | temperature, °C, one decimal |
+| how fresh | reports every ~60 s; last seen 2 min ago |
+| who may read it | every member / owner only |
+| command | none — a measurement, not a control |
+
+Then design **from** it: the V1 shows every datum the household would care
+about and every action that is both technically possible and authorized,
+grouped the way people live in the house — by room or by use, not by device
+or protocol. Anything you leave out, leave out on purpose, and say why in the
+inventory. A V1 that shows three values when the house reports twenty is not a
+first version; it is an unfinished one.
+
+What the interface must never do:
+
+- **invent data.** A value with no source is shown as absent, never filled in
+  with a plausible number or a demo fixture;
+- **blur freshness.** Distinguish *current*, *stale* (with its age) and
+  *unavailable* for every value, in words a resident understands;
+- **spend space on plumbing.** No protocol or platform vocabulary
+  (`ACCEPTED`, "relay connected", ABI, schema names, IDs), no banner restating
+  that a view is read-only, no title repeating the home's name on every card.
+  Every line of text is either information or an action.
+
 ### Reading a V3 house you inherited
 
 Most houses arriving at V4 already run Node-RED with the v3 MiakAPI nodes. Ask
@@ -135,7 +222,7 @@ keyword list should make it for you.
 
 ## 4. The coordinator
 
-`templates/home/coordinator/home.ts` is the shape to copy: the configuration is a
+Keep the coordinator in the same shape: the configuration is a
 **pure function of its options**, so it can be tested without a relay, a control
 plane or a network. `coordinator/main.ts` is the only file that touches the
 outside world. Keep that split. It is what makes `test/home.test.ts` possible,
@@ -145,8 +232,8 @@ Four declarations:
 
 ```ts
 {
-  state:        { 'zone.salon.light.on': false },   // paths and initial values
-  stateAccess:  [{ userId, patterns: ['zone.salon.*'] }],
+  state:        { 'zone.living_room.light.on': false },   // paths and initial values
+  stateAccess:  [{ userId, patterns: ['zone.living_room.*'] }],
   events:       [{ topic, directions: EventDirection.publishToUsers }],
   eventAccess:  [{ userId, publish: [], subscribe: [topic] }],
   functions:    { async 'lighting.set'(call) { /* authorize, act, return */ } },
@@ -171,7 +258,7 @@ see the old value. The reverse order is a race that will reproduce once a month
 and waste a day.
 
 **Reject bad arguments with a typed application error.** `ApplicationCallError`
-carries a numeric code the component can branch on. Do not throw a bare `Error`
+carries a numeric code the app can branch on. Do not throw a bare `Error`
 for a caller mistake; the distinction between "you asked wrongly" and "something
 broke" is the one the interface needs most.
 
@@ -180,42 +267,51 @@ The relay keeps ownership tables for topics, state paths and functions, detects
 collisions and rejects with `4409`. If you claim `lighting.set` for the whole
 house, you have taken a name another integration may need; scope what you own.
 
-## 5. The component
+## 5. The interface
 
-Import from `@miakapp/component`. The whole public surface is one module, and the
-whole rendering vocabulary is `ui.*`:
+### A whole-house application (default)
 
-```
-screen  stack  grid  section          layout
-text  status  progress  media         output
-button  toggle  input  select         interaction
-```
+`miakapp init --starter app` writes an `app:` section and a buildable app to
+edit. You own the document: build any DOM, ship your own CSS, route with
+`location.hash`, use React, Svelte, Vue, charts or WebAssembly — anything a
+bundler can inline. The deliverable is **one classic-script IIFE** of at most
+2 MiB, with no `import()` and no source map; the starter's `bun run build` is:
 
-You return one complete semantic tree per render; the trusted host draws it with
-its own components. You do not ship CSS, you do not ship a DOM, and you cannot
-style your way around the host. This is a constraint worth accepting rather than
-fighting: it is what lets the host stay accessible, themed and localized without
-auditing your code.
+```bash
+bun build app/main.ts --format=iife --minify --outfile dist/app.js
+```
 
-Handlers are functions, not identifiers to wire up by hand:
+Miakapp runs it in an isolated, opaque-origin frame below a permanent Miakapp
+bar, after the resident agreed to open the home. The frame has no network, no
+cookies or storage, no popups and no fullscreen; assets go in the bundle as
+`data:`/`blob:` URLs. Its only way to the home is `window.miakapp`, through the
+bridge the starter writes as `app/miakapp.ts` — the source of the `@miakapp/app`
+SDK, which is not on npm yet, so import the local file:
 
 ```ts
-ui.toggle({
-  id: 'salon-light',
-  label: 'Lampe du salon',
-  value: asBoolean(home.state.get(LIGHT_ON)),
-  disabled: home.staging || !healthy,
-  pending,
-  onChange: (next) => void setLight(next),
-})
+import { callErrorCode, connect } from './miakapp.js';
+
+const home = connect();
+home.subscribe((state) => render(state));        // also called once immediately
+await home.call('lighting.set', { on: true });   // rejects with a closed code
 ```
 
-Handlers are registered for the render that created them, so a stale tree cannot
-fire an action against new state.
+Do not edit the bridge; a newer CLI's starter carries any change to it.
+
+**Make it beautiful from the first build.** Run `miakapp docs design` before you
+draw anything: Miakapp ships design tokens, four themes (Minuit, Lumière, Miel,
+Craie), CSS recipes, an embedded font and example screens. The starter's
+`app/theme.ts` already uses them. They are a starting point you may change
+entirely; the Miakapp bar outside your frame is not yours to redraw.
 
-The limits are real and enforced: 1 024 nodes, depth 32, 30 renders per second,
-32 outstanding calls, 8 KiB per text node. If you are approaching any of them you
-are building a dashboard the household will not read.
+Declare every state path (exact or `prefix.*`) under `app.requires.state_read`
+and every function under `app.requires.call`. Events, media and `miakapp.*`
+functions are refused by `miakapp check`. Show `state.stale`, disable controls
+while it is true, and handle `outcome_unknown` exactly as below.
+
+**The bundle is not private.** Any signed-in user who learns its digest can
+fetch it. Put no household data in it — no names, rooms, devices or accounts —
+and read everything from state, which the coordinator filters per resident.
 
 ### Two states the interface must never hide
 
@@ -224,7 +320,7 @@ house. Show it. Per RFC 0002 §12.2 it is exposed, never hidden — a thermostat
 reading that is silently forty minutes old is worse than one labelled uncertain.
 
 **Staging.** `home.staging` is true while a release is staged: rendering works,
-calls and events do not. Disable the controls and say why, as the template does.
+calls and events do not. Disable the controls and say why.
 An interface that looks live and silently does nothing is the worst outcome
 available.
 
@@ -238,7 +334,7 @@ try {
 } catch (error) {
   // Deliberately not retried. The call may already have reached the lamp,
   // and the next state snapshot settles the question.
-  failure = error instanceof Error ? error.message : 'La commande a échoué';
+  failure = error instanceof Error ? error.message : 'The command failed';
 }
 ```
 
@@ -250,7 +346,7 @@ code 7.
 
 ## 6. The intersection rule
 
-Every name a component may touch appears in **two** places, and the effective
+Every name an app may touch appears in **two** places, and the effective
 grant is the intersection:
 
 | `miakapp.yaml` → `requires` | `coordinator/home.ts` |
@@ -261,14 +357,13 @@ grant is the intersection:
 | `call` | `functions` |
 
 Asking for more than the coordinator grants **does not fail loudly at
-publication**. The component simply never receives that path, and the interface
+publication**. The app simply never receives that path, and the interface
 renders a hole — an empty card, a control that does nothing, a temperature that
 is permanently unavailable. This is the single most common way a Miakapp home
 breaks, and it breaks quietly.
 
-So: assert the correspondence in a test. `templates/home/test/home.test.ts` does
-exactly this, and it is the reason a mismatch fails in CI rather than in
-someone's living room. When you add a path, change four things in one commit —
+So: assert the correspondence in a test, so a mismatch fails in CI rather than
+in someone's living room. When you add a path, change four things in one commit —
 the state declaration, the access pattern, the `requires` entry, and the test.
 
 ## 7. The loop
@@ -281,8 +376,8 @@ Run it before every publication and in CI. It costs nothing and catches the
 artifact rules the runtime would reject anyway.
 
 Do not treat a check that exists as a check that runs. On 2026-09-14 this
-repository had a template and a component example that were both verified
-locally and built by nobody, because the workflow called `bun run check` and not
+repository had two example packages that were both verified locally and built
+by nobody, because the workflow called `bun run check` and not
 `check:packages`; when CI finally exercised them they failed three times in a
 row on defects that had been sitting there invisibly. If you add a package, add
 it to the job that runs in CI, then watch one run go green before believing it.
@@ -305,25 +400,35 @@ writes no history, rewrites no source it did not generate, and invents no
 control-plane endpoint. The repository is the owner's.
 
 ```bash
-miakapp agent-pack                                             # once, per repository
-miakapp init --home <homeId> --control-plane <https url>
+miakapp docs start                             # this guide, from the installed CLI
+miakapp pair                                   # once per home and machine (§9)
+miakapp agent-pack                             # once, per repository
+miakapp init --starter app                     # manifest + buildable app; plain init writes the manifest only
 miakapp check
-miakapp publish  --expected-generation <n>
-miakapp activate --sha256 <digest> --expected-generation <n>
-miakapp rollback --sha256 <digest> --expected-generation <n>   # alias of activate
+miakapp status                                 # what is live now: generation, release, digest
+miakapp publish                                # upload, finalize, activate
+miakapp status                                 # verify the new digest is what is live
+miakapp activate --sha256 <digest>             # promote an already finalized digest
+miakapp rollback --sha256 <digest>             # alias of activate
 miakapp release <sha256>      # read one finalized release
 miakapp upload  <uploadId>    # reconcile a lost request
 ```
 
-`--expected-generation` is a compare-and-swap on the home's component pointer: the
-generation you believe it currently holds. It is `0` for a home that has never
-published. It is required, and it is what stops two agents from silently
-overwriting each other.
+Activation is a compare-and-set on the home's component pointer. Without
+`--expected-generation` the CLI reads the live generation first and activates
+the next one; the read takes no lock, so another publication landing in between
+still fails with `conflict` instead of being overwritten. Pass
+`--expected-generation <n>` when you want to assert the state you reviewed.
 
 Rollback is `activate` pointed at a digest you already trust. Keep the digest of
 every release you shipped; a rollback you can perform in one command is worth
 more than an incident you can explain.
 
+`miakapp status` after `publish` is the minimum verification: the live `sha256`
+must be the one you just built. It proves what the home runs, not that the
+interface is right — open its `home_url` as a member would before telling the
+owner it works.
+
 ### Driving the CLI as a program
 
 Every failure maps to exactly one stable exit code and one stable
@@ -366,22 +471,68 @@ Three differences are worth knowing before you call anything:
 `packages/cli/README.md` lists the tools. The exit codes above are the
 `exit_code` field in every result, so branch on the same table either way.
 
-## 9. Secrets
+## 9. Access: pairing and contexts
+
+You never sign in as the owner and never ask for a password, a Google login or
+an existing key. The owner grants access to one home, in their own browser:
+
+1. Ask the owner to open **https://miakapp.com/pair**, sign in to their own
+   account, choose the home (or create it), confirm the access it grants, and
+   send you the one-time code it shows. A code works once, for ten minutes.
+2. Redeem it. The code is read from stdin and never echoed:
 
-`MIAKAPP_HOME_KEY` comes from the environment. It is never a command-line
-argument, never printed, never written into a project file. No command accepts
-one, deliberately: an argument lands in shell history, in a process listing and
-in most CI logs.
+   ```bash
+   printf '%s\n' "<code>" | miakapp pair            # add --issuer <url> if the page shows one
+   ```
+
+   Over MCP, call `miakapp_pair` with `code`. Never repeat the code back in a
+   message, and never retry a refused code — ask for a new one.
+3. `pair` stores a **new, separately revocable** Home Key for this machine as a
+   context in `~/.miakapp`, keeps every other context, makes the new one
+   current, and proves the key can publish. It prints the key ID and label,
+   never the key.
 
 ```bash
-export MIAKAPP_HOME_KEY="$(your-secret-manager read miakapp/home-key)"
+miakapp context list          # every home this machine can publish to
+miakapp context show [name]   # one context; the key is never printed
+miakapp context use <name>    # make a context current
+miakapp context remove <name> # delete it locally (the owner revokes it server-side)
 ```
 
-If you are about to write a secret into `miakapp.yaml` so something works, stop:
-that is the failure this design exists to prevent.
+`~/.miakapp/config.json` holds names, homes, issuers and key IDs;
+`credentials.json` holds the keys. Both are mode 0600 in a 0700 directory and
+are replaced atomically; the CLI refuses a credentials file other accounts can
+read. `MIAKAPP_CONFIG_DIR` relocates the directory.
+
+Which key a command uses, highest precedence first:
+
+1. `--context <name>`, then `MIAKAPP_CONTEXT=<name>`;
+2. `MIAKAPP_HOME_KEY`, a raw key for CI and compatibility;
+3. the stored context paired with the home and issuer in `miakapp.yaml` — the
+   current context breaks a tie between two keys for that same home.
+
+A context, or a known key, for a different home than `miakapp.yaml` names is
+refused before any request: a key can never publish into the wrong house.
+
+Prefer one key per agent or machine, so the owner can revoke one without
+breaking the others. A coordinator running on the owner's machine still reads
+its own key from its environment.
+
+If you are about to write a secret into `miakapp.yaml` or any file in the
+repository so something works, stop: that is the failure this design exists to
+prevent.
 
 ## 10. Before you tell the owner you are done
 
+- [ ] `docs/inventory.md` lists every source, datum and action you found, and
+      the interface covers it or says why not.
+- [ ] Every value shows whether it is current, stale or unavailable; nothing is
+      invented, and no technical vocabulary is on screen.
+- [ ] The interface is published, `miakapp status` shows your digest live, and
+      you opened it as a member would — or you say precisely what you could not
+      check.
+- [ ] The owner received a working link and the rollback digest, not a
+      screenshot or a mockup.
 - [ ] Every physically consequential function authorizes its caller on its first
       line, and a test proves an unauthorized caller is refused.
 - [ ] Every name in `miakapp.yaml` is covered by the coordinator, and a test
@@ -390,19 +541,21 @@ that is the failure this design exists to prevent.
 - [ ] No call path retries an unknown outcome.
 - [ ] State is written before its event is published.
 - [ ] `bun run check` is green, and CI ran it — not just you.
-- [ ] The Home Key exists only in the environment.
+- [ ] The Home Key exists only in `~/.miakapp` or the environment, never in the
+      repository.
 - [ ] You recorded the digest of what you published, so rollback is one command.
 
 ## Where to read further
 
+Everything a home needs is above and in the CLI with its starter. The RFCs and
+platform paths below explain *why* the platform behaves as it does; you never
+need them, or the platform repository, to build and publish a home.
+
 - `packages/cli/README.md` — every command and every tool, including what the
   pack writes and what it refuses to overwrite.
-- `templates/home/README.md` — the mechanics of the template itself.
 - `docs/rfcs/0001` (Miakapp-V3) — wire protocol: ownership, collisions, `4409`.
-- `docs/rfcs/0002` — component runtime and the staleness rule. **The broker is
-  the authority for the guest ABI, not the RFC**: `component-runtime/src/runtime-broker.ts`
-  and `contract.ts` define the exact payloads, and the broker terminates the
-  instance rather than answering when a field is wrong.
+- `docs/rfcs/0002` — release pointer, capabilities and the staleness rule;
+  `docs/specs/2026-10-03-house-app-abi.md` — the app frame and its bridge.
 - `docs/rfcs/0003` — the coordinator SDK surface.
 - `docs/rfcs/0004` — Home Key bootstrap, scopes, publication.
 - `docs/rfcs/0005` — the trusted browser client.

package/assets/design/OFL-Manrope.txt

@@ -0,0 +1,93 @@
+Copyright 2019 The Manrope Project Authors (https://github.com/sharanda/manrope)
+
+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.