# Setup Guide

How to stand up this whole system from scratch, or reproduce it if you're starting fresh.

## 1. Website files

Upload these to your web host, preserving the folder structure exactly:

```
your-site/lessons/
├── index.html
├── day.html
├── policies.html
├── ask-a-question.html
├── guide.html
├── test.html          ← optional; internal tool only, safe to omit from a live deploy
├── js/                 ← all files
├── css/                ← all files
├── labs/               ← standalone lab tools (separate system - see §6 below)
│   ├── js/lab-certificate.js
│   └── css/lab-certificate.css
└── documents/          ← reference docs, not part of the live site itself
    ├── SYSTEM_REFERENCE.md
    ├── README.md
    ├── SETUP.md
    ├── PROJECT_KICKOFF.md
    └── Code.gs
```

No build step, no dependencies to install — everything is plain HTML/CSS/JS, loaded directly by the browser. External libraries (Google Fonts, and nothing else client-side) are loaded via `<link>`/`<script>` tags pointing at public CDNs.

## 2. The Google Sheet

Create one Google Sheet with the following tabs. Exact tab names don't matter to the code (each is referenced by its published URL, not its name), but **column headers matter** — the code reads them by name after lowercasing/trimming.

| Tab | Required columns (row 1, exact spelling) |
|---|---|
| Pacing (merged, all 3 courses) | `course, day, date, weekday, term, unit, topic_activity, day_type, learning_objective, essential_knowledge, mapping_note` (+ optionally `possible_lab_project`, and Cybersecurity-only `scenario, hands_on_activity, hands_on_note`) |
| Daily content | `course, day, widgetname, field_a, field_b, field_c, field_d, notes` |
| Vocabulary + Cheat Sheets (merged) | `type, course, category, term, description, example` |
| FRQs | `course, unit, question, excellent student response, weak student response` |
| Quiz Questions | `course, unit, question, option_a, option_b, ... option_h` |
| Resources | (see `renderResources()` in `index.html` for exact fields) |
| Terminal Steps | `step_id, label, command, arg, require_arg_match, require_cwd, notes, fs_template` |
| Classroom Rules | `rule` (one column) |
| General Messages | `date, message` |

Plus, for the star/rank/help-queue system (see §4 below), tabs named exactly: `rank_titles`, `bulletquestions`, `help_queue`, `roster`, `star_log`, `star_totals`, `student_work`.

`student_work` is created automatically the first time a lab tool logs a grade (§6) — no need to pre-create it, but it must exist in the same **private** spreadsheet as the other backend-only tabs.

## 3. Publishing tabs to the web

For every **public** tab (everything except the last four listed above):

1. **File → Share → Publish to web**
2. Choose the **specific tab** in the dropdown — never "Entire Document"
3. Format: **Tab-separated values (.tsv)**
4. Click **Publish**
5. Copy the resulting URL — it looks like:
   ```
   https://docs.google.com/spreadsheets/d/e/{long-id}/pub?gid={GID}&single=true&output=tsv
   ```

Paste each URL into the matching constant at the top of `index.html` or `day.html` (see the comment block above each `SHEETS`/`*_TSV_URL` constant for which URL goes where).

## 4. The backend (student help queue, stars, ranks)

`Code.gs` is a Google Apps Script, deployed separately from the website:

1. Open **Extensions → Apps Script** from the same Google Sheet
2. Paste in `Code.gs`
3. **Deploy → New deployment → Web app**, execute as yourself, accessible to "Anyone"
4. Copy the deployment URL
5. Paste it into the `API_URL` constant at the top of `ask-a-question.html`

This script reads/writes the four private tabs (`help_queue`, `roster`, `star_log`, `star_totals`) directly via the Sheets API — **never publish these four to web**, since they hold live per-student data.

`rank_titles` and `bulletquestions` are also read by this script (not via a published TSV), even though they may sit visually alongside the public tabs in your sheet's tab bar.

## 5. Testing before going live

Use `test.html` — it demonstrates every widget with hardcoded example data, useful for confirming a code change didn't break anything, without needing real spreadsheet data. It's not linked from anywhere on the live site and doesn't need to be uploaded to a public-facing host if you don't want it reachable.

For testing real spreadsheet-driven content, use `day = -1` in the daily content tab — reserved specifically for test rows, never used on a real lesson day.

## 6. Lab tools (`labs/`)

A separate system from everything above (see `SYSTEM_REFERENCE.md` §9 for the full explanation) — standalone, hand-built lab tools rather than spreadsheet-generated pages. Setup-wise, all it needs beyond what's already deployed in §4:

1. `labs/js/lab-certificate.js` and `labs/css/lab-certificate.css` are already deployed via the file upload in §1 — nothing extra to install.
2. Each lab's own HTML calls `PCSCertificate.render()` with `webAppUrl` set to the **exact same** deployed Web App URL used everywhere else (the `STAR_API_URL` constant in `js/student-id.js`) — don't create a second Apps Script deployment for labs.
3. `Code.gs` already includes the `log_student_work` action and auto-creates the `student_work` tab on first use — no manual sheet setup required, same as `star_log`/`star_totals`.