Built by the development agent · today
The workspace
The workspace, screen by screen
These are drawings of a workspace that is not built yet. Planned, not built They follow the order of its menu. The workspace is made for two roles: a product owner, who decides what to build, and an engineer, who judges how it is built. They may be one person. Agents draft, and people decide.
Every name, figure and date in a drawing is an example. Nothing in them is connected to the engine.
The sixteen screens
Dashboard
B Team · Dashboard
Your organisation · 2 projects
Dashboard
Tuesday 14 October 2026. What runs now, what waits for you, and what it costs. Only the projects you are on are listed.
See this page as
Product ownerSoftware engineerOne person, both roles
Working now
2
tasks, across 1 project
Waiting for you
4
oldest waiting 2 hours
Spent today
$1.46
of $10.00 for the whole engine limit is real spend is an example
The limit is read from engine/config/projects.toml, 13 October 2026.
Next turn
Tue 09:00
turn 3 of Volunteer shift planner · 1 batch returns by then · see the turn
Waiting for you, across your projects Only you can answer these. Nothing waiting on you starts until you do.
Approve the new vision
Volunteer shift planner · Vision · drafted by the agent that sharpens vision, value and who we serve
Approve the drafted issue "Reminder by text message"
Volunteer shift planner · Requirements · 2 questions the agent could not answer
Accept or send back "The swap request screen"
Volunteer shift planner · Artefacts · every standard reviewer has answered
Confirm two mockups: Reminder settings and Open shifts
Volunteer shift planner · Design · drawn by the architecture agent · nothing is built before you confirm
Spending against the limits example data A limit is a ceiling for one day. A project stops at its own limit, whatever the organisation has left.
The whole organisation
$1.46 of $10.00
Stop all spending
acts now: no approval needed
Volunteer shift plannerspending on
$1.46 of $3.00
The $3.00 a day is a limit the product owner set.
Stop this project's spending
acts now: no approval needed
Donor newsletter toolspending on
$0.00 of $3.00
The $3.00 a day is a limit the product owner set.
Stop this project's spending
acts now: no approval needed
Each project Start a new project
Volunteer shift planner example project
The open piece of work is "Swap a shift between volunteers".
Running now
Documentation agent: help text for swapping a shift
real time · started 10 minutes ago
Testing agent: checks for the next release
batch · returns by Tuesday 09:00
Waiting for you
4 items
Next turn
Tuesday 09:00 · turn 3 · 1 batch returns by then
Went wrong recently
The documentation reviewer could not finish because the project had reached its spending limit for the hour. Nothing was lost; it ran again 20 minutes later.
Open this project
Donor newsletter tool example project
No piece of work is open.
Running now
Nothing.
Waiting for you
Nothing.
Next turn
Wednesday 10:00 · nothing returns
Went wrong recently
Nothing.
this project's pages are not drawn in the mockup
Why only some projects. The dashboard shows the projects you are on and no others, so nobody sees the work or the spending of a project that is not theirs. Stopping spending works at once because it can only prevent a cost. Starting it again needs a person's approval, because starting spends money.
New project
B Team · New project
Your organisation · 2 projects
New project
Start a project from what your organisation's one-time setup already connected. You give it a name, a link to its code and one sentence about what it is for.
See this page as
Product ownerSoftware engineerOne person, both roles
Mockup only: show the organisation as
Set upNot set up yet
set up What your organisation already connected
You do not enter any of this again. It was connected once, on 2 October 2026, by the person who holds the code-host account. example
| Code host | Connected. B Team reads and writes your project files through it and keeps no second record. |
| Model providers | Two, both allowed by your data policy. A provider you have not allowed is never called. |
| Spending limit | One limit for the whole organisation. Each project gets its own limit inside it. |
Name of the project
For example: Volunteer shift planner
The name you will see in the menu and on the Dashboard. You can change it later.
Link to the project's repository
https://gitlab.com/your-organisation/your-project
The repository is where the project's code and files live. Paste the link your code host gives you to copy: the address in the browser, or the link behind its Clone button, in either form. B Team tidies it to the plain address.
What the product is for, in one sentence
For example: Volunteers arrange their own shifts from a phone.
This becomes draft 1 on the Vision page. The agent that sharpens vision, value and who we serve builds on it, and asks about what it cannot guess. You approve the Vision later; nothing is final now.
The project starts with
| Agents | The standard working agents and the five standard reviewers. |
| Spending limit | $3.00 a day example |
| Human review level | B: an engineer also reads the changes marked risky example |
You change the limit on Resources and the level on Team. Each change goes through a merge request on the project's own file, which you approve.
Propose the project
proposes: opens a merge request; nothing runs until it is approved
Still missing: a name, a repository link, a sentence about what the product is for
What happens when you propose
- B Team opens a merge request in your code host. A merge request is a proposed change that waits for a person to say yes.
- It adds the project to your organisation's list, with the standard agents and reviewers.
- You approve it with the Approve button. The code host records that you did.
- The project runs. The vision agent drafts draft 1 of the Vision from your sentence.
Until step 3 nothing runs and nothing is spent. An agent cannot do step 3 for you.
Where this is kept. The project is an entry in a file in your organisation's repository, so your engineers, your funders and every agent read the same record. This page only shows it and lets you add to it.
Overview
B Team · Overview
Volunteer shift planner · project
Overview
Where the project stands, and what waits on you this turn.
See this page as
Product ownerSoftware engineerOne person, both roles
Waiting on you
4
oldest waiting 2 hours
This turn
Tue 09:00
turn 3 is due; 1 batch returns by then
Spent today
$1.46
of the $3.00 a day this project may spend
Human review level
B
an engineer also reads each change marked risky
Waiting on you this turn Only you can answer these. Nothing waiting on you starts until you do.
Approve the new vision
Vision · drafted by the agent that sharpens vision, value and who we serve · 1 question it could not answer
Approve the drafted issue "Reminder by text message"
Requirements · 2 questions the agent could not answer
Confirm two mockups: Reminder settings and Open shifts
Design · drawn by the architecture agent · nothing is built before you confirm
Accept or send back "The swap request screen"
Artefacts · every standard reviewer has answered
Where each section stands In the order you work through them. Each is a view over a record in your code host; this page keeps none of its own.
Vision
waits on you
Draft 2 waits for your approval. Version 1 was approved on 2 October.
You write and approve; an agent drafts.
Value
Two goals set. What counts as "used" is not set yet.
You set the goals and what counts as used.
People we serve
Two groups, three needs, one persona, marked ASSUMPTION.
You check each persona’s evidence.
Requirements
waits on you
Four issues approved; one drafted issue waits.
You write goals and approve each issue.
Architecture
Approved on 10 October. The engineer proposes one new piece: a text-message service.
You approve the architecture as a whole.
Design
waits on you
Two mockups confirmed; two wait for your confirmation.
You confirm mockups before anything is built.
Roadmap
Now: swap a shift. Next: reminders. Later: three goals.
You order the goals.
Turns
Turn 3 is due Tuesday 09:00. One task is given to a person.
You shape the planner’s proposal.
Team
Two people, the standard agents and the standard reviewers.
You set the human review level.
Resources
$1.46 of $3.00 spent today. Two model providers.
You decide limits, models and the data policy.
Artefacts
waits on you
One change waits: "The swap request screen". Last release 9 October.
You accept or send back, and approve it going live.
Feedback
Two open questions for "Swap a shift", answered by hand until user tests exist.
You try it, for example with a stakeholder, and write what you learned.
Compliance
One finding open: phone numbers are kept longer than needed.
You are responsible for compliance.
Why the sections come in this order. You say what the product is for and who it serves before anything is planned, and plan before anything is built. An agent drafts in each section; only you approve.
Vision
B Team · Vision
Volunteer shift planner · definition page 1 of 3
Vision
What the product is for, who it is for, and who it is not for. Every agent and reviewer reads this before any work on the project.
See this page as
Product ownerSoftware engineerOne person, both roles
Draft 2 waits for your approval. Drafted by the agent that sharpens vision, value and who we serve, from your words when you started the project and from one conversation note. Version 1, approved on 2 October, stays in force until this one is approved.
What the product is for, in one sentence
Volunteers arrange their own shifts from a phone, so the coordinator spends the time on people rather than on the rota.
Version 1 said: "A rota tool for the volunteer coordinator."
Sources: [1] your words when you started the project · [2] conversation with the coordinator, 6 October
Who it is for
The volunteers who staff our shifts, and the coordinator who plans them.
The groups and their needs are on People we serve; this line only names them.
Who it is not for
Paid staff, whose hours are planned in the payroll system. Clients of the organisation.
Saying who it is not for keeps agents from building for them.
a question the agent could not answer
Should other branches of the organisation use it too?
Your words name one branch. The coordinator mentioned a second. The agent does not guess: an unanswered question stays in the vision as an open question.
Your answer
Approve
Ask for another draft
acts now: writes the vision into your repository and merges it under your own sign-in
The three definition pages
Together they say why the project exists. An agent drafts each; only the product owner approves.
- Vision: this page
- Value: the goals, and what counts as "used"
- People we serve: the groups, their needs and personas
Larger aims and their "why"
Each larger aim gets a short why: who it is for, the problem today, how we know, how they cope now, and how we will know it worked. Small fixes need none.
Swap a shift between volunteers
approved
Today volunteers have to phone the coordinator when they cannot make a shift.
Reminder by text message
draft
Today volunteers have to remember a shift booked weeks ago when nobody reminds them.
Where this is kept. The vision is a file in your project's repository, so your engineers, your funders and every agent read the same words. This page only shows it and lets you change it.
Value
B Team · Value
Volunteer shift planner · definition page 2 of 3
Value
What the product is meant to achieve, and how well the team is working. These are two separate blocks. B Team never adds them into one score.
See this page as
Product ownerSoftware engineerOne person, both roles
Block 1 of 2 · about the product
The product's own goals, and what counts as "used"
Drafted by the agent that sharpens vision, value and who we serve. You decide; nothing here is final until you approve it.
One thing waits for your approval: what counts as "used". The two goals below are set. The three levels of use are not set yet, so the measure "used after release" cannot be rated yet.
Goals and how we know two goals set example figures
A goal says what should be better for the people the product serves. Its KPI (key performance indicator) is the one number that shows whether it is.
| Goal | KPI, the number we watch | Now | Aim |
|---|---|---|---|
| Volunteers arrange swaps themselves | Share of shift swaps arranged in the planner, without phoning the coordinator | 38% | 80% by the end of the year |
| Fewer empty shifts | Shifts left empty in a month | 9 | 3 or fewer |
Each goal traces to a need on People we serve. The product records both numbers itself; nobody types them.
What counts as "used"
A product that exists is not a product that is used. Say here what use looks like, at three levels, before you look at the results. The levels are shares of the volunteers who have an account.
The agent's suggestion. A volunteer counts as using the planner in a month when they send or accept a swap request in it. Sufficient: 25%. Good: 50%. Excellent: 75%.
The event is one the product already records. The three levels are only a starting point: the agent does not know what your organisation needs.
Use this suggestion fills the fields below; nothing is saved
A volunteer counts as using the planner in a month when they
For example: send or accept a swap request
It must be something the product already records. Otherwise nobody can count it, and the measure stays empty.
Sufficient
% of volunteers
Enough to keep going.
Good
% of volunteers
The product is doing its job.
Excellent
% of volunteers
More than we hoped.
Set them before you look, if you can. The last release was 9 October. Levels written after a release can drift towards the result, so once approved the rating of "used after release" is marked levels set after release.
Approve
acts now: writes it into your repository and merges it under your own sign-in
Approve works when the event and all three levels are filled in.
Block 2 of 2 · about the team's work
The five measures
The machinery records them from its own timestamps and ledgers. Nobody types a number. They are shown together because any one of them alone misleads. Each is a report with no pass mark.
example data
Last 6 weeksLast 6 months
The period changes what is shown, never a number.
Effective first: are we building the right thing?
Accepted at first review
7 of 10 issues, one bar per week
40%
50%
60%
70%
60%
70%
How it is counted. Counted per issue (the goal), not per merge request. Splitting work into tiny pieces does not raise it.
Where it comes from. The code host's review records.
Used after release
42 of 120 volunteers sent a swap, one bar per week
not rated yet No levels are set, so there is nothing to compare 35% with. Set them in block 1.
0%
0%
12%
25%
31%
35%
How it is counted. "Used" is what you set in block 1, with its three levels, written before release.
Where it comes from. Events the product itself records. Counting people is personal data, so your data policy covers it.
Efficient second: are we building it well?
Time from decided to accepted
2.1 days in real time
In batch: 4.5 days
3.4 d
2.8 d
2.5 d
2.2 d
2.3 d
2.1 d
How it is counted. "Decided" is the moment the "Done when" was approved. Real time and batch are shown apart, so the cheaper choice never looks like the slow one.
Where it comes from. The machinery's own timestamps.
Human minutes per accepted change
18 min per accepted change
Counted per project, never per person
40 min
32 min
26 min
22 min
20 min
18 min
How it is counted. From the moment an item was opened for a person to the moment it was answered. Timing people would be surveillance, so it is never split by person.
Where it comes from. The machinery's own timestamps.
Cost per accepted change
$3.40 including rejected work
All model cost of the issue, divided by changes accepted
$5.10
$4.40
$4.00
$3.70
$3.50
$3.40
How it is counted. Work that was sent back or abandoned is counted too. Leaving it out would make cost look better than it was.
Where it comes from. The spend ledger, which records every model call.
Beside them: tasks that touched more than they said
1 of 14 tasks this month example
When a task opens its change, the files it changed are compared with the files it said it would touch. The planner cannot learn from a miss after the fact, so the count is shown here.
The three definition pages
Together they say why the project exists. An agent drafts each; only the product owner approves.
- Vision: what the product is for
- Value: this page
- People we serve: the groups, their needs and personas
Why two blocks
Block 1 asks whether the product helps the people it is for. Block 2 asks whether the team builds it well and at what cost.
A cheap, fast team that builds something nobody uses has failed. A product people love, built at a ruinous cost, has too. Adding the two into one score would hide both. So they stay apart.
Where this is kept. The goals and the levels of use are a file in your project's repository, so your engineers, your funders and every agent read the same words. The five measures are not typed anywhere: this page only shows what the machinery recorded.
People we serve
B Team · People we serve
Volunteer shift planner · definition page 3 of 3
People we serve
The people this product is for: their groups, what they need, what a typical person in each group is like, and what they do with the product.
See this page as
Product ownerSoftware engineerOne person, both roles
These are the people the product serves, not the people who use B Team. The volunteers and the coordinator below will use the shift planner. You and your engineer, who use B Team to build it, are described elsewhere. A person can be in both lists, but this page is only about the first.
approved Approved on 2 October
Drafted by the agent that sharpens vision, value and who we serve, and by the use-case agent. Nothing here was adopted on an agent's word: you approved it. Every agent and reviewer reads this version before it works on the project.
The groups Two groups use the product.
Volunteers
People who staff the shifts, mostly part time, mostly on a phone.
Needs 1 and 2 below
The coordinator
The one person who plans the rota and fills the gaps.
Need 3 below
What they need Written "I need … so that …". High level and stable: a need does not say how it is met.
Need 1 Volunteers
I need …
to swap a shift without phoning the coordinator
… so that
I can still help when my week changes
Served by 1 approved issue. See Requirements
Need 2 Volunteers
I need …
to be reminded of a shift I booked weeks ago
… so that
I do not forget it
Served by 1 approved issue and 1 draft. See Requirements
Need 3 The coordinator
I need …
to see which shifts are still empty
… so that
I can fill them before the day
Served by 2 approved issues. See Requirements
A typical person in each group One persona so far.
What is a persona? A persona is a short portrait of one typical person in a group, written so that everyone building the product keeps a real person in mind.
Maria, 34, volunteers on Saturday mornings Volunteers ASSUMPTION
She works full time and gives two Saturdays a month. She uses her phone for everything. Her week changes late, and she does not like to phone someone to ask for a favour.
How she copes now: she texts a friend on the team and hopes the coordinator hears about it.
Needs she has: need 1 and need 2.
Why this is marked ASSUMPTION. The agent wrote Maria from your words when you started the project and from the conversation with the coordinator on 6 October. No volunteer has been asked. Agents are told this, so they do not treat her as a fact.
Evidence, if you have it
Source: who you asked, or what you read
For example: three volunteers, short interviews
Date
For example: 20 October
Record the evidence
A persona without a source and a date stays an ASSUMPTION. Recording it counts as a change you approve below.
There is no persona for the coordinator yet. Draft one with the agent once you have talked to the coordinator.
What they do with the product Use cases, drafted by the use-case agent from the needs above.
A volunteer swaps a Saturday shift Serves need 1
- She opens her shifts on her phone and picks the Saturday she cannot do.
- She asks another volunteer to take it.
- The other volunteer says yes. The coordinator is told, and the rota changes.
The coordinator fills an empty shift on Thursday Serves need 3
- She opens the rota and sees the shifts nobody has taken.
- She picks the empty shift for Saturday.
- She asks volunteers to take it, and sees when someone does.
A volunteer checks what she has booked Serves need 2
- She opens the app after a busy week.
- She sees her next three shifts with day and time.
- She knows which one is coming and does not forget it.
Ask the agents for another draft
Nothing changes until you approve what comes back.
The three definition pages
Together they say why the project exists. An agent drafts each; only the product owner approves.
- Vision: what the product is for
- Value: the goals, and what counts as "used"
- People we serve: this page
Who does what here
Drafts: the agent that sharpens vision, value and who we serve writes the groups, needs and personas. The use-case agent writes the use cases.
Product owner: checks each persona's evidence and approves the page.
Software engineer: reads it and comments.
Where the needs lead
Every requirement traces to a need on this page. A requirement that serves no need is not approved.
Need 1: 1 approved issue
Need 2: 1 approved issue, 1 draft
Need 3: 2 approved issues
Open Requirements
Where this is kept. This page is a file in your project's repository, so your engineers, your funders and every agent read the same words. The page only shows it and lets you change it.
Requirements
B Team · Requirements
Volunteer shift planner · what must be true
Requirements
You write a goal. An agent drafts one issue from it, with a "Done when". The issue exists only after you approve it.
See this page as
Product ownerSoftware engineerOne person, both roles
1 Your goal and three why questions
Write the goal the way you would say it to a colleague.
Remind volunteers of their shift by text message.
Who is it for?
Volunteers who booked a shift weeks ago.
What is the problem today?
Today volunteers have to remember a shift booked weeks ago when nobody reminds them.
How will we know it worked?
Fewer shifts are missed without notice.
Draft an issue from this goal
Drafting costs a few cents. About $0.05 example
The three answers go into the issue. The agent that turns aims into issues on a roadmap looks only at your words here, at the vision and at People we serve. It cites each one.
2 The agent's draft: Reminder by text message draft: not yet an issue
Drafted by the agent that turns aims into issues on a roadmap. Waits for your approval.
Title
Reminder by text message
What it is for
Volunteers have to remember a shift they booked weeks ago, and nobody reminds them. A text message before the shift means fewer shifts are missed. [1] [2]
Sources for this paragraph.
[1] People we serve, need 2: "I need to be reminded of a shift I booked weeks ago, so that I do not forget it." example
[2] Your answers in step 1: the problem today.
Which need it serves
Every requirement traces to a need on People we serve. The agent proposes one. Without a need, the issue cannot be approved.
Need 1Need 2Need 3None
I need to be reminded of a shift I booked weeks ago, so that I do not forget it.
Done when
Each item must be something a test or a person can check.
A volunteer who gave a phone number gets a text message before a shift they booked.
Remove
A volunteer can turn the reminder off from their phone.
Remove
Nobody who has not said yes receives a message.
Remove
Volunteers find the reminder clear.
Remove
Add an item
Questions the agent could not answer
It does not guess. An unanswered question goes into the issue as an open question.
question 1 How long before the shift should the message arrive?
Your goal says "a reminder", not when. A day before and a few hours before are different.
Your answer
question 2 What is the most you want to spend on messages in a month?
Each message costs money. The architecture page shows the engineer's estimate. See Architecture
Your answer
Approve and create the issue
Discard the draft
acts now: creates an issue in your project’s tracker, and only after you approve
The issues 4 approved, 1 draft waiting
Let a volunteer swap a shift with another volunteer approved · being built now
4 "Done when" items · serves need 1: swap a shift without phoning the coordinator
Show a volunteer the shifts they have booked approved
3 "Done when" items · serves need 2: be reminded of a shift booked weeks ago
Show the coordinator which shifts are still empty approved
3 "Done when" items · serves need 3: see which shifts are still empty
Tell the coordinator when a swap is accepted approved
2 "Done when" items · serves need 3: see which shifts are still empty
Reminder by text message draft · waits for approval
4 "Done when" items · serves need 2: to be reminded of a shift I booked weeks ago
How an issue is made
- You write a goal and answer three why questions.
- The agent that turns aims into issues on a roadmap drafts one issue and lists what it could not answer.
- You approve. Only then does the issue exist.
Who does what here
Product owner: writes goals, answers the questions, approves each issue.
The agent: drafts; it never creates an issue on its own.
Software engineer: says where a "Done when" cannot be tested.
Why every issue serves a need. A requirement with no person behind it is a guess. The needs live on People we serve; the order of the issues is on the Roadmap.
A new piece may be needed. The reminder sends text messages, and the architecture has no part for that yet. The engineer has proposed one. See Architecture
Architecture
B Team · Architecture
Volunteer shift planner · how it is built
Architecture
In plain words: what the product is made of, and how the parts talk. You approve it as a whole before anything is built on it.
See this page as
Product ownerSoftware engineerOne person, both roles
approvedApproved on 10 October
The five parts below are the architecture every agent builds on. The architecture reviewer checked the product against it before this date.
What the product is made of Five parts, and one more proposed. Drafted by the architecture agent.
Volunteer appA web page on a phone. Volunteers see their shifts, swap and book.
Coordinator pageA web page on a laptop. The coordinator sees the rota and the empty shifts.
→
Shift serviceThe part that knows the rules: who may take a shift, how a swap works, that no shift is left empty.
→
DatabaseRemembers people, shifts and swaps.
Email serviceA ready-made service that sends emails for us.
Text-message serviceproposed
A ready-made service that sends one text message to a phone and tells us if it arrived.
How they talk
- The volunteer app and the coordinator page ask the shift service for everything. They never touch the database.
- The shift service reads and writes the database.
- The shift service asks the email service to send an email.
- The shift service would ask the text-message service to send a text message. proposed
Each part has one job. A part you cannot name in one plain sentence is a reason to ask the architecture agent to split it.
Proposed: a text-message service
proposed
Proposed by the engineer. Written up in plain words by the architecture agent. Cost figures are examples.
Why
The Reminder by text message issue cannot be built without a way to send text messages. Email is already there, but the coordinator says volunteers do not read it on the day.
Serves need 2: "I need to be reminded of a shift I booked weeks ago, so that I do not forget it." See the draft issue
What it costs
Per message
about $0.08
example
Per month, for 120 volunteers with 4 shifts each
about $38
example
Work to connect it
about 1 turn
example
The choices considered
Email only. No new part and no new cost. Volunteers may not see it in time.
A text-message service (proposed). One new part and a monthly cost. Reaches a phone directly.
Phone numbers. This part would hold volunteers' phone numbers. The Compliance section already has an open finding that phone numbers are kept longer than needed, assigned to the engineer.
Add it to the architecture
Decline the proposal
acts now: starts version 2 of the architecture. Nothing is built until you approve the whole.
The architecture reviewer's checkchecked 13 October
A reviewer agent that did not write the proposal reads the architecture and the change, and reports. It cannot approve. You do.
passedEvery part has one job
The text-message service does one thing: sends a text message.
passedThe new part talks only to the shift service
The apps never reach it directly, so a phone number never passes through a screen it does not need to.
notePhone numbers
The part would hold volunteers’ phone numbers. The service must forget a number once the message is sent. There is already a Compliance finding about numbers kept too long.
passedCost and reason are written down
The proposal gives a reason, a monthly figure and a choice it was weighed against.
Who does what here
Drafts: the architecture agent writes the plain-words description and the proposals.
Checks: the architecture reviewer, which is not the agent that drafted.
Software engineer: proposes pieces.
Product owner: approves the architecture as a whole.
Versions
Version 1approved 10 October
Each version is a file in your project's repository. The merge request underneath stays for anyone who wants to look.
Why you approve the whole. Each part may look small on its own. Together they decide what the product costs to run and what personal data it holds. Approval is yours, and it comes before the designs are built.
Design
B Team · Design
Volunteer shift planner · what it will look like
Design
The screens of the volunteer app, drawn as simple placeholders. You confirm each one before anything is built.
See this page as
Product ownerSoftware engineerOne person, both roles
2 of 4 mockups confirmed. A mockup shows what goes where, not how it will look or read. These are placeholders drawn by the architecture agent, not screenshots of anything built.
Header: My shifts
Shift: Saturday morning, 09:00 to 13:00, food bank desk
Shift: Saturday 25 October, 13:00 to 17:00, sorting
Shift: Thursday evening, 18:00 to 21:00, front door
Button: Swap this shift
Placeholder, not a screenshot
My shifts
confirmed 6 October
A volunteer sees the shifts they have booked, with day, time and place.
Serves need 2. Drafted by the architecture agent.
The engineer says
can be built as drawn
Built. About 1 turn.
Take back the confirmation
Header: Swap a shift
The shift you give away: Saturday morning
Pick a volunteer: list of names
Field: a message, if you like
Button: Ask to swap
Placeholder, not a screenshot
Swap a shift
confirmed 8 October
A volunteer picks a shift and asks another volunteer to take it.
Serves need 1. Drafted by the architecture agent.
The engineer says
can be built as drawn
Built. About 1 turn.
Take back the confirmation
Header: Reminder settings
Field: your phone number
Switch: text me before a shift
Choice: how long before the shift
Button: Save
Placeholder, not a screenshot
Reminder settings
waits for your confirmation
A volunteer gives a phone number and chooses whether to get a text message before a shift.
Serves need 2. Drafted by the architecture agent.
The engineer says
not answered yet
Something to change first? Say what.
Confirm this mockup
Ask for a redraw
acts now: marks this mockup as the one to build from
The engineer has not said yet whether this can be built. You can confirm anyway; the planner then flags it.
Header: Open shifts
Filter: choose a day
Open shift: Saturday morning, front door
Open shift: Sunday afternoon, sorting
Button: Take this shift
Placeholder, not a screenshot
Open shifts
waits for your confirmation
A volunteer sees shifts nobody has taken yet and takes one.
Serves need 3. Drafted by the architecture agent.
The engineer says
can be built with a change
About half a turn. The list needs paging.
Something to change first? Say what.
Confirm this mockup
Ask for a redraw
acts now: marks this mockup as the one to build from
Who does what here
Drafts: the architecture agent draws the placeholders from the needs and the approved architecture.
Product owner: confirms each mockup before anything is built from it.
Software engineer: says whether it can be built, and at what cost.
Why you confirm first
A screen built from a drawing you did not look at is rework. The planner only plans work from confirmed mockups.
Open Requirements
Related
People we serve: every mockup serves a need.
Architecture: the parts the screens talk to.
Roadmap
B Team · Roadmap
Volunteer shift planner · project
Roadmap
Your goals in the order you want them: Now, Next and Later. The planner takes the tasks of each turn from the goal in Now.
See this page as
Product ownerSoftware engineerOne person, both roles
Where this is kept. Now, Next and Later are three milestones in your code host. A milestone is a named group of work there. This page shows them and changes them; it keeps no list of its own. Moving a goal moves its issues to another milestone.
The order below is a draft. The agent that turns aims into issues on a roadmap drafted it on 10 October, from your goals and the approved architecture. It only proposes. The order is yours to change, and it counts only after you save it.
the same as the milestones in your code host
Now
What the planner turns into tasks.
Swap a shift between volunteers
Today volunteers have to phone the coordinator when they cannot make a shift.
Four issues approved
Move up
Move to Next
Next
After Now.
Reminders
Today volunteers have to remember a shift booked weeks ago when nobody reminds them.
One drafted issue waits for approval
Move to Now
Move to Later
Later
Wanted, but not yet.
A volunteer’s own shift history
Volunteers want to see which shifts they have done.
No issues yet
Move to Next
Move down
Fill empty shifts
The coordinator wants to ask volunteers who said they can help when a shift is empty.
No issues yet
Move up
Move down
Hours report for the funder
The funder asks each year how many hours volunteers gave.
No issues yet
Move up
Move down
Save the order
Back to the agent's draft
acts now: moves each goal's issues to its milestone in your code host, under your own sign-in
What the three columns mean
Now is what the planner turns into tasks. Next is what comes after it. Later is everything you want but are not ready for. A goal in Later costs nothing yet.
Each goal was written on Requirements, with its why. The agent drafts the issues of a goal only once it is close to Now.
Dependencies pointed out
None yet. The engineer can point out when a goal cannot start before another.
Why you decide. An agent can see what depends on what in the code. It cannot see what matters most to the people you serve. So the agent drafts, the engineer warns, and the order is yours.
Turns
B Team · Turns
Volunteer shift planner · project
Turns
What is due, what the planner proposes for the next turn, and who works on what right now.
See this page as
Product ownerSoftware engineerOne person, both roles
Turn 3 is due Tuesday 09:00open: waiting for the batch and the engineer’s task
A turn is due at a moment that is stated, and it closes when what was due has returned. It is not a fixed length. If something is late, the turn stays open; it does not close on the clock.
Swap rules in the shift servicestill out
A batch for an agent, sent Monday 15:10. Batch work comes back by the turn it was sent for.
Show the batch coming back mockup only
Connect the text-message servicegiven to a person
The one task given to a person this turn. It returns when the engineer finishes it.
Turn 3 closes when both have returned. It is not closed by the clock.
This is a proposal from the planner. The planner drafted it from the goal in Now and from what each task will touch. It only proposes. You can reorder, merge, split or drop tasks, choose real time or batch for each, and give a task to a person. The register then checks the result.
Real time or batch. Real time: a person is waiting and the answer comes in minutes. Batch: cheaper and slower, and it comes back by the next turn, up to a day later. The size of the saving has not been measured on our own jobs. All prices and estimates here are examples.
Proposed for turn 4 4 tasks · 4 for agents · 0 given to a person
1
Dutch and English texts for the swap screen
Batch
Done byDevelopment agent
Touchesweb/texts/nl.json · web/texts/en.json
Sharesnothing
Comes backby turn 4, up to a day later
Estimate$0.10 as a batch example
Refused by the register.
Also uses web/texts/nl.json, which "The swap request screen" holds.
Start it after that is done
Drop the task
Move up
Move down
Merge with the next
Split in two
Switch to real time
Give to the engineer
Drop
2
Tell the coordinator on screen when a swap is accepted
Real time
Done byDevelopment agent
Touchesservice/notify/
Sharesnothing
Comes backin minutes, while someone waits
Estimate$0.35 in real time example
Move up
Move down
Merge with the next
Split in two
Switch to batch
Give to the engineer
Drop
3
Update the volunteer guide
Batch
Done byDocumentation agent
Touchesdocs/guide.md
Sharesnothing
Comes backby turn 4, up to a day later
Estimate$0.07 as a batch example
Move up
Move down
Merge with the next
Split in two
Switch to real time
Give to the engineer
Drop
This agent is set to batch only, so it cannot run in real time.
4
Tell the coordinator by text message when a swap is accepted
Real time
Done byDevelopment agent
Touchesservice/texts/ · tests/texts/
Sharestext-message account
Comes backin minutes, while someone waits
Estimate$0.40 in real time example
Refused by the register.
Also uses service/texts/, tests/texts/, text-message account, which "Connect the text-message service" holds.
Start it after that is done
Drop the task
Move up
Move down
Merge with the next
Split in two
Switch to batch
Give to the engineer
Drop
What this proposal costs example estimate, not measured
$0.92
If every task for an agent ran in real time: $1.10. Tasks given to a person cost no model time. The daily limit is $3.00; a call over it is refused before it is made.
Turn 4 is due at
Thursday 09:00
A stated moment, not a length. It closes when what was due has returned.
2 task(s) refused by the register. Fix them or drop them.
Approve this proposal
Back to the planner's version
acts now: puts these tasks on the register and sends the batches. Nothing is published.
Who works on what now
The register is a list kept by the machinery, not by the planner. Every task is on it before it starts. It refuses a task that would work on the same files as one already running. It cannot be talked round.
Swap rules in the shift servicebatch sent
WhoDevelopment agent
ModeBatch, sent Monday 15:10, due back Tuesday 09:00
Touchesservice/swaps/ · tests/swaps/
Sharestest database
Stop this task
The swap request screenwaiting for you to accept it
WhoDevelopment agent, then the standard reviewers
ModeReal time. Finished; every reviewer has answered.
Touchesweb/shifts/ · web/texts/nl.json
Sharespreview server
Open the change
Connect the text-message servicegiven to the engineer
WhoThe engineer, a person (given by the planner)
ModeDone by a person. No model time.
Touchesservice/texts/ · tests/texts/
Sharestext-message account
A task given to a person is on the register like any other, so no agent starts on the same files. stopping acts now: the task stops at its next step and what it wrote stays on its branch
Refused earlier, and why
Yesterday 14:52
"Dutch and English texts" could not start beside "The swap request screen": both change web/texts/nl.json.
Yesterday 11:20
A second task for the engineer's file service/texts/ could not start: it is held for the engineer.
A refusal costs nothing and starts nothing.
Did a task stay inside what it declared?
When a task opens its change, the files it changed are compared with the files it said it would touch. This month, 1 of 14 tasks touched more than it declared example.
The register cannot learn from this after the fact, so the number is shown rather than hidden. See the changes on Artefacts
Team
B Team · Team
Volunteer shift planner · project
Team
The people and the agents of this project, together. Agents draft; people decide.
See this page as
Product ownerSoftware engineerOne person, both roles
People A project needs two roles and no more. One person may hold both. The names are examples.
Sanne Bakker
example name
you, in this view
Role
Product owner
Decides what gets built and in what order. Approves what goes live. Sets the review level, the spending limits and the data policy.
Review role
Accepts or sends back each change on Artefacts, after the reviewers have answered.
Joris Visser
example name
Role
Software engineer
Proposes the pieces the product is made of, takes the tasks the planner gives to a person, and fixes the findings that are theirs.
Review role
You read the changes the planner marks risky, and any change that touches the project’s risky list: credentials, the network, anything written outside the project, and its libraries. Your reject ends the change.
Human review level: who reads the codenow: level B
The standard reviewers and the project's own checks look at every change. This level says which changes a person who writes code also reads, before you can accept them. A reject by that person ends the change.
Level A: checks only
The standard reviewers and the project’s checks, nothing more. No engineer reads the code.
For you: cheapest and fastest. You accept changes that carry the line "No human engineer has read this code."
Level B: an engineer on risky changes
The planner marks risky changes. A named engineer reads those before you accept them.
For you: a short wait on risky changes only. Needs a named engineer.
in force now
Level C: an engineer on every change
A named engineer reads every change. You cannot accept one until they have answered.
For you: the slowest, and the most careful. Needs a named engineer.
Propose level B
proposes: nothing changes until you approve the merge request below
Working agents Each drafts one stage of your work. None of them decides: a person approves what they draft.
Vision, value and who we serve
Sharpens your vision, your goals and the groups you serve, and lists what it could not work out as questions.
Runs on
claude-fable-5-1 exampleLatest test-set result
example: 11 of 12 cases passed exampleThen: You approve it on Vision, Value and People we serve.
Use cases
Turns the needs of each group into use cases: what a person does, step by step.
Runs on
claude-sonnet-5 exampleLatest test-set result
example: 9 of 10 cases passed exampleThen: You approve it on People we serve.
Architecture
Describes in plain words what the product is made of, and sketches the screens as mockups.
Runs on
claude-fable-5-1 exampleLatest test-set result
example: 8 of 10 cases passed exampleThen: You approve the architecture as a whole. The engineer proposes the pieces.
Aims into issues, on a roadmap
Turns each goal into issues, each with a "Done when", and drafts the order of the roadmap.
Runs on
claude-sonnet-5 exampleLatest test-set result
example: 12 of 12 cases passed exampleThen: You approve each issue and the order.
Planner
Proposes the tasks of the next turn: in what order, real time or batch, from what each will touch.
Runs on
claude-fable-5-1 exampleLatest test-set result
reasoning only: no test set has been run exampleThen: You shape it. The register refuses a clash.
Documentation
Keeps the guide and the project’s documents in step with what is built.
Runs on
claude-sonnet-5 exampleLatest test-set result
example: 10 of 10 cases passed exampleThen: The documentation reviewer checks it. You accept it.
Development (the builder)
Writes the code for one task, on its own branch.
Runs on
claude-sonnet-5 realLatest test-set result
13 of 13, 23 September 2026 realThen: The standard reviewers check it. The review level says whether an engineer also reads it. You accept it.
Testing
Runs the project’s checks and drafts the open questions for trying the product out.
Runs on
claude-sonnet-5 exampleLatest test-set result
example: 7 of 8 cases passed exampleThen: You judge the answers on Feedback.
Infrastructure
Prepares changes to where the product runs and what it needs to run.
Runs on
claude-sonnet-5 exampleLatest test-set result
example: 6 of 8 cases passed exampleThen: Likely on the risky list, so at levels B and C an engineer reads it. You approve it going live.
Standard reviewers They check work; they never write it. Each is independent of the agent whose work it checks.
Security reviewer
Looks for ways a change could expose your data or your keys.
Runs on
claude-opus-5-5 realLatest test-set result
its own set is not written yet realThen: Its verdict is shown on the change. It never merges anything.
Documentation reviewer
Checks that the documents say what is now true.
Runs on
claude-opus-5-5 realLatest test-set result
its own set is not written yet realThen: Its verdict is shown on the change. It never merges anything.
Compliance reviewer
Checks a change against the privacy and legal rules this project has set. Not built yet.
Runs on
claude-opus-5-5 exampleLatest test-set result
not built yet: no test set exampleThen: Its verdict is shown on the change. It never merges anything.
"Done when" reviewer
Checks that the change does what the issue’s "Done when" says.
Runs on
claude-opus-5-5 realLatest test-set result
its own set is not written yet realThen: Its verdict is shown on the change. It never merges anything.
Architecture reviewer
Checks that the change fits the architecture you approved.
Runs on
claude-opus-5-5 realLatest test-set result
its own set is not written yet realThen: Its verdict is shown on the change. It never merges anything.
How to read the models and results
A test set is a fixed list of example jobs with known good answers. An agent's instructions or model are meant to be used only after they pass it. Today a person runs that test by hand; the system is meant to enforce it.
Chips: real is a figure from the project's records. example is a placeholder. The two test-set runs marked real are from 23 September 2026: 13 of 13 for claude-sonnet-5 as builder, and 15 of 15 for claude-opus-5-5 as reviewer, which cost $0.0896. The builder and reviewer models are read from engine/config/roles.toml on 13 October 2026; the planner and the compliance reviewer are examples.
To change the model an agent runs on, go to Resources. It is also a merge request you approve.
Resources
B Team · Resources
Volunteer shift planner · project
Resources
What the project spends, which models and providers it uses, who may see its data, and where it lives and runs.
See this page as
Product ownerSoftware engineerOne person, both roles
Nothing here is a switch. Every change on this page becomes a merge request on the project's own file, the file in your repository that holds the project's settings. You approve it, and only then does it count.
Spent today
$1.46
of the $3.00 a day this project may spend
Model providers allowed
2
Anthropic and Scaleway
Code host
gitlab.com
the record of the work
The product runs on
A European hosting provider
the live shift planner
1 Spending against the limit
$1.46 of $3.00 today
49% of the daily limit example
A call that would go over the limit is refused before it is made.
The planner
$0.31
Development agents
$0.62
The standard reviewers
$0.45
The other agents
$0.08
The split by agent is an example. The four parts add up to $1.46.
Daily spending limit, in dollars
3.00
A change is a merge request you approve. It never raises the limit silently.
2 Data policy: who may see this project's data
"See" means the text of your issues, your code and what people tell you in feedback is sent to that provider so its model can read it. A provider you do not allow is never called. Every provider outside the EU starts off. Turning one on is an explicit choice. A provider is approved only if its terms exclude training on your prompts and give a processing agreement.
Today. Every decided role of the engine runs on Anthropic. That is the engine's own setting, not a client project's. Here, your project starts with every provider outside the EU off. real
Anthropic outside the EU: off by default
model list answers: 13 models, 4 October 2026
Commercial models. Every standard agent runs on Anthropic in this example. Where it runs: the provider’s cloud; the region is read from its terms at setup.
Scaleway hosted in Europe
A European provider of open-weights models. No transfer outside the EU, so no transfer basis is needed. No role runs on it yet.
OpenAI outside the EU: off by default
model list answers: 133 models, 4 October 2026
Commercial models. Where it runs: the provider’s cloud; the region is read from its terms at setup.
A model on your own machine would need no permission, because nothing leaves it. It is not wired yet.
3 The model for each role
A model is chosen for a role only if your data policy allows its provider and it passed that role's test set. The test set is a fixed list of example jobs with known good answers. Prices are per million tokens (pieces of words), in and out.
| Role | Model | Provider | Your policy | Latest test-set result |
|---|---|---|---|---|
| Vision, value and who we serve |
claude-fable-5-1
example
|
Anthropic | allowed | example: 11 of 12 cases passed |
| Use cases |
claude-sonnet-5
example
|
Anthropic | allowed | example: 9 of 10 cases passed |
| Architecture |
claude-fable-5-1
example
|
Anthropic | allowed | example: 8 of 10 cases passed |
| Aims into issues, on a roadmap |
claude-sonnet-5
example
|
Anthropic | allowed | example: 12 of 12 cases passed |
| Planner |
claude-fable-5-1
example
|
Anthropic | allowed | reasoning only: no test set has been run |
| Documentation |
claude-sonnet-5
example
|
Anthropic | allowed | example: 10 of 10 cases passed |
| Development (the builder) |
claude-sonnet-5
real
|
Anthropic | allowed | 13 of 13, 23 September 2026 |
| Testing |
claude-sonnet-5
example
|
Anthropic | allowed | example: 7 of 8 cases passed |
| Infrastructure |
claude-sonnet-5
example
|
Anthropic | allowed | example: 6 of 8 cases passed |
| Security reviewer |
claude-opus-5-5
real
|
Anthropic | allowed | its own set is not written yet |
| Documentation reviewer |
claude-opus-5-5
real
|
Anthropic | allowed | its own set is not written yet |
| Compliance reviewer (not built yet) |
claude-opus-5-5
example
|
Anthropic | allowed | not built yet: no test set |
| "Done when" reviewer |
claude-opus-5-5
real
|
Anthropic | allowed | its own set is not written yet |
| Architecture reviewer |
claude-opus-5-5
real
|
Anthropic | allowed | its own set is not written yet |
claude-sonnet-5
Price in / out: $2 / $10 real
claude-opus-5-5
Price in / out: $4 / $20 real
claude-fable-5-1
Price in / out: [not read]
The two test-set runs marked real are from 23 September 2026: 13 of 13 for claude-sonnet-5 as builder, and 15 of 15 for claude-opus-5-5 as reviewer, which cost $0.0896. The prices of the two Anthropic models are read from engine/config/roles.toml on 13 October 2026; its comment cites the provider's pricing page, read 23 September 2026. Square brackets mark a figure not read yet. A new model's test set runs before its merge request can be approved; if one case fails, it does not go in.
4 The code host
Your code host is the record of the work. B Team shows it to you and writes into it; it keeps no second record.
Self-managed GitLabgitlab.com
Address of the repository
https://gitlab.com/example-organisation/volunteer-shift-planner
Connected with a token limited to this one project, with an expiry date [date]. B Team says where it stores the token and never shows it back. GitHub and others come later.
5 Where the product runs
The live volunteer shift planner. The infrastructure agent drafts changes here; a change like this is likely on the risky list, so the review level applies.
A European hosting providerYour own server
A small hosting provider in the EU, chosen when the project started. It holds the web pages and the shift data. example
6 Where B Team itself runs
On your own machine or server
A guided setup, step by step, with your code-host account and your provider keys. Each step says what it stores and where.
selected · the setup is still being designed
B Team's hosted service in Europe not yet
We intend to offer it, but not before these are measured:
Secrets kept out of files, logs and prompts not met
An audit log of who did what not built
Data policy for each project this screen is its mockup
Separation between organisations not built
Sign-in and who may do what not built
States as of 12 October 2026, from the project's own records. real
The merge request for your changes
No changes from the current settings yet. Change something above.
Propose these changes
proposes: nothing changes until you approve the merge request
Artefacts
B Team · Artefacts
Volunteer shift planner · project
Artefacts
Every change with what the reviewers said, a preview, the releases and the evidence behind each release. The development agent builds; the standard reviewers check; only you accept and approve.
See this page as
Product ownerSoftware engineerOne person, both roles
Mockup control. The human review level is set on Team, through a merge request on the project's own file, which you approve. This project is at level B. Try this page at:
Level ALevel BLevel C
Every change, with its reviewers' verdicts Five standard reviewers look at every change, whoever wrote it. Each looks at one kind of thing.
ChangeSecurityDocumentation"Done when"ArchitectureComplianceWhere it stands
The swap request screen
passed with a notepassedneeds your eyespassed with a notepassed with a note
Waits for the engineer’s review
Connect the text-message service
not opened yetnot opened yetnot opened yetnot opened yetnot opened yet
In progress, not opened as a change
Written by the engineer · task in turn 3
The shift list on a phone
passedpassedpassedpassedpassed
Live in release 4
Built by the development agent · 7 October
The sign-up form
passedpassed with a notepassedpassedpassed
Live in release 3
Built by the development agent · 1 October
example The reviewers' own test sets are not written yet, so none of their verdicts is a gate yet. The one reviewer test set that exists scored 15 of 15 real, 23 September 2026.
The swap request screen
Waits for the engineer’s review
For the aim "Swap a shift" · built by the development agent · opened today at 14:40 · cost so far $0.82 example
What changes, in plain words
- A volunteer who cannot make a shift picks another volunteer and asks them to take it. It works on a phone.
- The other volunteer receives the request as a message and can see who asked.
- Not in this change: accepting or declining the request, and telling the coordinator. Those come in the next two tasks.
Checked against the "Done when" of the aim: the first item is met; the other two are the next tasks. A reviewer cannot judge whether the screen is easy to use on a phone. That is why you try it below.
What each reviewer said Each gives the file and line it rests on.
Security passed with a note
The screen sends the other volunteer’s phone number to the browser. It is not needed here.
Cites web/shifts/swap.html line 58
Its own test set: not written yet
Documentation passed
Screen texts match the wording of the volunteer guide. The guide itself is a later task.
Cites docs/guide.md line 7 to 19
Its own test set: not written yet
"Done when" needs your eyes
The first item looks met from the code. The reviewer cannot judge whether the screen is easy to use on a phone. Try it.
Cites web/shifts/swap.html line 12 to 40
Its own test set: not written yet
Architecture passed with a note
Two texts are written into the page instead of the shared text file the other screens use.
Cites web/shifts/swap.html line 31
Its own test set: not written yet
Compliance passed with a note
The request stores the first volunteer’s phone number. How long phone numbers are kept is the open finding on the Compliance page.
Cites web/shifts/swap.html line 58 and your data policy
Reviewer not built yet; this verdict is an example
Be careful what this means. Every reviewer is a separate agent that did not write the change. A reviewer catching a real fault has not been measured yet. The builder's test set scored 13 of 13 real, 23 September 2026; the reviewers' test sets are not written yet.
The project's own checks
These run as code, without AI. They are the commands your project lists in its own file.
Tests41 passed, 0 failed
Style checkpassed
Texts in both languagesEnglish missing: next task
example The latest run of all checks is on Feedback.
Files it touched
The task said it would touch web/shifts/ and web/texts/nl.json.
web/shifts/swap.html said so
web/shifts/swap.css said so
web/texts/nl.json said so
web/shared/menu.html did not say so
One file was touched that the task did not name. It is counted, and the engineer sees it. example
Publications that come with this change Going live does not publish anything to anyone. Each publication needs its own approval.
Drafted by the documentation agent. They unlock when the change is live, so nobody is told about a screen that does not exist yet.
Newsletter draft
"You can now ask another volunteer to take your shift, from your phone."
Goes to the volunteers’ mailing list (212 people, example figure).
Approve this newsletter
acts now: sends the newsletter to everyone on the list
Locked until the change is live.
Social post draft
"Cannot make Saturday? Ask a fellow volunteer to take your shift, right from your phone."
Goes to the organisation’s own account.
Approve this post
acts now: posts it publicly, and it stays public
Locked until the change is live.
Human review level B
The planner marked this change risky, because it handles a phone number. An engineer reads the code before you accept.
The engineer has not read it yet
1 · Try it
Opens the change in a preview. It is not the live product, and nobody who uses your product sees it.
previews: not built yet
Try it in a preview
2 · Accept and put it live, or send back
Accepting says the change is good, and putting it live sends it to the people who use your product. While you are also the approver, these are one button.
Accept and put it live
acts now: merges the change in your code host under your own sign-in, and releases it
Locked until you have tried it in the preview.
When the organisation names a separate approver later, accepting and putting it live become two steps, and the second one is theirs.
Or send it back, with a reason
What should change?
Send back with this reason
acts now: your decision is written on the merge request in your code host
Releases and their evidence packs A release is what went live together. Its evidence pack is what a funder, a board or an auditor can check afterwards.
Release 4 · 9 October
Hide the evidence pack
The shift list on a phone
ChangesThe shift list on a phoneApprovalsAccepted and approved by the product owner on 8 October; the engineer read the code.FindingsTwo notes, both resolved before release.Models and costTwo model providers · $1.37 (example)Data policyNo change in this release.Who had accessThe product owner and the engineer.
Download this pack
export: not built yet
acts now: gives you a file; nothing changes
example The pack is meant to come in open formats that last, so a public body can file it in its archive.
Release 3 · 2 October
Show the evidence pack
The sign-up form
Where the agents stop. Agents draft the change, the documentation and the publications. The reviewers check. Merging and publishing are gates only a person passes, and an agent cannot pass them for itself.
Feedback
B Team · Feedback
Volunteer shift planner · project
Feedback
For each aim, a few open questions about whether it works for the people it is for. The testing agent drafts them; you answer them by hand and write what you learned back to the aim.
See this page as
Product ownerSoftware engineerOne person, both roles
User tests come later. Tests with the people the product serves, such as the volunteers, are not part of B Team yet. Until they exist, you answer these questions yourself, for example after trying the product with a stakeholder such as the coordinator. Nothing on this page starts work by itself: what you learn only changes the plan when you decide it does.
Aim: Swap a shift 2 open questions
Today volunteers have to phone the coordinator when they cannot make a shift. Drafted by the testing agent from this aim's "how we will know it worked". One to three questions per aim, each in the form "If we …, will …?".
Question 1 open
If we let a volunteer ask another volunteer to take their shift from a phone, will they stop phoning the coordinator?
What did you find?
YesPartlyNoNot tried yet
Who tried it, and when
For example: with the coordinator, Tuesday afternoon
What happened, in your words
Something was broken or wrong. The engineer reads this.
Save my answer
acts now: saves your answer in your code host; it starts no work
Question 2 open
If we tell the coordinator only when a swap is accepted, will they still know who is on each shift?
What did you find?
YesPartlyNoNot tried yet
Who tried it, and when
For example: with the coordinator, Tuesday afternoon
What happened, in your words
Something was broken or wrong. The engineer reads this.
Save my answer
acts now: saves your answer in your code host; it starts no work
What was learned about this aim
What you learned goes back to the aim, so the next person and every agent reads it with the aim. It changes no task by itself.
7 October, with the coordinator example
The "Ask a volunteer" button was easy to find. The date was missed twice, so the screen now shows the date first.
2 October, with two volunteers example
Both said they would still phone if the other person did not answer within an hour.
Write what you learned back to the aim
For example: volunteers found the button at once, but missed that the coordinator is told only after the swap is accepted.
Write it back to the aim
acts now: adds a note to the aim in your code host; it changes no task
Aim: Reminder by text message no questions yet
There is nothing to try until the first change for this aim is opened. The testing agent drafts its one to three questions then, and they appear here.
The project's checks
The testing agent runs the checks your project lists in its own file, whenever a change is opened. They run as code, without AI. Latest run: today at 14:52, on "The swap request screen".
Tests41 passed, 0 failed
Style checkpassed
Texts in both languagesEnglish missing: next task
Last run on the live product (9 October)38 passed, 0 failed
example A passing check says the code does what the tests say. It does not say people can use it. Only trying it tells you that, which is what the questions are for. See the change itself on Artefacts.
Who does what here. The testing agent drafts the questions and runs the checks. You, the product owner, answer by hand and write back what you learned. The engineer reads what reports a fault. No agent starts work because of an answer.
Compliance
B Team · Compliance
Volunteer shift planner · project
Compliance
Where the project stands on security and on the law, row by row, in plain words. The security reviewer and the compliance reviewer draft each state; a person decides on every finding.
See this page as
Product ownerSoftware engineerOne person, both roles
Met
13
a reviewer checked it and found nothing
Open
1
a reviewer checked it and a finding waits
Not checked
9
no reviewer has looked at it in this project yet
Rows in all
23
security and compliance together
example states Every state on this page is an example. In the real page each state comes from what a reviewer measured, with the date. The compliance reviewer is not built yet, and the reviewers' own test sets are not written yet, so "not checked" is the honest state for most rows today.
The one open finding open, with the engineer example finding
Phone numbers are kept longer than needed
Found by the compliance reviewer on 13 October · assigned to the engineer · decided by the product owner, who is responsible for compliance
The shift planner keeps every volunteer's phone number for as long as the account exists, also for volunteers who left months ago. Your data policy says personal data is kept only as long as it is needed, and no reason is written down for keeping the numbers of people who have left. Privacy law (the GDPR) asks the same.
Cites db/volunteers.sql line 14 and your data policy on Resources
The reviewer's suggestion. Delete a volunteer's phone number 12 months after their last shift, or write down why it is needed for longer. a suggestion, not a decision
Your decision
The default needs nothing from you: the engineer fixes it. You can instead accept it as it is, or say it is not a problem. Both need a written reason, which is kept with the finding.
Your reason (needed to accept it or to say it is not a problem)
Why is this acceptable?
Accept it as it is
This is not a problem
acts now: your decision and reason are written on the finding in your code host
Every row Show:
AllOpenNot checkedMet
Met: a reviewer checked and found nothing. Open: a reviewer checked and a finding waits. Not checked: nobody has looked yet, which says nothing about whether it is fine.
Security
What keeps the project safe. Drafted by the security reviewer.
Agents get only the tools they need
The agent that writes pages cannot also send mail or touch the servers.
checked by the security reviewer, 13 October (example)
met
Each agent and service has its own narrow key
No key is shared between projects, and a key opens only what its holder needs.
checked by the security reviewer, 13 October (example)
met
Keys and passwords stay out of the code, the prompts and the logs
They live in a safe place and are handed out only when needed.
checked by the security reviewer, 13 October (example)
met
Code that agents run is kept apart from your computers
It runs in a closed box that cannot reach the rest.
not checked in this project yet
not checked
The internet is closed unless a role needs it
An agent reaches only the places its job needs.
checked by the security reviewer, 13 October (example)
met
Text from outside is treated as information, never as an order
A web page or message that reaches an agent cannot make it do something new.
not checked in this project yet
not checked
Publishing, merging and going live need a person
An agent cannot pass these steps for itself.
checked by the security reviewer, 13 October (example)
met
Libraries the project uses are pinned and scanned for known weaknesses
So a bad update cannot slip in unseen.
not checked in this project yet
not checked
Every action is written to a log that cannot be changed quietly
So you can see afterwards who did what.
not checked in this project yet
not checked
Spending limits and a stop button
A job that runs away is stopped, and you can stop the whole project.
checked by the security reviewer, 13 October (example)
met
What an agent writes is checked before it is used
Output is validated, and never run or published unreviewed.
checked by the security reviewer, 13 October (example)
met
Compliance
What privacy law, AI rules, accessibility and your clients ask. Drafted by the compliance reviewer.
You choose which AI providers may see your data
Your data policy lists them, with where each one runs.
checked by the compliance reviewer, 13 October (example)
met
A provider outside the EU is off unless you turn it on
Turning it on shows the legal basis and needs your explicit choice.
checked by the compliance reviewer, 13 October (example)
met
Personal data is kept no longer than needed
Phone numbers are kept longer than needed. One finding waits.
checked by the compliance reviewer, 13 October (example)
open
Read the finding
The makers never use your issues or prompts for their own purposes
Your work stays yours.
not checked in this project yet
not checked
A description of your data flows you can use in your own privacy assessment
You decide whether one is needed; B Team helps you write it.
not checked in this project yet
not checked
Agents do not build features that profile individual donors
Such a job needs a named responsible person and an assessment first.
checked by the compliance reviewer, 13 October (example)
met
Every change records which model and provider wrote and reviewed it
And it is labelled as made by an agent.
checked by the compliance reviewer, 13 October (example)
met
A named person approves everything an agent produces
No output is accepted without a person.
checked by the compliance reviewer, 13 October (example)
met
Staff get short material on what agents can and cannot do
Given at setup.
not checked in this project yet
not checked
Pages meet the accessibility standard (WCAG 2.1 level AA)
So people who use a screen reader or only a keyboard can use them.
not checked in this project yet
not checked
Each change keeps its test result, reviewer findings, approver and rollback plan
So a change can be explained and undone.
checked by the compliance reviewer, 13 October (example)
met
You can leave: export all your data, settings and code
In open formats, at no charge.
not checked in this project yet
not checked
Who is responsible
The product owner holds the role
Nobody else holds the role of person responsible for compliance, so it is the product owner's. The compliance reviewer helps. Another person can take the role later; until then every finding is decided by the product owner.
Who drafts what
The security reviewer looks at the security rows. The compliance reviewer looks at the rows on privacy, AI rules and accessibility. Each writes the state and the file and line it rests on. Neither can close a finding: only a person does.
Proof you can hand over
Each release has an evidence pack: the changes, approvals, findings, the models used and the cost. It is for a funder, a board or an auditor who wants to check.
Open the releases on Artefacts
Not legal advice. This page shows what the reviewers measured against written rules. Whether a rule applies to your organisation is a question for a lawyer.