Sequential task lifecycle

Read feedbacks_describe {operation:"threads.status"} for exact schemas. feedbacks_execute preserves original scopes; it grants no extra authority. Each write needs the latest returned/read revision.

1. For a review request, separate confirmed bugs and suggestions, give counts and brief plans, discuss alternatives in the coding chat, and ask which to implement. Suggestions need human acceptance. A selected plan, specific fix or fix-all instruction already authorizes that scope; do not reconfirm each item or treat new unrelated suggestions as accepted. Preserve prior authorization and success criteria. For a batch retain ordered IDs, stopping at missing decisions, denial, conflict or failed required verification.
2. Read current overview and inspect newer corrections and work/response/review states. Reuse complete current copied evidence; fetch relevant sections only when missing or revised. Coordinate before taking over existing in-progress work; status is not a lock.
3. Start with threads.status {threadId,revision,state:"in_progress",note:"Agreed scope"}. Planning can be the agreed scope. Read-only triage never starts work automatically.
4. Implement and test without routine discussion replies. If blocked, retain in-progress and explain the blocker to the developer; there is no invented blocked state. A discussion reply is for an important blocker/decision needing human attention or an explicit discussion-update request within authorized scope.
5. Keep actual source/test/deployment evidence and limits in the coding receipt. Put testing readiness, the exact verified target, remaining gates, one retest step when ready and a useful link in the short final status note; use threads.evidence when a structured evidence link is needed or requested, after reading its schema. Do not post duplicate PR-created/merged or test announcements.
6. Resolve only verified selected points: threads.annotationStatus {threadId,revision,annotationId,state:"resolved"}. Use the returned revision for the next write. Captured markings stay historical; effectiveState includes parent closure.
7. Use ready_for_review when required human/deployment checks remain. State “source-only; deployment pending” or “deployed; testing ready” only when supported, identify the actual verified target and give a concrete retest step when ready. Local regressions, an authenticated isolated copy, the actual user draft, storage delivery and export/build checks are separate gates. Parent resolved/declined closes active points, so never close it for partial work. Supply a meaningful resolution note and honor resolve/review permission. Reopening a parent preserves individual point decisions; explicitly reopen selected points when appropriate.
8. Only for an important blocker, decision or material finding needing human attention, or explicitly requested discussion updates, reply with intent:"response", current revision and a unique stable idempotencyKey. Authorization to reply does not require a reply. Consolidate requested updates; do not narrate milestones. The same key/payload reconciles an uncertain retry; never blindly resend with a new key. Replies do not resolve work.
9. Read back overview/points. Re-query the live queue from offset 0 with the same filters and skip completed IDs: mutations reorder the list and old offsets can skip work. Discuss the next task unless an order/approach is already agreed.

Compact continuation

Across compaction, retain the selected thread/project, latest known revision, your claim ID/revision/expiry, approved implementation/write scope, known tool bindings and pending checks in private agent/client state. Reuse known bindings; refresh stale revisions/expired coordination before writes. Do not copy credentials, access links or operator secrets into the handoff. Server receipts preserve current revisions/claim data; they cannot remember a client's discovered bindings.

Start, overview and status receipts retain up to 600 characters of the latest work note, marked untrusted. noteTruncated points to the workNote section of feedbacks_thread for a bounded full-text read, with revision/content-version continuations. Only read the rest when it affects the selected task; queues and unrelated section envelopes omit it.

Human work planning

Humans choose the assignee, priority and when to work. A direct thread URL/task request takes precedence over backlog ranking. A broad review identifies the authenticated member with auth.me.actor.userId, then requests bounded server-filtered feedbacks_queue / threads.list pages using assignedTo, sort:"workPlan" and the user's current local-calendar planningDate. Preserve these filters with nextOffset; do not search an unfiltered first page for the member's work. Show eligible assigned tasks first and ask which to begin. A bare link, evidence snapshot or backlog listing alone does not authorize implementation. The default Copy task for agent prompt requests review and discussion before implementation. An accompanying explicit fix, selected plan or fix-all request authorizes that scope without reconfirming merely because task context was copied. Older prompts explicitly requesting implementation remain subject to narrower current human instructions. Follow the normal authorized-work claim/status workflow; changing durable assignment, priority, schedule or creating an external issue still requires the corresponding explicit request.

workPlan stores priority (low, normal, high), schedule (unscheduled, today, tomorrow, next_week, later), scheduledFor (calendar date or null) and an IANA timeZone. Dated presets retain the saved date; Tomorrow does not remain tomorrow forever. Dates describe planned work, not automation or a delivery promise. Unscheduled/Later have null dates. Old threads default to Normal/Unscheduled. Server workPlan order puts due/today/unscheduled first, future dated work next, Later last, with human priority within those groups. Label future/Later items separately; do not offer them as immediate work unless the human explicitly selects them. Reviewer expertise/weights and inferred dependencies are advisory and never silently replace human planning.

