@olegkoval/agent-skills 1.34.0 → 1.35.0

package/packages/software-development/wikipedia-uk-editor/adapters/windsurf/rules/wikipedia-uk-editor.md

@@ -1,125 +0,0 @@
-<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
-
----
-description: "Draft policy-compliant Ukrainian Wikipedia edits — translate an English article into uk, expand or source an existing uk article, or fix a maintenance backlog item — and return ready-to-paste wikitext plus an edit summary."
----
-
-# Ukrainian Wikipedia Editor
-
-Turn a URL or article title into a complete, policy-compliant Ukrainian Wikipedia edit that the human pastes into the wiki editor themselves.
-
-## Hard Rules
-
-1. **Never submit an edit.** No `action=edit`, no logged-in browser automation, no bot password. This skill only reads and drafts. The human pastes and saves. Automated saving without a ВП:БОТ approval risks a block.
-2. **Never invent a source, a date, a number, or a citation.** Every fact added must trace to a source that was actually fetched in this session. If it cannot be sourced, it does not go in the article.
-3. **Never copy-paste prose from a source.** Ukrainian Wikipedia deletes copyright violations (ВП:Авторські права) on sight. Paraphrase in Ukrainian and cite.
-4. **Never translate machine-literally.** A rough MT dump is a deletion candidate. Ukrainian syntax, Ukrainian transliteration of names, Ukrainian date format (`12 березня 2024`), decimal comma.
-5. **Use only template and policy names verified against the live wiki.** See `references/wikitext-uk.md`. If a template is not listed there, verify it exists before using it — the helper script has a `check` command.
-6. **Disclose AI assistance** on the user page and, when substantial, in the edit summary. Undisclosed LLM output is the fastest route to scrutiny.
-
-## Outcome
-
-A single deliverable written to a scratch file and echoed in chat:
-
-- the **target page** (exact ukwiki title, and whether it exists)
-- the **wikitext** — always the complete final article in one `.wiki` file, ready to paste over the whole edit box; never a diff, never a БУЛО/СТАЛО list of manual replacements
-- the **edit summary** in Ukrainian (≤ 200 chars)
-- the **source list** with the URL, publisher, and date actually fetched for each
-- **risk notes**: notability (ВП:ЗН) standing, anything a patroller will challenge, what still needs a human check
-
-## Workflow
-
-### 1. Classify the task
-
-| Input | Mode |
-|---|---|
-| explicit newcomer task (tier + type, e.g. "Середні → Оновлювати статті") | mode set by task type — see below |
-| en.wikipedia.org URL, no uk equivalent | **Translate** — new uk article |
-| uk.wikipedia.org URL, stub or thin | **Expand** |
-| uk.wikipedia.org URL with `{{Без джерел}}` / `{{Джерело}}` | **Source** |
-| uk.wikipedia.org URL, prose/format problems | **Cleanup** |
-| "what should I edit next" | **Plan** — read `references/strategy.md`, propose a ranked list |
-
-When a newcomer task type is given, it **overrides** the state-based guess above. The per-type scope contract in `references/newcomer-tasks.md` is binding — an assigned type is a ceiling on what the edit may touch, not a floor.
-
-Resolve the title first — `scripts/wiki.sh` handles redirects. Never draft against the wrong title.
-
-### 2. Read before writing
-
-```sh
-./scripts/wiki.sh get uk "Тайтл"          # current wikitext
-./scripts/wiki.sh get en "Title"          # source-language wikitext
-./scripts/wiki.sh langlink en "Title" uk  # does a uk version already exist?
-./scripts/wiki.sh check uk "Шаблон:Особа" # does this template/page exist?
-./scripts/wiki.sh tasks <type> [n]        # list candidates for a newcomer task type: copyedit|links|references|update|expand
-```
-
-Stop and report if:
-- a uk article already exists for a "new translation" (then it is an **Expand** task, not a new page)
-- the subject fails ВП:ЗН — do not draft an article that will be deleted; say so and propose an alternative target
-
-### 3. Gather real sources
-
-For **Translate**: the English article's own reference list is a source *lead*, not a source. Fetch each reference actually cited for the claims you keep. Drop claims whose sources are dead or paywalled beyond verification. Prefer Ukrainian-language sources where they exist — patrollers weigh them higher.
-
-For **Source/Expand**: search for the specific unsourced claim, not the topic in general. Reject blogs, press releases, user-generated wikis, and the subject's own site for anything contested (ВП:АД).
-
-Record for each source: URL, title, publisher, publication date, access date. These become `{{Cite web}}` / `{{Стаття}}` / `{{Книга}}` parameters — see `references/wikitext-uk.md`.
-
-### 4. Draft the wikitext
-
-Follow `references/wikitext-uk.md` for structure, citation templates, infoboxes, section names, categories, and the `{{Перекладена стаття}}` attribution template that translations legally require.
-
-Scale to the subject: a person gets ~4–8 sourced sentences minimum, not two. Under that, it is a stub — label it `{{Заготовка}}` honestly rather than pretending it is complete.
-
-### 5. Self-check before delivering
-
-Run every item. Report failures rather than hiding them.
-
-- [ ] Every non-obvious factual claim has an inline `<ref>`
-- [ ] No sentence is a translated copy of a copyrighted source
-- [ ] Every template used exists (checked, not assumed)
-- [ ] `{{Перекладена стаття}}` present with the source revision id, if translated
-- [ ] Categories present and non-empty; at least one is a real existing category
-- [ ] Interwiki handled via Wikidata note, not hardcoded links
-- [ ] Neutral tone (ВП:НТЗ) — no promotional adjectives, no unattributed evaluation
-- [ ] No original synthesis (ВП:ОД)
-- [ ] Dates, numbers, and name transliterations are Ukrainian-correct
-- [ ] Edit summary written in Ukrainian and states what changed and why
-- [ ] The edit stayed inside the assigned task type's allowed scope
-- [ ] Any maintenance template removed was actually earned — the underlying problem is genuinely fixed
-
-### 6. Deliver
-
-For Expand / Source / Cleanup: fetch the current wikitext, apply the changes programmatically (a small Python pass over the fetched file, asserting each anchor string matched exactly once), and write the whole resulting article out. Verify it before delivering — section list intact, every intended change landed, nothing else dropped.
-
-Write the draft to a scratch file: the raw `.wiki` file contains nothing but article wikitext (the full final article, ready to paste over the whole edit box); the human-readable explanation of what changed goes in a separate `.md`. Print the edit summary, and tell the human exactly where to paste it:
-
-- new article → `https://uk.wikipedia.org/wiki/Тайтл?action=edit`
-- existing article → `https://uk.wikipedia.org/w/index.php?title=Тайтл&action=edit`, replace the whole edit box
-- test first → `Вікіпедія:Пісочниця` or the user's own `Користувач:Ім'я/Чернетка`
-
-End the delivery with a copy-to-clipboard command in its own fenced block, using a quoted absolute path — quoted because scratchpad paths contain characters the shell will otherwise mangle — always the raw `.wiki` file, never the `.md`:
-
-```sh
-pbcopy < "/absolute/path/to/slug.wiki"
-```
-
-Add an optional second line when the edit summary is long enough to be worth copying:
-
-```sh
-printf '%s' 'Опис редагування…' | pbcopy
-```
-
-Then stop. Do not offer to save it.
-
-## References
-
-- `references/strategy.md` — the contribution strategy: what to farm, in what order, and how to build standing without getting flagged
-- `references/wikitext-uk.md` — verified uk templates, citation formats, article skeletons, policy shortcuts
-- `references/newcomer-tasks.md` — the newcomer task tiers (Легкі/Середні/Важкі) and the binding scope contract for each task type
-- `scripts/wiki.sh` — read-only MediaWiki API helper
-
-## Verification
-
-The skill has done its job when the human can paste the output unchanged, and the resulting edit survives patrolling with no maintenance template added.

package/packages/software-development/wrap-up/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-wrap-up",
-  "description": "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches.",
-  "skills": "./skills"
-}

package/packages/software-development/wrap-up/adapters/codex/README.md

@@ -1,17 +0,0 @@
-# Codex Adapter for wrap-up
-
-This is the Codex-specific adapter for the `olko:wrap-up` skill. The canonical workflow is in
-`../../SKILL.md`.
-
-## Usage
-
-Invoke it manually or after a completed task:
-
-```text
-Use the olko:wrap-up skill to verify the completed task, clean task-owned artifacts, and report the delivery receipt.
-```
-
-For Codex, keep the receipt fields required by the agent operating contract and treat local correctness,
-remote state, PR state, CI, deployment, and human/device QA as separate gates. Use `git worktree list`
-before removing worktrees, preserve unrelated dirty files, and never claim completion from a local green
-check alone.

package/packages/software-development/wrap-up/adapters/cursor/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:wrap-up",
-  "version": "0.1.0",
-  "description": "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches.",
-  "skills": "skills/"
-}

package/packages/software-development/wrap-up/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:wrap-up",
-  "version": "0.1.0",
-  "description": "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches.",
-  "skills": "skills/"
-}

package/packages/software-development/wrap-up/adapters/kiro/steering/wrap-up.md

@@ -1,77 +0,0 @@
-<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
-
----
-inclusion: manual
-description: "Verify a completed task against its original objective, confirm applicable checks, and safely tidy task-owned artifacts, worktrees, and local branches."
----
-
-# Wrap Up
-
-Run this skill manually from time to time or as the final step after a task reaches its goal. It is a delivery audit and cleanup pass, not permission to expand scope or hide unfinished work.
-
-## 1. Reconstruct the task
-
-- Read the original request, acceptance criteria, task plan, and final diff.
-- Write a short objective statement and an acceptance matrix: each requested outcome, its evidence, and its status.
-- Compare the result with the original idea, not merely with the implementation plan. Mark anything ambiguous or unverified as `UNKNOWN` rather than assuming it is complete.
-- Identify the exact repositories, worktrees, branches, files, services, and temporary paths owned by this task. Preserve pre-existing user work.
-
-## 2. Verify the implementation
-
-- Inspect the final diff and confirm every requested behavior is implemented.
-- Check related tests, types, docs, configuration, migrations, and feature flags where the change requires them.
-- Run the repository-defined checks appropriate to the change. Follow local instructions and use the project’s package scripts rather than bypassing its tooling.
-- Prefer the smallest meaningful verification first, then the full applicable suite. Record exact commands and results.
-- If a check fails, determine whether it is caused by this task. Do not call the task green because an unrelated check happened to pass.
-- For user-facing behavior, require real browser/device or human evidence when that is part of acceptance; automated tests alone are not visual acceptance.
-
-## 3. Verify delivery state
-
-Keep these gates separate and evidence-backed:
-
-- Local worktree: branch, `HEAD`, tracked changes, and untracked files.
-- Remote: tracking branch and remote SHA, verified with Git or the existing provider CLI.
-- PR: current title/body, merge state, review threads, and required checks, when applicable.
-- CI: current-head status, not an old successful run.
-- Deployment: actual deployed version or endpoint health, when applicable.
-- Device or human QA: real acceptance evidence, when applicable.
-
-Do not claim remote, PR, CI, deployment, or QA completion from a local test or commit alone. Do not push, merge, deploy, or delete a remote branch as a side effect of this skill unless the task explicitly authorized it.
-
-## 4. Clean task-owned artifacts
-
-Clean only paths created by this task or explicitly named for cleanup.
-
-- Remove known temporary files, test output, logs, copied fixtures, and scratch directories after capturing any required evidence.
-- Never recursively delete a broad directory, the workspace root, an unresolved glob, or an unknown untracked file.
-- For dirty paths that predate this task or cannot be attributed confidently, leave them in place and report them.
-- Check the repository’s worktree list and remove only task-owned worktrees that are clean and no longer needed. Use an exact path; never remove a worktree containing uncommitted user work.
-
-## 5. Clean local branches safely
-
-- Confirm the task branch has the intended commit and that the remote branch contains the same work when remote delivery was required.
-- If the remote branch is merged, verify the merge state before deleting the local branch.
-- If the remote branch is pushed but unmerged, treat it as the recovery point. Delete the local branch only when the task is delivered, the remote branch is confirmed intact, the worktree is clean, and the user’s workflow permits local deletion. Otherwise preserve it and report why.
-- Never use force branch deletion or destructive checkout/reset commands unless the user explicitly requests that exact recovery operation.
-- Before deleting a branch, verify it is not checked out by another worktree and that no unique local commits would be lost.
-
-## 6. Report the result
-
-Lead with the outcome. Include concise evidence, cleanup performed, items intentionally preserved, and the smallest next action for any blocker. Always finish with this receipt, using `NOT_APPLICABLE` for out-of-scope gates and `NOT_RUN` for applicable checks that were not executed:
-
-```text
-OBJECTIVE:
-CHANGED:
-NOT_CHANGED:
-TESTS:
-BUILD:
-REMOTE:
-PR:
-CI:
-DEPLOYMENT:
-DEVICE_OR_HUMAN_QA:
-KNOWN_LIMITATIONS:
-FINAL_STATUS:
-```
-
-`FINAL_STATUS` must be exactly one of `DELIVERED`, `BLOCKED`, or `INTENTIONALLY_UNCHANGED`. Use `BLOCKED` when required evidence or cleanup cannot safely be completed; name the blocker and next action. Never promote a partial result to `DELIVERED`.

package/packages/wearables/garmin-watchface/adapters/claude/plugin.json

@@ -1,5 +0,0 @@
-{
-  "name": "olko-garmin-watchface",
-  "description": "Design, build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C.",
-  "skills": "./skills"
-}

package/packages/wearables/garmin-watchface/adapters/codex/README.md

@@ -1,3 +0,0 @@
-# Codex adapter
-
-Use the canonical skill directly from `packages/wearables/garmin-watchface/SKILL.md`.

package/packages/wearables/garmin-watchface/adapters/cursor/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:garmin-watchface",
-  "version": "0.1.0",
-  "description": "Design, build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C.",
-  "skills": "skills/"
-}

package/packages/wearables/garmin-watchface/adapters/grok/plugin.json

@@ -1,6 +0,0 @@
-{
-  "name": "olko:garmin-watchface",
-  "version": "0.1.0",
-  "description": "Design, build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C.",
-  "skills": "skills/"
-}

package/packages/wearables/garmin-watchface/adapters/kiro/steering/garmin-watchface.md

@@ -1,260 +0,0 @@
-<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
-
----
-inclusion: manual
-description: "Design, build, test, screenshot and publish Garmin Connect IQ watch faces in Monkey C."
----
-
-# Garmin Connect IQ watch faces
-
-Monkey C gives you almost no safety net. The compiler is happy to build a face
-that draws off the bottom of the screen, a test suite that contains no tests, and
-a colour that is not the colour you get. Everything below is a failure mode that
-looked like success first.
-
-**Read `reference/` files as needed — do not read them all up front.**
-
-| File | When |
-| --- | --- |
-| `reference/display.md` | Choosing colours, brightness, legibility; **AMOLED always-on and burn-in** |
-| `reference/layout.md` | Positioning anything; content clipped, overlapping, or off-screen |
-| `reference/testing.md` | Writing tests; a suspiciously clean test run |
-| `reference/simulator.md` | Screenshots, settings not applying, monkeydo hanging |
-| `reference/devices.md` | Adding device support, launcher icons, API levels |
-| `reference/store.md` | Publishing, listing copy, IP questions |
-| `reference/publishing.md` | Driving the store portal in a browser; upload/update flow, validator rejections |
-
-## Tools
-
-Run these rather than reinventing them. All are standalone.
-
-```bash
-bin/ciq-doctor                    # toolchain check: SDK, JDK, key, devices
-bin/ciq-devices                   # survey installed devices by resolution
-bin/ciq-devices --same-as fenix6pro   # products you can add with no code change
-bin/ciq-capture out.png           # calibrated simulator screenshot
-bin/ciq-capture out.png --face --size 260   # cropped + masked to the round display
-bin/ciq-calibrate                 # re-derive the display rect if capture looks wrong
-bin/ciq-release                   # pre-submission check: package, screenshots, icon, keys, copy
-```
-
-`bin/ciq-release` is what you run before opening the store portal. Every check
-in it is something otherwise discovered halfway through the submission form --
-a stale screenshot set, an icon still copied from the last project, or copy
-containing a character the description validator rejects.
-
-`bin/ciq-capture` exists because `screencapture -R` grabs a screen *region*, not
-a window: without a frontmost check it silently photographs whatever is on top,
-and the window moves between simulator restarts. Both failure modes produce a
-plausible PNG of the wrong thing.
-
-## The seven things that will bite you
-
-### 1. `make test` can compile zero tests and report success
-
-If `monkey.jungle` sets `base.excludeAnnotations = test`, every `(:test)`
-function is stripped from **every** target, including the unit-test build. You
-get `BUILD SUCCESSFUL` and a green run with nothing compiled — even when the test
-files reference symbols that no longer exist.
-
-Fix: a second jungle passed as an additional `-f`. See
-`templates/monkey.test.jungle` and the `test` target in `templates/Makefile`.
-
-**Prove it before you trust it.** Put a deliberately unresolvable symbol in one
-test and confirm the build fails:
-
-```monkeyc
-return ThisDoesNotExist.definitelyNotAFunction();
-```
-
-### 2. Never hardcode a Y coordinate or assume a font height
-
-`dc.getFontHeight()` is the only source of truth, and the numbers are larger than
-they look. Measured on fenix 6 Pro:
-
-| Font | Height |
-| --- | --- |
-| `FONT_XTINY` | 19 |
-| `FONT_TINY` | 29 |
-| `FONT_SMALL` | 32 |
-| `FONT_NUMBER_MEDIUM` | 74 |
-
-**Font tiers already scale with the device.** `FONT_XTINY` is a tier, not a
-pixel height: a 454px watch supplies a proportionately taller glyph than a
-260px one, unasked. So when text looks wrong at a new resolution, the bug is a
-LENGTH that failed to scale, never the font. Do not add screen-size branching
-to pick a bigger tier -- doing so double-scales, and labels end up wider than
-the containers naming them.
-
-Content drawn past the screen height is simply invisible — no error, no warning,
-no clipping indicator. A two-line `FONT_NUMBER_MEDIUM` block is 148px of a 260px
-face.
-
-Derive every Y at draw time, and **clamp** so a bottom row cannot be pushed off:
-
-```monkeyc
-function clampRuleY(derived as Number, footerH as Number) as Number {
-    var reserved = (footerH * 2) + GAP_BELOW_RULE + GAP_BETWEEN_ROWS;
-    var maxRuleY = SCREEN - BOTTOM_MARGIN - reserved;
-    return derived > maxRuleY ? maxRuleY : derived;
-}
-```
-
-See `reference/layout.md`.
-
-### 3. The screen is round; your layout is not
-
-Check content against the bezel curve, not the bounding square. A rectangle
-inscribed in a circle fails at its **corners** long before its sides.
-
-```monkeyc
-function halfWidthAt(y as Number) as Number {
-    var dy = y - CENTER;
-    var inside = (CENTER * CENTER) - (dy * dy);
-    return inside <= 0 ? 0 : Math.sqrt(inside).toNumber();
-}
-```
-
-### 4. Colours are quantised, and brightness is reflectance
-
-Many devices snap to a 4×4×4 lattice: `0x00 / 0x55 / 0xAA / 0xFF` per channel. A
-colour not already on it is not the colour that ships.
-
-More important: MIP screens are **transflective with no backlight**. A colour's
-brightness *is* how much ambient light it returns. Grey reflects about two-thirds
-of what white does. Choosing a photographically accurate grey for a large area
-makes the whole face read as dim on the wrist while looking fine in the
-simulator's backlit LCD.
-
-Corollary: a saturated colour on a glyph reflects only its own channel, making
-the thing you want to read the *dimmest* thing on screen.
-
-See `reference/display.md`.
-
-### 5. The simulator lies about settings
-
-It persists app settings and **ignores changed defaults in `properties.xml`**
-until you do File → Reset All App Data. A property will keep reading its old
-value while the XML plainly says otherwise. This looks exactly like broken
-settings code.
-
-Reset also drops the loaded device, so relaunch and re-push afterwards.
-
-See `reference/simulator.md`.
-
-### 6. On AMOLED, the face you designed is the one that fails review
-
-`requiresBurnInProtection` devices must show a restricted always-on frame
-between wrist raises. The trap is that the *stronger* your face's identity —
-a bright panel, a filled dial — the worse a dimmed version of it performs,
-because it still lights most of the screen. The always-on frame has to be a
-different drawing: outlines where there were fills, and shifted a few pixels on
-a cycle so no pixel is driven continuously.
-
-Also note the flag can be **null** on older products, and a null propagating
-into a `Boolean` field throws at the first wrist drop.
-
-See the AMOLED section of `reference/display.md`.
-
-### 7. A watch face CAN have settings on the watch
-
-`AppBase.getSettingsView()` has existed since **API 3.2.0** and the SDK
-documents it as "only applicable to watch faces and data fields". Plenty of
-store copy — including, at one point, this author's own — claims settings are
-reachable only from the phone. They are not.
-
-The override signature must include `or Null` or the compiler rejects it as
-narrowing:
-
-```monkeyc
-function getSettingsView() as
-    [WatchUi.Views] or [WatchUi.Views, WatchUi.InputDelegates] or Null {
-    return [new SettingsMenu(), new SettingsMenuDelegate()];
-}
-```
-
-Two things to get right in the menu itself:
-
-- `ToggleMenuItem` has **already flipped its own state** by the time `onSelect`
-  runs. Read `isEnabled()`; negating the stored value inverts the setting.
-- A picker should `setFocus()` the current choice, not open at the top of a long
-  list. If the list filters out unavailable options, item position is *not* the
-  option id — count the focus row as you build the list.
-
-Keep one module that owns every property read, each wrapped with a default, and
-have both the phone path and the on-watch menu go through it. Two readers with
-two sets of defaults is exactly how the watch and the phone come to disagree
-about what "off" means — and check the fallbacks actually match
-`properties.xml`, because nothing enforces that.
-
-## Workflow
-
-### Starting a face
-
-1. `bin/ciq-doctor` — confirm SDK, JDK, developer key, target device installed.
-2. Copy `templates/Makefile`, `templates/monkey.jungle`, `templates/monkey.test.jungle`.
-3. Generate a fresh app id: `python3 -c "import uuid;print(uuid.uuid4().hex)"`.
-4. Split source by responsibility. This structure has held up well:
-
-| Module | Holds |
-| --- | --- |
-| `Palette.mc` | Colours only, all lattice-exact |
-| `Layout.mc` | Geometry, derivations, bezel maths — no drawing |
-| `<Widget>.mc` | Drawing primitives (rows, bars, segments) |
-| `Fields.mc` | Formatting and thresholds — pure, easy to test |
-| `Sensors.mc` | Sensor reads with null handling |
-| `<Name>View.mc` | Composition only |
-
-Keeping `Layout` free of `Dc` calls is what makes geometry unit-testable.
-
-### Every change
-
-```bash
-make build && make test && make lint
-```
-
-`make lint` is level 3 and catches real problems the level 2 build allows.
-
-### Before committing
-
-Capture and *look at it*. Layout bugs are invisible in a passing test run:
-
-```bash
-make build && make sim
-bin/ciq-capture /tmp/face.png --face --size 260
-```
-
-Then Read the PNG. Every layout bug in this skill's history was found by looking,
-not by testing.
-
-## Monkey C gotchas
-
-- Module-level functions take **no** visibility modifier. `private` and `hidden`
-  are class-only; at module scope they are syntax errors.
-- `dc.fillPolygon` wants `Array<[Numeric, Numeric]>`. Cast the literal:
-  `[[x, y], ...] as Array<[Numeric, Numeric]>`.
-- `getInitialView()` returns
-  `[WatchUi.Views] or [WatchUi.Views, WatchUi.InputDelegates]`.
-- `Application.Properties.getValue()` **throws** when a key is absent, which
-  happens on a fresh install before settings have ever been written. Wrap every
-  read with a default.
-- Integer division everywhere. Centring an odd width leaves a 1px skew — write
-  tests that allow it rather than forcing constants to stay even.
-
-## Reference watches and homages
-
-If reproducing a real object, get these right before anything else, because they
-are what makes it recognisable:
-
-- **Display polarity.** A 1970s LCD is *positive*: dark segments on a pale panel,
-  the inverse of every modern face. Getting this backwards turns a crystal into a
-  screen.
-- **Proportion.** Bezels on vintage digitals are thick; the window is smaller
-  than memory suggests.
-- **Where the legends sit** — maker's name on the bezel, not the glass.
-
-No system font is a segment display. If you need one, draw it: see
-`reference/layout.md` for a working seven-segment renderer, including the ghost
-(unlit) segments that are most of what sells the effect.
-
-**Do not print a real brand on the face.** See `reference/store.md`.