Week 2

This week you find your client, frame their problem, and write the proposal that Phase 1 depends on. Everything in the first class is in service of the second, where Phase 1 is delivered.

Before the first class

Nothing new. Finish anything left over from week 1: the tools installed and signed in, your accounts created, and your GitHub username on the roster workbook. See the setup guide.

The first class

Three blocks, in this order. These concepts are quizzed — not the tools, the ideas underneath them — and you are asked about them individually.

Finding a project

• A business problem, not a solution. "We will build an app" is not a problem.
• Where projects come from. Someone you already know who runs something: a family business, a society, a clinic, a department — someone who will still answer the phone late in the semester. Proximity beats ambition.
• The four questions to ask a client. What happens today, step by step? What goes wrong, and how often? What do you do when it goes wrong? Who else touches this besides you? Ask all four before proposing anything at all.
• Do not lead the witness. A question that suggests its own answer gets a polite yes and teaches you nothing.
• What an accepted proposal contains, and what gets rejected — the five ways a proposal comes back.
• What you must tell your client. That this is a coursework prototype built by students, that it is publicly visible at a public address, and that it is unsupported after the final week of the semester. Say it in the first meeting, not after the semester ends.

Working with AI

• Why you must hold the concepts. You cannot phrase an instruction for a concept you do not have, and you cannot judge an answer you do not understand. Quotas also run out, usually mid-phase, and part of this work is yours to do by hand.
• Prompting, in three moves. Give it the context it cannot see — the file, the schema, the error. Say what "done" looks like before it starts. Ask for the plan before the code.
• How to verify. Run it on the real path, not the happy path. Feed it bad input: empty, wrong type, a duplicate. Read it, and be able to say what each part does. The failure mode is not code that breaks; it is code that looks right and is confidently wrong.
• You own what you ship. The agent wrote it; you are answerable for it, including the parts you did not type. Misconduct here is the inability to explain your own system, not the use of a tool.

Every pull request carries a declaration, in one of these two forms:

AI-Assisted: <tool> / <what it produced> / <what you changed>

AI-Assisted: none

Both are fully legitimate. Not declaring is the offence.

The repository

• Six words. A repository is the team's folder plus its entire history. A branch is a line of work that does not disturb anyone else's. A commit is a saved point carrying your name and a message. A pull request says "here is my work, please look at it before it becomes real". A review is a teammate reading it and saying what they checked. A merge makes it part of the real thing. Branch › commit › pull request › review › merge is the whole working method of this course.
• Three rules, and only three. One branch per story, named after the task. Nobody merges their own work — a teammate reads it and says what they checked. The Client Lead accepts: a story is not done because the person who built it says so.
• The commit form — a type, a scope, what changed, and the story ID, so the work traces back to the board.

