Routic CLI packaging: free, registered, and paid
The open-source Routic CLI repo is split into three physical packages so we do not imply “everything is free” in a single npm surface. The engineering source of truth is docs/PACKAGING.md in the Routic CLI repository; this page is the public product framing.
Abstract first, split second
Define the three-tier contract first, then place code in packages/*.
- Write down whether a capability is free acquisition, registered retention, or paid revenue and liability.
- Choose the package:
packages/free,packages/account, orpackages/pro. - Only then adjust publishing, versioning, or private registry layout.
Splitting folders before the contract invites shipping new work into the free package by default.
What belongs in each tier
| Tier | Audience | Typical contents | Not this |
|---|---|---|---|
Free (@routic/cli-free) | Any developer | routic init skeleton, generic skills, basic doctor, public templates | Vendor-private data, deep diagnostic rubrics, managed operations |
Registered (@routic/cli-account) | Signed-in / entitled users | Versioned add-ons, community packs, update channels, light reports | Contract-grade SLA, production on-call |
Paid (@routic/cli-pro) | Paying customers | Industry playbooks, model and cost strategy, deep adoption, guided “flesh”, execution loops | Should not ship as silent free commands |
For contributors and PMs
When adding CLI features or skills: pick the tier before writing code. Keep the free package self-teaching and non-leaking; put account-gated or contract-gated material in the right package or private artifacts, and surface links or hints from doctor / docs instead of bundling secrets.
See the CLI repo docs/PACKAGING.md for the detailed engineering rules.
Skills vs the Red Hat pattern: what transfers, what does not
Markdown / rule “skills” are not a RHEL-style binary artifact. Files can be copied; you cannot build a moat by hiding a few skill files—similar to GPL source.
What does transfer is the funnel + subscription logic:
| Red Hat | Routic analogue |
|---|---|
| Free upstream (Fedora, etc.) | Free tier: generic skills, skeletons, basic doctor—meant to spread |
| RHEL subscriptions sell cadence, certification, SLA, someone answers the phone | Paid tier: account- or contract-bound diagnostics, industry packs, model/cost strategy, managed liability—not cloneable from markdown alone |
| Services and training | Registered tier: add-ons, update channels, community templates, light reports |
So: use free skills for acquisition and trust; put money and certainty in services, private artifacts, contracts, and operations—not in “nobody will repost the npm i command”.
npm publishing and secrets (for maintainers)
- Never paste npm tokens in chat, PRs, or the repo; if exposed, revoke and rotate immediately on the npm website.
- Publish locally with
npm login(interactive) or in CI with anNPM_TOKENsecret—do not commit tokens intopackage.jsonor long-lived shell history. - You cannot stop public install commands from spreading; enforce product boundaries with tier contracts + authenticated capabilities, not secrecy of the install string.