Summer Build 2026

# Summer Build 2026

Initiative-level planning for the summer platform build: assignment-type expansion, LMS integration, YAWP Reporter, and the team workflow for moving work from prototype to testing to Bryant approval and deployment.

## Meeting

- **Attendees:** Brian, Kevin Gregorio, Bryant Brock
- **Date:** 2026-05-26
- **Granola:** `3fbd5f2d-e409-42bd-b585-fed305edd5cd`
- **Purpose:** Set the vision for the summer build and lock in how Brian, Kevin, and Bryant work together.

This is not a single engineering handoff. It has now split into pillar-specific specs:

- [Central PM system](central-pm-system.md)
- [Assignment creation standardization](assignment-creation-standardization.md)
- [LMS integration v1](lms-integration-v1.md)
- [Yawp Reporter v1](yawp-reporter-v1.md)
- [ACT and SAT writing practice](act-sat-writing-practice.md)

## Summer vision

Summer is the platform-building season ahead of the fall push.

The headline deliverables are:

- Expand assignment types, with a matching tutor and grading assistant for each.
- Integrate YAWP with school Learning Management Systems.
- Build YAWP Reporter so teachers can run class and student reports.
- Tighten the project workflow so specs, PRs, previews, and shipped state stay visible without making Kevin/Brian operate Git.

## Working flow to agree on

The main process question is how work moves between Kevin, Brian, and Bryant.

Proposed handoff stages:

1. **Build:** Kevin prototypes or builds the assignment type, tutor behavior, and grading logic.
2. **Design and test:** Brian defines the pedagogy/content and tests the flow in real use.
3. **Share:** Kevin and Brian pass work back and forth in a visible place, with clear labels for "ready to test" and "ready for review."
4. **Approve and deploy:** Bryant gives final approval and owns production deployment timing.

Decisions to make:

- Where does in-progress work live so all three people can see it?
- What is the cadence: weekly Monday check-in, async updates, or both?
- What is the bar for "Bryant-ready"?
- Who is allowed to flag work as Bryant-ready?
- Who owns deployment timing after Bryant approves?

May 26 operating notes:

- Kevin can keep using `yawp-pm` because it is working for asynchronous spec refinement.
- The pain is not markdown itself; the pain is repo/Git mechanics and split lifecycle state across `yawp-pm` and `yawp-2.0`.
- PRs/previews are the implementation source of truth once a prototype exists.
- A central dashboard/app should pull from markdown + GitHub PRs + previews so status is visible without manually opening both repos.
- Fast previews matter only if seed data lets Kevin log in and test with the expected classes/users.

## Priority 1: Assignment types

Each new type needs three pieces:

- The assignment type itself.
- The tutor behavior for the student writing flow.
- The grading assistant behavior and rubric.

Already in place:

- Five-paragraph essay
- Thesis-driven essay
- Daily Pages

Proposed build order:

1. **AP courses**
   - AP U.S. History
   - AP European History
   - AP English Language and Composition
   - AP English Literature
2. **Test prep**
   - ACT writing section
   - SAT writing section
3. **Stretch**
   - College application essay

Questions to settle:

- First AP type: make the current AP History/APUSH work excellent before switching to AP Lang/Comp.
- How much can AP English, AP Literature, AP European History, and AP U.S. History share?
- Which rubric and tutor behaviors must be custom per type?
- What does "done" mean per assignment type: prototype, Brian-tested, Bryant-approved, or production-piloted?

Related implementation details from the call:

- Assignment creation needs one shared model across dashboard, My Classes, and assignment-type pages.
- Multi-class assignment creation should be available wherever assignment creation is available.
- Teacher-facing tutor context should come out for now; it is too easy to conflict with the curated tutor.
- Assignment type should determine the matching tutor and grading assistant by default.
- Point value belongs on assignments, both for teacher grading display and future LMS gradebook sync.
- Submit-for-grade should default on unless a specific assignment type/product decision says otherwise.

## Priority 2: LMS integration

LMS integration matters for college contracts and is increasingly attractive for high schools.

Early signal:

- The UA pilot runs on Blackboard, so Blackboard is likely an early integration target.

Candidate systems:

- Blackboard
- Canvas
- PowerSchool
- Google Classroom
- Blackbaud

V1 scope questions:

- Which LMS is first?
- Does v1 include roster sync, grade passback, SSO, or only one of those?
- What is the technical lift and implementation risk?
- What does a pilot-ready integration need to prove for UA?

Research direction:

- Build LTI 1.3 / LTI Advantage first.
- Add OneRoster next for roster/gradebook interoperability.
- Use native vendor APIs only where LTI/OneRoster do not cover the flow.
- Canvas is likely the cleanest first technical target; Blackboard is important for higher-ed/UA validation.

## Priority 3: YAWP Reporter

YAWP Reporter lets teachers run reports on classes and individual students using selected fields, such as assignments and date ranges.

Why it matters:

- It may be the single greatest stickiness and moat YAWP can provide.
- It turns accumulated writing and feedback data into a teacher-facing reason to keep using the platform.

Initial reporting filters:

- Class
- Student
- Assignment or assignment set
- Start date
- End date

Report levels discussed:

- Single student, single essay.
- Whole class on a specific assignment.
- Longitudinal student tracking over time.
- District/admin-level analytics and engagement metrics.

Reporter should also support conversational follow-up and instructional coaching recommendations. Fun metrics like word counts, pages written, time spent, and revision volume should be considered because they make the writing work tangible. Prior writing-lessons work may be salvageable here.

Open product questions:

- Which reports are most valuable for a teacher's weekly workflow?
- Should Reporter start as a class-level tool, student-level tool, or both?
- How much overlap should it have with the existing comprehensive student analytics direction?
- What data can teachers export or share?

## Next steps

- Confirm owner and rough timeline for each pillar.
- Set a weekly Monday check-in.
- Hold the Monday 1:30 PM Central / 2:30 PM Eastern summer check-in unless Kevin's work constraints require a change.
- Split this initiative into separate specs for assignment-type expansion, LMS v1, YAWP Reporter v1, and the central PM system.
- Define the Bryant-ready bar for summer work before the first prototype is handed off.
- Fix preview seed parity so fast PR previews are actually usable by Kevin.

## Engineering handoff checklist

This initiative is not ready for engineering as a whole. Each downstream spec should clear the normal PM handoff bar before implementation.

- [ ] Domain context covered
- [ ] File paths in `yawp-2.0` listed
- [ ] Data model implications spelled out, including backward-compat plan
- [ ] UX sketch in prose
- [ ] Edge cases enumerated
- [ ] Test plan written
- [ ] Rollout plan decided