Files

T

smoidoandClaude Opus 5 b514e00745 README down to what a user needs; the rest into docs/

The README had grown to 1,010 lines of user docs and design notes in one file,
and had gone stale: it still showed the old numbered menu, set up only three
providers, and listed preflight checks and a file layout that predate the last
three releases. It now carries install, first run, the full command
reference, the providers at a glance, troubleshooting and a docs index.

docs/:
- providers.md    presets, defaults, the model cache, context windows, each
                  provider (OpenRouter's cost guard and guardrail check are
                  written up for the first time), adding a provider
- live-sessions.md  what a switch does to running sessions, and repair
- design.md       why settings.json, why keys stay out of it (and the vault
                  per platform), the preflight checks as they are now
- bar-widget.md   the widget as it is now: providers from health.json, every
                  server provider's settings, the restart after an upgrade
- architecture.md the pieces, every file on disk and who writes it, the
                  contracts between them, where to change what
- development.md  running the tests, the conventions the code follows,
                  working on the widget, releasing
CONTRIBUTING.md points at it.

Also:
- The per-project session listing used awk, which the CLI avoids because it
  is missing from minimal images; it uses the script's own TSV helpers now,
  and tests/static.sh fails on any awk in the CLI.
- tests/static.sh checks every relative Markdown link and #anchor.
- A unit test pins the managed env keys between cm-json.py and
  claude-mode.ps1, which only a comment kept in step before.
- test_sessions covers the per-project listing, which nothing ran.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-15 01:52:03 +03:00

778 B

Raw Blame History

Contributing

Thanks for looking. Everything you need is in docs/development.md: how to run the tests (scripts/test.sh), the conventions the code follows, how to add a provider, and how a release is cut. docs/architecture.md maps the pieces.

In short:

Run scripts/test.sh before you send anything; add a test for what you change, and check that it fails without your change.
Never test by switching your own machine — the tests run in a sandbox for a reason.
A new provider is usually a providers.json entry and a preset, not code.
Keep the POSIX port bash 3.2 compatible and the PowerShell ASCII-only and 5.1 compatible.

By contributing you agree your work is licensed under the MIT licence.

778 B Raw Blame History

Contributing

778 B

Raw Blame History