feat(orders): add duplicate-order check  [#14]

One repository per team, used through GitHub Desktop: buttons, not typed commands. Work that is invisible in the repository did not happen, and every student commits under their own account.

Slides

• Finding a project, working with AI — first class
• Your repository, and the team agreement — second class

Every deck for the term is on the slides page.

Before the second class

• Hold your first client meeting. Read the interview article below before it, not after it.
• Draft docs/proposal.md in your team repository, in the eight required sections and nothing else. The required shape is on the project proposal page, with a worked example that would be accepted and three versions that would be returned.
• Put the same content on your page. Your page is already live — edit docs/index.html and merge, and it updates itself. You are questioned from that address in the second class — nobody presents. It is checked as done or not done, and it is not graded on how it looks — spend this week talking to your client, not making it pretty. The steps are on publishing from your repository.

The second class

Bring your laptop. The class opens with your own repository on screen and runs in three parts: your first pull request, signing the team agreement, and the Phase 1 delivery.

Your repository exists

It was created for you at github.com/isom472-fall2026/ — team1 to team5, by team number. Accept the invitation in your email or your GitHub notifications before the class; until you accept, you cannot push anything.

Read docs/setup.md in your own repository first — your GitHub identity, which is Settings › Git › Author in GitHub Desktop and decides whether your commits count as yours, then your public page and Supabase — then docs/how-we-work.md, which covers the loop and every phase.

Your page is already published

Your proposal page is live now at isom472-fall2026.github.io/<your-repo>/docs/, showing placeholder text until you edit it. There is no publish button and no setting to find: edit docs/index.html, open a pull request, merge it, and the page updates by itself about a minute later.

The loop, once, together

Branch › commit › pull request › review › merge, done by the whole room on one small change each. You cannot push straight to main — GitHub refuses it, on purpose, for every team repository. Everything reaches main through a pull request that somebody else approved, and nobody approves their own.

The same walk, with every button: your first change, twice — by hand and with Antigravity.

The team agreement, signed twice

Fifteen minutes, with your team sitting together and your laptops open. docs/team-agreement.md holds the hours each of you can give, how to reach each other, and what the team does when a member goes quiet. Every member signs it in class, and it is part of Phase 1.

A signature here is a commit from your own GitHub account, not typed text. You make two of them: one by hand, and one through Antigravity. The second is the check that Antigravity works on your laptop — a laptop that cannot do it is one we fix on the day, not in week 6.

The order, for the whole team:

1. The Phase 1 Lead asks Antigravity to open one issue: everyone signs the team agreement, and Antigravity works on every laptop, with a checklist naming each member.
2. The Phase 1 Lead makes the branch <issue-number>-sign-the-team-agreement. Everything below happens on it.
3. Each member, by hand: fill in your own row — name, role, hours, how to reach you — type your name in Signed — by hand, commit it yourself and push. Touch nobody else's row.
4. Each member, through Antigravity: ask it to write your GitHub handle and today's date in Signed again — through Antigravity and commit that one file. You push it — the agent does not.
5. The Phase 1 Lead opens the pull request. A teammate who did not open it reviews it and merges.
6. The Phase 1 Lead asks Antigravity to check every row and every commit's author, comment what it checked, and close the issue.

The three prompts are written out in docs/prompts.md in your own repository, under Signing the team agreement. Copy them from there rather than retyping them.

If your commit shows a grey avatar, your git identity is not your GitHub account and the commit does not count as yours — fix it in GitHub Desktop under Settings › Git › Author, with the screenshot on the setup guide, and commit again. If Antigravity does nothing, say so in class: sign by hand, finish your row, and stay two minutes at the end. If Approve is greyed out on a teammate's pull request, you have not accepted the repository invitation — accept it at github.com/notifications and reload. Until you do, GitHub lets you comment and nothing more, so your review cannot unblock the merge.

The proposals

Nobody presents. Your page is opened from its live public address and you are questioned from it directly, for seven minutes. The decision is said out loud — accepted, or returned with a reason and a date. Every team hears the other teams' problems, which is the point of running it that way.

• A worked example — a finished Phase 1 in a real repository: the proposal, the published page, the signed agreement, and one reviewed pull request.
• Your first change, twice — the loop by hand, then with Antigravity.
• Your repository — the rules and the layout.
• Publishing from your repository — every button, with screenshots.

Due this week

Phase 1 — a formed team, a verified environment, and a proposal the instructor accepts. 5 marks.

• A formed team, with roles recorded on the roster workbook.
• A verified environment — the tools installed and signed in.
• The team agreement signed in class by every member, twice — by hand and through Antigravity.
• A proposal the instructor accepts, in the required shape — as docs/proposal.md, and published as a page from your repository.
• Rejected proposals come back within three calendar days.
• The first resubmission carries no penalty; a second caps that component at half.
• No team passes the end of week 3 without an accepted proposal. At that point a project is assigned from a standing list, that component scores zero, and the rest of Phase 1 is unaffected.

A rejection in week 2 is the course working as designed. See the deliverables page for the exact dates.

Read

About two hours of required reading this week — the heaviest of the term, and deliberately front-loaded so the later weeks are build time.

• Read User Interviews 101 before your first client meeting, not after it.
• Read the concepts in About Git and ignore the typed commands — this course uses GitHub Desktop.

Use

• The project proposal — the required shape.
• A worked example — a finished proposal, published, in a real repository.
• Your first change, twice — by hand, and with Antigravity.
• Publishing from your repository — how the page gets an address.
• Your repository — the rules and the layout.
• Deliverables — the exact dates.