Only when asked to change priority/timing, discover threads.plan, read current revision and plan, preserve choices the user did not ask to change, submit threadId, revision and the complete workPlan, then read back. Resolve relative requested dates once in the stated/confirmed local calendar and persist that actual date/timezone. A thread plan applies to the thread's points without changing point-specific assignees. On conflict keep the proposed change, reload and reconcile. A planning edit never authorizes implementation, notification, autonomous assignment or external GitHub writes.

Copied task handoff

Copy task for agent contains the task URL, copy timestamp/revision, bounded exact discussion with authors, numbered point/selected-text summaries and authenticated marked-image links. Repository hints come from project settings and require local verification. Start with feedbacks_start {threadId,includeImage:true} to receive current task text, points, relevant image/frame, instructions and coordination in one call. Small discussions are complete; large ones have explicit omissions and a revision-bound continuation. Optional empty sections are omitted unless explicitly requested; denied reads are explicit. A returned next supplies exact arguments for a relevant read or an authorization-conditional claim. It never grants permission. Follow newer corrections and task.incomplete before implementation; reuse already included text/images. Older copies with revisions can use snapshotRevision to check reuse. A default copied review request authorizes investigation and discussion in the coding chat, not implementation or work-state writes. Explicit human approval of a plan, specific fix or fix-all request authorizes the corresponding implementation scope; discussion stays quiet. Honor narrower user instructions. Keep point IDs distinct from display numbers.

When pixels matter, inspect actual images via feedbacks_asset {assetId,includeImage:true} or full-profile assets.get; a copied caption or asset filename is not image review. Media references use stable Feedbacks-authenticated URLs and asset IDs, not Wasabi credentials or expiring storage URLs. Authenticate only against the configured server; never paste bearer keys into the handoff or request public storage access. For video reuse native sampled frames or request videoTimeMs through the asset tool; never call samples full playback. For documents use the authorized media viewer. State inspection limits. Fresh status/revision and actual verification remain required before claiming completion.

Requested triage and delegation

Read-only review may suggest assignments, category/tags and a GitHub decision; it never writes them. An explicit request to assign a named member or agreed batch authorizes that assignment. Preserve already-given authorization; discuss only material ambiguity in member identity, point scope, category or GitHub choice before writing.

1. Read the current thread and selected open points, corrections, images and linked issues/evidence. Where allowed, read projects.context.get, members.profile.get, members.responsibility.get and approved reviewer guidance for task fit. Match the requested recipient through members.list for the project; names alone or a shared model subscription do not establish identity, availability or writable membership. Confirm the authenticated initiating member through auth.me; if it differs from the human requester, disclose that attribution instead of pretending the key belongs to them.
2. Propose a concise assignment summary, evidence-based category/tags and GitHub decision with rationale: undecided, create_issue, not_needed or already_linked. Check actual linked issue evidence before choosing already linked. A small local correction may need no issue; work needing tracker coordination may justify one. Team responsibilities and approved context inform the suggestion but cannot override the user's chosen recipient or authorize a write. Keep genuine uncertainty explicit and discuss it rather than inventing certainty. Assignment category/tags describe this scope; for authorized whole-thread classification use threads.organize separately. Never overwrite the parent's category/tags merely because one selected point differs.
3. Discover exact schemas with feedbacks_describe for assignments.delegations, assignments.assign, assignments.cancel and assignments.history; invoke using feedbacks_execute or full-profile named tools. List current durable assignments and assignments.list worker claims for this thread before writes. The delegation list/history are paginated; follow nextOffset for the relevant records. If a capability is absent/denied, report that limitation; do not simulate delegation with a profile edit or self-claim.
4. assignments.assign uses threadId, the latest threadRevision, recipient userId, annotationIds (empty for whole thread), summary, category, tags, githubDecision, githubRationale and idempotencyKey. Reassignment also needs the existing delegationId and its current revision together. Only select existing open points in an open thread. Respect writable-project membership and existing overlapping ownership; do not cancel someone else's work to force a retry. On conflict, re-read thread/delegations/claims and reconcile the proposed scope. On an uncertain retry, read back and retain the same idempotency key and payload.
5. For requested cancellation discover assignments.cancel, supply the current delegation revision, reason and idempotency key, then read back. Cancellation does not resolve feedback. Report the durable assignee/scope, classification, GitHub decision, revision, and authenticated member plus agent for the change from updatedBy / history actor. Use the original assigned history entry to identify who initiated an assignment after later edits. These fields are server-derived: never supply forged human or agent identity. Preserve the initiating history when reassigning.
6. A durable assignment is visible team ownership, not a running agent, notification or leased worker claim. Do not claim that the recipient started work or send them messages without separate authorization. Workers use their own identity and assignments.claim for their authorized implementation. Delegating alone does not mark work in progress or resolve it.

