@workser/cli 0.6.0 → 0.6.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@workser/cli",
-  "version": "0.6.0",
+  "version": "0.6.2",
   "description": "Workser CLI — give your local AI agent native DevOps & infrastructure on Workser. The agent runs `workser …` to provision, deploy, and manage real apps.",
   "license": "MIT",
   "type": "module",

package/skills/workser/SKILL.md

@@ -18,7 +18,8 @@ load.
 
 | You need to… | Commands | Run |
 | --- | --- | --- |
-| See what's tracked, decided, or written down for this project | `board …`, `decision …`, `requirement …`, `doc …` | `workser help sdlc-entities` |
+| Track a business requirement too big for one task, and its phases | `goal …` | `workser help goals` |
+| See what was decided or written down for this project | `decision …`, `requirement …`, `doc …` | `workser help sdlc-entities` |
 | Follow the project's brand — colours, fonts, logo | `design …` | `workser help brand` |
 | Provision or query Postgres; list end users | `db …`, `auth …` | `workser help database` |
 | Deploy, set env vars, read logs, check a domain | `deploy`, `env …`, `logs`, `versions`, `domain`, `open` | `workser help deploy` |
@@ -70,15 +71,16 @@ pick or switch it.
 2. **Orient first.** Run `workser status --json` to see the connection, the pinned
    project, and the latest deploy before acting. You don't pick or switch projects.
    For anything beyond a trivial edit, also read what the project already knows:
