ai4kanban 0.8.0 → 0.9.0

package/README.md

@@ -42,15 +42,39 @@ rather not install anything.
 From your project root:
 
 ```bash
-akb install --tracks feature,bug,research
+akb install
 ```
 
-That scaffolds `docs/kanban/`: the track folders, the board index, the memory set, and a
-blank `config.md`. Nothing is written outside that folder — that is the whole footprint.
+That scaffolds `docs/kanban/`: the board folder, its index, the memory set, and a blank
+`config.md`. Nothing is written outside that folder — that is the whole footprint.
 
-Pass the tracks your project actually splits into. Normally you don't run this by hand —
-you paste the install prompt from <https://ai4kanban.dev/INSTALL_PROMPT.txt> and your agent
-reads the repo, picks the tracks, runs this command, and fills in the config afterwards.
+Normally you don't run this by hand — you paste the install prompt from
+<https://ai4kanban.dev/INSTALL_PROMPT.txt> and your agent reads the repo, runs this
+command, and fills in the config afterwards.
+
+### A second board in the same repo
+
+`akb install --board <dir>` puts the board somewhere else — one repository, two boards:
+
+```bash
+akb install --board marketing/kanban
+```
+
+A board away from `docs/kanban` is **named, not found**: with no flag `akb` still walks up
+for `docs/kanban`, so name yours with `--board <dir>` on any command, or
+`export AI4KANBAN_BOARD=<dir>`. A command typed inside the board folder finds it. The flag
+beats the variable, and both beat `--dir`.
+
+The board app shows which one you are on in the folder chip, and switches between them
+there.
+
+## Verify a marketing draft
+
+After `akb channel <channel> <id>`, run `akb marketing verify <channel> <id>` to check that
+repurpose against the writing memory. Fresh reviewers report violations, a writer fixes
+that one draft, and the board verifies again, stopping after at most three verify passes.
+The runs stay under one job; any remaining findings stay on its last verification run.
+This is a separate step on marketing boards and has no `--print`. See `akb guide marketing-verify`.
 
 ## Drive the board from your coding agent
 
@@ -94,12 +118,12 @@ card can be built from a terminal, over ssh, or from a script, without a chat se
 without a browser.
 
 ```bash
-akb implement 12              # build the card, then review what was built
-akb review 12                 # judge the delivery in flight on it again
-akb refine 12                 # sharpen it until it is ready to build
+akb card implement 12              # build the card, then review what was built
+akb delivery review 12                 # judge the delivery in flight on it again
+akb card refine 12                 # sharpen it; defaults to standard QA
+akb card refine 12 --effort lightweight --print  # use the chosen effort inline
 akb create "add dark mode"    # write the card(s) for it
-akb propose                   # write the next tasks
-akb archive 12                # finish it
+akb card archive 12                # finish it
 ```
 
 Add `--print` to any of them and nothing starts: it prints what to do instead, filled in
@@ -107,34 +131,37 @@ for this board — the card's own path, the steps it has left, the memory file i
 point at, and the command that closes the job.
 
 ```bash
-akb implement 12 --print      # the steps, for whoever is asking
+akb card implement 12 --print      # the steps, for whoever is asking
 ```
 
 That is the mode for an agent already in a session: it does the job where it is, rather than
 paying for a second agent to do it. Start a run when you want the work to happen on its own.
 An agent working inside a run always gets the printed flow, so a run can't spawn a copy of
-itself. `akb help runs` carries the whole rule.
+itself. `akb help` carries the whole rule.
 
 The run keeps working after the command returns. Watch it, or stop it, from anywhere —
 including from the board app, which drives its buttons through these same commands:
 
 ```bash
-akb runs                      # what is running, and what ran lately
-akb log 3f2a1b04 --follow     # watch a run as it goes
-akb stop 3f2a1b04             # end one
-akb resume 3f2a1b04           # continue one that failed
+akb run list                      # what is running, and what ran lately
+akb run log 3f2a1b04 --follow     # watch a run as it goes
+akb run stop 3f2a1b04             # end one
+akb run resume 3f2a1b04           # continue one that failed
 ```
 
-Which agent runs them — Claude Code, Codex, Cursor, OpenCode, DeepSeek Harness or ZCode — and
-what it is set to:
+What they run as. A **runtime** is the whole answer — the coding tool (Claude Code, Codex,
+Cursor, OpenCode, Kimi Code, DeepSeek Harness, ZCode or Grok Build), the provider, the
+endpoint, the key, the model id, the reasoning level and any extra arguments — and every
+agent names one. The first row is **Global default**, which an agent naming none runs:
 
 ```bash
-akb agent                     # what runs, and how it is set up
-akb agent list                # the agents it can run, and what each one takes
-akb agent use codex
-akb agent set model gpt-5.1-codex
-akb agent set apiKey sk-…     # saved to docs/kanban/.env, never shown back
-akb agent test                # one small chat, to see it works
+akb agent                                  # every runtime, and what each agent runs
+akb agent list                             # the coding tools it can run, and what each takes
+akb agent runtime add "My gateway" codex   # add a row; its id comes from the name
+akb agent set --runtime my_gateway model gpt-5.1-codex
+akb agent set --runtime my_gateway apiKey sk-…   # docs/kanban/.env, never shown back
+akb agent bind builder my_gateway          # point one agent at it
+akb agent test my_gateway                  # one small chat, to see it works
 ```
 
 Runs use these settings, never what your shell happens to export. `akb help` lists
@@ -168,15 +195,15 @@ Every message is its own command, so a conversation is picked up from any termin
 survives closing one. The board's conversation and each card's are separate, both under
 `docs/kanban/.chats/`, on your machine and out of git.
 
-A chat is not a run: it never shows in `akb runs` and never holds a card. A change to a card a
+A chat is not a run: it never shows in `akb run list` and never holds a card. A change to a card a
 run is already working on is refused, and the refusal names the card and what that run is
 doing. Only an agent whose command can take a second message into its own session can hold a
 conversation; on any other, chat says so and names the agents that can.
 
 ## The manual
 
-`akb help runs` is what a coding agent reads: every command it may call — the card work,
-the runs, the agent settings — and when to call each. `akb board help` is the board's own
+`akb help` is what a coding agent reads: every command it may call — the card work,
+the runs, the agent settings — and when to call each. `akb raw help` is the board's own
 bookkeeping beneath it: ids, a card's fields, the index, the releases.
 
 The flows are `akb guide`:
@@ -185,13 +212,14 @@ The flows are `akb guide`:
 akb guide                     # every flow, one line each
 akb guide board               # how the board works: card format, layout, memory
 akb guide qa-loop             # settle one card's planning gaps
+akb guide qa-lightweight      # short check for clear, localized work
 akb guide plan-release        # fill a release from its goal
 ```
 
 A printed flow already carries the ones its action needs, in full, so this is for the rest.
 
-A run that writes or changes a card is followed by `akb refine` on that card, as a run of its
-own — so `akb create`, `akb revise`, `akb resolve`, `akb propose` and `akb plan-release` all
+A run that writes or changes a card is followed by `akb card refine` on that card, as a run of its
+own — so `akb create`, `akb card revise`, `akb card resolve` and `akb release plan` all
 come back with their cards refined. Archiving or rejecting a card does the same for every card
 it was blocking that now has nothing left in its way.