From request to delivered work: the complete Wagglet workflow

A work item should not become “done” just because somebody dragged a card to the right.

Wagglet separates the decisions that teams often blur together: somebody had an idea; a reviewer decided it was worth preparing; an owner made the task safe to put in front of the team; a runner claimed it; an agent or person reported an outcome; another person judged that outcome; and, for code, GitHub confirmed whether a branch actually landed.

That separation makes the workflow look longer on paper. In practice, it removes the guessing from every handoff. Each stage answers one question, leaves a receipt, and hands the next participant a bounded job.

There is one terminology trap worth clearing up first: a Wagglet Draft already is a Ticket. It is a private Ticket with DRAFT status, not a temporary document that is later copied into a different record. Publishing changes its visibility and makes it Open; it does not discard the Draft or mint a second task.

Key takeaways

• A Wagglet Draft is the same Ticket in a private preparation state; publishing makes that Ticket Open rather than creating a second work item.
• Claim, delivery, acceptance, merge, and deployment are separate facts, so each transition has a named owner and an auditable result.
• Teams may enter through a Request, Draft, Story item, or direct Open Ticket, but they should not skip ownership, evidence, review, or repository truth.

The whole factory at a glance

The main path is request → Draft → Open → Claimed → Delivered → Done. The diagram also shows the legitimate side doors: a manager can promote their own private note, a team can start from a Story item or a Draft directly, and a duplicate request can be included in work that already exists.

Factory manifest

One work item, four truthful lanes

Request → Draft → Open → Claimed → Delivered → Done

1. 01

   Capture and triage

   1. Private note
   2. Published request

   Reject returns the request to its owner with a reason.

2. 02

   Prepare authorized work

   1. Private Draft
   2. Prepared Ticket

   A Story item or an existing task can provide a legitimate side entrance.

3. 03

   Execute on the board

   1. Open
   2. Claimed
   3. Delivered
   4. Done

   Send back keeps the runner; reopen clears the claim; accept records Done.

4. 04

   Record repository truth

   1. Reported branch
   2. Git merge state

   Delivery, acceptance, merge, and deployment remain separate facts.

Text equivalent: a private Note may be published as a Request. A reviewer may send the Request back with a reason, promote it into a private Draft, or include it as a source of an existing task. A manager may also promote their own Note without first sharing it. A Draft may come directly from the new-ticket form or from an optional Story item. Publishing moves the same Ticket to Open. One eligible runner claims it, performs the work, and files a delivery report. A reviewer then accepts it as Done, sends it back to the same runner as Claimed, or reopens it as Open for a new runner. For code work, the reported branch and its merge state are tracked on a separate lane; delivery, acceptance, merge, and deployment are different facts.

That last sentence is the rule that keeps the factory honest:

Stage 1: catch the idea before asking for a specification

The fastest entrance is Requests at /requests. It is intentionally lighter than a ticket form.

A teammate can type a one-line Note, press Enter, and keep moving. That Note is private to its owner. It can later carry details and attachments, but it does not enter the shared queue until the owner chooses Publish.

Publishing a Note creates a Published Request. This is not the same as publishing a Draft. It only says, “I want the team to consider this idea.” Reviewers then have three different answers available:

• Promote when the idea deserves its own task.
• Include when an existing task already covers the idea.
• Reject when the request should not proceed as submitted; the reviewer must leave a reason, and the row returns to its owner's private Notes.

An owner can also Unpublish their own Request without calling it a rejection. And a manager can take the shortcut from their own private Note directly to a Draft when there is no value in performing a public-review ceremony for themselves.

There is no separate APPROVED Request status. In the current product, Promote is the review action that says, “prepare this as new work.” The Request becomes immutable provenance for the Draft it created. If a reviewer instead uses Include, the Request keeps its own wording and becomes an origin of the selected task without rewriting that task's title, prompt, files, or current work.

The Request owner's Accepted tab is a receipt, not a claim that execution has finished. Its row can still say Draft, Open, Claimed, or Delivered. Only after the eventual delivery is accepted does the row itself say Accepted.

Stage 2: use the Draft as a private preparation room

