Friday Studio¶

Friday is not a lecture and not a lab on a toy problem. It is the hour your team works on your own client project, in the room, with a TA who knows your project.

How it runs¶

Same room, same time, whole class. Thirteen teams work in parallel, seated in three zones by TA. You sit in the same zone every Friday.
Each TA owns four or five teams for the entire semester. You get the same TA every week, at every checkpoint. They know your project's history, which is the point.
Every studio has one scoped objective, summarized on the Schedule and set out in full below. It is the move you saw demonstrated on Project Pulse in Wednesday's lecture, now applied to your code.
TAs circulate. They are there to unblock and to review, not to lecture.
On three Fridays, studio is your checkpoint presentation to your TA. That week's objective moves to out-of-class team time, and the checkpoints say what you present. Checkpoint 2 is the exception: you book it with your TA outside class in week 11.

Attendance in studio counts the same as lecture attendance: each absence is a 1% grade reduction.

Adapt Project Pulse to your project¶

Every lecture teaches on Project Pulse: Java, Maven, Spring Boot, and Vue. Your project is probably built on something else, and that is fine. When a studio applies a concept to your project, your coding agent does the translation: it reads the module and your documents, and proposes your project's version of each Project Pulse choice. Your team decides, and you must be able to say why.

Give the agent the context: the module's URL, your specification, your architecture-of-record, your charter, and one line on your stack and where each part lives. Then start from this prompt:

Read <module URL>. It teaches <topic> on Project Pulse, a Java, Spring Boot,
and Vue project. Our project is <stack, and the folder each part lives in>.
Read docs/requirements/, docs/design/architectural-design.md, and our charter.

1. List each choice Project Pulse makes for this topic (<the choices the
   module names>), and the principle in the module it serves, with its section.
2. For each, propose our version. For a choice that is easy to swap (a library
   or a tool), recommend one and give its latest release date. For a choice
   that is hard to reverse (architecture, persistence, authentication, where
   the system runs), give two or three options with their tradeoffs, and do
   not pick one.
3. Say what in Project Pulse does not apply to us, and why.
4. Draft the table for our pull request description. Change no file until we
   have decided.

The table goes in the description of the pull request the adaptation produces:

Project Pulse's choice	The principle it serves (module section)	Our choice	Why ours differs	What does not apply to us

The agent drafts it; your team corrects it. The second and last columns are your part: a row whose principle nobody on the team can explain is a row you have not understood, whatever the agent wrote.

Who decides depends on how hard the choice is to undo. An easy choice (a test library, an analyzer, a formatter): adopt the agent's recommendation only after you have run it on your own code. A hard choice: your team picks from the options and records it as a KD-* in section 9 of your architecture-of-record, with the option it rejected.

Record each decision where it lives, not only in the table: a convention in section 8.2, a key decision in section 9, and its one-line instruction in your charter, so your agent follows it next session. The week 11 gate studio is a worked example.

Teaching assistants¶

Led by Hiep Nguyen. Each TA takes four or five of the thirteen teams and keeps them all semester.

TA	Email	Teams
Hiep Nguyen (lead)	HIEP.N.NGUYEN@tcu.edu	1, 2, 5, 9, 13
Ali Gasimli	A.GASIMLI@tcu.edu	3, 6, 10, 12
Yuv Raj Pant	YUV.RAJ.PANT@tcu.edu	4, 7, 8, 11

Team numbers are on the Teams page.

Where your repository lives¶

One member owns it, under their own GitHub account. Name that person before you create anything, and write their name and the repository URL into your contract's header.

The repository is public, named cosc-40943-team-NN-<slug> to match your brief on TCU Online. Create it with a README so it has a main branch from the start. Public means your client's material does not go in it: see what belongs in the repository and what belongs in Drive.
The owner invites every other member, all three TAs, and the instructor as collaborators: nine people for a team of six, eight for a team of five. A personal repository gives every collaborator write access, which is what you want.
A Project's access list is separate from the repository's. Everyone can be on the repository and still be unable to move a card. After you create the Project and link it, the owner adds the team and your TA under the Project's own settings. This is the step teams forget, and your TA checks it from an account that is not the owner's.
The owner has to be someone continuing into COSC 40993 in the spring. If they leave the course, transfer the repository before they go. Everyone clones on day one, so no single account is ever holding your history hostage.

Once it exists, the owner turns on branch protection and the merge settings in the Git Workflow page. Everyone else reads that page before their first branch.

