@fui-org/fui-cli 2.2.0 → 2.2.1

package/README.md

@@ -49,8 +49,7 @@ Installed fui with Bun? Install Playwright the same way, so fui finds it: `bun a
 
 `fui` installs one skill, `fui`, for each AI agent it finds, and refreshes it after every update. It holds the commands, the
 safety rules and the FUI domain rules (module.json, components, tAPI and stored procedures, design systems); `fui skill`
-prints it. For Claude Code, `fui` also installs two agents, `fui-builder` and `fui-tester`, in `~/.claude/agents`, used
-by the larger tasks below.
+prints it. One AI agent handles each request from implementation through verification, without sub-agent hand-offs.
 
 | Agent       | Skills folder                  |
 | ----------- | ------------------------------ |
@@ -66,25 +65,15 @@ Installed an agent later? The next `fui` run adds its skill. To install by hand:
 fui skill install [--agent claude,codex,antigravity|all]
 ```
 
-## Larger tasks: a team of agents (Claude Code)
+## Work with one agent
 
-You never pick a mode. For each request to build or change something, the agent decides: when you name the place or the
-exact change, it does exactly that and checks it; when you describe behavior and leave the places to it (a new screen, a
-feature across the UI and its stored procedures, a bug of unknown cause), it runs a team. A team run needs you twice: to answer the questions at the start, and to approve the release at the end. In between, a
-planner (your session) writes a plan with acceptance criteria, a builder writes the module and its stored procedures, a
-tester who has not seen the builder's work checks them, and the builder fixes what the tester found. The agents work one
-after another.
-
-There is nothing to set up: the two agents come with `fui`. A Claude Code session that started before they were
-installed does not see them, and then the agent does the same steps alone, with no independent tester. The builder and
-the tester cannot run anything that changes the server or real data (publish, deploy, `fui exec`, `--confirm-write`,
-deletes); the planner shows you the result and the one release command, and runs it only after you approve.
-
-Then ask as usual, for example `add a search box and an edit dialog to /my-project/students`. Say "do it directly" or
-"run it as a team" to overrule the choice.
-
-The run keeps its plan, test reports and the review packet in `<workspace>/_team/<run>/`. Stored procedures are checked
-by reading them, never by running them, so a SQL error can still appear at deploy.
+Ask as usual, for example `add a search box and an edit dialog to /my-project/students`. The same agent understands the
+request, changes the UI and stored procedures, checks the result and fixes proven failures. Exact changes are handled
+directly; broader work gets a short internal plan without creating hand-off files. Checks run from cheapest to most
+expensive, and browser rendering is used only when pixels matter. After all assigned module work passes its checks, the
+agent publishes the module and deploys its SPs automatically. Say `do not upload`, `local only`, `draft` or `preview
+first` when you want it to stop before changing the server. Destructive operations and real-data writes still require
+explicit approval.
 
 ## Quick tour