Things can change
A command, a file name or a gate can change between beta releases. Read the release notes before you update.
RoyaScaff 1.3 and 1.4 are beta.
These are the next versions of the engine. They work, they are tested, and teams are piloting them — but commands, files and rules can still change between releases. Try them on a side project first.
Need something stable today? Use 1.2 (npx royascaff init).
What "beta" means here
Ready to try. Not ready to bet on.
Opt in on purpose
npm install royascaff still gives you stable 1.2. You only get 1.4 when you ask for royascaff@beta.
Your feedback shapes it
Found something confusing or broken? royascaff feedback "…" writes a report you can read and then send us.
1.4
BETAA navigator and a tracer for AI-assisted delivery. 1.4 keeps your product knowledge in project/, tells the AI the one next step, and only lets work move forward through checks that pass. Status is computed from evidence — nobody types "done".
One next step
Say royascaff continue in your AI tool. next names the single next action and the short card to read for it.
Gates, not promises
A change moves only through advance, which runs every check on the way and stops at the first that fails.
People approve
The project, the roadmap and each design are approved by a person. The AI cannot approve, and editing a design after approval makes the approval stale.
One board
project/STATUS.md is rebuilt from the project, never edited by hand: next up, features, active work, fixes and health.
Context per task
context TASK-… builds what one task needs — rules, architecture, the pages it touches — inside a token budget. It says what was left out.
Tests inside every change
Every delivered requirement needs a test before Ready. Tasks for a must requirement run their new tests red first.
Checked in a real browser
For web apps, a Playwright smoke check opens the app at three screen sizes and fails on errors and dead buttons. Your own look is scored against a visual bar.
Adapters for your stack
generic, node, web-ui, web-api, web-3d. The core stays generic; you can add your own adapter in project/adapters/.
Try 1.4 beta
$
npx royascaff@beta init --name "My product" --code PROD --app web=apps/web
$
npx royascaff@beta install
Run them inside a git repo, commit, then type royascaff continue in Cursor or Claude Code. Already on 1.2 or 1.3? npx royascaff@beta migrate . shows a dry run first; --apply migrates and --rollback undoes it. Nothing is deleted.
Known limits in this beta
| Limit | What to do for now |
|---|---|
| Dependency rules written in plain words are not checked | They still reach every task's context. Write the ones code can break as path rules. |
| Framing is measured as content at the canvas border | Fine for a scene with the subject in the middle. Other layouts can raise the limit in their adapter. |
| No JSON Schema for each record kind yet | export and roundtrip guard the data. |
1.3
BETAThe layered SDLC engine. 1.3 turned the 1.2 control path into a full software lifecycle: requirements, domain, design, slices, changes and release, each with its own layer. It is a Markdown-first reference — most of its ideas now live on, with checks, in 1.4.
Three blueprints
A Main Blueprint for the whole product, a Slice Blueprint for each vertical slice, and a Change Blueprint for each change.
Intent × risk routing
route-work reads what you want and how risky it is, picks the workflow and decides which gates apply.
Eight workflows
Initial build, change, bug fix, polish, refactor, reverse engineer, reconcile drift and release.
Two kinds of status
Every item tracks how well it is known and how far it is built — separately.
Atomic skills
Small skills for one job each: capture requirements, analyze impact, design, plan, build context, implement, verify, reconcile.
A small CLI
validate, index and context: check the project, build its views and make exact-reference Context Packs.
How a new app moves in 1.3
route-work → capture-requirements → model-domain-workflow → design-solution → plan-execution for the next vertical slice → build-context for the next task → implement-task → verify-change → reconcile-knowledge → repeat for the next slice
1.3 is not published on npm. Its files are in the GitHub repo for reading and reference. To use these ideas on a real project, start with 1.4 — npx royascaff@beta migrate . moves a 1.3 project across.
Side by side
Which version should I use?
Short answer: 1.2 for real work today, 1.4 beta to try what comes next.
| 1.2 | 1.3 | 1.4 | |
|---|---|---|---|
| Status | STABLE | BETA | BETA |
| Install | npx royascaff init | Not on npm (reference only) | npx royascaff@beta init |
| Shape | Markdown flows and templates | Layered SDLC contract + small CLI | CLI engine + navigator skill |
| Status of work | Written in files | Two dimensions: known and built | Computed from events and evidence |
| Gates | Verify before merge | Adapt to intent and risk | Enforced by advance; people approve |
| Best for | Teams shipping today | Reading the design ideas | Pilots and side projects |