Home

Owner: Kelly Ballinger, Avery Smith, Sasan Pourassef, Jazzmyne Nixon | Last updated: 2026-03-09 | Status: Completed

Start Here

This wiki is the single source of truth for the project. Keep this Home page current; everything else hangs off it.

Tips that keep wikis useful: One-page "Start Here" stays current; everything else hangs off it. Owners + "Last updated" at the top of each page. Link to single source of truth (boards, repos, dashboards) – don't duplicate anything. Short ADRs, often – Architecture Decision Records (ADRs) tiny notes that capture an important technical decision, the context, and the consequences. 5–10 minutes each saves hours later. Links to demo scripts – double as acceptance tests and presentation prep.

REQUIRED: Must-have wiki pages (if applicable to your project)

• Project Overview & Goals
  • A one-page summary of the problem, who benefits, and what “success” looks like (a short demo checklist works well). This anchors the team and gives graders a clear lens for evaluation.
• Team Standards for Development
  • A concise summary of the most important working rules for your team, especially as they apply to development. Should cover:
    • Team Communication Standards – Concise summary of 461 policy. Update if necessary.
    • Coding Standards – language/style guides, linting, formatting, comments, etc.
    • Testing Plan & How to Run Tests – What you test (unit, integration, manual checks), test data, and how to run everything.
    • Branching & Release – git flow, versioning, tagging, release checklist.
    • Coding Review – when and how is code reviewed, using pull-requests, formal review sessions, pair-programming, etc.
    • CI/CD – policy and pipeline overview, who builds what and when, what runs where.
• Requirements & Scope
  • Your key project requirements in condensed form. Include any important user stories, features or detailed specifications, metrics (e.g., responsiveness, reliability, projected number of users), project risks, plus links to important resources (Requirements Doc). Keeps the project feasible and ties testing back to intent.
• System Design (with diagrams)
  • The big picture: main parts, how they talk, data flow, key assumptions, and links to important resources (Design Doc). Builds a shared mental model so teammates and reviewers can follow your design.
• Developer Setup & Project Conventions
  • Step-by-step: how to get the code, set it up, run it, and where things live in the repo. Reduces setup time for new contributors and TAs and avoids “works on my machine.”
• Decision Log (short design notes)
  • Small entries with: the question, options, the choice, and why (date + owner). Prevents re-hashing old debates and shows your reasoning to graders.
• Release Plan & Notes (milestones/demos)
  • For each milestone: what’s new, how to try it, and known issues. Helps you plan demos, communicate change, and track progress over the term.
• Handoff, Reflection, and Future Work
  • Limits of the current build, “if we had two more weeks,” and tips for the next team. Shows thoughtful reflection and sets up continuity.

Recommended pages

• Deployment Guide – prod/staging setup, environment variables, provisioning steps.
• User Guide – user guide and walkthrough.
• FAQ – The beginnings of a knowledge base.

Demo checklist (definition of success)

• User can sign in and access protected studio pages
• User can create, view or edit a card without errors
• Saved deck loads correctly in playtest page
• Player can complete core actions such as playing a card and ending a turn
• AI opponent takes a valid turn with basic draw and play behavior
• Action log correctly updates during gameplay
• Match runs end to end without crashes or broken routes