Promotion creates a Draft in the same project. The reviewer's identity becomes the Draft's creator. When somebody else wrote the original Request, that requester is added as a collaborator, so they can see and co-own the private work rather than losing their idea behind a management wall.

The Request title becomes the Draft title. Its longer details become Human instructions, and its attachments move with it. LLM instructions deliberately start empty: a one-line request is not silently treated as a complete prompt.

Only the creator and collaborators can see a private Draft. Cross-ticket manager or administrator powers do not pierce that boundary. Collaborators can edit and publish; permanent deletion remains the original creator's decision.

This is where the task author turns intent into something another human-agent pair can run. A prepared agent task can contain:

• detailed LLM instructions, including the definition of done;
• separate Human instructions for setup, judgment, and escalation;
• project, repository, source branch, and intended delivery destination;
• preferred models and rules about who may claim;
• attachments and dependencies;
• Work Value, difficulty, hands-on level, estimate, and urgency;
• a readiness check, a human-QA request, and required screenshot or video proof.

The two instruction fields have different readers. Human instructions are shown to the person and are not inserted into the copied agent prompt. The agent side receives the detailed task plus generated, bounded context and requirements. That two-audience design is explained separately in the Dual Prompt.

A Draft does not have to originate as a Request. An owner can create one directly at /tickets/new, and an authorized MCP connection can use create_draft. Teams should use the Request lane when provenance and triage matter, and go straight to a Draft when the decision to prepare the work has already been made.

Stories are a planning side entrance, not another task lifecycle

A Story is an optional layer above Tickets. It holds a short feature description and an ordered list of item titles so a team can plan without pretending every future item already has a good prompt.

An unlinked Story item is simply Planned. An editor can turn it into a Draft or publish it directly as Open. Once linked, the Story item mirrors the real Ticket's state; it does not maintain a second checkbox that can disagree with the board.

Three boundaries matter:

1. Story order is narrative order, not a dependency. Any item may become work now.
2. A Story is not claimable or deliverable. The linked Ticket owns execution.
3. Private-Draft privacy survives the link. The Draft's owner can open it; other Story editors can see only that the item is occupied by a Private Draft; ordinary viewers and bounded agent Story context see the public planning item as Planned.

Stories also support chores for plan items that will never become Wagglet tasks. A chore can have a manual state because there is no Ticket behind it to contradict. As soon as a real Ticket is linked, the Ticket's lifecycle becomes authoritative.

Stage 3: publish the prepared Ticket to the board

For a signed-in teammate, the main Wagglet workspace is the board with four columns: Open, Claimed, Delivered, and Done. Drafts remain at /drafts until an owner publishes them.

On first publication through the browser, Wagglet validates that an agent task has LLM instructions—or that a human-only task has Human instructions—rechecks claim restrictions against the live team, changes the same Ticket from Draft to Open, and records when it first became public. It can now appear on the board and notify eligible teammates.

Publication still does not guarantee immediate claimability. A Ticket can be reserved for named people, opened to people with particular team tags, denied to certain people or tags, or held behind unfinished prerequisite Tickets. The board and server use the same eligibility rules, so a refusal should explain why the work cannot be taken rather than presenting a button that later fails mysteriously.

Taking a Ticket off the board is reversible. Unpublish returns unfinished work to a real private Draft, releases an active runner, retires a standing delivery when needed, and preserves the history. Republishing restores the same Ticket and original public age instead of announcing it as brand-new work. A finished Ticket is the exception: it keeps Done even while unpublished because hiding a completed record must not erase its accepted outcome.

Stage 4: claim one runner, then hand that runner the agent context

Claiming is exclusive. An eligible teammate moves the Ticket from Open to Claimed, and Wagglet records a new task attempt under that runner. If the work is released, reopened, or automatically released after going stale, that attempt remains part of the history even though the Ticket becomes available again.

On an agent task, the Ticket page's Claim flow also tries to put a fresh agent prompt on the runner's clipboard. If the claim came from another surface, or the clipboard copy failed, the runner can use Copy agent prompt on the claimed Ticket.

