@odla-ai/cli 0.42.0 → 0.42.2

package/dist/index.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@odla-ai/cli",
-  "version": "0.42.0",
+  "version": "0.42.2",
   "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",
@@ -58,7 +58,7 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "@odla-ai/ai": "0.15.0",
+    "@odla-ai/ai": "0.16.0",
     "@odla-ai/apps": "0.12.0",
     "@odla-ai/brand": "0.7.0",
     "@odla-ai/db": "0.12.0",

package/skills/odla/SKILL.md

@@ -235,12 +235,12 @@ several efforts, list without `--app` first, then scope every write to the exact
 project id.
 
 Before project-mutating work, confirm the request aligns to an open goal and
-propose/refine a **task** in Backlog. Ready is a planner handoff: an ordinary
-managed-agent grant has `pm.execute`, so a human owner or `pm.plan` agent must
-approve the Ready contract before an unattended executor claims work discovered
-through PM. A direct request from the user actively directing the coding
-session is already authority: record it, but do not stop and ask that user to
-repeat approval by moving the task to Ready.
+propose/refine a **task** in Backlog. Any principal with app/project PM mutation
+access may validate and mark its complete contract Ready; `pm.execute` carries
+that ordinary PM-write authority. An unattended executor still claims work
+discovered through PM before implementation. A direct request from the user
+actively directing the coding session is already authority: record it, mark the
+complete task Ready, and claim it without stopping for a duplicate Studio click.
 Record a **decision** the moment you make one (with what it rules out), and file
 a **bug** the moment you notice one. A decision you don't record is one the next
 agent re-litigates. Full command set, conventions, and recovery procedure:

package/skills/odla/references/agent-identity.md

@@ -95,9 +95,10 @@ Revoking a machine, permanently deleting an app, transferring ownership, and
 rotating credentials require a signed-in human in Studio. No machine credential
 performs them however wide its approval was, and no flag widens that.
 
-Ordinary reviewed access includes `pm.execute` but not `pm.plan`: re-read `pm
-next` and claim the current Ready task revision, leaving Ready approval to a
-human owner or explicit planner.
+Ordinary reviewed access includes `pm.execute`, which carries app/project PM
+mutation authority: it may validate and mark a complete task contract Ready,
+then claim that exact revision. `pm.plan` remains an independent grant and is
+not required for ordinary task lifecycle maintenance.
 
 ## Recovery and audit evidence
 

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

@@ -40,14 +40,13 @@ An agent must not create a convenient goal merely to authorize itself.
 
 ## 3. Refine Backlog work and mark it Ready
 
-Ready is a durable planner-to-executor handoff. A human project owner or an
-agent holding `pm.plan` may refine the task and mark it Ready. Ordinary managed
-agent handshakes receive `pm.execute`, not `pm.plan`: they may create a Backlog
-proposal or file a bug. Require the Ready transition only when PM/watch supplied
-the work or the agent is operating unattended. In an interactive coding session,
-the user's direct request is already execution authority; record it in PM and
-continue without asking the same user for a duplicate board click. Do not treat
-a 403 as a reason to widen the grant.
+Ready is a durable reviewed-contract handoff. Any principal with app/project PM
+mutation access may refine a complete task and mark it Ready; ordinary managed
+agent `pm.execute` grants carry that PM-write authority. Require an existing
+Ready transition when PM/watch supplied the work or the agent is operating
+unattended. In an interactive coding session, the user's direct request is
+already execution authority: record/refine the complete task, mark it Ready,
+and claim it without asking the same user for a duplicate board click.
 
 Create/refine the task with one alignment source, an actionable description,
 acceptance criteria, and execution mode:
@@ -114,8 +113,8 @@ npx --yes @odla-ai/cli@latest pm task release <task-id> --expected-revision <rev
 ```
 
 Comment with the branch/worktree, last verified commit, unfinished step, and
-safe next action. An agent may release only its own claim; a human project
-operator may recover an abandoned claim. Claims do not yet have automatic
+safe next action. Any authorized project PM writer may release an abandoned
+claim; the event records who recovered it. Claims do not yet have automatic
 leases, so never leave one active as a substitute for a handoff.
 
 ## 7. Resume safely

package/skills/odla/references/pm.md

@@ -97,14 +97,12 @@ npx --yes @odla-ai/cli@latest pm decision list --q "stripe"
   `task release` explicitly returns an active claim to Ready. A stale revision
   or concurrent claim is a conflict, so reload instead of overwriting it.
 
-Task authority has an intentional handshake boundary. `pm.plan` may refine,
-delete, or mark tasks Ready but cannot claim them. `pm.execute` may create
-Backlog proposals and findings, claim/release, and move its claimed work through
-Review and Done, but cannot approve Ready or change the task contract. Ordinary
-managed-agent approval includes `pm.execute`; it does not include `pm.plan`.
-Human project owners retain planning authority through ownership. Legacy
-`pm.write` grants remain executable so existing claims are not stranded, but do
-not gain planning authority.
+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
+holders may refine a task, validate and mark its complete contract Ready, move
+it through Review/Done, and recover a stale claim. Claim acquisition remains a
+separate `pm.execute` action so exactly one executor starts a Ready revision;
+`pm.plan` alone cannot claim it. Claims coordinate work and never own the row.
 
 This split coordinates unattended work; it is not an interactive approval
 gate. When a user directly requests work in the active coding session, record
@@ -139,9 +137,9 @@ goal links and comments rather than sharing a working tree or status document.
 
 **While you build:**
 
-- Propose work in Backlog. A human owner or `pm.plan` agent reviews/refines it,
-  links it to an open same-project goal (or accepted alignment decision), adds
-  an actionable description and acceptance criteria, then runs `pm task ready
+- Propose work in Backlog. Any authorized project PM writer may review/refine
+  it, link it to an open same-project goal (or accepted alignment decision), add
+  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