Team roles

Each member of a team holds one standing role for the whole semester and owns exactly one artifact. On top of that, one member leads each phase. This page says what each role owns, what it produces, how it uses the two AI tools, and what it is expected to catch in other people's work.

Teams choose their own roles at the setup session and record them on the roster workbook. See Setup for how that session runs, and Deliverables for what is due and when.

Client Lead

What you own

The client relationship and what the system must do.

Your artifact, and where it lives

The backlog: user stories, each with acceptance criteria, kept as issues on the team repository board. The requirements section of docs/proposal.md is where the first version of it is written — see the proposal template.

Your rhythm through a sprint

• At the start — agree with the team which stories are in this sprint, and write acceptance criteria for each one before anybody builds it.
• During — answer questions about what the client meant. Talk to the client when the answer is not yours to give.
• At the delivery — accept or reject each story. You are expected to reject some. What is not finished goes back to the backlog and you decide where.

Using AI for this role

This is planning and wording, so it is Gemini Enterprise work. Paste in your raw notes from the client meeting, the stories already in the backlog, and the wording of criteria the team accepted last sprint, so the new ones come out in the same shape.

Ask for stories drawn from what the client actually said, and for each criterion to name a screen, an action and a result someone else can observe. Before you trust a criterion, read it as if you were the person who has to check it at the delivery and did not write it. If you cannot say what you would open and what you would look at, it is not a criterion yet.

Here are my notes from the client meeting, unedited.
Turn each request into a user story with acceptance criteria.
Every criterion must name a screen, an action, and a result I can
observe without reading the code. If a request is too vague to write
a checkable criterion, list it as an open question instead of
guessing what the client meant.

What you check on teammates' pull requests

That the merge names the story it belongs to, and that it does what that story says — not a nearby thing that was easier. Watch for work that quietly grows past its story, and for a pull request that closes a story whose criteria are not all met.

What you are not responsible for

How it looks or how the screens flow — that is the Design Lead. Or whether it is deployed — that is the Build Lead. You decide whether it is the right thing, not whether it is the right build.

Design Lead

What you own

What it looks like and how it flows.

Your artifact, and where it lives

The HTML prototype and the screen list, in prototype/. It is built in Gemini Enterprise, committed to the repository, and opened in a browser. A prototype nobody can open is a description of a prototype.

Your rhythm through a sprint

• At the start — draw the screens the sprint's stories need, and agree with the Data Lead on anything that crosses between you.
• During — keep the interface consistent as other people add features. You are the one who notices that screen five stopped matching screen one.
• At the delivery — the prototype and the running system agree, or the difference is deliberate and written down.

Where your work meets someone else's

Where your screens meet someone else's data, the shape of what passes between you is already written in two places, and there is no third document to produce. The schema says what the data is — the table, its columns, which of them may not be empty. The acceptance criteria on the story say what your half is handed and what it does when something is missing. Agree both with the Data Lead before either of you starts, and change the schema only in a pull request you have both read.

Using AI for this role

Gemini Enterprise builds prototypes well and cannot touch your files, so you paste the result in yourself and see exactly what you committed. Paste in an existing page as the pattern to copy, the story and its acceptance criteria, and the list of fields that actually exist. Ask for one more page in the same markup and the same class names.

Before you trust a screen, check every field on it against the schema with the Data Lead. A field the prototype shows and nothing stores is a promise the team has to keep later.

Below is an existing page from our prototype. Follow it exactly:
same markup, same class names, same spacing. Here is the next story
and its acceptance criteria, and here is the full list of fields
that exist. Produce one page. Use only fields from that list — if
the screen needs something that is not on it, stop and name it
rather than adding it. Include the empty state and the error state.

What you check on teammates' pull requests

Whether this merge invents a second way to do something the prototype already solved, and whether the screens still match each other after it lands. You are also the one likely to catch a field shown on a screen that nothing stores, and a stored field no screen ever shows.

What you are not responsible for

Whether the data behind a screen is stored correctly or protected — that is the Data Lead. Or whether the system is deployed — that is the Build Lead.

Data Lead

What you own

The data and its structure: what the app records, and who may see what.

Your artifact, and where it lives