This begins the Task Handoff. During the active claim, the prompt can include a repeatable, read-only credential rooted in that one task. It lets the agent refresh the task's current context and, for a Story-linked task, inspect the bounded Story overview and selected published sibling tasks. It cannot browse the whole board, read unrelated work, expose another person's private Draft, change status, or deliver.

The human runner remains responsible for the human side of the handoff: getting the right workspace open, resolving access the agent cannot obtain, answering bounded questions, observing the real result, and performing the requested human QA. If the Ticket requires a screenshot or video, the current run's runner must attach new proof after the claim; an old image or another teammate's upload does not silently count.

Wagglet also has an MCP Workspace Workflow, which is a different door into the same records. A person's named MCP connection can search authorized work and perform explicit actions such as creating a Draft, publishing, claiming, delivering, sending back, reopening, or accepting—only when that person's current permissions allow each action. Every write carries an operation ID, and mutations of existing records carry the relevant expected revision, so stale work conflicts and safe retries return the original result rather than repeating the mutation.

MCP is not a magic administrator and it is not the Task Handoff credential. Task Handoff is bounded to one claimed task; MCP is an ongoing personal workspace connection. Both ultimately use the same Wagglet lifecycle and authorization rules. The distinction is documented in the Task Handoff guide and the MCP Workspace guide.

Stage 5: deliver evidence, not a “done” gesture

When the work is ready, Copy delivery prompt mints a fresh one-time credential and copies a second prompt for the same agent session. The first credential was for reading; this one is for reporting the result. The agent submits a free-text delivery report and, when relevant, the branch it actually pushed.

The person holding the claim can also file the delivery in the UI, and an authorized owner or reviewer can file one on the runner's behalf. Either way, execution credit stays attached to the recorded attempt runner, not automatically to the person who typed the report.

A delivery report can say “implemented and tested,” but it can also honestly say “tried this approach; it failed; here is why.” Wagglet records the report as a Delivery event and moves the Ticket from Claimed to Delivered. It does not move it to Done.

Required screenshot and video proof are enforced before ordinary delivery. A human-QA requirement, by contrast, gives the agent and runner an explicit QA handoff; the reviewer still has to judge the resulting evidence rather than treating the presence of a switch as proof that the work is correct.

Stage 6: a reviewer chooses among three genuinely different verdicts

Delivered means, “a result is waiting for judgment.” An authorized reviewer now has three paths:

Accept

Acceptance moves the Ticket to Done, closes the recorded attempt as Accepted, and writes the resulting Contribution Score awards. Independent acceptance requires a different person from the attempt runner. An owner-runner or Admin runner has an explicit self-verified close with the same points, labeled as such and excluded from independent-review quality rates.

Send back

Send back moves Delivered to Claimed and keeps the same runner. The reviewer must write what needs changing and may identify whether the problem was in the task instructions, the run, or neither. That feedback enters the next agent prompt. The old delivery stays as evidence and is normally marked as deprecated so it is not mistaken for the standing answer. A new rework attempt begins for the same runner.

Reopen

Reopen moves Delivered to Open and clears the claim so somebody else can take over. The attempted delivery remains in history but is no longer the Ticket's answer. This is not a harsher spelling of Send back: it changes who owns the next attempt.

The runner can also undo their own accidental delivery. That returns the Ticket to Claimed without pretending that a reviewer supplied feedback or blame.

These distinctions produce a usable history. “One delivery was sent back, the same runner fixed it, and a second person accepted the next attempt” is a much more useful record than a card that moved backward and forward twice.

Stage 7: keep acceptance and Git truth on separate rails

For non-code work, Done may be the end. For code, the creator can ask the runner to push to the source branch, create a new branch, or push nothing. When merging is in scope, the branch the delivery actually reports is the candidate head: it is evidence about what happened, while the configured source/destination is intent. No push deliberately suppresses a merge offer even if a report happens to mention a branch.

When a distinct delivered branch and a repository are available, a reviewer may use Accept & merge. The label sounds like one operation, but its ordering is deliberate:

1. Wagglet accepts the delivery and records the outcome.
2. It then asks GitHub to open or adopt a pull request and merge the reported branch.