Environment setup is not studio work. Getting Project Pulse running on your own machine is assignment 1, and the setup steps are the place to start if yours still does not run. With 77 students and three TAs, studio cannot absorb cold installations.

Where your requirements documents live¶

In your team repository, under docs/requirements/, next to your code. Not in Google Drive, not in a shared document. Your AI teammate reads your repository and nothing else, so a specification it cannot open is a specification it cannot build from.

Blank templates are in course-templates. Copy them in once and they are yours from then on. traceability.md lands one level up, at docs/traceability.md, because from week 8 it maps design, code, and tests as well as requirements:

git clone https://github.com/tcu-cosc-40943/course-templates.git
cd your-team-repo
mkdir -p docs
cp -r ../course-templates/requirements docs/
cp ../course-templates/traceability.md docs/

If you copied requirements/ in week 3, run only the last line.

Copy them, do not fork. Each file opens with instructions telling you what the section is for, how to produce it, and how to check it; leave those in place until the document is finished, because they are context for your agent on every later pass. The Requirements as the Contract module is the reading behind them.

One of them is used before a client meeting, not in studio. client-interview-guide.md is your script for each client meeting and the record of what was said in it. Work it with your agent beforehand, take it into the meeting on the scribe's laptop, and commit it the same day as client-interview-YYYY-MM-DD.md, one file per meeting. Your repository is public, so the record names people by role, never by name, and carries no contact details or anything the client asks you to keep private; those go in your Drive (why). Everything it leaves unanswered becomes an entry in OPEN-ISSUES.md.

The Napkin drill¶

Rounds 0 and 1 ran in weeks 3 and 5; the drill is paused for the rest of the term (schedule). The frame and its rubric stay in the module, and its one rule still applies before any agent session: write yours first, then ask the agent, then diff. Prompting first anchors you on the agent's answer.

What studio is not¶

It is not a substitute for your team's working meetings. Fifty minutes a week does not build a product.
It is not office hours for the exams.
It is not a place to start the week's work from zero. Arrive having read the objective.

Each studio¶

One section per studio, in date order. If you missed one, the section says what your team did and what it produced; your repository is the record of it. What each checkpoint reviews is on the Project page; a checkpoint Friday gets a section here when the hour also has work in it, as Sep 4 and Oct 2 do. Fridays with no studio are marked on the Schedule.

Week 2, Sep 4: your team's first hour¶

Objective: a meeting slot, a signed contract in a repository, and a client meeting requested, all by minute 50. This is Checkpoint 0, verified in the room rather than presented.

Before you arrived: read your client brief on TCU Online, and finish assignment 1, due that morning.

When	What your team did
0-6	Found your team in your TA's zone.
6-15	Names, contact details, the Slack channel. Then fixed the recurring weekly meeting time.
15-25	Stood up the repository and the Projects board, in the order under Where your repository lives.
25-33	Read the brief together, wrote the three questions to ask the client first, and sent the meeting request.
33-45	Filled in the team contract as `docs/team-contract.md`. Each member signed it in the browser, in their own commit. This was the one time anyone committed straight to `main`.
40-50	Your TA cleared Checkpoint 0, while the last signatures landed. Teams already clear opened their first two issues from the brief.

What you produced: docs/team-contract.md, signed; the repository, Projects board, and Slack channel, with your TA and the instructor on each; a sent client meeting request with a date proposed.

How your TA checked it: one signature commit per member, from that member's own account; clause 1 names a day and a time ("Tuesdays" fails); clause 7 says what actually happens when someone does not deliver; the TA and instructor are collaborators and the Project opens for someone who is not the owner; the meeting request was sent, not drafted.

The repository you stood up is where everything after this lives, starting the next Friday.

Week 3, Sep 11: Napkin round 0, then the first requirements¶

Objective: your team's first hour on your client's requirements: Napkin round 0 on your own project, then the first draft of docs/requirements/, written on branches through pull requests. The hour was also the deadline to register in Project Pulse.

Before you arrived:

The repository owner turned on branch protection for main with "Require status checks to pass" left off, following Git Workflow.
A team that had met its client committed its notes as docs/requirements/client-interview-YYYY-MM-DD.md.
Everyone brought a laptop and the client brief.