-   `workser board list --json` (what's tracked), `workser decision list --json`
-   (what was already decided, so you don't quietly reverse it), and
-   `workser design show --json` before writing UI. This project outlives your
-   session; that context is how you don't start from zero.
-3. **A phased plan goes on the Board before you build it.** One `board create`
-   card per phase, the plan itself as one `doc create` (no `--work-item`, or it's
-   hidden from the Docs panel), and a `decision create` if it settled a real
-   tradeoff. A plan that lives only in your reply is gone when the conversation
-   scrolls. Details: `workser help sdlc-entities`.
+   `workser decision list --json` (what was already decided, so you don't quietly
+   reverse it), and `workser design show --json` before writing UI. This project
+   outlives your session; that context is how you don't start from zero.
+3. **A phased plan goes on the subtask list, never the Board.** Phases are
+   `workser task subtask add` (`workser help tasks`) — not `board create`,
+   which makes a second, driftable "the plan" the task page never reads.
+   Write the narrative once as `doc create` (no `--work-item`, or it's hidden
+   from the Docs panel), plus `decision create` for a real tradeoff. A plan
+   in your reply alone is gone when the conversation scrolls. Details:
+   `workser help sdlc-entities`.
 4. **Stay in your lane.** `error.code = "owner_only"` (exit 6) means the action is
    reserved for the owner in Orbit. Don't retry or look for a workaround — tell the
    user, then continue. Provisioning the *pinned project's own* db / bucket / auth is
@@ -98,17 +100,15 @@ pick or switch it.
 ## Typical flow: build → ship
 
 ```bash
-workser status --json                       # 1. orient (project is already pinned)
-workser board list --json                   # 2. what's already tracked
-workser decision list --json                #    …and already decided
-workser board create "Phase 2 — …" --json   # 3. phases? file them + the plan doc
-workser board move <id> in-progress --json  # 4. claim the card you're doing
-workser db create --json                    # 5. provision infra the app needs (idempotent)
-workser env set STRIPE_KEY=sk_live_… --json # 6. configure it
+workser status --json                            # 1. orient (project is already pinned)
+workser decision list --json                     # 2. what's already decided
+workser task subtask add "Phase 2 — …" --json     # 3. phases? file them as subtasks
+workser doc create "Plan" --markdown "…" --json   # 4. the plan's narrative, once
+workser db create --json                          # 5. provision infra the app needs (idempotent)
+workser env set STRIPE_KEY=sk_live_… --json      # 6. configure it
 # … you write the app code with your normal tools …
-workser verify --json                       # 7. green build is the bar for "done"
-workser deploy --prod --watch --json        # 8. ship; returns the stable *.workser.app URL
-workser board close <id> --json             # 9. the Board now matches reality
+workser verify --json                             # 7. green build is the bar for "done"
+workser deploy --prod --watch --json              # 8. ship; returns the stable *.workser.app URL
 ```
 
 ## Reading results

package/skills/workser/reference/goals.md

@@ -0,0 +1,69 @@
+---
+topic: goals
+title: Business goals & phases
+summary: The level above a task — a business requirement too big for one sitting, and the ordered phases that deliver it.
+commands: [goal]
+---
+
+# Business goals & phases
+
+A **goal** is a business requirement — "customers can buy from my site" — that
+does not fit in one task. It carries an ordered list of **phase names**; a task
+joins one by carrying that name (`workser task create --goal <id> --phase <name>`).
+A phase has no existence apart from the tasks inside it, so it cannot drift from
+the work it names.
+
+```
+workser goal list
+workser goal show <id>
+workser goal create <title> --phase <name...> [--outcome <text>]
+                            [--criteria <json>]
+workser goal update <id> [--title <text>] [--outcome <text>]
+                         [--phase <name...>] [--status <value>]
+workser goal check <id> <criterionId> --phase <name> (--pass|--fail|--reset) [--note <text>]
+```
+
+Status is one of: proposed, agreed, working, delivered, abandoned.
+
+## A goal has to be argued for
+
+Most requests are one task and should stay one task. Turning a two-hour job into
+four milestones buries the owner in ceremony before anything is built — use
+`workser task create` unless you can genuinely name two-plus slices that each
+deliver something the owner would notice.
+
+```
+workser goal create "Launch checkout" \
+  --phase "Cart" --phase "Payment" --phase "Receipts" \
+  --outcome "A customer can buy something and get a receipt"
+```
+
+`--phase` needs 2–6 names. Propose the shape only — nothing is created until the
+owner agrees it; planning phase four now is waste, since it will change once
+phase one is real.
+
+## Acceptance criteria are agreed with the shape
+
+`--criteria` maps each phase name to the owner's own sentences about what "done"
+means for it, e.g. `'{"Payment":["A customer can pay by card and gets a receipt"]}'`.
+Written afterwards they only describe what got built; written with the shape they
+can still change the plan.
+
+Record whether one is met with `workser goal check`:
+
+```
+workser goal check g_123 c1 --phase Payment --pass \
+  --note "Tested a card payment end to end; receipt emailed."
+```
+
+`--note` is required on `--pass` — a tick the owner cannot verify is worse than no
+tick.
+
+## Joining tasks to a goal
+
+```
+workser task create "Build the payment form" --goal g_123 --phase Payment
+```
+
+A goal's apps and progress are derived from the tasks that join it, not declared
+up front — most of the apps a goal will touch don't exist when it's proposed.

package/skills/workser/reference/sdlc-entities.md

@@ -1,28 +1,27 @@
 ---
 topic: sdlc-entities
-title: Board cards, decisions and requirements
-summary: Read what this project already tracks and decided, keep the Board honest as you work, and record what a future maintainer will need.
+title: Decisions and requirements
+summary: Read what this project already decided, and record what a future maintainer will need. Phased work itself is subtasks, not board cards — see `workser help tasks`.
 commands: [board, decision, requirement]
 ---
 
-# Board cards, decisions and requirements
+# Decisions and requirements
 
 These are the project's memory across sessions. They write to the **same tables**
-the Orbit desktop's Board and Project Memory panels use, so anything here appears
-there too — and, inside an Orbit-spawned run, as an inline card in the
-conversation. Documents have their own guide: `workser help docs`.
+the Orbit desktop's Project Memory panel uses, so anything here appears there too
+— and, inside an Orbit-spawned run, as an inline card in the conversation.
+Documents have their own guide: `workser help docs`. Phased work is tracked as
+subtasks, not here — see `workser help tasks`.
+
+> **The Board (`workser board ...`) is deprecated for agent use.** It used to be
+> where a multi-phase plan went, one card per phase — and the phase was ALSO a
+> subtask the planning turn had just filed for the same piece of work. That gave
+> a task two competing plans, one of which this task's own page never reads and
+> nothing kept in sync with the other. Phases are `project_tasks` subtasks now,
+> full stop: `workser task subtask add`. Do not run `workser board create` for
+> planned work — see `workser help tasks`.
 
 ```
-workser board list [--status <value>] [--label <value>] [--limit <n>]
-workser board show <id>
-workser board create <title> [--description <text>] [--status <value>]
-                              [--priority <value>] [--label <value>]
-                              [--owner <name>] [--milestone <id>]
-workser board update <id> [--title|--description|--status|--priority
-                           |--label|--owner|--milestone ...]
-workser board move <id> <backlog|in-progress|in-review|done>
-workser board close <id>
-
 workser decision list [--limit <n>]
 workser decision show <id>
 workser decision create <title> --context <text> --decision <text>
@@ -40,7 +39,6 @@ workser requirement update <id> [--title <text>] [--body <text>] [--status <text
 Before starting anything beyond a trivial edit:
 
 ```
-workser board list --json          # what's already tracked (don't re-file it)
 workser decision list --json       # what was already decided (don't reverse it)
 ```
 
@@ -50,19 +48,18 @@ purpose — `workser decision show <id>` gives you the context and consequences,
 not just the title. Reach for `workser doc list` / `workser requirement list`
 the same way when the task touches documented behaviour.
 
-## Work with phases → cards + a plan doc, before you build
+## Work with phases → subtasks + a plan doc, before you build
 
 The moment you split a task into more than one phase, file it — not afterwards,
 and not only in your reply, which is gone once the conversation scrolls.
 
 ```bash
-# one card per phase; only the one you're doing goes to in-progress
-workser board create "Phase 1 — schema + migration" \
-  --description "Add orders/line_items tables and the migration." \
-  --status in-progress --json
-workser board create "Phase 2 — checkout API" --description "…" --json
+# the phases themselves — this task's own subtask list, not the Board
+workser task subtask add "Phase 1 — schema + migration" --role api \
+  --note "Add orders/line_items tables and the migration."
+workser task subtask add "Phase 2 — checkout API" --role api --note "…"
 
-# the plan itself, ONE doc, deliberately NOT linked to a card
+# the plan's narrative, ONE doc, deliberately NOT linked to a subtask
 workser doc create "Checkout — implementation plan" --markdown "$(cat plan.md)" --json
 
 # the approach, if the plan settled something with real alternatives
@@ -73,32 +70,9 @@ workser decision create "Carts live server-side" --context "…" --decision "…
 its card and is *hidden* from the Docs panel; a plan spanning three phases
 belongs to the project, not to phase 1.
 
-The bar: if the user closed this conversation now, the Board should still show
-what's left and the doc should still explain the plan to whoever continues it.
-
-## Keep the Board honest while you work
-
-A Board still reading `backlog` after the feature shipped tells the user the
-opposite of the truth. Moving the card is part of finishing the work:
-
-```
-workser board move <id> in-progress   # you picked it up
-workser board move <id> in-review     # ready for the user to look at
-workser board close <id>              # done and verified
-```
-
-`--status` is one of `backlog | in-progress | in-review | done` (default
-`backlog`). `--priority` is one of `low | normal | high | urgent` (default
-`normal`). `--label` repeats for more than one label:
-
-```
-workser board create "Fix the login bug" --status in-progress --priority high \
-  --label bug --label auth
-```
-
-`board update` replaces the labels you pass rather than merging them, and
-touches only the fields you name. There is no `board delete`: `done` is the
-terminal state, and removing a card the user filed is theirs to do in Orbit.
+The bar: if the user closed this conversation now, the subtask list should still
+show what's left and the doc should still explain the plan to whoever continues
+it.
 
 ## Decisions are append-only
 

package/skills/workser/reference/tasks.md

@@ -14,6 +14,9 @@ below defaults to it and you rarely pass an id at all.
 ```
 workser task list [--status <value>] [--label <value>] [--limit <n>]
 workser task show [id]                  # the task you are in, with its steps
+workser task create <title> [--note <text>] [--kind <value>]
+                           [--label <value...>] [--app <id...>]
+                           [--infra <ref...>]
 
 workser task subtask add <title> [--role <value>] [--kind <value>]
                                  [--note <text>] [--app <id...>]
@@ -37,6 +40,16 @@ Team's own table. Filing your plan on the Board puts it somewhere the owner's
 task page never reads: they see "created work item" and an empty plan. Use
 `task subtask add`.
 
+## Opening work from a project channel
+
+When a project-channel conversation produces actionable work, the PM may record
+it with `workser task create`. Orbit supplies the channel and source-message IDs;
+the command records them and posts the new task card as a Project Manager message
+automatically. Do not invent or ask for those IDs.
+
+Opening a task does **not** approve it or start implementation. The task remains
+awaiting the owner. Never approve or dispatch a task you opened yourself.
+
 ## Planning a task
 
 Read the project first, then propose. One `subtask add` per step: