Missions
What a mission is, the four ways to create one, its lifecycle, the missions board, and how a mission stays in sync with the ticket it came from.
A mission is the outcome Madebook holds work to. It is not a ticket and it is not a task list.
Three nouns are easy to confuse, and they are not the same noun:
| Noun | What it is |
|---|---|
| Source item | The ask as the source wrote it — a Jira story, a ClickUp task, a pasted paragraph. |
| Mission | The outcome Madebook holds work to, with the contract that says what correct means. |
| Work item | One step of a mission's execution plan — a concrete technical change an agent worked out after reading the mission and the repository. |
Jira work is product-management work. Madebook work items are technical execution work. Madebook does not compete with your tracker.
Why a mission matters
An agent cannot be pointed at a mission whose contract is not approved. Registering a session against a draft-contract mission is refused outright:
{reference} has a draft contract (v{n}). A lead approves it on the Missions page before an agent can start on it.
That approval is the human gate. It records that a person read every clause and vouches for what should be built.
The missions board
Workspace → Missions.
What must be accomplished. Open one for how it will be built, who is on it, and what has been proved.
Three views, remembered per workspace: Board, List and Tree. There is deliberately no calendar view — nothing in the data carries a due date.
Two tabs: Missions, and To choose from (imported source items with no mission yet).
Filters
| Filter | What it means |
|---|---|
| All | Everything. |
| Ready | Contract approved, not started, nobody on it. |
| Active | A live session, or in progress or verifying. |
| Needs attention | Open questions, needs judgment, a violated clause, a plan waiting, or an unapproved contract. |
| Source changed | The ticket moved after the contract was written. |
| Completed | Shipped or abandoned. |
A shortcut line appears whenever anything needs attention.
What a tile tells you
Status, reference, source key, and a step count. Then one line of meta, whichever applies first:
- a live session and its current step, or just "working"
- shipped, and when
- "plan waits for a lead"
- "{n} open question(s)"
- "contract v{n} draft"
- "{complete}/{total} steps · {n}%"
- "ready for an agent"
And a four-stage path along the bottom — Draft → Active → Verified → Done — which pulses at the current stage while agents are live, and greys out entirely when the mission is abandoned.
The four ways to create one
1. Write it by hand
New mission → Write it by hand. Title and objective now; the contract on the mission page.
{reference} created — now write the contract
2. Generate from a story
New mission → Generate from a story.
Paste the ticket or the requirement as it was written. It is kept as the source item; the contract is drafted from it and says what the text did not settle, as open questions, rather than guessing.
The dialog tells you what it will run on before you press anything — the model and provider approved for your organization, or that AI runs are refused, or that no model is configured and the draft will be assembled without a model.
The text must be at least five words. The button reads Generate the mission, or Assemble the mission when there is no model.
It records the pasted text as a source item, classifies it as a bug if it mentions a bug, defect, regression or crash and a story otherwise, pulls acceptance criteria out of any bulleted list under an "acceptance criteria" heading, and drafts a contract.
3. Import from a work system
Connect Jira, ClickUp or Monday.com and every story becomes a source item. See below.
4. Re-draft from a moved source
When the ticket behind a mission changes, re-drafting replaces the clauses from the current text as a new version.
The lifecycle
| Status | Meaning |
|---|---|
draft |
Being written. |
ready |
The contract is approved; an agent can start. |
in_progress |
Work is under way. |
verifying |
Being checked against the contract. |
needs_judgment |
Something needs a person. |
ready_to_ship |
Contract satisfied and the evidence gate met. |
shipped |
Done. |
abandoned |
Dropped. |
The contract has its own two states, draft and approved, tracked separately with a version number.
Approving and revoking
Approve contract v{n} — needs mission.approve, owner or admin.
Three things can refuse it:
| Code | Message |
|---|---|
| Empty | "There is nothing to approve — the contract has no clauses." |
| Open questions | "{n} question(s) about the requirement is/are unanswered. Answer them, or remove them, before approving — an approved contract must not rest on a guess." |
| No proof | "A contract needs at least one proof clause. Without it "done" can never be computed, only claimed." |
Revoke approval turns it back into a draft and agents are refused again until a lead approves.
Adding or removing a clause on an approved contract does the same thing automatically, and bumps the version — because the thing that was approved no longer exists.
Open questions
A generated contract records what the requirement did not say, rather than guessing.
{n} thing(s) the requirement does not say. The draft did not guess; the contract cannot be approved until these are answered.
Each takes an answer "from whoever owns the requirement". Dismiss all removes them without answering, recorded as your decision. Up to 20 answers, each up to 1,000 characters.
An unanswered set raises an attention item at disposition decide, urgency 45.
Work sources
Sources on the missions toolbar.
Where missions come from — live work systems, the sample backlog, and what people entered here.
Supported: Jira, ClickUp, Monday.com, Openbook.work, a Sample backlog, and Madebook itself for things entered by hand.
| Provider | What it needs | What a "source" is |
|---|---|---|
| Jira | Email and API token, as email:token, plus the site URL |
A Workspace |
| ClickUp | API token | A List |
| Monday.com | API token | A Board |
| Sample backlog | Nothing | A Scenario |
A Jira connection with the wrong base gives "Jira needs the site URL, e.g. https://acme.atlassian.net." A badly shaped credential gives "Jira needs "email:api-token"."
Each connection card shows its status, its item counts, its import filters and field mapping, and its last sync — "{n} new, {n} updated, {n} removed, {n} unchanged", or "never".
Sync now reports exactly what changed. Pause means webhooks and the schedule are ignored until you resume. Removing a connection keeps everything already imported, as Madebook-owned.
A switch, Draft a mission for every new story, is off by default:
New stories will get a draft contract automatically — still nothing an agent can start on until a person approves.
A per-connection webhook URL is available; it carries its own secret, so paste it only into the work system.
Sync writes source items only. It never touches a mission. A mission records which source version it was written against, and the difference is computed on read.
When the source moves
A callout appears on the mission:
{key} changed in {provider} after contract v{n} was written
with a line-level diff over the title, description, acceptance criteria, status, level, parent and assignee, and the two commit-like versions it is comparing.
Two buttons:
- Re-draft from the source as v{n+1} — clauses replaced, approval withdrawn, a lead reads it again.
- Keep as written — "Kept as written — recorded as your decision."
If development has begun, the callout says so and nothing is touched automatically.
If the ticket was deleted:
{key} was deleted in {provider} — The contract still stands as written. Abandon the mission if the work is really gone, or keep it if the item was moved.
The tracker closing a story while the mission is still open raises its own attention item: "the source already calls this done", at disposition review.
Shipping
Done — ship now, needing mission.ship (owner or admin).
If the contract is satisfied, the dialog says so. If it is not:
The contract is NOT satisfied. Shipping anyway is allowed, and it is recorded in the audit log as your override with your reason.
The reason becomes mandatory and the button turns destructive: Ship with override. The audit entry reads "{reference} shipped WITH AN UNSATISFIED CONTRACT — {reason}".
Blocking it outright would just teach people to route around Madebook.
Deleting a mission
Behind a … menu, deliberately — a red button in the primary row of every mission is a button somebody eventually clicks by reflex.
Refused while an agent is on it:
{n} agent session(s) is/are on this mission. Stop them first — deleting a mission under a live session would orphan running work.
Deleted with it: the contract, its clauses, its verifications, its versions, the work items, test plans, decision gates, evidence, evidence requirements, remediation requests and attention items.
Kept, with their mission link cleared: agent sessions, change sets, risk assessments, review capsules and context snapshots. They are a record of what happened.