When	What your team did
10 min	Napkin round 0 on your own project, committed as `docs/napkin-round-0.md` and sealed.
25 min	Copied the templates in and drafted, one person per section, each on its own branch and pull request: Background, Business Opportunity, Business Objectives (each with a number), Vision Statement, Glossary, and `OPEN-ISSUES.md`.
By 10:50	Pull requests merged, with commits from every member.

Three rules for the drafting: expect merge conflicts in vision-and-scope.md and resolve them locally; do not finish the document; do not invent content, and put anything you do not know in OPEN-ISSUES.md. A vision and scope generated by AI that nobody read fails.

Project Pulse registration closed at 10:50. The invitation came from peer.evaluation.tool.senior.design@gmail.com, which also sends the weekly activity report and peer evaluation reminders every Monday and Tuesday. Late submissions are not accepted, so keep that address out of junk: mark it "Not junk" and add it to Safe senders (Outlook on the web: Settings, Mail, Junk email, Safe senders and domains). If you never received the invitation, tell your TA.

What you produced: docs/napkin-round-0.md, sealed; the six sections in docs/requirements/; commits from every member; a Project Pulse account.

How your TA checked it: branch protection is on, business objectives carry numbers, commits come from more than one member, and every member is registered in Project Pulse.

Then week 4, with no studio. The rest of vision and scope, the feature list, the use cases, the business rules, and the start of the specification were team work in your own meeting slot, to be checked at the next studio.

Week 5, Sep 25: finish the specification for Checkpoint 1¶

Objective: bring your specification to what Checkpoint 1 reviews on Oct 2, and have your TA review one use case with you. This is the supervised hour week 4's work did not get. Checkpoint 1's other half, the architecture-of-record, comes from week 6's lectures and is drafted in the Oct 2 studio.

Before you arrive: your TA checks week 4's work on GitHub before class. Check it yourself first:

docs/requirements/ exists and has your content, not only the blank templates.
Your use cases came in through pull requests, not straight commits to main.
business-rules.md has at least one rule, with a source.
Each use case lists the BR-* identifiers that govern it in its Business Rules field, and the quality attributes that apply in Associated Information.
docs/traceability.md exists. See the copy command if it does not.

Pick your riskiest use case before class, the one most likely to break your architecture or surprise your client. It is the one your TA reviews, and the one you build first.

When	What your team does
0-3	Your TA tells you what the pre-class check found.
3-8	The frame, from the front: what Checkpoint 1 reviews, and how to split the hour.
8-50	Work the specification, one owner per piece, one branch and one pull request each. Your TA sits with each of its teams for about eight minutes to review your riskiest use case.

What to work on, as the week 4 team work split it:

Glossary and vision and scope: finish the sections week 3 left open, and bring both up to date with what your client meetings changed.
Use cases: every one written in full, extensions included.
Business rules: a source for every rule, and each rule's identifier in the Business Rules field of every use case it governs.
Constraints and quality attributes in the specification, each quality attribute with a number and a way to measure it.
Both tables in docs/traceability.md, with their checks.
OPEN-ISSUES.md: everything only your client can answer, as the agenda for your next client meeting.

The use case review. Your TA reads your riskiest use case with you against the checklist at the bottom of the use case template, most common failure first:

Is there at least one extension per step that can fail?
Can the system test every precondition?
Does every business rule appear as an identifier only?
Does every step alternate actor and system?
Does the name start with a verb?
Could a tester write test cases from this without asking you anything?

What you produce: merged pull requests that move each piece forward, and the reviewed use case revised by pull request before Checkpoint 1.

How your TA checks it: the pre-class check, the six questions on your riskiest use case, and commits from every member.

The use case your TA reviews is also your first build-context, in week 8.

Week 6, Oct 2: Checkpoint 1, and your architecture-of-record¶

Objective: your TA reviews your specification with you, which is the first half of Checkpoint 1, and your team drafts its architecture-of-record, the second half. The reading is Software Architecture, Just Enough, and assignment 2 is due before class the same morning.

Before you arrive:

Copy the architecture template into your repository. From the root of your team repository, with the course templates cloned beside it:
```
git -C ../course-templates pull
mkdir -p docs/design
cp ../course-templates/design/architectural-design.md docs/design/
```
The first line updates the copy you cloned in week 3. If you never cloned it, run git clone https://github.com/tcu-cosc-40943/course-templates.git beside your team repository first.
Section 9 of your specification has a number in every quality attribute. The architecture's requirements table is built from them.
Your use case areas are settled: listed at the top of the Use Case List in use-cases.md, with every use case in one. Every area gets a row in the architecture.

