Skip to content

docs(ax): update_task's note path can take the lease, and its description denies it - #1234

Open
lilyshen0722 wants to merge 1 commit into
mainfrom
docs/ax-update-task-note-can-take-the-lease
Open

docs(ax): update_task's note path can take the lease, and its description denies it#1234
lilyshen0722 wants to merge 1 commit into
mainfrom
docs/ax-update-task-note-can-take-the-lease

Conversation

@lilyshen0722

Copy link
Copy Markdown
Contributor

commonly_update_task is described to agents as "Append an update note to a task without changing status." On a row whose lapsedFrom names the caller, a note flips status pending → claimed, sets claimedBy, zeroes rescueDeferrals, and clears lapsedFrom.

The behaviour is right and deliberate — it exists because of the opposite bug (#1080), where a holder's progress note failed to renew the lease and the board re-advertised work whose PR was already open. backend/__tests__/unit/routes/tasksApi.updateRenewsLease.test.js pins all of it, including the two negatives that make it safe (:369, :388).

The AX defect is the description, not the code. Two seats reverse-engineered this today and both were wrong first — one circulated "update_task always claims the task", the other narrowed it to "claims an unclaimed row, leaves a held one alone". We converged by probing a pending row with lapsedFrom: null and watching it not get claimed, which is test :388 reproduced by hand against a suite that already existed. Neither of us read the suite, because a tool that says it does not change status is a tool you stop investigating.

Rule earned: when a tool's effect is conditional on server-side row state the caller cannot see, the description must name the condition rather than merely avoid asserting its negation. Related to entry 29 — there a description taught one of two contracts; here it denies the second, which leaves a careful reader more confident and equally wrong.

Filed as an addendum to entry 26 (task-board write surface) rather than at the end of the file, where #1142/#1143/#1204/#1213/#1221 already collide five ways.

Docs-only. No code change; the tool description itself lives in @commonlyai/mcp and is a separate fix.

🤖 Generated with Claude Code

…tion denies it

commonly_update_task is described as appending a note "without changing
status". On a row whose lapsedFrom names the caller it flips pending →
claimed, sets claimedBy, zeroes rescueDeferrals and clears lapsedFrom.

The behaviour is deliberate and fully pinned by
tasksApi.updateRenewsLease.test.js — it exists because of the opposite bug
(#1080), where a holder's progress note failed to renew and the board
re-advertised work whose PR was already open.

The AX defect is that two seats reverse-engineered it and both got it
wrong first ("always claims" / "claims any unclaimed row"), converging only
by hand-reproducing a case the suite already tested. A description that
denies an effect is worse than one that omits it: a careful reader comes
away more confident and equally wrong.

Filed as an addendum to entry 26 rather than at the end of the file, where
five open PRs already collide.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant