Reusable Sprint 2 prompts

Use one feature prompt at a time with the common context. Give a model access to all three repositories, or attach relevant files; a model without files cannot honestly audit their current implementation. Do not paste environment secrets. Assign separate branches/tasks to teammates to avoid overlapping edits.

Common context to copy

We are building Toodle for Wits COMS3011A: a Tutor Management System.
Read PROJECT_CONTEXT.md, the actual Git changes, and toodle-docs/docs/project/
sprint2-audit.md and course-workflow.md before changing code. Verify their claims
against source. Repositories: Toodle (React/Vite/Auth0), toodle-api
(Express/Prisma/PostgreSQL/Auth0), toodle-docs (MkDocs). Preserve existing work.

Sprint 2 weights: core 25%, UI/API automated tests 10%, stakeholder reviews 10%,
externally available documented API and integration 15%, formal user feedback
and integrated fixes 10%, methodology 10%, bug tracker 5%, database docs 5%,
third-party code docs 5%, testing docs 5%.

Organisers manage courses and assign qualified tutors from a single board.
Qualification depends on verified course marks, timetable compatibility and
remaining weekly hours, visible before saving. Students/tutors can apply for
regular courses; overflow volunteering is separate. Tutors log/submit timesheets
and excuse themselves; organisers review these workflows. Google Calendar and
email APIs belong to another developer: preserve existing Brevo code and define
integration contracts without implementing that teammate's work.

Use existing components/services and server-side role/ownership checks. Finish
the bounded task with meaningful UI/API tests, error handling and current docs.
Report changed files, executed commands/results, remaining risks and manual
acceptance steps. Never invent stakeholder feedback, deployment success or tests.
Do not reset shared data or modify deployed migration history to hide conflicts.

Task: [paste one task below].

1. Connect and release the existing application — P0

Resolve Toodle's environment/deployment readiness. Read connection-recovery.md
and prisma/check-connection.js. The original application migration was recovered
with exact database checksum; all seven migrations are applied and schema diff
is empty. Preserve the restored LF migration and keep the superseded SQL outside
migrations. Prisma maps reason to reviewReason and CourseApplicationStatus to
ApplicationStatus; motivation is required. Deploy the prepared Vercel proxy
rewrite and current API/frontend workflows from the agreed release branches.
Verify frontend API base URL, Auth0 audience/domain/callbacks, CORS, generated
client, health and authenticated requests. Run the three-role acceptance script
against agreed test accounts. Deliver a reproducible startup/deploy runbook and
actual evidence; identify precisely any access still required.

2. Finish allocation-board correctness — P0

Audit AllocationContext.jsx, AllocationBoardPage.jsx and allocation/session
services. Make active staffing and remaining hours exclude removed/pending
allocations consistently while keeping pending assignments visibly labelled.
Revalidate every status/hours mutation server-side, preserve audit history and
enforce lock semantics. Align the frontend lock action with the API validator.
Handle stale validation, duplicates and concurrent capacity changes. Keep inline
mark/availability/clash/hour feedback and mandatory override reasons. Explain
the current advisory/manual versus strict-application policy and implement any
change only from an agreed stakeholder rule. Test stale updates, over-capacity,
unverified marks, inactive counts and keyboard/mobile assignment.

3. Timesheets from work log to sign-off — P0

Inspect existing TimesheetsPage and API before extending them. Verify a tutor can
log work against their assignments, edit drafts, submit a weekly timesheet and
see deadlines/status. Organisers must approve, return corrections or dispute
with reasons; enforce valid transitions, ownership and immutable approved data.
Verify payroll CSV values and prevent duplicate/overlapping entries as defined
by the team's rules. Add useful API/UI workflow tests and document transitions,
payroll format and acceptance evidence. Coordinate notification events with the
email developer without implementing email delivery.

4. Excusal and overflow volunteer workflow — P0

Trace existing excusal, overflow-post and overflow-claim code end to end. A tutor
requests excusal for their own dated session; an organiser reviews it; eligible
overflow work becomes discoverable; a student claims it and an organiser reviews
the claim. Prevent duplicate claims/approvals, double staffing, wrong-owner
changes and invalid terminal transitions. Explain whether posting overflow is
automatic or an organiser decision. Test the linked browser/API journey and
concurrent claims with PostgreSQL. Keep regular course applications distinct.

5. Sprint evidence and testing — P0

Create a rubric-linked evidence index from actual repository and team records.
Run meaningful UI/API suites, add browser E2E tests for the three main roles and
isolated PostgreSQL tests for course-application approval concurrency/rollback.
Document commands, fixtures, environments, skips and CI failure policy. Prepare
a formal feedback script/form and stakeholder review agenda; integrate supplied
real feedback into issues and fixes. Link tracker issue to commit, test and
retest. Update stale MkDocs testing/roadmap/tech-stack claims. Clearly separate
planned, locally tested and deployed evidence; never invent meetings or results.

6. Public API and teammate integration contract — P0

Document implemented routes with OpenAPI, auth instructions, roles, request/
response examples and errors. Demonstrate external authenticated consumption
with agreed test credentials and publish the correct base URL. Preserve Google
Calendar/email ownership. Agree assignment/session/review/deadline event payloads,
identifiers, Africa/Johannesburg timezone handling, idempotency, retries and an
observable failure path with that developer. Add contract tests for these
boundaries without taking over provider OAuth or delivery implementation.

7. Candidate ranking and safe bulk suggestions — P1

Build on the shared eligibility validator. For each course rank eligible tutors
using verified marks, available hours and workload fairness. Show why each tutor
is eligible or excluded. Let organisers preview a deterministic bulk proposal,
adjust it and accept selected assignments. Preserve locked assignments, show
unfilled courses, revalidate on commit and avoid partial/inconsistent writes.
Document scoring and tradeoffs; test scarce tutors, tied scores, no feasible
solution, locks and conflicts. Do not call this a globally optimal allocator
unless the algorithm and tests establish that property.

8. Database and third-party documentation — P0/P1

Generate an accurate schema reference from Prisma with entities, fields, keys,
relations, indexes, workflow enums, retention/deletion policy and deployment/
recovery instructions. Reconcile migration documentation with actual history.
Inventory dependencies from both package manifests/locks and docs requirements:
exact resolved version, official source, verified licence, purpose, why selected
and where used. Include attributed copied code/assets separately. Backend uses
Vitest/Supertest, not Jest. Do not claim licence verification without checking.

Model choice

My suggested allocation of work: GPT-6 Astra or GPT-5.6 Sol for migration reconciliation, transactions and difficult cross-repository reviews; GPT-5.6 Terra for a bounded UI/API feature; GPT-5.6 Luna for clearly specified documentation inventory and summaries, with human verification. This is task-fit advice, not a benchmark result. Availability depends on the account/client. See the official model guidance, checked 14 September 2026. The prompts are model-independent and can also be given to another coding assistant with repository access.

Do not spend this sprint implementing the entire advanced brief. Stabilise P0 flows and assessment evidence first. Draft comparison, collaborative editing, whole-school optimisation and historical restoration belong in separate later tasks unless the stakeholder explicitly prioritises them.