Your TA checks these two on GitHub before class. A team that fails either fixes it first, in the room, before starting the architecture. - Read Project Pulse's architecture-of-record: its Quality Goals, its architecturally significant requirements, and KD-modular-monolith, KD-relational-graph, and KD-vertical-slices.

When	What your team does
0-3	Your TA tells you what the pre-class check found.
3-8	The frame, from the front: what the weekend check reads, and the order to fill the template in.
8-50	Draft the architecture-of-record, one owner per section, one branch and one pull request each. Your TA sits with each of its teams for about eight minutes to review the specification.

The specification review. Your TA reads your specification with you against what Checkpoint 1 names: glossary, vision and scope, use cases, business rules, and the draft specification. It starts from the riskiest use case reviewed on Sep 25 and whether its revision landed.

The order to draft in. The template marks what is due now: sections 1 through 5, section 8 (both 8.1 and 8.2), and section 9. Start with the ranked table of architecturally significant requirements (section 9.1), because every other section cites it. Then the context diagram, the container diagram, and the component table, running the two checks at its end, then section 8.1, which names the trust boundary in writing. Then section 8.2: one short subsection for every concept in its table, each a rule in one sentence and the reason for it. The file that shows each rule done right comes later, once there is code; do not invent one. 8.2 is the part most teams finish after the hour, before the deadline. Write KD-deployment-shape last, with the requirement that would have forced the other answer. Your agent draws the diagrams; the ranking and the decision stay with the team.

What you produce: docs/design/architectural-design.md, merged to main by 11:59 pm Friday. Whatever is on main then is what your TA reads.

How your TA checks it, over the weekend, with feedback as one issue in your repository by 8 pm Sunday:

Every use case area in use-cases.md has a row in the component table (section 5.2).
Every external system on the context diagram appears in some "Depends on" cell.
The requirements table (section 9.1) reuses your specification's identifiers and includes at least one SEC-*.
KD-deployment-shape cites the requirement that drives it and names a rejected alternative.
Section 8.1 names the trust boundary and answers all three questions: how users authenticate, what each role may see beyond its role, and where sensitive data lives.
Nothing is designed below responsibility: no endpoints, no classes, no columns. (A convention in 8.2 that every endpoint follows, such as a URL prefix or an error format, is a rule, not a design, and passes.)
Section 8.2 has a subsection for every concept in its table, each with a one-sentence rule and the reason for it.

Fix what the issue raises by pull request, and close the issue from it. Week 7's design-of-record builds on this map from Monday.

Week 8: your first build-context, in your team meeting¶

Friday Oct 16 is a lecture this term, not a studio. Run this hour in your team's own meeting after Wednesday's lecture, and finish it by Sunday Oct 18, 11:59 pm, before your agent builds the proving slice. There is no frame from the front: this page is the frame. Your TA checks it on GitHub and replies on each issue by Tuesday Oct 20.

Objective: each pair on your team writes one use case up as a build-context, an issue that cites the use case instead of copying it, runs the questions test on it, and sorts the gaps it exposes before building. The reading is Context Engineering, sections 4.5 and 4.7, and your individual practice run was assignment 2.

Before your meeting: at least one member of each pair has a working agent session on a laptop they are bringing. Your riskiest use case is your proving slice, designed in week 7 and due running at Checkpoint 2. Your charter carries a one-line rule, citing section 8.2 of your architecture-of-record, for at least error handling and time (why). Your build-context cites them; it does not restate them.

When	What your team does
0-5	Read this section together.
5-22	Write the issues, in pairs. The pair with your riskiest use case takes it; the other pairs take the next two. A team of five runs a pair and a trio. One person writes, the other checks that the use case exists at the path you gave and that its Business Rules field is filled in.
22-38	Run the questions test, in pairs, then sort what comes back.
38-50	Pool as a team. Each pair reads out its specification pile. Questions only your client can answer go into `OPEN-ISSUES.md`. Each pair posts its sorted list as a comment on its issue.