The two halves are not atomic. A conflict, required review, failing check, revoked credential, or branch-protection rule may block the merge after the work was accepted. That failure does not take away the runner's accepted outcome. The Ticket can truthfully be Done while its merge chip says conflict, blocked, pull request open, or merge failed.

Plain Accept remains available without merging. A branch may also be merged separately. Wagglet can reconcile its stored state against GitHub by checking whether the base contains the delivered branch and by inspecting pull-request evidence. A person cannot simply assert “merged” through a generic status control.

Even a verified merge is not proof of deployment. The honest vocabulary is:

• Delivered: a runner reported an outcome.
• Accepted / Done: an authorized reviewer accepted that outcome.
• Merged: Git evidence says the delivered branch landed on the base.
• Deployed: a separate release system proves that revision reached an environment.

Wagglet currently records the first three layers where applicable. It should never use one as a shortcut for another.

A synthetic walkthrough: one bug through the entire line

The following example is invented. It demonstrates product behavior; it is not a customer case or evidence of saved time.

An artist named Nina notices that a mobile game's boss health bar sits under the device notch in landscape mode.

1. Capture. Nina adds a private Note under the Pocket Dungeons project: “Boss bar hides under the notch in landscape.” She adds an iPhone screenshot and two sentences about when it happens.
2. Request. Nina publishes the Note. The team can now see it under Published Requests; her private working Notes remain private.
3. Triage. Marta, the producer, confirms it is real and chooses Promote & edit. A private Draft is created. Marta owns it, Nina is a collaborator, the screenshot moves onto the Draft, and Nina's details become Human instructions.
4. Prepare. Marta writes the LLM instructions: use the existing safe-area helper, change only the combat HUD, cover portrait and landscape, add a deterministic layout test, and stop if the authored HUD anchor conflicts with the shared helper. The Human instructions ask the runner to test the boss scene on the two named simulator sizes. She requires human QA and a fresh landscape screenshot, sets the repository and dev source branch, and selects New branch as the delivery destination.
5. Plan, optionally. Marta links the private Draft to the Planned “Fix combat HUD safe areas” item in the Combat UI polish Story. The public Story title remains visible; the private prompt does not.
6. Publish. Marta publishes the same Ticket. It becomes Open on the board.
7. Claim. Alex is eligible and claims it. The Ticket becomes Claimed and the ticket-page flow copies the agent prompt. Alex opens the correct repository and lets the agent perform its readiness check before editing.
8. Human-agent run. The agent changes the shared layout use and leaves the game running. Alex performs the two named visual checks and attaches a new screenshot from this attempt.
9. Deliver. Alex uses Copy delivery prompt in the same agent session. The agent files its report, names the tests it ran, calls out one unrelated legacy warning, and reports the pushed branch fix/boss-bar-safe-area. The Ticket becomes Delivered.
10. Rework. Marta finds that the bar is now too low on one small Android device and chooses Send back. Her feedback names the exact viewport and keeps Alex on the Ticket. It appears in the agent's next prompt. Alex corrects the breakpoint, repeats QA, attaches fresh proof, and delivers again.
11. Accept. Marta reviews the second report and screenshot, then chooses Accept & merge. Wagglet records acceptance first. GitHub then merges the reported branch into dev, and the merge state is recorded separately.
12. Receipt. Nina's Request row now says Accepted, its origin remains visible on the Ticket, and any origin contribution is based on the recorded acceptance—not on the day the request was merely promoted.

At no stage did Wagglet need to pretend that a one-line bug report was already a prompt, that a delivery was already correct, or that an accepted task was already deployed. That is the factory: not more ceremony, but one honest decision at a time.

Which stages can you skip?

The workflow is strict about truth, not about forcing every team through every screen.

The stages that should not be skipped are the semantic ones. Somebody still owns the decision to expose work. One runner still owns an attempt. A delivery still needs a verdict. And merge truth still comes from the repository, not from optimism.

To inspect the two agent paths, read the Task Handoff guide and the MCP Workspace guide. Or sign in and follow one small synthetic task from Request to acceptance before moving real work onto the line.