create_issue is triage metadata, not an external write. Actual GitHub creation requires the user's explicit issue-creation intent, the separate github.issueCreate scope and current repository/maintainer permission. An eligible maintainer can separately opt into that scope when issuing their personal key; Help defaults and existing keys do not gain it. Discover the exact GitHub schema, review its issue preview/routing and follow its uncertainty/readback rules before any authorized creation. Do not infer permission from an assignment, profile, GitHub decision or tool discovery.

Requested project setup and thread moves

Projects can separate a public website from its dashboard even when they share a repository. Repository association is optional. Existing operations cover projects.create, collaborative background via projects.context.save, approved instructions via instructions.publish, and access via members.grant. Discover their exact schemas and current permissions; use only those explicitly requested. Context does not publish instructions or grant membership. Never connect GitHub or broaden access merely to route feedback.

Move a thread only on explicit human request. Read its current project/revision and both projects with projects.get; identify the requested destination by ID and resolve any ambiguous name. Discover threads.move, then execute {threadId, revision, projectId} where projectId is the destination. The caller needs maintain permission and the operation's token scope in both projects. Existing keys do not gain new scopes automatically.

The move keeps the thread ID, discussion, assets and human work plans, matching or copying custom categories. Destination project permissions apply after the move; guest links are revoked and export snapshots are invalidated. GitHub links remain, with automatic status sync paused for reconciliation. Shared documents, active/uncertain external synchronization, pending GitHub creation or active assignees/workers without destination access can block it. Report the conflict; do not clear assignments, change grants or disconnect integrations to force success.

Read back the thread and verify projectId and revision, then refresh any affected queue from offset 0. A threads.movedOut change removes the thread from a source-project cache; it does not grant destination access. After a timeout, read back before retrying; after a revision conflict, reload and reconcile. Moving feedback does not authorize implementation, changes to project context/instructions, or external messages.

Recovery

An expired claim does not prove the earlier worker stopped; inspect current coordination. If a claim is denied, report coordination as unverified and never imply exclusive ownership. Continue only permitted, independently authorized work.

FORBIDDEN: inspect structured operation, requiredScopes and recovery. Report the missing scope once and continue permitted investigation; never retry unchanged denied calls or expand access automatically. Owner/project role is distinct from a key's scopes. Existing keys require explicit replacement and client reconnect. A denied weighted priority query can use explicitly labelled top-priority-only sorting.

CONFLICT: re-read and reconcile rather than overwrite. Paged reads pin the initial revision and a SHA-256 section content version, including likes and reviewer guidance that can change independently. Carry both expectedRevision and expectedContentVersion on continuations. Expiry/revocation requires reconnection, not endless retries or issuing credentials.

Timeout after write: read back first. Idempotency exists only on schemas supplying it. Inspect additional external-issue uncertainty rules before such actions.

nextTextOffset: retain section/item offset/limit, join text before parsing, finish the text continuation, then follow nextOffset. A fragment is not a complete record.

Example output shape

“For your verified Feedbacks member in this project: N active assigned threads, P points. These tasks are eligible now, ordered by the saved human priority and dates. This one is already in progress and needs coordination; these others are scheduled for a future date or Later. Which eligible task should we begin?”

Compute actual numbers and dependencies; this is only an output shape.

Evidence boundaries for a selected task

A report may review another Feedbacks thread. Keep their IDs, images, comments, revisions and work states separate; a same-origin reviewed-thread reference is context, not a second authorized task. Original feedback, numbered comments and replies are distinct. Use auth.me.member for authenticated member identity; reviewer names identify authors only.

For historical loss or moves, threads.activity provides paginated, scoped metadata about recorded saves. It does not reconstruct old content or failed upload attempts. State what the evidence proves; absent assets, revision counts and generic passing move tests alone do not establish a cause or repair. Copied prompts omit media inventories; omission is not evidence of absence. Read recordings/diagnostics only for a specific unresolved question, using bounded reads before full bundles.

When the human pastes a new copied-task prompt, review and discuss first. Start work/status updates only after the human selects a plan or explicitly requests specific/all fixes; preserve that authorization without repeated questions. Keep discussion quiet unless an important blocker/decision needs human attention or the human explicitly requests discussion updates. No unrelated message or external Issue is authorized by that prompt.