The schema and seed data in Supabase, and two files in the repository that must always agree: db/schema.sql (the tables, keys, row level security and policies, runnable on an empty project) and docs/schema.md (what a row in each table means, how the tables relate, who may read and write and why — no column lists). Every change to a table arrives as a reviewed pull request that edits both, so the team can see what changed and when. A change made by clicking in the Supabase console and never committed did not happen as far as the rest of the team is concerned.

Your rhythm through a sprint

• At the start — read the sprint's stories against the current schema. If it has to change, change it once, early, and tell everyone the new names.
• During — answer field questions, and keep seed data realistic enough to test with.
• At the delivery — check row-level security on every table this sprint touched. Every sprint, not once.

Using AI for this role

This is file and schema work, so it is Antigravity. It reads db/schema.sql and proposes changes to it, and it will act on the database without asking inside your project folder, prompting you only when an action crosses outside it. Tell it to read the current schema before proposing anything, read the SQL it produces before you run it, and update docs/schema.md yourself.

Verify three things every time: that every column it names exists and is spelled the way your schema spells it, that the constraints you meant are present, and that the new tables have policies saying who may read and who may write.

Read the current schema before proposing anything.
Write the change to db/schema.sql for the story below. For every new table
include the not-null and foreign-key constraints, a uniqueness
constraint where duplicates would be wrong, and row-level security
policies. In a comment, list which role may read and which may
write each table. Do not use a column name that is not already in
the schema — if you need a new one, add it in db/schema.sql and tell
me, so docs/schema.md is updated in the same pull request.

What you check on teammates' pull requests

Any query that touches a table you changed, any new table that arrives without a policy, and seed data committed with something in it that should not be in a repository. You are the one likely to catch that a feature reads a table it should not be able to see at all.

What you are not responsible for

What a screen shows or how it flows — that is the Design Lead. Or whether a story counts as done — that is the Client Lead.

Build Lead

What you own

That it actually runs.

Your artifact, and where it lives

The deployed system at its public address, plus release notes committed to the repository, one short entry per sprint: what went out, and anything known to be broken. How to publish and where the address comes from is in the publishing guide.

Your rhythm through a sprint

• At the start — make sure every member can run the system on their own machine. A teammate who cannot start it cannot deliver a story.
• During — keep the main branch deployable. A branch that cannot deploy on the day of the delivery becomes everyone's problem.
• At the delivery — deploy, open the public address on a device that is not yours, and write the release note.

Using AI for this role

Antigravity, because this is files, configuration and commands. Paste in the full build log when something fails — unedited, including the lines you think are noise. Ask which line first shows the failure, and ask for one change at a time with a way to tell whether it worked.

Verify by running it. The only evidence that the system runs is the system running at its public address, opened by you. Also read every configuration file the agent edited, line by line: this is where keys and addresses get written into places that are committed.

The deploy failed. Here is the complete build log, unedited.
Tell me which line first shows the failure and what caused it.
Do not change any file yet. Propose one change, and tell me exactly
what I should see if it worked.

What you check on teammates' pull requests

Anything that changes how the system starts, builds or deploys. A credential or key that should never be committed. A new dependency added to solve one small thing. You are the one likely to catch that a merge runs on the author's machine and nowhere else.

What you are not responsible for

Whether a feature is the right feature or meets its criteria — that is the Client Lead. Or finding the defects in it — that is the Quality Lead.

FinOps Lead

What you own

What the AI work costs, and what the team changed as a result.

Your artifact, and where it lives

The Sprint FinOps Ledger, at docs/finops-ledger.md, one section per sprint. It lives in the repository and is committed. It is never kept in a spreadsheet somewhere else and copied in later.

Your rhythm through a sprint

• At the start — say what the team is going to watch this sprint, so people notice it while it happens.
• During — record rows as the work happens. This is the whole job, and it is the part that gets skipped.
• At the delivery — write the sprint's section, including what the team would do differently, and commit it.

Using AI for this role

There is nothing to generate here. This role observes. Every other role asks a model to produce something; you read what actually happened and write it down. The ledger's value is that it is a record, and a record that was generated is not one.

What you may use a tool for: asking Antigravity to list the commits in a sprint so you can see which stories the work landed under, or asking Gemini Enterprise to tighten the wording of a row you wrote. What you may not do is ask either tool what a story cost, which model was used, or what the team should say it would do differently.

What you check on teammates' pull requests

That AI use is declared, and that the declaration matches the change. You are also the one likely to notice the expensive habits: the whole codebase pasted in to answer a one-file question, the same failed attempt repeated six times with no change of approach, the largest model reached for by reflex.

What you are not responsible for

Making the technical choice — that belongs to whoever is building, and to the Build Lead. You record the choice, the reason, and what it cost.

Quality Lead

What you own

Finding defects in the running application.

Your artifact, and where it lives

Bug issues in the team repository — issues on the board, not files in a folder. Each one carries steps to reproduce and is tracked to a disposition: fixed, deferred, or not a defect. All three are acceptable endings. None of them is leaving it open. A list of open bugs nobody closed is not quality work.

Your rhythm through a sprint

• At the start — read the sprint's stories and their acceptance criteria, so you are testing against what was promised.
• During — test the running application, not the plan. File issues as you find them, with steps someone else can follow.
• At the delivery — every issue you filed has a disposition, and the deferred ones say who deferred them.

Using AI for this role

Antigravity writes tests against real files. Gemini Enterprise turns a rough note into a report someone else can follow. Paste in the acceptance criterion in the client's words, then the code — in that order, and say the tests come from the criterion.

Before you trust a test, ask what would have to break for it to fail. If nothing would, it is not a test. Before you trust a bug report, follow your own steps on a fresh start and see the defect again.

Here is the acceptance criterion, in the client's words.
Here is the function that is supposed to satisfy it.
Write the tests from the criterion, not from the code. Include the
empty case, the duplicate case, and the case where the user is not
allowed. If the code does something the criterion does not require,
do not assert it — list it separately as a question for me.

What you check on teammates' pull requests

Whether this merge breaks something that already worked, and whether a pull request that closes a bug issue says how you would see it fixed. You are the one likely to catch tests added alongside a feature that assert nothing, and a fix that was never reproduced in the first place.

What you are not responsible for

Fixing what you find. Whoever owns the story fixes it, and the Client Lead decides whether it is worth fixing now or goes back to the backlog.

How the roles fit a team of four, five or six

Phase Lead — the rotating role

What you own

The phase. You run it: keep the board current, make sure the delivery lands on time, and act as the instructor's point of contact for that phase. You hold this on top of your standing role, which does not pause while you lead.

Your artifact, and where it lives

The phase delivery note, at docs/delivery-notes/phase-1.md through phase-6.md, one file per phase. It says what was delivered, who did what, and links to the stories. Written by the lead of that phase, committed in that phase — not reconstructed later by somebody else.

You also cut that phase's tag. At the due date the repository is tagged phase-1 through phase-6, and the tag is what is graded — so work pushed after you cut it is not in it. The repository page has the wording.

The rotation

There are six phases. A team of six has everyone lead once. A team of five means one member leads twice. A team of four means two members do. Decide the whole rotation at the setup session, not one phase at a time — the roster workbook asks for all six.

Teams choose their own roles and their own rotation and record both on the team roster workbook (.xlsx). The Phase 1 Lead emails the completed workbook to the instructor at mo.almarzouq@ku.edu.kw. The instructor then creates the team's repository and invites every member to it. Nothing else starts until that happens, so it is the Phase 1 Lead's first job.

Using AI for this role

The delivery note is a record of what happened, like the ledger, so the same rule holds: read the repository, then write. Antigravity can list the commits and the closed stories in the phase, which is a faster way to see what landed than asking teammates to remember. What it cannot tell you is who did what and whether the delivery was actually on time. Do not ask a model to write the note; ask it to show you the phase.

What you are not responsible for

Doing the phase's work. You are not the manager of your teammates and you do not own their artifacts. You own that the phase is delivered and that the note says truthfully what happened in it.

What holds for everyone

Whatever role you hold, these apply. They are the reason a role is a lens and not a job description.

• Take at least two named stories off the backlog every sprint, and build each one end to end: agree with the Client Lead what done means, follow the Design Lead's pattern, follow the Data Lead's rules, build it, get a teammate to review the merge, and show it at the delivery. That means every member does requirements, design, data and building every sprint, by construction.
• Review teammates' pull requests. Nobody approves their own. A review says what you checked, not that you looked.
• Commit under your own account. Work that is invisible in the repository did not happen. See the repository rules.
• Declare AI use on every pull request — the tool, what it produced, and what you changed — or AI-Assisted: none. Both are legitimate. Not declaring is the offence.
• A role is what you own, not the only thing you do.