@odla-ai/cli 0.42.2 → 0.43.1

package/dist/index.js

@@ -56,7 +56,7 @@ import {
   startHostedSecurityJob,
   surfacePaths,
   validateInvocation
-} from "./chunk-K6ATAKGR.js";
+} from "./chunk-T4OPSRME.js";
 import {
   exitCodeFor,
   redactSecrets

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@odla-ai/cli",
-  "version": "0.42.2",
+  "version": "0.43.1",
   "description": "Agent-operable CLI for odla provisioning, calendar consent and connection lifecycle, System AI administration, Worker secrets, security jobs, and smoke checks.",
   "license": "MIT",
   "homepage": "https://odla.ai/docs/packages/cli",

package/skills/odla/SKILL.md

@@ -214,17 +214,24 @@ on the app. It is platform-side: there is nothing PM-specific to install or
 provision. Start a session by reading it, and keep it current while you build:
 
 ```cmd
-npx --yes @odla-ai/cli@latest pm next --app <appId>
+npx --yes @odla-ai/cli@latest pm next --app <appId>    # open goals, Ready, Doing
+npx --yes @odla-ai/cli@latest pm start --app <appId>   # claim the top Ready task
 ```
 
+`pm next` ends by naming the command to run next, and `pm start` claims Ready
+work in one call — it reads the current revision and compare-and-swaps against
+it server-side, so you never carry a revision between commands. It cannot mark
+work Ready: that contract is reviewed separately.
+
 For a durable supervisor loop, establish and persist an exact-project PM cursor:
 
 ```cmd
 npx --yes @odla-ai/cli@latest pm watch --app <appId> --entity task --jsonl
 ```
 
-A Ready event is a wake-up signal, not permission: reload the task and linked
-goal and win the current revision's atomic claim before starting. PM-attached
+A Ready event is a wake-up signal, not permission: re-read `pm next` and win the
+atomic claim before starting — `pm start` does both, against the revision that
+is current when it runs rather than the one the event carried. PM-attached
 comments use the same cursor (`--action comment.created`); general Discussion
 topics and mentions still use `discuss watch`.
 

package/skills/odla/references/pm-work-intake.md

@@ -16,14 +16,19 @@ for the current chat and should name the PM goal and task references.
 ## 1. Resolve context and read authoritative state
 
 ```cmd
-npx --yes @odla-ai/cli@latest context show --context <profile>
 npx --yes @odla-ai/cli@latest pm next --app <appId> --json
-npx --yes @odla-ai/cli@latest pm handoff --app <appId> --json
 ```
 
-Read any existing Doing task before selecting another. For each candidate, read
-the task, its goal, and their comments. If the current chat has a Codex Goal,
-confirm that its objective and verification still match these records.
+`pm next` is the whole intake read: open goals, Ready candidates, and work
+already in Doing, filtered by the server and projected to the fields you act on.
+It ends with a `next:` line naming the exact command to run — follow that rather
+than reconstructing the sequence from memory.
+
+Add `pm handoff --app <appId> --json` when you need the fuller unresolved
+picture (Backlog and Review as well, plus open bugs), and `--verbose` to either
+when you need whole records with their audit trail. Read any existing Doing task
+before selecting another. If the current chat has a Codex Goal, confirm that its
+objective and verification still match these records.
 
 ## 2. Check alignment
 
@@ -68,16 +73,33 @@ Claim and release require `pm.execute`. Planning authority alone is
 intentionally insufficient, so the principal that approves a task does not
 silently become its executor.
 
-Review the latest task revision immediately before claiming:
+Start the work in one call:
 
 ```cmd
-npx --yes @odla-ai/cli@latest pm task get <task-id> --json
-npx --yes @odla-ai/cli@latest pm task claim <task-id> --expected-revision <revision>
+npx --yes @odla-ai/cli@latest pm start --app <appId> --json
+npx --yes @odla-ai/cli@latest pm start --app <appId> <task-id> --json   # a specific task
 ```
 
-Only one concurrent caller can win. On conflict, reload `pm next` and the task;
-do not retry with a guessed revision. Once claimed, use the repository's
-worktree procedure and mention the PM references in the execution chat:
+`pm start` claims the top-ranked Ready task — the board's own order, not a
+tie-break it invents — and narrows to one outcome with `--goal <goal-id>`. It
+reads the current revision and compare-and-swaps against it server-side, so you
+never carry a revision between commands, and it reloads once if the task moved
+in between. It returns the claimed task, its goal, and the acceptance criteria
+to work against, so starting work costs one command rather than four.
+
+Only one concurrent caller can win. If the task is taken while starting it,
+`pm start` says so and stops rather than retrying blindly; run it again to take
+the next Ready task.
+
+`pm start` deliberately cannot mark work Ready. That contract is reviewed
+separately (step 3), so an agent cannot authorize its own work: starting
+something that is not Ready refuses and names the command that readies it.
+
+`pm task claim <id> --expected-revision <n>` still exists for a caller that has
+already read the revision itself and wants the bare transition.
+
+Once claimed, use the repository's worktree procedure and mention the PM
+references in the execution chat:
 
 ```text
 [Task title](https://odla.ai/studio/pm/board/<task-id>)

package/skills/odla/references/pm.md

@@ -61,7 +61,7 @@ npx --yes @odla-ai/cli@latest pm next --app <appId>
 ```
 
 ```cmd
-npx --yes @odla-ai/cli@latest pm task claim <id> --expected-revision <n>
+npx --yes @odla-ai/cli@latest pm start --app <appId>
 ```
 
 ```cmd
@@ -87,15 +87,23 @@ npx --yes @odla-ai/cli@latest pm decision list --q "stripe"
   authorized immutable event log retains the deletion snapshot for recovery and
   audit until the exact project lifetime is purged.
 - `next --app <appId>` is the read-only intake view: open goals, current Doing
-  work, and Ready candidates. It never claims or mutates work.
+  work, and Ready candidates. It never claims or mutates work, and its `next:`
+  line names the exact command to run next. Records are projected to the fields
+  you act on; `--verbose` returns whole records with their audit trail.
+- `start --app <appId> [<task-id>]` claims Ready work in one call: it reads the
+  current revision and compare-and-swaps against it server-side, reloads once if
+  the task moved, and returns the task, its goal, and the acceptance criteria.
+  `--goal <id>` narrows the candidates. It cannot mark work Ready.
 - `watch --app <appId> --jsonl` establishes and resumes an exact-project PM
   lifecycle cursor. Persist checkpoint records, deduplicate at-least-once
   delivery by `eventId`, and use `--entity`, `--state`, `--by`, or `--self` for
   one stable consumer policy.
 - `task ready <id> --expected-revision <n>` validates and records the Ready
-  contract. `task claim` atomically moves the reviewed Ready revision to Doing;
-  `task release` explicitly returns an active claim to Ready. A stale revision
-  or concurrent claim is a conflict, so reload instead of overwriting it.
+  contract. `task release` explicitly returns an active claim to Ready. A stale
+  revision or concurrent claim is a conflict, so reload instead of overwriting
+  it — `pm start` does that reload for you. `task claim <id> --expected-revision
+  <n>` remains for a caller that has already read the revision and wants the
+  bare transition.
 
 Task lifecycle maintenance uses app/project PM mutation authority. `pm.plan`,
 `pm.execute`, and legacy `pm.write` all carry ordinary PM-write access, so their
@@ -114,13 +122,14 @@ the request in PM but do not require them to repeat it with a Ready transition.
 write:
 
 ```cmd
-npx --yes @odla-ai/cli@latest context show --context <profile>
 npx --yes @odla-ai/cli@latest pm next --app <appId>
 ```
 
-Then read `pm bug list --app <appId> --status open` and
-`pm decision list --app <appId> --limit 10`, plus
-the selected task, linked goal, and their comments. That is the state of the
+That one read is open goals, Ready candidates, and Doing work, and it ends by
+naming the command to run next. Then read `pm bug list --app <appId> --status
+open` and `pm decision list --app <appId> --limit 10`, plus the linked goal and
+its comments — `pm start` returns the task and goal you claim, so you do not
+need to fetch those separately first. That is the state of the
 project—including anything a *different* agent left behind.
 
 Before project-mutating work, decide whether the request aligns to an existing
@@ -142,9 +151,11 @@ goal links and comments rather than sharing a working tree or status document.
   an actionable description and acceptance criteria, then run `pm task ready
   <id> --expected-revision <n>`. The stored column is still `todo` for API
   compatibility, but every product surface calls it Ready.
-- An agent starts only with `pm task claim <id> --expected-revision <n>`. The
-  compare-and-set claim assigns the authenticated principal and moves the task
-  to Doing. Never use `pm task set --column doing` to bypass it.
+- An agent starts with `pm start --app <appId>`, which takes the top-ranked
+  Ready task (or the one you name). The compare-and-set claim assigns the
+  authenticated principal and moves the task to Doing; `pm start` performs that
+  swap against the revision it just read. Never use `pm task set --column doing`
+  to bypass it.
 - Use one claimed task and one owned worktree/branch. If you must stop before
   review, run `pm task release <id> --expected-revision <n>` and comment with
   the recovery point. Move to Review when evidence is ready; mark Done only