The issue cites the use case, and the use case cites the rest. Its Business Rules field carries the BR-* identifiers and its Associated Information carries the quality attributes, so the issue does not list them again; a second list goes stale the same way a pasted use case does. Project-wide constraints (the stack, the hosting, the client's systems) belong in your charter, which the agent reads every session. Open the issue on your board and fill in this skeleton. Anything longer than a line or two under "Not yet in the specification" belongs in the specification: write it there, then cite it.

## Build-context: UC-<AREA>-<slug>

**Realizes:** UC-<AREA>-<slug> (docs/requirements/use-cases.md)
**Touches:** <paths you expect it to change, or "new:" and the path>

### Not yet in the specification
<Decided, but not written down anywhere yet.>

### Estimate
clarify and design <low>–<high> h, build and review <low>–<high> h, verify <low>–<high> h

Do not paste the use case in. A pasted use case is a second use case, and one of them goes stale.

The questions test. Open your agent at the root of your team repository, switch to plan mode (Shift+Tab in Claude Code), paste in the issue body, and then this:

Read the use case this issue cites and everything it references.
Before writing any code, list every assumption you would have to
make to implement it: rules, thresholds, terms, data, who may do
what, and which files you would change. For each one, say whether
you found it in the repository (and where) or had to invent it.

Agreeing with the list is not the output. A decision on each invented assumption is. Sort every one into a pile:

Specification. A rule, a threshold, or a term that should be written down where your client can see it. Usually the biggest pile. A new rule goes in business-rules.md and its identifier goes in the use case's Business Rules field; a rule that exists but the use case never cited needs only the second edit.
Charter. A convention or project-wide constraint about how the project runs, for your AGENTS.md, because the agent reads it every session.
Issue. True of this task only.

If everything landed in the issue pile, go around again.

What you produce: one issue per pair on your board, with its sorted list as a comment, and new entries in OPEN-ISSUES.md. Close the specification and charter piles by pull request before the agent builds from the issue. Then the use case's owner fills in the Estimate, the refined one, sized from the design's test list (how), still before the agent builds. From then on, every weekly activity report line about that use case starts with its ID.

How your TA checks it, on GitHub by Tuesday Oct 20, replying on each issue: the issue cites the use case rather than copying it or listing its rules; the use case it cites exists; the sorted list is posted; not everything is in the issue pile; the Estimate is a range in all three parts, and it was written before the first commit the agent made for this use case.

Week 10, Oct 28 and 30: catch up on your proving slice¶

Wednesday and Friday are both studio this week, and Checkpoint 2 moves to week 11. Your team demonstrates its slice to your TA in a slot you book outside class, any time from Mon Nov 2 to Fri Nov 6 (what it checks). These two hours are for getting there.

Objective: by the end of Friday your proving slice (your riskiest use case) has a merged design-of-record, is built by the agent from that design, is reviewed by a teammate against the design's test list, and is merged. Tag v0.1.0 by your Checkpoint 2 slot.

How `/design` and `/implement` work¶

course-templates now carries two commands, in .claude/commands/, that run the method's two build stages (Phase C). Each is a plain Markdown file of instructions the agent follows when you type its name. You give it a use case ID, for example /design UC-ORD-place-order.

	`/design <UC-ID>`	`/implement <UC-ID>`
What it reads	The use case (every extension), the business rules and `FR-*` it cites, the glossary, `OPEN-ISSUES.md`, your architecture-of-record with section 8 in full, the design-of-record template, the area's existing design if there is one, the existing code, and your charter	The merged design-of-record for the area, the same use case and rules, the glossary, section 8 of your architecture-of-record in full, your charter, the use case's row in `docs/traceability.md`, and the code the design points at
What it does	Drafts every section of the template: the sequence diagram, components, the API contract, key decisions, the data change, and one test row per flow. Lists every point it had to assume, and challenges anything in the specification that looks wrong	Builds on a branch in readable commits: any needed refactor first, then the trunk (shared code), then one commit per leaf. Writes a test for every row of the design's test list, checks the diff against section 8, runs the suites, and updates the traceability row
Where it stops for you	After the draft: you answer its assumptions and accept the shape before it writes `docs/design/<area>.md`	Before a refactor the design did not name, and after the trunk commit, so the owner reads it and says what it changed
What it leaves you	The design file, the traceability row set to `📐 Designed`, any specification fix, and a pull request description with the questions test	Code and tests on a branch, the traceability row's Build and Verify set honestly, and a pull request description mapping each test-list row to its test
What it never does	Write code, or approve its own design. A teammate who did not write it reviews and merges the pull request	Build from an unmerged design, add a dependency nobody checked, or approve its own work. A teammate reviews the pull request

Run each one in a fresh session (/clear first), so the agent reads your documents rather than an earlier conversation. Read both files before you run them; they are short. On Copilot CLI, follow their phases by hand, as a checklist.

Make them yours. They are your team's files once they are in your repository, so change them by pull request like any other file the agent reads: point them at the paths your project actually uses, add your stack's test commands and conventions, add a check your reviews keep catching, or drop a step that does not fit your project. Keep the stops for a person (the accepted shape, the trunk read, a teammate's merge), because those are where your judgment goes in. Say in the pull request what you changed and why.

Before Wednesday: at least two members bring a laptop with a working agent session in your team repository. Pull course-templates (git pull in your clone of it, or clone it as in where your requirements documents live). Know which use case is your slice, and which of these your team is in, because it decides your Wednesday:

Your slice today	Wednesday	Friday
No design yet	Run `/design`	`/implement`
Design pull request open, not merged	A teammate reviews and merges it in the first half hour; then the questions test if it was skipped	`/implement`
Design merged, not built	Questions test on it, fix what it finds; then the Checkpoint 2 items that are not code	`/implement`
Built and merged already	The Checkpoint 2 items, then tag `v0.1.0`	`/design` your next use case by its Release order

Your TAs run both hours. Ask your TA in the room, and post anything the room cannot settle in your team's Slack channel.

Wednesday Oct 28: install the commands, then the design¶

When	What your team does
0-10	Install the commands by pull request. One member copies them in, opens the pull request, and a teammate merges it.
10-45	No design merged yet: the slice's owner and a partner run `/design UC-<AREA>-<slug>`. Read the draft, answer every assumption it lists (a question only your client can answer goes into `OPEN-ISSUES.md`), accept the shape, then run the questions test in a fresh session (its prompt is the last section of the template). Design already merged: run the questions test on it in a fresh session and fix what it finds by pull request. Everyone else finishes the build-context issues from week 8 or the Checkpoint 2 items that are not code (the calibration table, the coarse estimates, the release plan).
45-50	Open the design's pull request and name the teammate who reviews it. It must merge before anyone runs `/implement`, so aim for Thursday.

cd your-team-repo
git switch -c add-workflow-commands
mkdir -p .claude/commands
cp ../course-templates/.claude/commands/design.md ../course-templates/.claude/commands/implement.md .claude/commands/
git add .claude/commands
git commit -m "Add the /design and /implement commands"
git push -u origin add-workflow-commands

Friday Oct 30: build, review, merge¶

When	What your team does
0-5	Confirm the slice's design is merged on `main`. If not, merge it first; nobody builds from an unmerged design.
5-35	The owner runs `/clear`, then `/implement UC-<AREA>-<slug>`. It will stop to propose a refactor if one is needed, and it stops after the trunk commit: read that commit and say what it changed and why before letting it go on. The build will likely run past the hour; that is expected, and the owner finishes it after class. The rest of the team starts the calibration table rows from your activity reports and the Checkpoint 2 items that are not code.
35-50	When the pull request is open, run a fresh-context review first: a new session (`/clear`), then `/code-review` in Claude Code, or on Copilot CLI ask it to review the pull request against the use case and the design's test list. Then a teammate who did not build it reviews the pull request against the use case and the design's test list, marking each row covered or not (how). Apply Monday's testing lecture to each test the agent wrote: what is its oracle, and would it fail if the code were wrong (how). Not open by minute 35: do this in your next team meeting, before your Checkpoint 2 slot.

What you produce: the commands on main, the slice's design merged, and the slice's implementation pull request open or merged by the end of Friday. Your TA is in the room both days to unblock you and takes attendance, which counts as it does every studio; this is not a checkpoint, and nothing else is graded in the room.

When the agent gets in the way. Out of usage: switch to a teammate's laptop and session; the documents are in the repository, so nothing is lost. A command not found: check that .claude/commands/ is on the branch you are on and restart the session. The agent wants to skip a stop or approve its own work: say no, it is following your files, and the stops are in them.

Before your Checkpoint 2 slot: the slice merged, v0.1.0 tagged with release notes, and every item on the checklist ready to show. Book the slot with your TA in your team's Slack channel by the end of Friday's studio.

Week 11, Nov 6: the gate on your repository¶

Objective: by the end of the hour your team's main cannot take a change that fails the build, the tests, or the analyzers. Monday's Static Analysis and Wednesday's CI/CD both land here. Assignment 3 is due at the start of class, and Checkpoint 2 slots run outside class as booked.

Your agent writes it; your team owns it. Most of your projects are not Java, so Project Pulse's files are the example, not a template. Read them as the example of a finished gate: its pull request workflow, maven-build.yml, and the analyzer blocks in its pom.xml. Your coding agent (Claude Code, Codex, or whichever your team uses) proposes the tools for your stack and drafts the workflow. Your team decides what goes in and reads every line before it merges. This is the adapt step, applied to the gate.

Before Friday: if your Checkpoint 2 slot is today and you have not tagged v0.1.0 with release notes, do it first (how).

When	What your team does
First 15 minutes, after attendance	Choose and run the tools. Give your agent the prompt below. Decide as a team which tools to adopt (four tests), run each one in checking mode, and record the counts by rule
Next 10 minutes	The workflow. Read the agent's draft together against the six questions, fix what fails them, correct the comparison table, then open the pull request with the table in its description so the checks run once
Next 10 minutes	Merge the workflow pull request after a teammate approves it. Then the owner creates the "Protect main" ruleset on screen while the team watches, following the eight steps in CI/CD 4.4 (why each rule), and someone tries a direct push to `main` to see it refused
Next 5 minutes	Plant one bug on a branch, open a pull request, and watch it go red with Merge locked. Then, in class if time allows and otherwise before Monday, write a "Static analysis" subsection in section 8.2 of your architecture-of-record: the tools you chose and why, the gate command, and how a finding is settled (what goes where). Add to your charter, citing it: the gate command, "a baseline only shrinks," and "never weaken a check to make it pass without saying so in the pull request." Write the open deployment question into section 7 of your architecture-of-record, with an owner (the questions)
Last 5 minutes	Your TA checks your ruleset and the locked pull request, then points at one line of your workflow and asks any member what it does

A prompt to start from. Fill in the first line, and keep the rest:

Our project is <languages and frameworks, and the folder each part lives in>.
We are adding static analysis to our pull request pipeline.

1. For each part of our stack, propose free tools that run in our own build
   with no account: a formatter, a linter, and a type checker if the language
   has one. For each, say what it catches, why you chose it over the
   alternatives, and its latest release date.
2. Give the command that runs each tool in checking mode, changing no files.
   Run them and report the findings counted by rule. Do not fix anything.
   Stop here and wait for us to choose.
3. After we choose, write .github/workflows/pull-request.yml. On every pull
   request to main, run our build, our tests, and the chosen checks, and fail
   on any finding. Model it on Project Pulse's workflow:
   https://github.com/Washingtonwei/project-pulse/blob/90668c51b83f5352acf8d0f304a46590625cc87c/.github/workflows/maven-build.yml
   One job per part of the stack, every action pinned to a full commit SHA,
   checking commands only (no --fix, no --write), no continue-on-error.
   Use ubuntu-latest, and do not build for a device (no iOS, Android, or
   game export build).
4. Explain the workflow line by line.
5. Draft the comparison table for the pull request description: one row
   per job, with Project Pulse's matching job, the command that fails it,
   and what it does not check.

The comparison table goes in the workflow pull request's description. The agent drafts it; your team corrects it, because "what fails it" and "what it does not check" are where your review shows. For a Flutter app it might begin:

Project Pulse job	Our job	What fails it	What it does not check
`build`: `mvn verify` (tests, SpotBugs, PMD)	`app`: `flutter analyze`, `dart format --set-exit-if-changed .`, `flutter test`	Any analyzer finding, an unformatted file, a failing test	Android and iOS builds (debt row in section 11)
`frontend`: ESLint, type check, Prettier, all `continue-on-error`	None: the Flutter app is our only client
`dockerfile`: Hadolint	None: we do not ship a container yet

What you produce: the workflow, merged through a pull request that carries the comparison table, and the ruleset on main, the red pull request (close it afterward), the 8.2 subsection and the charter lines merged, and the open question in section 7. Your TA takes attendance, which counts as it does every studio; this is not a checkpoint.

When it gets stuck. The workflow goes red on its own pull request: that is the first run telling the truth about findings already in your code. Fix the easy ones with your agent, turn off rules you reject with a reason in the configuration, and baseline only what you cannot finish today (Static Analysis 4.6), so main is green before you plant the bug. A workflow fails with "unable to resolve action": the agent made up a commit SHA, so look up the release's commit on the action's own GitHub page. A check that will not appear in the ruleset: see the end of the steps. Your backend lives in a subfolder: set working-directory on the step, as Project Pulse does.